Developers of Sympa

[IKEDA Soji <address@concealed>]

Dear all,

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:

I'll propose a few changes to the plan by David a bit.

4.(bis.) When Guillaume will have finished step 2 (organizational changes
  etc.) and Sympa-6.2 beta will have been released, overwrite trunk
  by sympa-6.2-branch.
  Namely, once we will discard changes after r7678.

5.(bis.) Then, create a new branch sympa-7.0-branch.
  Changes after r7678 would be applied to this branch again.

In my rough estimation, number of significant commits is 400 or so,
excluding those by Guillaume.

Replaying them by us is slightly easier and fairer than replaying
reorganization by Guillaume alone.


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

I'm OK.  In this step, over a half of Guillaume's commits will be
applied to sympa-6.2-branch.

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

OK.

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

By my proposal, trunk will have been in sync to sympa-6.2-branch.
He don't have to repeat refactoring work twice.

Thus, all will be able to work on new sympa-7.0-branch.


Regards,

--- Soji

-- 
株式会社 コンバージョン  セキュリティ&OSSソリューション部   池田荘児
〒231-0004　神奈川県横浜市中区元浜町3-21-2 ヘリオス関内ビル7F
e-mail address@concealed  TEL 045-640-3550
http://www.conversion.co.jp/