Developers of Sympa

[IKEDA Soji <address@concealed>]

David,
# Sorry, I misoperated mailer then message had been sent only to you.

On Wed, 05 Feb 2014 17:10:54 +0100
David Verdin <address@concealed> wrote:

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

Well, I'll write some examples.

Several changes at sympa-cleanup were to extract parameter values
in %Conf::Conf and to give each function/method calls them as
arguments.  I feel such changes going against refactoring.  Moreover,
such style may ruin readability and maintenability and may invite
errors and bugs.

Such "defactoring" possibly can be one of relay points in more
general refactoring process.  If that's the case, however, I don't
understand what kind of goal he is going toward.  Otherwise, if
it's his goal, I can't agree to him.

Similarly, I don't understand what he aims at by preserving argument
list (@_).  I guess that in many cases it would be better to break
reference to variables on caller-side (in other words, to make
subroutine calls "call by value") so that independency of each
subroutine will be improved.

Or similarly, he is trying to use named arguments as much as
possible.  However, Perl doesn't support function prototyping with
named arguments (e.g. as Python).  It also may invite errors (typos
in argument names will silently ignored and an undefined value will
be passed).  I suppose arguments would be distinguished by their
positions in argument list as much as possible (besides, optional
args may be passed as hash, not hashref.  In this point I agree
to him).

Furthermore, though this is the issue once discussed,
removing connection pooling feature from SDM just because it is
complex will obiviously unstabilize Sympa (indeed, it will become
merely unusable).  To "cleanup" unneccessary things is not same as
to remove what one does not understand.

                                  *

Note that I don't want to deny all works by Guillaume.  Not only
that, examples above are not really the problem, if it could be
corrected as everyone here agreed.

After all, my greatest suspicion is that, if I raised any questions
described above or similar, I might be answered by words "I am not
interested in such issue", "It's not current priority" and so on
(how is the commit not interested by committer?).  And yet another
changes will be rejected.

I think it is unreasonable.

In conclusion, I desided to observe what will be done on trunk for
some more moment.


Regards,

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