Developers of Sympa

[Guillaume Rousse <address@concealed>]

Le 22/10/2013 14:40, IKEDA Soji a écrit :
> > > We need to issue a Sympa version, or the project will be in a very bad
> > > shape.
> > That seems indeed a good idea, but I think it's suicidal to consider the
> > current content of sympa-cleanup branch as a viable solution to produce
> > even an alpha release: the code doesn't even compile, and is a ugly mix
> > between one year of parallel development.
>
> I agree.  Additionally, I have wished that the development style of
> Sympa would gradually approach to "continuous integration" practice:
>
> By relatively short periods (e.g. several months), repetitive
> regular releases will be issued.  No matter what each release is,
> it may always contain some improvements or fixes.  That's good
> enough, isn't that?
Sure, and that's what I tried to do by introducing unit tests in 
sympa-cleanup branch, before introducing code refactoring.

> To reach such stage, we will have to overcome a number of problems.
> Although, I would like you to note my ambition.
>
> > For me, the viable solution would be to use as base either:
> > a) sympa-6.2 branch, for new features
> > b) sympa-cleanup before the merge, for code readability
> >
> > And once one branch chosen as base, eventually replay some of the
> > changes introduced in the other progressively, using the minimal test
> > suite to catch regression after each commit.
> >
> > Given most of my initial changes were purely syntactic ones, easy to
> > replay mechanically, and than I never even attempted to actually run my
> > code outside of unit tests, I really think we should use sympa-6.2 as base.
>
> As I said, I had privately replayed your changes.  In so far as
> syntactic changes and relocations, it may be relatively easy: It may
> be done in a month.
File relocation, subversion metadata harmonisation, file content 
correction, headers consistency enforcement (once content decided): one hour

Fixing code layout (indentation, spacing, etc): one hour.

Transfering all Sympa code to a Sympa:: namespace: one hour.

Turning all methods and functions calls to fully-qualified syntax: one hour.

Sorting import statement, dropping useless ones, adding needed ones: one 
hour.

Basically, all of this can be achieved in one day work.

What takes times, tough, is to gradually refactor functions and methods 
prototypes, and split modules, to reduce cross dependencies, and reach a 
testable state. One week, eventually, but definitively not one month. 
And even less, if everyone concurs in the same direction, instead of 
following its own agenda.

> However, I regret to say that we might not commit anything new to
> repository, while we had not had common perspective of development,
> coding and modularization.
>
> Conway's “Perl Best Practices”(«De l'art de programmer en Perl»)
> suggested by David seems ideal basis of our mutual understanding.
> IMHO it is rather the book on psychology than programming: It
> accurately points out many psychological traps all programmers are
> fallable [*].
>
> Conversely, if you had not finished reading this book, even if we
> agreed on all other issues, we have not made consensus, Guillaume.
>
> Please inform us when you have finished reading (or if you have not
> begun, when you began, too).
Thanks for your suggestion, I already read it, quite a long time ago. 
But this is still a book, not a bible. And achieving conformity is not 
an objective in itself. As well as trying to adhere to perlpodstyle man 
page, or FSF Howto on how to correctly use GPL.

Now, the main debate is not wether to look for conformity or not (I 
think we all agree), but wether this is a priority or not. And if this 
conformity prevails over any other kind of consideration, such as for 
instance the technical level needed to understand the changes involved.

Currently, we are four people (5 including Marc) involved in Sympa 
development, with various level of understanding. It is a very limited 
workforce pool, especially given target audience. I'd rather incriminate 
the very-low readability of the current code base, due to various issues 
such as:
- misuse of casual programming techniques such as object-orientation
- abuse of developers-only concepts such as 'Robot' objects
- dead and redundant code all over the place
Etc...

Solving this readability issue first, while limiting the added technical 
complexity, is my own priority. And I'd rather turn the current 
discussion toward comparing our priorities, instead of patronizing 
"please read those book" advices.
--
Guillaume Rousse
INRIA, Direction des systèmes d'information
Domaine de Voluceau
Rocquencourt - BP 105
78153 Le Chesnay
Tel: 01 39 63 58 31

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