Developers of Sympa

[David Verdin <address@concealed>]

Hi Guillaume,

Le 18/12/12 16:26, Guillaume Rousse a écrit :

address@concealed">Hello guys.

I think my branch is reasonably ready to merge. I reached my first milestone, and I'd prefer to first sync with other's work before pursuing API cleanup.

Great!
Is it your version of a Christmas present? ;)

address@concealed">
Here is a quick resume of what was achieved sofar:

* Source tree cleanup
All subdirectories containing code (soap, wwsympa, src) are now contained in a single directory (src): this makes grepping for code usage far easier, for instance.

Very good. This separation did no longer make sense: several functions are shared amongst different interfaces.

address@concealed">
This source directory is also more logicaly structured, with less depth: web content is now in src/www/js, for instance, instead of src/etc/scripts/js

That will simplify the understanding of the sources structure. The src/etc directory was a bag-of-many-things and even I was never sure of where the files were.

address@concealed">
Most files and directories there now have consistent svn properties (svn:eol-style, and svn:keywords), and consistent file headers (including vim and emacs modelines).

It's good. I don't think anybody codes Sympa from a Windows platform but forcing the eol style is a good thing.
What do the modelines do? (I abandonned emacs last year, when I discovered geany).

address@concealed">
* Namespace usage
All perl packages now use a shared top-level Sympa:: namespace, some of them using nested namespaces (Sympa::Tools for what was previously the tools package, Sympa::Datasource for data sources, etc...)

address@concealed">
All lowercased package names have been converted during the merge: tools is now Sympa::Tools, for instance.

Some packages have been renamed in the process, to ensure consistency and drop useless Sympa prefix. For instance, TT2 is now Sympa::Template, for consistency with Sympa::Template::Compat. And SympaSession is now Sympa::Session.

address@concealed">
I'm not sure about Marc and Marc::Search, tough. Are they Sympa-specific piece of codes, or already existing code just bundled to avoid a dependency ?

As far as I remember, it is not Sympa specific code, but it is bundled because of some tweakings the original authors made in it a long time ago.

address@concealed">
* Packages import cleanup
Unused packages have been removed from import lists.

That must have been a pain... Thanks!

address@concealed">
Remaining ones have been sorted, with distinct list for Sympa packages and external ones.

Usage of compile-time vs runtime loading have been sanitized, with runtime loading restricted to optional modules, or breaking cross-dependencies.

Good thing. This will prevent failures for missing modules that are not actually used... It happenned before.

address@concealed">
* Packages export cleanup
No package export anything anymore, and all usage of external subroutines/variables always use fully-qualified name.

I'm a little fuzzy on this: Does it mean that, to access data in a module, we need to use accessor subs (get_something, instead of Module::something) ?
I think it would make sense as it gives us good opportunities to catch exceptions at the root.

address@concealed">
* Generalisation of strictures usage
All packages now use strict.

No kidding? Did you also achieve the impossible, i.e. using strict in wwsympa.fcgi? ;-)

address@concealed">
* Interdependencies cleanup
The large tools package have been splitted in multiple ones: Sympa::Tools::File, Sympa::Tools::Time, etc... This allow to leverage dependencies issues, including circular ones.

Many subroutines requiring direct access to Sympa::Configuration have also been modified to receive required values as parameters, allowing to break more circular dependencies. This also make them more modular, and easier to tests.

Indeed.
We inscreasingly use objects, which most of the time carry their own parameters, making method calls easier - most of the time, the fucntions I create don't use parameters at all). So parameters will probably be used only for utility modules sucha as mail.pm, and the offspring of late tools.pm. So the increased attention required to call functions using parameters instead of config will remain restricted to few areas of the code.

address@concealed">
As a result, all packages can now be loaded separatly...

Great! It will be so easier now to use them.
We'll need to be carefull when adding new code, now, to prevent creating new interdependencies. Maybe this could be tested by the continuous integration tool (see below)?

address@concealed">
* First pass at documentation cleanup
Most existing comments have been converted to POD format, using a consistent template.

Good. How would you formally describe this template (so that we can start using it and, hopefully, dissert for a long time about its pertinence, which is one of the big joys of being a developper)?

address@concealed">
A few undocumented functions/methods have also been documented.

Yes, that's also a default we have... Most of the time, we document subs after we develop them. And somtimes we forget.

address@concealed">
* Initial test suite
We now have some tests in the t/ subdirectory. Most of them are simple automated tests (compilation test, pod syntax check, etc...) which just brings minimal quality testing. They are also a few actual functional tests for some functions defined in the Sympa::Tools hierarchy.

Great. We now have a continuous integration platform on Sourcesup (Hudson). I will start searching how to set it up correctly for Sympa and how to use your test suite.

address@concealed">
Indeed, that's quite a lot of changes, rather invasive. I just tested installation and sympa_wizard usage so far, and I was rebuffed by not-so-clear error messages while trying to launch daemons :) Should I continue those tests further, and ensure my branch is sane, or can we first try to merge it in its current state with other branches before testing and stabilizing the result ?

Well, there are conflicting constraints, here.

I think that, when we merge, I should do it, because I have a good knowledge of most of the new code and I would just have to see where it must fit in the new organization.
I also think we should merge first. Our own modifications will certainly break things in your code but it's not a big deal as you work on a pure development branch, with no production deadline. We have all the time we want to make it work.
But I also have a lot of stabilization work to do in the 6.2 to be able to put in production in January (one month later than expected already). So I won't be able to handle the merge before the holidays.
Then, if you have time to spend on Sympa before the beginning of January, it's probably better to spend it stabilizing the sympa-cleanup branch. at least, you could fiw the bugs coming from your own work, they are often easier to find out. I just hope you won't have to work on parts of the code that are no longer valid because Soji or I radically changed this part.

All in all, it's good to see that you reached this milestone. We have now a cleaner, better organized code and this is a very good omen for the future of the project. Thanks again for you efforts!

On another note: When discussing with Marc yesterday, he mad two suggestions:

1. take the occasion of the incoming Sympa formation we organize next spring to make a Sympa hackfest. we stay a few more days on the formation location and spend these days coding.
2. help us organizing the Sympa days. He is in charge of prospective in his university and consequently has access to ressources to help free software communities. We have these Sympa days in mind since a while now and I think it could be usefull. The idea would be to gather users to share experiences on the software. It could also addresse developpers. Nothing formal: just the users, us and people willing to share their own particular usage of Sympa. We could probably find money to make Soji come (if he is interested of course).

These are longer term projects than our current questions regarding coding, of course.

Best regards,

David

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