Stable Loggerhead Branch

[Max Kanat-Alexander]

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

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

	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.

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

	-Max
-- 
http://www.everythingsolved.com/
Competent, Friendly Bugzilla and Perl Services. Everything Else, too.