Developers of Sympa

[David Verdin <address@concealed>]

Le 05/11/13 02:56, IKEDA Soji a écrit :

Guillaume,

When you will begin and finish your work on step 2?

 2. Guillaume does the organizational changes he suggested: moves to
    Sympa namespace, identation fixes, etc. These are the "one day long"
    operations he suggested yesterday. He can also add the two minimal
    tests he mentionned to ensure non regression when fixing a bug.

We including you had agreed to David's proposal.  I'm watching when
you put your agreement into practice.

After a short conversation with Guillaume, he intends to do it as soon as his other missions lets him the time to do it.
Afterwards, we'll be able to install the 6.2 on our production server, then release a beta.

Cheers,

David

Regards,


--- Soji

On Mon, 04 Nov 2013 17:21:10 +0100
Guillaume Rousse <address@concealed> wrote:

Hello.

Le 03/11/2013 03:50, IKEDA Soji a écrit :

Hi,

Guillaume's new directory layout seems to have a bit more room for
improvement.  For example subdirectories under src/ may be moved to
top level.

Also expecting registration to CPAN, I drafted a modified layout.

The desirability of such registration has never been discussed sofar. 
Altough I don't have any actual objection, I don't see much interest:
- sympa does not belong to the primary target of CPAN (it is an 
application, not a reusable perl library)
- sympa doesn't use ExtUtils::MakeMaker or Module::Build build system, 
meaning cpan clients won't be able to install it

And even if desirable, there is no constraint on internal archive 
structure.

--------------------------------  ------------------------
Current layout                    Proposed
--------------------------------  ------------------------
doc/                              doc/
ext/                              ext/ --- Be separate modules in the future.
mail_tt2/                         default/mail_tt2/
po-wwsympa/                       po-wwsympa/
po/                               po/
src/bin/sympa.generic             sympa.generic
src/bin/sympa.in                  sympa.in
src/bin/            [OTHERS]      bin/  or  script/ [std]
src/cgi/mime.types                default/mime.types
src/cgi/            [OTHERS]      libexec/
src/etc/                          default/
src/lib/                          lib/ [std]
src/sbin/                         sbin/  or bin/ [std]
src/soap/sympa.wsdl               default/sympa.wsdl
src/soap/sympa_soap_client.pl.in  bin/  or /srcipt/ [std]
src/soap/sampleClient.php         ? --- May be moved to contrib.
src/soap/           [OTHERS]      libexec/
src/www/                          www/
t/                                t/ [std]
web_tt2/                          default/web_tt2/
--------------------------------  ------------------------

Note: "[std]" indicates (approximately) standard source layout with
ExtUtils::MakeMaker.

Resulting layout will become:

--------------------------------
bin/  or  script/ [std]
doc/
ext/
default/
lib/ [std]
libexec/
po-wwsympa/
po/
sbin/  or  bin/ [std]
t/ [std]
www/
--------------------------------

I fail to see much advantage here in flattening the archive so much. And 
I even see a disadvantage, as it make usage of command-line tools as 
'grep' of 'find' more difficult: you have to either specify multiple
directory targets, or filter out more noise in the output, whereas 
having all source code files self-contained in a single directory is 
much more practical.

I'd rather go the opposite way, and also try to make template and 
translation files isolated in their own respective hierarchies:
├── po
│   ├── mail
│   └── www
└── templates
     ├── mail
     └── www
This would first unclutter the top-level directory, make the content of 
those directory more self-explanatory, and enforce consistent naming for 
related content.

I'm also interested, in redistributing executables in a more logical 
manner between the two current 'bin' and 'sbin' directories. Or to 
rename them differently, if their purpose was just to distinguish 
between core components, and auxiliary tools.

The whole notion of 'standard layout' is biased here. Just because Sympa 
is written in Perl doesn't mean than every common practice in the Perl 
world automatically applies. Especially practices related to the 
distribution of general-purpose perl libraries.
-- 
Guillaume Rousse
INRIA, Direction des systèmes d'information
Domaine de Voluceau
Rocquencourt - BP 105
78153 Le Chesnay
Tel: 01 39 63 58 31

--
A bug in Sympa? Quick! To the bug tracker!

David Verdin Études et projets applicatifs
Tél : +33 2 23 23 69 71 Fax : +33 2 23 23 71 21   www.renater.fr	RENATER 263 Avenue du Gal Leclerc 35042 Rennes Cedex

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