Developers of Sympa

[David Verdin <address@concealed>]

Dear all,

Le 08/11/13 04:19, IKEDA Soji a écrit :

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.

That's the spirit, yes.

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.

Point of view we agree with. I agree with all the benfits you pointed.
CPAN registration is a very good point, I think but we can do it progressively. that's why I said 'it is not a pressing matter'.
Our aim now is to make the Sympa code consistent, testable and desintricated. Then we'll be able to port to CPAN.

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

So that you'll be able to read HTML mails. Understood.

Regards,

--- Soji

--
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