Developers of Sympa

[IKEDA Soji <address@concealed>]

             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?

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.


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.

* 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).

  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.

* 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 should agree on appropriate .perltidyrc options as soon as
  possible.

  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.

|  3. We tag a new alpha, put it in production, when we are sure it is OK,
|     we tag a beta. The 6.2 continues its life.

I think it will be done in sympa-6.2-branch.

|  4. We give Guillaume /full licence/ on the trunk. He can reorganize
|     whatever he thinks will improve the code design. He will ask us
|     questions on what a function does, what a module is supposed to be,
|     etc. and we can make remarks regarding his choices. /But he will
|     have the last say on what is considered a good practice or not//and
|     we will not take offence of his choices/. During this period, we
|     keep an eye on his commits to prevent any functionnality breaks. The
|     objective here is to produce a 7.0 version isofunctional to the
|     revision 9574. I will also report any bug fixes from version 6.1 and
|     6.2. Guillaume should also explain some refactorings to help me
|     write good practices guidelines

It's OK for me.

|  5. Once the refactoring work is over, Soji, Étienne and I can start
|     adding functionnalities: error handling, efficient filesystem locks,
|     etc. We will do it while respecting the good practices defined in
|     stage 4. Guillaume can make remarks if he thinks we don't respect
|     the good practices /but no new rules will be defined during this
|     period./ We have the last say on how we write code as long as we
|     respect the predefined guidelines. He will, on the topic of good
|     practices, be the voice of memory.

It's OK for me.

BTW I'm planning another big refactoring on WWSympa,
*alias_manager.pl and so on.  I wish to work on it in separate
branch, keeping in sync with trunk and release branches.


| I suggest that, in the future, we repeat stages 3, 4 and 5 as the Sympa 
| lifecycle. However, discussion will be more open in stage 4 : In order 
| to fix a lot of ugly code resulting from years of Sympa development, he 
| needs to be free to produce the 7.0 version. But most of the cleanup 
| will be done by the time the 7.0 is done. So any new architectural 
| consideration should be consensual.


Regards,

--- Soji