Developers of Sympa

[David Verdin <address@concealed>]

Hi soji,

Le 05/02/14 15:25, IKEDA Soji a écrit :

On Wed, 05 Feb 2014 13:26:35 +0100
David Verdin <address@concealed> wrote:

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.

I said to him: "Anyhow you take them, I will do my best", and also
said: "I won't write about this issue anymore, and will observe
what you do".  So please not be anxious.

Good! I'm happy to see we all agree on a status quo and advance towerds better code and - more importantly - releases!

BTW I recently cannot decide if trunk would be the base of new
major release (7.0).
I don't have much objection to reordering and unit tests
demonstrated at sympa-cleanup branch, but have certain suspicion on
refactoring.

What kind of suspicions? Would you fear that refactoring would unstabilize the trunk?

So, please let me observe what will be done in trunk for more
moments.  Anyway I promise to respect release schedule you proposed.

Thank you so much, soji !

Best regards,

David

Regards,

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! 
<https://sourcesup.renater.fr/tracker/?group_id=23>
RENATER logo
*David Verdin*
Études et projets applicatifs

Tél : +33 2 23 23 69 71
Fax : +33 2 23 23 71 21

www.renater.fr <http;//www.renater.fr>
	RENATER
263 Avenue du Gal Leclerc
35042 Rennes Cedex

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