Developers of Sympa

[IKEDA Soji <address@concealed>]

All,

On Thu, 24 Oct 2013 11:58:38 +0200
David Verdin <address@concealed> wrote:

> Hi Soji,
> 
> Le 23/10/13 19:02, IKEDA Soji a écrit :
> > 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.
> I noticed it!
> OK, this is clearer to me.
> >
> >> 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).
> Oh well, if someone sees a bug during this period, it would be sad not 
> to fix it.
> but it depends
> >
> > - 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.
> It's very clear. :-)
> My opinion is that we should try to accept his ideas for a start. As I 
> stated in my mail, we don't have to observe him silently and we can 
> debate his choices. The only important point is that, if we the 
> discussion reaches a dead end, he is the one that will have the last 
> say.

I got it.  At last Guillaume brings the hammer down, all of the else
shall sit up.

>      I motivate this by my personal observation: when you had arguments 
> about design, from my point of view, both solutions were valid and 
> produced working code. I could have chosen any of the two solutions at 
> random and be content with it. you're both perl expert and don't propose 
> solutions that won't work. So for both pahses 4 and 5 I chose as the 
> final decider the one of us that has the priority on the branch: 
> Guillaume for phase 4, Étienne you and me for phase 5.
> What we won't do, however, during phase 4, is commit new code without 
> asking him.
> 
> >
> >    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?
> Suggest. Guillaume is open to discussion as long as we don't mix 
> objectives: Refactoring and feature development for example.
> Another point: when guillaume is working on, say, functions relocation, 
> he may not be available to make other refactoring changes (half a day 
> per week, remember).
> That means the even if he agrees with us, the changes may not be immediate.
> If you see how to make a modficiation and we agree, you may also code it 
> yourself but Guillaume should tell when it is possible to do it. This 
> way, we avoid for example collisions between a module move and 
> modifications to this module.

I see.  What necessary is working and postponable modifications.

> >>   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?
> To this day, all the modifications of r7678 are already in the trunk.
> I'll report manually bug fixes from branch 6.2 and 6.1 to the trunk, as 
> soon as possible.
> So, yes, in this stage, any change to 6.2 will have been reported to the 
> trunk, but not using a merge.

I seem a bit complicated.  r9547 will have always been reflected to trunk.
I understand.

> >> 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.
> That will be my job. I'll make sure that any bug fix / small feature 
> added to the  6.2 branch is reported to the trunk.
> Keep in mind that the /big/ work of refactoring and readability 
> improvement will take place right now. After that, changes itroduced by 
> guillaume will be far lighter.
> 
> Did I answer your concerns correctly?
> 
> Best regards,
> 
> David
> >
> > Regards,
> >
> > --- Soji

Now I have taken in.  David, I entirely agree to your proposal.

Warmly thanks,

--- Soji

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