Re: Fixes to jazz chord displays (issue 5320074)

[Adam Spiers]

On Mon, Nov 7, 2011 at 2:11 PM, Graham Percival
<address@hidden> wrote:
> On Mon, Nov 07, 2011 at 12:34:15PM +0000, Adam Spiers wrote:
>> On Mon, Nov 7, 2011 at 12:12 PM, Graham Percival
>> <address@hidden> wrote:
>> > I doubt it.  Just upload a new issue.
>>
>> So then we would have *three* Rietveld issues tracking the
>> same thing.
>
> The google code issue is our pointer.  Rietveld is our memory.  We
> have one object in memory (the rietveld issue you're going to
> upload), and two objects which have been de-referenced (Janek's
> and Carl's uploads).
> Our machine has infinite memory (because it's run on google
> servers, and they have more bandwidth than god, and also more
> processing power than the NSA [1]).  Garbage collection happens
> whenever Carl and Janek get around to it.
>
> Stop wasting time -- both mine and yours -- trying to handle the
> memory manually.  Unless you're writing kernel or DSP code,
> programmers outgrew that in the 90s.

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.

2. It's not always clear that they have been de-referenced, which can
   easily cause confusion.  Case in point - I accidentally updated an
   old issue within the last 24 hours because I forgot a new one had
   superceded it.  And I was directly involved with the creation of
   both!  This could have been avoided by closing the old issue except
   for Rietveld's inflexible ACL model.  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'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", but then what would the garbage
collection you refer to actually do?

> capiche?

Almost.  It's still an over-complex system though.  Ultimately I think
it boils down to (a) Rietveld having a lowest common denominator
approach to revision control systems rather than properly supporting
git/mercurial, and (b) having two sub-par systems (Rietveld and Google
Code) when one comprehensive integrated system would be much better
(not sure that such a beast exists yet, but github looks pretty damn
good these days, maybe also Gerrit).

> [1] this is almost certainly false, but it's such a nice pithy
> quote that I couldn't resist inventing it.

:-)  Actually I suspect it's true.