launchpad-dev team mailing list archive

[Martin Pool <mbp@xxxxxxxxxxxxx>]

On 27 January 2011 13:41, Max Kanat-Alexander <mkanat@xxxxxxxxxxxx> wrote:
>> It seems like at the moment we have a case where trunk, though it has
>> some good work in it, isn't usable by the project's largest user, it
>> has some tests failing, it is lacking tests for some things, and seems
>> to have some regressions.
>
>        That's somewhat correct. Tests are failing on the stable branch, also.
> There are no regressions from *loggerhead's* standpoint, that I know of.
>
>> The regression, if I understand correctly,
>> is that the historydb changes make things slower in some important
>> cases,
>
>        No, I doubt that this is true. loggerhead already has to build an
> entire branch history and cache it when a branch is first accessed. It
> doesn't even usually store this cache persistently on disk, and it only
> stores 10 recent caches in memory. So unless there's something serious
> that I'm missing, there's no way that history_db is slower than
> non-history_db.

OK, this is interesting.

It seems like we mostly need to determine whether trunk will be slower
with historydb turned off than 1.18 is now.   Max seems to think it
will not be; John seems to think it will be.

If it is in fact no worse, then we could fairly trivially also add a
know to just disable /raw across the board, and then Launchpad can qa
and deploy trunk.   So basically #2 from my list, and we can have just
one branch, although it will be one from which we are not yet using
every feature.  Enabling those features in production can then be
scheduled whenever.

If this is true or easily achievable it is much better than worrying
about renaming/abandoning branches.

>        Ah, well, no matter what you call it, it has to have tests that
> actually check that things aren't regressing, or the LOSAs will start
> calling it "codebounce" again. I suspect that at this very second, trunk
> and the stable branch are equally stable, but I really have no concrete
> idea beyond my personal opinion and local experience, without the tests.
> Even if you start pushing changes onto some new branch (no matter what
> you call it) there's simply too much risk that the system will become
> unstable again--particularly because you'd be working with a worse
> architecture on that stable branch than there is on trunk (which had
> some fair bit of nice refactoring).

There is another issue that when we want to deploy a new Loggerhead
revision into Launchpad, we need to have processes etc to try it out
under realistic load, to assess how it's doing, and to roll back if
there are problems.  The next time we do deploy we may need to freshen
these processes.  I think this is largely orthogonal to the question
of how Loggerhead's upstream branches are structured, except that the
larger the jump we make next time we upgrade, the more stress it will
put on the deployment process.

Part of this is that we probably want a "what's actually in
production" branch distinct from upstream development, pulling from it
from time to time.  That doesn't seem too hard.

-- 
Martin