Developers of Sympa

[IKEDA Soji <address@concealed>]

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.

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
> 


-- 
株式会社 コンバージョン  セキュリティ&OSSソリューション部   池田荘児
〒231-0004　神奈川県横浜市中区元浜町3-21-2 ヘリオス関内ビル7F
e-mail address@concealed  TEL 045-640-3550
http://www.conversion.co.jp/