Developers of Sympa

[IKEDA Soji <address@concealed>]

Dear all,

On Wed, 23 Oct 2013 16:03:47 +0200
David Verdin <address@concealed> wrote:

> Dear all,
> 
> I suggest we let the tension decrease a little. ;-)
> 
> Currently, I have three aims for Sympa:
> 
>  1. Issue new versions with new, useful features
>  2. Improve overall stability and reliability of the software
>  3. Ease the work of contributors, which means improving code
>     readability, organiation and documentation
> 
> I know that:
> 
>   * Soji shares all these aims,
>   * Guillaume's main objective is about point three, which has deep
>     consequences on point 2 (and will greatly ease point 1).
> 
> I think most of the recent controversy is due to this slight difference. 
> Soji is very good at adding new features in Sympa, which often means 
> large moves in the code. Guillaume is very good at improving code 
> clarity, which he does by atomic changes and commits.
> Problem: We currently have a single branch on which we can work. If Soji 
> makes big moves, it will trouble Guillaume's work. if Guillaume 
> questions Soji's code design while it is in progress, it slows down 
> features development ("premature optimization is the root of all evil", 
> Donald Knuth).
> That's it: we merged a branch with working code, whose design might be 
> improved (especially ours :-P ) to a branch dedicated to design 
> improvment, and we all pursue our aims, not noticing that they are 
> mutually concurrent.
> 
> I think that code design modifications and features development should 
> not be done at the same time. The head revision of the 6.2 branch 
> contains working code that should go to production as soon as possible. 
> It may contain design that is discussable, but we should discuss it 
> /after/ we have successfully issue a version with this code that works. 
> This way, design discussions would occur without any pressure, in a 
> period of time when, if we decide to completely reorganize the code, it 
> will not delay the issues of new versions.
> 
> Don't get me wrong: I think design improvement is essential to Sympa 
> survival. As noted by Guillaume, we have a small workforce. Currently:
> 
>   * Guillaume has half a day per week to spend on Sympa
>   * I have roughly two days a week to spend on Sympa
>   * Étienne has theoretically one day a week to spend on Sympa, but
>     right now (and until the beginning of 2014) he is completely
>     monopolized by other tasks, which means 0 days a week.
>   * Soji, I don't know how much time your company gave you to spend on
>     Sympa. Could you give us an estimation of this time?

I'll have one to two days a week - 1.5 days.

Due to time difference and so on, I don't always work for Sympa in
working time.

> Design improvement will ease feature development, code readability and 
> it will bring us what we need: contributors. Sympa is a free software. A 
> free software survives and evolves not only by the will of a single 
> entity (RENATER in our case) but because a community gathers around it 
> and contributes.
> 
> Practically, it means that design improvements, once discussed and 
> agreed, /must/ lead to new good practices that we all share and respect. 
> These good practices will be written, for memory, in the developper's 
> space of the Sympa wiki.
> 
> 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.
>  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.
>  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.
>  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

Questions:

- Guillaume had not only reorganize but also done several bug fixes
  and improvements.  May I understand that such modifications will
  take place at the next stage?  (Of course, changes not affect to
  logic such as typo fixes --- he also takes care of them --- would
  be done here).

- Some refactoring efforts by Guillaume can be controversy.
  When someone feels another way of refactorization is better, how
  should we behave?  ...Sorry, I can't explain my question very clear.

  For example, I took attention to additional function parameters to
  avoid dependency loop: I supposed (for example) it can be
  resolved by some kind of encapsulation.  Perhaps it would need new
  design of several classes.  In such case, what should each of us do?

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

In this stage, we will merge modifications after r7678 on
sympa-6.2-branch into turnk.  Is my understanding proper?

> 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.
> 
> This is, I think, the steps we should follow to:
> 
>  1. Issue new versions with new, useful features
>  2. Improve overall stability and reliability of the software
>  3. Ease the work of contributors, which means improving code
>     readability, organiation and documentation
> 
> (See how coherent I am? :-P )
> 
> A last personal word to Guillaume and Soji: You don't know each other 
> very well, but I do. I trust both of you, not because you're nice guys - 
> which incidentally is the case, but that's not the subject here ;-) - 
> but because you both worked on Sympa with great efficiency in the past. 
> For example: If there are still Sympa packages in many Linux 
> distributions, it's because Guillaume rewrote all our autotools usage. 
> If Sympa can handle any encoding in mails and web, it's because Soji 
> upgraded Sympa to full UTF-8 usage.
> If I suggested the organization above, it is because I fully trust you, 
> otherwise I would never have given you full access to the Sympa SVN 
> repository. I mean: I'm the guy in charge of the Sympa project. It 
> doesnt' give me any authority on any Sympa contributor - especially not 
> you - but it granted me the right to answer to all the Sympa users about 
> why Sympa does this or that or doesn't do this or that. I wouldn't give 
> you rights to the SVN repository if I thought it would make this part of 
> the job any harder than it is already...
> 
> Well I think that mail was long enough.
> 
> That leaves only one question: do you agree?
> 
> Best regards,
> 
> David

My impression: Guillaume's work inevitablly lost touch with
other branch(es) by its nature.  I might have to sync with his work
in some ways.

Regards,

--- Soji

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