Stable Loggerhead Branch

[Martin Pool]

On 2 July 2010 04:19, Max Kanat-Alexander <mkanat at bugzilla.org> wrote:
> On 06/30/2010 06:31 PM, Martin Pool wrote:
>>>        1) Determine what major refactoring of loggerhead is necessary.
>>>        2) Complete that major refactoring, and put any necessary finishing
>>> touches on any refactoring that's already been done.
>>>        3) Add tests that assure that loggerhead is fully functional and can
>>> scale to Launchpad scale.
>>
>> 1, 2 & 3 are of course great, and I would encourage you to at least
>> give a brief summary of how you want to do them on the list, at least
>> for the sake of my education.
>
>        Well, (2) depends somewhat on (1). In order to do (1), I would need to
> become more familiar with the codebase in general, and not just the
> parts that I've been fixing for stability and scalability issues. For
> example, I'm really familiar with the bits of code that analyze revision
> history, and I'm somewhat familiar with the logging and Paste glue, but
> I'm less familiar with the UI code.
>
>        For (3), I'd first have to become more familiar with the existing
> tests. Then, I already have a basic load-testing tool for loggerhead
> written in Perl; I'd just have to translate it to Python, make it part
> of the test suite, and have it assure that under load, loggerhead still
> behaves as expected (even if it gets slower).

As John said I think you should distinguish load tests from unit
tests.  You probably don't want to run load tests on every commit but
you should run unit tests.

I meant not just describe it now but also as you go along and find
things you wonder about or that you want to change.  Think out loud.

>
>>> 4) Actually freeze the trunk for a month and focus on stability
>>> issues. I know that freezing the trunk is drastic and usually
>>> unnecessary when you have an awesome DVCS, but I think that this
>>> one time, it will be warranted.
>>
>> 4- I think you should branch before you start doing the refactoring.
>> [snip]
>> Perhaps that should be called 1.18?
>
>        I can do that, but I'd never release it and call it 1.18. Loggerhead
> just isn't stable enough. I wouldn't even recommend that people use the
> 1.x branch, if we had one, just like nobody recommends using the
> "stable" (ha ha) branches of loggerhead now. But there would be a brief
> period during the refactoring where 1.x was likely more stable than 2.x
> and Launchpad would want to use it, so it's a reasonable idea for us to
> have a 1.x branch that's somewhat short-lived.

Having a branch but no tarball releases is ok with me.

>        After that, on trunk I think we should focus on stability. You can
> personally work on features on another branch, but we won't be looking
> at feature merge proposals until we're relatively sure that the general
> code architecture is stable. *Then* we branch, and new features can land
> on trunk. But I'll never have a stable trunk if I have to continuously
> stabilize new features while I'm also refactoring for stability.

This is a bit hypothetical because nobody has actually put up a
non-stability patch targeted to 1.18 but if someone did, it would be
the right thing to review and merge it so as to unblock them.  If
their patch would put extra work on you to stabilize it then you
should get them to do that.  You could cajole another bzr dev into
doing the review.

>> The feature freeze for Ubuntu Maverick is at the end of July so we
>> should decide which branch and release ought to get in there.  I'm not
>> saying you should rush the work to get it in, but it would be a shame
>> to have 2.0 be stable but not shipped or vice versa.
>
>        Hmm. Well, at this point, I don't think any known version of loggerhead
> will be stable enough by the end of July. The version we're using at
> Mozilla works *most* of the time, so perhaps we could just figure out a
> point on trunk that's relatively stable and call it 1.18 for Maverick.

Maverick currently has 1.17+bzr424-1 so if we get a later revision
which is either more stable or better in other ways let's get that in.

mbp at grace% rmadison loggerhead
loggerhead |     1.10-1 | jaunty/universe | source, all
loggerhead | 1.17-0ubuntu1 | karmic/universe | source, all
loggerhead | 1.17+bzr400-1 | lucid/universe | source, all
loggerhead | 1.17+bzr424-1 | maverick/universe | source, all

-- 
Martin