Developers of Sympa

[David Verdin <address@concealed>]

Hi,

Le 19/12/12 20:31, Marc Chantreux a écrit :

On Wed, Dec 19, 2012 at 05:35:51PM +0100, David Verdin wrote:

There is a gap between what we perl developpers consider as normal
sysadmin practices, and real world practices. And it has to be
balanced against the added value of additional dependencies if you
want to target real users. Here, that's clearly overkill.

I agree with guillaume here. Even though I appreciate CPAN as a
provider of all-purposes modules, we had a lot of reports overs the
years of failed installation due to problems with CPAN.

I really miss this point: what is complicated in installing largely
tested CPAN packages like Package::Stash ? 

Nothing for this one in particular; I don't know it.
My point was: we want to have good guarantee, when adding a new dependency, that it will not add any more trouble to install process.
An other point may be: as scattered as we can be, geographically speaking, we sill work on the same project. that means we are a team and it is important that we can work together. My Perl culture (and Étienne's) is less important than yours, though we need to be able to understand and manipulate your code. If the code becomes too abstract, it will become difficult for us to work with you. I don't know what we can do with Package::Stash, but I'd like to understand it before we start using it.

Sysadmins just don't have the time to play with modules.

and they really don't need (as soon as sympa is shipped correctly with some
recommendations about deployment). maybe i should help here ? 

Likely. :)
I just had a speech with Mark Overmeer that you may or may not know (his CPAN profile is: http://search.cpan.org/~markov/).
He is working on the VOOT protocol(https://github.com/andreassolberg/voot/wiki/Protocol) in Sympa for Surfnet (the Dutch national reserach and educational network).
He strongly support the idea of a Sympa bundle, too. he suggested that such a bundle should contain Sympa-specific tests. I'm not sure what it means exactly, but I suppose it would replace (or at least make a big part of the job of) the current sympa_wizard.pl.

The easier it is to install Sympa, the better.

right! (as i said: i'm in charge of those stuff at unistra). my dream
is to tape "cpan install Bundle::Sympa" from the shell to be sure that
all the sympa related perl stuff is ready to run.

That's where you lost me. However, as much as I appreciate Marc's
enthusiasm in participating to the projet, I again agree with
Guillaume. We have a lot of things far more crucial than discussing
development choices that were made 10 years ago. They are here and
we must deal with them.

Just to be clear: adding dependencies is not a goal but if i come to
rewrite some code, i clearly prefer to write no code at all just using
the existing stuff.

maybe you should have a chat with some koha developpers for exemple:
they have exactly the same problems: 

* old and large codebase
* "real world" sysops

and they are comming back to the "staying away from CPAN" strategy which
is now one of the first reasons of koha bug tracking activity.

Well, we use CPAN. For functionnalities (DKIM, Oauth, etc.).
It's a balance: we use CPAN for a benefit, we stay away from it when we feel our code is specific and doesn't require CPAN.

ONCE Sympa 6.2 is beta, and we have merged Guillaume'work, we will
have a lot of quiet time to discuss these topics.

sure: i wasn't trying to change everything and i'm just too young in the
project to have any good vision of what must be done. i just pointed to
a module that can avoid an AUTOLOAD strategy as i just read about it
used in sympa.

Being young is not a default. Actually, Guillaume improved Sympa greatly probably because he had a fresh eye on the code.
Just be ready: I'll probably ask a lot of dumb questions when you discuss advantages / disadvantages of specific variants in Perl coding. That's the way I learn... ;)

regards 
marc 

Attachment: smime.p7s
Description: Signature cryptographique S/MIME