launchpad-dev team mailing list archive

[Max Kanat-Alexander <mkanat@xxxxxxxxxxxx>]

On 01/26/2011 05:51 PM, Martin Pool wrote:
> 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.

	Totally, sounds very sensible.

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

> and secondly that the raw view makes things insecure in some
> important cases.

	That is true, for Launchpad only. All of the non-Launchpad security
cases are already handled by loggerhead itself. The Launchpad case will
have to be handled by custom code developed especially for Launchpad--it
will likely go into the loggerhead-launchpad project or will be a piece
of IT configuration, rather than actually being a change to loggerhead
itself.

> I've also been told that trunk has changed enough
> from 1.18 that it's nontrivial to port changes between them.

	That's true for many things, yeah. Bug fixes are pretty easy, but major
feature changes are going to be different for the two branches.

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

	Ah, I don't think opinions vary that much on this. I've always worked
on projects where trunk was expected to work, and I think that's a
sensible method of development.

> Loggerhead trunk is not really in that state now.

	Ah, well, I'd say more that we don't *know* whether or not loggerhead
trunk is in that state now. I'm not aware of any significant issues in
loggerhead itself, but without the test suite being more complete, I
just can't really say.

	When CodeBrowse ran trunk before, it crashed constantly. Now it runs a
stable branch and does not crash constantly. So if you're going to have
CodeBrowse run trunk, you really should have some method of
assuring--with a reasonably high probability--that CodeBrowse will not
suddenly start crashing all over the place again with every push.

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

	Oh really? Did jam say that? As far as I know loggerhead should perform
identically to how it does now (relatively slowly) with history_db
turned off.

	There just wouldn't be any reason to update CodeBrowse to trunk if you
weren't using history_db, because CodeBrowse already has all the other
important features from trunk.

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

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

	-Max
-- 
http://www.bugzillasource.com/
Competent, Friendly Bugzilla, Perl, and IT Services