launchpad-dev team mailing list archive

[Martin Pool <mbp@xxxxxxxxxxxxx>]

On 26 January 2011 12:45, Max Kanat-Alexander <mkanat@xxxxxxxxxxxx> wrote:
>        Hey folks! The next step for improving codebrowse is to get loggerhead
> trunk running on launchpad. This will require the following things:

Thanks for that, Max.

I want to sort out something where we can get fixes into Loggerhead
and deployed to Launchpad; where work done for Launchpad does not
gratuitously diverge from what other people run; and where work that
has been done into trunk is not wasted.

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.  The regression, if I understand correctly,
is that the historydb changes make things slower in some important
cases, and secondly that the raw view makes things insecure in some
important cases.  I've also been told that trunk has changed enough
from 1.18 that it's nontrivial to port changes between them.

Opinions vary on whether it's ok to have a trunk that sometimes goes
unstable on the way to getting better but I like having it always
stable and usable.  Loggerhead trunk is not really in that state now.

So we have at least four options:

0- Leave trunk as it is, and keep working from and fixing a branch
that is stable.  That's kind of an easy choice.  But if all the work
going into the project is going into the non-trunk branch, it's hard
to see that trunk will ever catch up, or get any bug fixes.  So you
basically just end up with people who think they're installing trunk
actually getting something stale.

1- Before doing anything else, finish off the unfinished work in
trunk.  Generally I would prefer this option, because it avoids
diverging and you get the payoff for the work previously put in.
However in this case it sounds like this will take a lot of work to
get historydb ok.

2- Alternatively, leave the unfinished work in trunk, but allow it to
be switched off: then people for whom it is worthwhile can use it and
those who can't won't.  In the abstract I think this is a good second
choice; it might work well for things like the /raw view.  However, it
seems that this is not feasible to do for historydb because it's been
done in a way that will make things slower if it's absent.

3- Move the incomplete work onto a separate branch and reset trunk to
being something that is stable.  (That can be done by reverse merges,
pull-overwrite, or whatever.)  Then people finding the experimental
work a good tradeoff can use it, but trunk will be in a known good
state.  As people work from it, they can merge in and finish off other
work.  This is aiui what Robert wants to do.

I guess all of us would prefer to do 1 or 2, but in the medium term,
absent some non-Canonical person coming along to do them, they are not
going to happen soon.  So we have to choose between 0 and 3, which is
in a way a choice of labeling or semantics.  Either could work;
neither is great.  For people tracking trunk it is not very nice to
suddenly have it jump backwards, and nor is it very nice for it to not
move at all while fixes are landing elsewhere.

I think Robert has a reasonable point that for people working on the
project it is good to have trunk be the development focus, and for
users that they not get unnecessarily half-baked work, so therefore he
prefers #3.  I don't have a strong opinion between them; I would
mostly just like to see that we do have a path forward and code being
rolled out.

-- 
Martin