Developers of Sympa

[Guillaume Rousse <address@concealed>]

Le 04/01/2014 02:11, IKEDA Soji a écrit :
>               He's murdering the time! Off with his head!
>
>                                                  --- Queen of Hearts
>
> Guillaume and all,
>
> Guillaume occasionally says like "I have no time.", but I doubt if
> it is true.  You have been working on sympa-cleanup branch for a
> full one year.  There was enough time, wasn't it?
Accusing others of lying each time you don't understand their working 
schedule and motivations isn't the best way to work collectively. This 
kind of agression has nothing to do with current discussion, on a 
technical developement mailing list.

> OTOH _also_ for all else, the idea to discard all of your works in
> the last year is pain.  Because, despite of distance and time
> difference, we were sharing the same time.
>
> So, before hurriedly beginning replay of past commits, we should
> examine what would be done and what won't be done again.
First, I don't see the need of a 5-years plan, when there is already a 
consensus on the first steps (cleanup before refactoring).

Second, I offered to discard one year of my own work, in order to find a 
quick solution to the dead-end we were facing. I could as well have 
suggested to rebase the trunk on my own branch, before the merge, and 
that's your work that would have to redone. So yes, I feel a bit 
concerned about quickly re-instoring a testable code base.

> Here is David's plan.  I'll add my comments.  Please see also the
> spreadsheet I posted.
>
> On Wed, 23 Oct 2013 16:03:47 +0200,
> David Verdin <address@concealed> wrote:
>
> | So, here is the plan to achieve the decorrelation of features
> | development and design considerations:
> |
> |  1. I will split the 6.2 branch into two new branches:
> |       * revision 7678 will become the new 6.2 branch. it corresponds to
> |         the 6.2a.32 tag that is currently in production since one year
> |         on the RENATER's servers. It works, it is OK to go beta.
> |       * revision 9547 will become the new trunk. It is the last revision
> |         of the 6.2 branch before the merge with sympa-cleanup.
>
> It's done.
>
> |  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.
"Guillaume does" does not mean "he is the only one to be able to do the 
job, and everyone else is condemned to sleep as long he's not finished". 
That just does not work, as just demonstrated by the two past monthes.

I just volonteered to do this work, but I frankly don't care if someone 
else is able to proceed it earlier as I can.

> * What to do prior to this step
>
>    Bug fixes made in other branches should be merged as much as
>    possible.  Because, after layout change, merging process will be
>    relatively difficult (although it will still be possible).
Different file layout is a moderate pain here, especially compared to 
indentation changes. I disagree about the forced ordering here, because 
as already said, it prevents each of us to work paralleously. If that's 
really needed, tough, I'd like a time windows for those changes to be 
replicated, before I could continue to work.

>    Our ultimate goal is undoubtedly to continue releasing Sympa.
>    Improvement of usability for users should be put at higher
>    priority.
>
> * Where to do it
>
>    I supposed that this step would be done in sympa-6.2-branch,
>    and then will be merged into trunk.
>
>    If you (Guillaume) are not familiar with merging work, I'll gladly
>    do it.
This doesn't really matter for me, as long as I have clear instructions 
about where to work.

> * Layout change
>
>    I don't have objection to do it.
>
> * Reformatting (indentation fix etc.)
>
>    This would be done by perltidy: There are no need to edit files
>    manually.
We don't care what kind of editor each of use are using to work, why 
should we care about the tool used to perform indentation ? Feel free to 
use perltidy if you want, but that's not my choice.

>    We should agree on appropriate .perltidyrc options as soon as
>    possible.
No, that is useless. We just need to agree on the result, and that was 
already done AFAIK.

>    N.B. I don't consider actual options important.  What options we
>    chose, they will generate working Perl code.  That's why I agreed
>    to .perltidyrc by both Guillaume and David.
>
> * Adding unit tests
>
>    I agree to add "minimal" tests here.  Many tests are known not to
>    work in current sympa-6.2-branch and trunk, due to dependency loop.
>
>    N.B. I don't agree to Guillaume's succeeding modifications in
>    sympa-cleanup branch to avoid dependency on global $Conf::Conf.
>    Appropriate encapsulation should be used instead.
>    I painted such commits grey in my spreadsheet.
I'd prefer to keep those technical issues for later discussion, after 
the 6.2/trunk actual differenciation.

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