Developers of Sympa

[David Verdin <address@concealed>]

Whoa whoa  whoa, period, guys.

May I be so bold as to remind you our primary objective?

It is "make some code that works".

So please, Soji, let Guillaume commit with the granularity he likes and let us consider copyright issues when we don't have more pressing matter on our hands.

Cheers!

David

Le 30/01/14 16:56, IKEDA Soji a écrit :

Guillaume,

On Thu, 30 Jan 2014 16:20:09 +0100
Guillaume Rousse <address@concealed> wrote:

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.

Yes, according to my next request, if you work once by a week, you
would be better to explain what to do (one week), then commit
accumulated commits (another one week).  Thus, we would avoid the
vicious cycle we are currently falling into.

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.

If you are not interested in the format of copyright notice, why
don't you revert your change when the other stated objection to it?
If you did such, things would go easier, I believe.


Regards,

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