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