Developers of Sympa

[IKEDA Soji <address@concealed>]

David, Guillaume and all,

On Thu, 07 Nov 2013 15:55:00 +0100
David Verdin <address@concealed> wrote:

> Hi Soji,
> 
> Le 07/11/13 01:07, IKEDA Soji a écrit :
> > On Wed, 06 Nov 2013 16:45:05 +0100
> > David Verdin <address@concealed> wrote:
> >
> >> Hi,
> >>
> >> Le 04/11/13 17:21, Guillaume Rousse a écrit :
> >>> 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.
> >> Are you talking about the trunk or the 6.2 branch?
> >>>> 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.
> >> To sum up: we need to have a correct modularization and get rid of
> >> circular references.
> >> If this leads to porting some modules to CPAN, it is potentially
> >> interesting. But this is not our current priority.
> > "_Also_ expecting registration to CPAN", I wrote.  Expecting it
> > just results the name of a few directories.
> I think we agree on this. I just wanted to catch the occasion to precise 
> my exact thought about CPAN. I'm all for moving modules to CPAN if it is 
> udeful to the community.

This is digressive comment.

For example, I have been trained not to use HTML "richtext" mail.
This is due to the belief that plain text is most portable format
(and partly due to insecure implementation by popular Microsoft
MUAs).  So, I perplexed when I found that Sympa slightly gives
weight to HTML mail.  However, I hadn't wanted to persist removing
such features.  In fact, they are very meaningful feature for
some people.

I would like not to decide something I haven't understood well
being insensible, as much as I can.

                              *

Registering CPAN includes some levels of improvement (or,
possiblly degression for anyone...).

When Sympa will have been sufficiently modularized, I prospect, it
will become nearly a module with thin skin of executables.  Perhaps
somebodies disagree to me, but it is not so unnatural for me to
registar Sympa in the future to CPAN.

Attempt to register to CPAN encourages some standardizations.

- Installation procedure using Makefile.PL is familiar with
  many Perl users.

- ExtUtils::MakeMaker (or similar modules) will simplify some
  process to build, test or install the application.
  E.g. If modules are in lib/ directory and each test cases is in
  t/ directory, "test" target with test harness will automatically
  be added into Makefile.

- Additionally, we will no longer depend on autoconf/automake
  framework.  Actually, we need it just to determine locations
  of C compiler, some system tools and Perl itself.

- We can benefit with CPAN testers on various platforms.
  Currently, our scope tend to incline to Linux and MySQL.

Note that I don't insist to register Sympa to CPAN as soon as
possible.  I showed my point of view.


To return to subject, I'll respond to David's comment in next post.
I have to install Thunderbird :-).

Regards,

--- Soji

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