On Wed, Jan 26, 2011 at 7:12 PM, Max Kanat-Alexander <[email protected]> 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 _______________________________________________ Mailing list: https://launchpad.net/~launchpad-dev Post to : [email protected] Unsubscribe : https://launchpad.net/~launchpad-dev More help : https://help.launchpad.net/ListHelp
