Stable Loggerhead Branch

[Martin Pool]

On 1 July 2010 01:30, Max Kanat-Alexander <mkanat at bugzilla.org> wrote:
>        Hello! I'm new to the list, but I've been in #bzr for a long time. For
> an introduction on who I am, see:
>
>        https://lists.launchpad.net/launchpad-dev/msg03685.html

Hi Max!

>
>        With that out of the way:
>
>        I think there should be an actual stable branch of loggerhead. Right
> now there's 1.17, but that's not actually stable--it lacks bug-fixes
> that the trunk has, and it doesn't get new bug-fixes backported. (There
> are no 1.17.x releases.)

A stable branch sounds nice.

>
>        Part of the problem has been that loggerhead has, generally, needed
> some significant changes in order for it to perform to Launchpad scale,
> and some general major backend changes, like jam's bzr-history-db work.
> I think that loggerhead actually isn't in a position, even at the
> moment, where we *could* create an actual stable branch.
>
>        So, here's what I think we should do:
>
>        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.
>        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.
>        5) Once we're reasonably sure that trunk is stable, branch it and call
> it 2.0.
>        6) From there on out, any bug fix that lands on trunk should also land
> on 2.0, and we should do regular releases. (2.0.1, 2.0.2, etc.)
>        7) New feature releases will be 2.1, etc.
>        8) We should stop encouraging people to run trunk on their production
> sites.

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.

4- I think you should branch before you start doing the refactoring.
Even if you don't intend to do any further changes to the old branch,
it will give other people a place to target fixes they want to make
before the refactoring is complete.  My experience is it's much better
to "freeze" by saying "I will only work on X" rather than "changes to
Y won't be accepted" - if people want to fix things in 1.x give them a
place to do that.  It may turn out a bug does come up that you do want
to fix and release on 1.x.

Perhaps that should be called 1.18?

5-8 also great.

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.

Also on launchpad-dev we should talk about how this ought to fit in to
their rollouts.

-- 
Martin