Re: developer newsletter

[John Mandereau]

Le dimanche 10 janvier 2010 à 13:35 +0000, Graham Percival a écrit : 
> Yeah, but 80% of the time, that person is me.  And I'm doing major
> changes to the build system that could potentially screw up other
> people.  When major developers (be it John in relation to
> translation stuff, Carl about new developers, or Han-Wen and Jan
> about anything) point out problems in stuff I did a few months
> ago, it really makes me stop and re-evaluate what I'm doing.

This is normal; even doing our best, some goals are so difficult or
require an amount of work that is not compatible with the need of having
something which is implemented quickly, so there's always a balance to
be found between them.


> I mean, I don't make a proposal unless I really think it's a good
> idea, so when I don't hear any objections after a few weeks, I
> assume that there were no objections because everybody else also
> thought it was good.  But empirical evidence now shows that this
> isn't true, so I'm trying to find a way to discover these problems
> earlier.

I doubt there is such a way that will work all the time; there might be
one if we were full-time developers, but even in this case we might
oversight some drawbacks of a proposal and only discover them after its
implementation.  In our current situation, it's much worse, as I'm sure
not all developers (at least I don't, mainly because I earn no money
with it and I'm not enough addicted, available and skilled) look at each
nitty-gritty detail of committed piece of code or makefile and its
consequences.

If a developer wants to require approval for a proposal, a patch
submission is necessary; if he commits directly, there is some chance
that it doesn't get checked by any other developers for a few months or
years.  I don't think that each commit to the build system should be
submitted as a patch, but I highly recommend it for the new waf scripts;
an equivalent way of submitting a patch is asking to look at a secondary
branch (dev/*) then squash all commits of this branch into a single one
with a good and detailed commit message.  I especially insist on
detailed commit messages for such important patches, which should
demonstrate the committer knows exactly what he wants (i.e. what or
which goal the added/changed code is supposed to achieve), and if he's
motivated enough why he does it that way.

Another thing that we could do instead of creating another list is
writing down as a specification (even written quite informally) the
important changes already started i.e. the i18n of Texinfo, stuff
specific to building the website on lilypond.org (all details that are
independent of the build system), and switching the build system.  In
each specification we should at least explain the desired goal, and we
may specify the expected amount of work and the tools to be used.

Draft specifications could be developed on the wiki or on the list; I'd
prefer mainly on the wiki, discussion pages on the wiki being definitely
usable for discussion, so this would not overload the list traffic.
Specifications which are finalized and approved by all interested
developers may then be added in the CG.

Of course, all this may not be worth the extra work, but looking back at
my very little development experience (especially LilyPond-related), I
believe it's worth trying it.  If there are no objections or better
suggestions, I'm gonna start doing this for the translation
infrastructure.

Best,
John

signature.asc
Description: Ceci est une partie de message numériquement signée