Re: GOP-PROP 12: keep master in ready-to-release state (probable decision)

[Reinhold Kainhofer]

Am Friday, 23. September 2011, 11:17:32 schrieb David Kastrup:
> "Trevor Daniels" <address@hidden> writes:
> > How would this code be reviewed?  Do you envisage still
> > uploading to Reitfeld?  Would this be before pushing to
> > dev/* or after?  I still think this is a complication too far.
> > Certainly it needs more thought and comment from the 'big'
> > developers before being adopted.

I see this as basically the same way we are doing it now: Each developer 
already keeps local branches around. For reviewing, it might be useful to push 
a branch to origin, so others can simply check it out, but I see no gain in 
requiring a branch on the git server for each larger feature. It only 
complicates things with one more branch to handle (believe me, I'm juggling 
development branches between three computers...).


> It is a compromise between the damage and the good developers manage to
> do.  The higher the number of developers, the more important it becomes
> to avoid damage, since damage blocks everybody, and good initially helps
> only a single application.

Well, in this case, it's really not David's fault. To the contrary, his 
patches finally take on some larger structural changes, which clean up a lot 
of the lilypond syntax. Of course, larger structural changes in the core 
internals will surface problems that were hidden so far.

The reason for the increased breakage in the last month is not that we are 
suddenly much more sloppy, but rather that finally someone takes on some long-
standing cleanup issues, and those expose other bugs. I don't think this 
necessitates a change in how we approach patches. Once the dust has settled, 
we'll have less bugs and much cleaner internals.

> I have not exactly been the paragon of damage avoidance lately.  Part of
> the problem is a quite old single-core development system making it very
> expensive to do a full check, particularly on small changes.  Another
> part of the problem is working on several interlocking changes with
> related features: it does not make sense to write independent
> documentation for interlocking features, and it is not really feasible
> to create independently working reviews, so I try to flush out the base
> work rather sooner than later in order to make it possible to let the
> work on top be reviewed at all.

For such large changes, a review system like gerrit will really make life 
easier, as it allows you to keep the full branch, and have each patch reviewed 
separately.

> Obviously, I have not yet found a balance in the current development
> process where I don't turn into an annoyance.  A staging branch might be
> a step in the right direction.

You can always simply push your local development to origin/dev/dak or so...

> I am not sure cherry-picking is the way to go.

Neither do I.

Cheers,
Reinhold
-- 
------------------------------------------------------------------
Reinhold Kainhofer, address@hidden, http://reinhold.kainhofer.com/
 * Financial & Actuarial Math., Vienna Univ. of Technology, Austria
 * http://www.fam.tuwien.ac.at/, DVR: 0005886
 * LilyPond, Music typesetting, http://www.lilypond.org