Developers of Sympa

[Guillaume Rousse <address@concealed>]

Le 21/01/2014 07:33, IKEDA Soji a écrit :
> Guillaume,
>
> Second,
>
> * Of course, we are encouraged to make chages boldly.  However, we
>    also should take care that our changes will be disclosed to
>    public.
>
> It is not neccessary to commit change each time when you move each
> file.  Moreover, it will make commit logs hard to grasp: users have
> to track tens of (sometimes more than a hundred of) commits to
> understand what was done.
>
> Let's keep in our mind that repository will be browsed not only by
> us, core developers, but many external developers and even all the
> future developers.  Extreamly minced commits will become burden on
> development.
>
> We would be better to accumulate multiple changes related to one
> another and to commit them at once.
>
> (Of course it depends.  Anyway, we should not commit unrelated
> changes at once.)
>
> In this way, I believe that (for example) reordering work will be
> done by less than ten commits.  --- But before resuming the work,
> please read next.
The desirable commit granularity is an highly subjective issue. I 
personaly think than smaller commits are easier to read review, and 
eventually revert, but that's indeed discussable.

However, given than I can barely work half a day per week on Sympa 
codebase, pushing small modifications avoid locking other contributors, 
including yourself, or forcing me to merge concurrent change with 
unfinished work.

> Last,
>
> * We would be better to spend enough time so that we would not
>    murder the time anymore: At first explain what to do, then
>    discuss, and commit at last.
>
> You probably think that "In such way, doubled to tripled time will
> be spent".  If you think so, you are wrong.
>
> If you explained what you were planning in advance, unnecessary
> controversy will be avoided.  In addition, discussion in advance
> will reduce reworks on controversial commits.
>
> As a result, both time spent for commit works and duration of
> development will be shorten.
>
> And needless to say, commit log will become more intelligible by
> everyone.
What make development long (and painful) is not the lack of prior 
discussion IHMO, but endless bikeshedding, such as comparative value of 
coma vs dash in a copyright statement. Especially for a project 
distributing release with outdated information for more than 10 years 
now without any problem sofar.
--
Guillaume Rousse
INRIA, Direction des systèmes d'information
Domaine de Voluceau
Rocquencourt - BP 105
78153 Le Chesnay
Tel: 01 39 63 58 31

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