On 12/15/10 10:19 AM, "Graham Percival" <gra...@percival-music.ca> wrote:

> We have a lot of newbie contributors now.  That's great!  However,
> newbie contributors aren't confident, and aren't able to figure
> out why the build is failing.  Especially when they're trying to
> build lilypond for the first time, and automatically assume that
> if git master can't build it's their fault.
> 
> To anybody with git push ability: keep your maoing garbage off of
> git master.  It's not fair to our young ones.  This has happened
> half a dozen times in the past few months.  That's half a dozen
> times too many.
> 
> To anybody else with git push ability: if git master cannot
> compile -- either with "make" or "make doc" -- then revert the
> problematic commit.  Don't politely ask the committer to fix it.
> Don't politely ask if there's a problem and start discussing it.
> Revert the maoing commit, and *then* start discussing how to fix
> it on -devel.
> (but make certain that the commit is actually bad -- if you
> suspect a build problem, then try rebuilding from scratch)
> 
> If somebody reverts one of your commits, don't take it personally.
> We're just trying to let new contributors get started.
> 
> 
> Carl: I killed your 713aeac92c2bd06a9ae0ed38d13f4b20fba3f9a8 which
> was the regtest for 1440.  Dunno why it was failing; building it
> from the command-line worked fine.
> 

I was just working on it.  I'm sorry about the maoing garbage on master.

Thanks for reverting the commit.

The problem is that the snippet runs, but it generates an error (which it's
supposed to do).  But that error breaks the doc process.

I accept responsibility for pushing the bad patch to master.  It's my fault.

But it also shows a severe weakness in our build system.

In order to be sure a one-line patch doesn't break the build, we need to to
make doc-clean && make doc, which on my system takes more than an hour, and
significantly slows my machine while it's working, because of all the disk
access involved.  And I'm supposed to do that for every patch?  If so, I'm
not going to do many patches.

So I have a set of other practices that work most of the time, and I follow
those.  Occasionally, they don't work.  For example, make doc works because
it didn't recognize one of the changes in an input file.  So I think
everything works, but then it breaks on a clean build.

We've got to have some better process to handle this.  I don't know what it
is.  Maybe a correct build system, so we don't need to do make doc-clean to
ensure things aren't broken.  Maybe an english-only make doc, so we don't
need to build all the languages when we're only working in english.  Maybe a
separate branch that we can push changes to and only gets moved to master
once a week when it's been verified by a build-meister.

I can see the problem with confusing the new contributors.  And I think we
should avoid it.

But I also see the problem with frustrating me.  Maybe I'm the only one who
feels this way.  But I'll just give up on submitting small patches if I have
to do make doc-clean && make doc for every one of the small patches.  I
don't have time to do it.

Thanks,

Carl


_______________________________________________
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel

Reply via email to