launchpad-dev team mailing list archive

[Max Kanat-Alexander <mkanat@xxxxxxxxxxxx>]

On 01/25/2011 06:46 PM, Robert Collins wrote:
> I will *always* worry about new technologies; and I'm sure that the
> sysadmin teams will do so as well. Increasing test coverage is good,
> but not enough to eliminate concern :).

	You took me too literally. If we didn't have some concern about
deploying new technologies, we would be silly or ignorant. :-)

	In any case, we are in agreement that the test coverage of loggerhead
should be increased.

> That means we're running a fork; I guarantee someone will forget in
> the future and have it enabled without meaning too.

	That seems unlikely (disabling it involves commenting one actual code
line) but, I agree, possible.

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

>  - add an option (does not imply a command line option) controlling it
> to the wsgi app.

	That would probably be a reasonable possibility. I don't want to go
down the road of having too many options, though.

>>        5) Deploy loggerhead 1.19 with history_db.
> 
> What are the implications of this; how do we turn it on? Can we still
> share caches, and how will it interact under high load?

	Those would be questions for jam.

> So, we use a time limited token rather than single-use tokens, because
> of large files, internet being unreliable etc, but thats basically it.

	There's no risk (and considerable security advantage, given that most
attacks that would be dangerous are instantaneous) to using single-use
tokens if you have the system *redirect* to the token supplier on
invalid tokens. (Then the token supplier can throw the error if you
aren't supposed to get a token.)

> The thing is, we don't need *a* separate domain, we need a *wildcard*
> domain with each security context getting its own domain.

	That's already what loggerhead does. You can get one domain per branch.

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

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

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

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