On 26 January 2011 12:45, Max Kanat-Alexander <[email protected]> wrote: > Hey folks! The next step for improving codebrowse is to get loggerhead > trunk running on launchpad. This will require the following things:
Thanks for that, Max. 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. 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. The regression, if I understand correctly, is that the historydb changes make things slower in some important cases, and secondly that the raw view makes things insecure in some important cases. I've also been told that trunk has changed enough from 1.18 that it's nontrivial to port changes between them. 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. Loggerhead trunk is not really in that state now. So we have at least four options: 0- Leave trunk as it is, and keep working from and fixing a branch that is stable. That's kind of an easy choice. But if all the work going into the project is going into the non-trunk branch, it's hard to see that trunk will ever catch up, or get any bug fixes. So you basically just end up with people who think they're installing trunk actually getting something stale. 1- Before doing anything else, finish off the unfinished work in trunk. Generally I would prefer this option, because it avoids diverging and you get the payoff for the work previously put in. However in this case it sounds like this will take a lot of work to get historydb ok. 2- Alternatively, leave the unfinished work in trunk, but allow it to be switched off: then people for whom it is worthwhile can use it and those who can't won't. In the abstract I think this is a good second choice; it might work well for things like the /raw view. 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. 3- Move the incomplete work onto a separate branch and reset trunk to being something that is stable. (That can be done by reverse merges, pull-overwrite, or whatever.) Then people finding the experimental work a good tradeoff can use it, but trunk will be in a known good state. As people work from it, they can merge in and finish off other work. This is aiui what Robert wants to do. 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. I think Robert has a reasonable point that for people working on the project it is good to have trunk be the development focus, and for users that they not get unnecessarily half-baked work, so therefore he prefers #3. I don't have a strong opinion between them; I would mostly just like to see that we do have a path forward and code being rolled out. -- 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
