On 27 January 2011 13:41, Max Kanat-Alexander <[email protected]> wrote: >> 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.
OK, this is interesting. It seems like we mostly need to determine whether trunk will be slower with historydb turned off than 1.18 is now. Max seems to think it will not be; John seems to think it will be. If it is in fact no worse, then we could fairly trivially also add a know to just disable /raw across the board, and then Launchpad can qa and deploy trunk. So basically #2 from my list, and we can have just one branch, although it will be one from which we are not yet using every feature. Enabling those features in production can then be scheduled whenever. If this is true or easily achievable it is much better than worrying about renaming/abandoning branches. > 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). There is another issue that when we want to deploy a new Loggerhead revision into Launchpad, we need to have processes etc to try it out under realistic load, to assess how it's doing, and to roll back if there are problems. The next time we do deploy we may need to freshen these processes. I think this is largely orthogonal to the question of how Loggerhead's upstream branches are structured, except that the larger the jump we make next time we upgrade, the more stress it will put on the deployment process. Part of this is that we probably want a "what's actually in production" branch distinct from upstream development, pulling from it from time to time. That doesn't seem too hard. -- Martin _______________________________________________ Mailing list: https://launchpad.net/~launchpad-dev Post to : [email protected] Unsubscribe : https://launchpad.net/~launchpad-dev More help : https://help.launchpad.net/ListHelp
