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

[David Kastrup]

Reinhold Kainhofer <address@hidden> writes:

> Am Friday, 23. September 2011, 11:17:32 schrieb David Kastrup:
>
>> 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.

It sure is.  State before the commit: documentation compiles.  State
afterwards: it doesn't.  It is not my _bug_, but certainly my 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.

That's not a quite correct characterization.  I am doing considerable
extension of functionality, and in order to do this reasonably cleanly,
there is some cleanup work.  That this resulted in type-checking of
Scheme markup function arguments was sort of an accident: I put the
respective functionality for EXPECT_SCM into the parser (required in
order to _not_ let defaulting optional arguments get checked) and made a
search and replace for EXPECT_SCM patterns.  And when this came across
the markup argument list, I saw no good reason to leave the
type-checking out there.

It tripped up a bug in make all (which I fixed), so I actually had
warning that old bugs may trigger.  I just had wrongly assumed that
James, when doing the regtesting on the large machines, would get the
doc build done as part of that.  Since that is the most expensive part
of verification, I considered it worth waiting the half-day until he
could verify.

So I got it wrong.

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

If you take a look at the breakage, it is mostly the sort of work I
considered "trivial" and committed without full testing, or while
getting my test setup wrong.  The hard stuff, until that last commit,
tended to be ok on first try.

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

If it is too complex for people to work with, that won't help much.  I
really have to take a look.

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

That's not likely to get as much testing or exposure as a general
staging branch.  origin/dev/dak sounds more like suitable for
proof-of-concept stuff.

-- 
David Kastrup