Re: Fixes to jazz chord displays (issue 5320074)

[Graham Percival]

On Mon, Nov 07, 2011 at 02:44:01PM +0000, Adam Spiers wrote:
> On Mon, Nov 7, 2011 at 2:11 PM, Graham Percival
> <address@hidden> wrote:
> > The google code issue is our pointer.  Rietveld is our memory.  We
> 
> Sure, but it's the de-referencing which worries me for two reasons:
> 
> 1. These older review issues contain potentially useful history about
>    the review process, so allowing them to be garbage collected
>    doesn't sound safe to me.

True, although our entire review kind-of sucks when people have
large-ish new features.

But this is also a fairly rare: we had a race condition between
uploading of patches and your knowledge of our development
process.  Or maybe it's a starving philosopher problem...
beginners need a waiter to allocate and pick up forks for them,
while developers are encouraged to look around the table and
decide which forks to use for themselves.


> 2. It's not always clear that they have been de-referenced, which can
>    easily cause confusion.  
> I suppose a workaround could
>    be to put a comment at the bottom "THIS ISSUE IS NOW RETIRED, SEE
>    ISSUE 12345".  I'll do that from now on.

We've done stuff like that occasionally.

> > We're not going to lose the de-referenced pointers, so it's not a
> > memory leak.
> 
> Your analogy was working quite nicely until this point, but I don't
> know what you mean by "de-referenced pointers".  I'm guessing you
> meant "de-referenced objects",

oops, yes.

> but then what would the garbage
> collection you refer to actually do?

Since not everybody is using the new git-cl, and since the new
git-cl isn't bullet-proof in any case, we tend to lose
approximately 5% of our patches.

... I'll pause a moment while you get over your shock.


Done?  ok, great.  The traditional solution is to manually click
on people's names, i.e.
http://codereview.appspot.com/user/dak

and look at all the patches under the "Created by dak".  19 times
out of 20, between 20% - 80% of those patches are still actively
discussed or being worked on.
(yes, that's a large range, but I wanted to keep my 95% confidence
interval)
Up to 60% of those patches have been pushed and can be "garbage
collected" (i.e. dak logs in and clicks the round "x" beside the
patch), and up to 30% of those patches were forgotten about.  A
few reminders, a quick round of reviewing later, that patch can be
pushed, and we've got one more bugfix or new feature.

The benefit of running garbage collection is to reduce the number
of patches that have already been pushed.  That should make it
easier to spot the forgotten patches.  (in practice, of course we
run garbage collection and lost-resource finding algorithms at the
same time, since that means that we only traverse our list once)


There's also patches that people attach to comments on the google
code issue tracker.  Those are even easier to lose.

> > capiche?
> 
> Almost.  It's still an over-complex system though.

Other than GOP, we haven't put any serious effort into scaling up
development.  Back in 2009, we had a huge technical debt (lots of
regressions blocking a stable release).  It took over a year of
dedicated work just to reach the stability of 2.12.

We still have tons of technical debt, but at the moment I think
our "social debt" is even worse.  We don't have a good workflow
for dealing with the amount and skills of developers.  At the
moment we're stumbling forward with hack on top of hack.

GOP is an attempt to systematically clear up that social debt,
until we get to a level at which we can move back to tackling the
technical debt.  And somewhere in this mix, we have people
clamoring for systematic revamping and committment to our input
syntax, i.e. GLISS.  I'm actually beginning to think that we
should cut GOP short; just institute a few more hacks to keep
development rolling forward, then run GLISS for half a year or
something to take some of that pressure off.


The bottleneck in this whole process is my absolute committment to
working for 10 hours a week on lilypond; no more, no less.  I've
spent multiple weeks working more than 50 hours on lilypond, and
that just isn't sensible for my career.

- Graham