Developers of Sympa

[IKEDA Soji <address@concealed>]

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.


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.

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


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


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