Developers of Sympa

[David Verdin <address@concealed>]

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?
  

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.

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

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

--
A bug in Sympa? Quick! To the bug tracker!

David Verdin Études et projets applicatifs
Tél : +33 2 23 23 69 71 Fax : +33 2 23 23 71 21   www.renater.fr	RENATER 263 Avenue du Gal Leclerc 35042 Rennes Cedex

Attachment: smime.p7s
Description: Signature cryptographique S/MIME