Developers of Sympa

[IKEDA Soji <address@concealed>]

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,

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