Developers of Sympa

[IKEDA Soji <address@concealed>]

All,

2014/01/06 18:28、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.

I meant that _not_ only you should be off with head.

We have not been able to behaved appropriately to incorporate Guillaume's 
work into Sympa release for one year.  We (including me, and of course you) 
should think this fact over.

I'll respond to Guillaume's posts after a few days.


Indeed, I'm very fatigued.

Regards,

--- Soji

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