launchpad-dev team mailing list archive

[Robert Collins <robert.collins@xxxxxxxxxxxxx>]

On Wed, Jan 26, 2011 at 7:12 PM, Max Kanat-Alexander
<mkanat@xxxxxxxxxxxx> wrote:
>>  - delete it from trunk too if its not ready
>
>        It's totally ready for loggerhead itself--only Launchpad has the system
> of public/private branches.

Thats true, however by pages served, Launchpad represents by far the
majority of Loggerhead users. (Another proxy is bugs reported on
Loggerhead - again, the bulk come from Launchpad users).


>> I am proposing that we consolidate the Loggerhead trunk and launchpad
>> branches. The alternative that I see is Launchpad devs having a
>> somewhat harder time working with Loggerhead, which I predict will
>> show itself as bitrot at the project level.
>
>        This sounds mostly like a question in names. Right now one branch is
> called "launchpad-pqm/devel" and one branch is called "trunk". There are
> already distros that have packages of trunk (Debian, for example) and
> other people running trunk. If you suddenly replace that branch with a
> branch that (a) has disrelated changes (which it does, because the
> backports from trunk were not merges) and (b) is not a the same revision
> level, then all the downstream consumers are going to suffer.

Its true that some downstream consumers will need to adjust; whether
they will suffer or not is a bit subjective. bzr will DTRT, and
packagers are a human step in the process so can decide what to do
going forward. I don't think its a question of names; its about where
maintenance is happening and who will be doing maintenance. More on
this later.

>>  - We move Loggerhead to be part of 'Launchpad-project'
>
>        That's fine as long as we're just talking conceptual groupings. Of
> course loggerhead should remain an excellent product for all of the
> non-Launchpad users of bzr.

Right now Loggerhead is essentially unmaintained - the Launchpad team
isn't maintaining it, the Bazaar team are not maintaining it; you've
been doing some (great) work in bugfixing but there isn't a community
of active folk gardening bugs, gardening merge proposals and generally
keeping it ticking along.

Without maintenance, Loggerhead will bitrot: it will slowly fail to
adjust to bzr API changes, not be updated for browser support, yui
changes etc. I'm proposing - with Martin and Francis agreement - to
volunteer the entire Launchpad team to maintain Loggerhead, as we
maintain lazr-*, Launchpad itself, and a spattering of other code
bases. I am not volunteering the team to do arbitrary development -
the things we build will (of course) be things that Launchpad needs,
but as the largest and most stressed Loggerhead site (to the best of
our knowledge) our changes should be broadly beneficial to most
Loggerhead users; further the Launchpad engineers are pretty good
engineers, who value writing to interfaces, abstraction layers and
extension points : I have very little concern that should do (say) a
Cassandra cache backend, that we'd fail to make it pluggable and
replaceable for folk with more modest needs.

>>  - All future trunk landings are done with a commitment to
>> stablise-within-days-or-revert (which the feature squad structure in
>> Launchpad is well suited for)
>
>        That will require that you improve the test suite in order to be able
> to actually say, in some quantitative way, that the branch is "stable,"
> though, no? For all I know, trunk is stable right now. I certainly
> haven't checked in any broken code, and I don't know anybody else who
> has either.

Well. historydb isn't stablised: its a regression in terms of
Launchpad (per John's email its not suitable for immediate deployment,
needing some weeks of engineer time, maybe more - it has to be updated
to deal with privacy, to get a concept of project in place, to preseed
(to cater for the three times slowdown on first page loads)). The test
suite is /one/ metric for fit-for-purpose / stability, but its not the
only one.

This is the situation from Launchpad and Bazaar's perspectives.

>From Bazaar's perspective Loggerhead is unmaintained; an interested
maintainer with a particular bias is preferrable to no maintainer.

>From Launchpads perspective Loggerhead must be changed substantially
to meet our performance and reliability goals. We've been using a
contractor (you) with great success at debugging reliability issues,
but one side effect of the outsourcing solution was a hands-off result
within the team. So we want to bring it in-house, to ensure that the
accountability - and responsibility for getting Loggerhead's Launchpad
instance fully up to scratch is clearly and unambiguously that of the
Launchpad team. (AKA owning the stack).

There is an offer on the table whereby we (the Launchpad team) can
become the maintainer of Loggerhead; if we do then to make maintenance
easier - and thus more reliable - I intend to shuffle stuff that isn't
ready for Launchpad off to the side; its not 'gone', and it will get
revisited, but its not ready-for-use either. It is 'Work In Progress'.

If the consensus is that Launchpad shouldn't maintain Loggerhead,
thats fine with me too. However to make sure that we see the merge
proposals within the team, and that bugs for the code base we will be
maintaining have a home, we will need to create a new project for
launchpad-loggerhead. This is purely mechanical due to limitations in
the Launchpad code-review UI - we can't have a single URL for all
Launchpad team reviews otherwise. (Not yet anyhow).

Now, you might say that if we're doing code reviews and bug triage for
the Loggerhead we deploy, we should do it for the current trunk
Loggerhead without moving stuff off to the side - which isn't an
unreasonable request, except that that inventory is going to be there
for 6-9 months, which is a very long time to wear a technical debt
which isn't needed and which can be (in mechanical terms) very quickly
resolved.

-Rob