On Mon, Nov 07, 2011 at 02:44:01PM +0000, Adam Spiers wrote: > On Mon, Nov 7, 2011 at 2:11 PM, Graham Percival > <gra...@percival-music.ca> 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 _______________________________________________ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
