Philippe Bossut wrote: > So the question is really one of dev process: in the next 6 months, do > we think we will create updates from the current 0.6 branch only or that > we should be more hardcore on our milestone process and do them from the > trunk? IOW, the choices are: > 1- Forward: The 0.6 branch is the only place to create incremental > updates (trunk will be too unstable) and we'll use forward numbering on > the trunk (0.7xxx). > 2- Backward: The trunk is the place to create incremental updates, we > are committed to produce high quality milestones moving forward and we > then need to use a backward numbering scheme (0.6xxx)
The trunk broke the first day we opened it for development, and it is still broken. We have no idea when it will be fixed. We took pretty massive changes in the first day. Things that we know of: There's wx build issues in the full build (so we cannot produce any new changes in wx until that is fixed). Import performance (at least) became three to ten times slower on Windows, and I have a suspicion many other cases with large calendar suffered as well on Windows. Unfortunately we don't know of any others beyond the import test, since running the performance tests now takes so long that nobody wants to do it on Windows and additionally the QA Lab Windows machine dies when running these perf tests (most likely a hardware issue). This is a pretty extreme situation we are in now, but there have been cases in the past where we have a thing or two broken almost all the time, while usually any single major issue gets fixed within a week or so. That is just to say that it will take us time to spin up a milestone. At a minimum I think it will take a week from trunk which is under heavy development, but possibly a little longer. Maybe that is ok for the general milestone. However, I am concerned what happens if someone reports a critical security issue with Chandler. A week or a little longer sounds bad to just fix the known issues and get to usable release, when we'd need to scramble with the security fix as well. And who knows what new security bugs we've already introduced into the trunk. The safe bet here would be to release the security fix from the branch. But we could also take the view that we are still too early to be this sophisticated and just get an update from the trunk. I guess I am on the fence on that. I could live with either model during the 0.7 cycle. -- Heikki Toivonen
signature.asc
Description: OpenPGP digital signature
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ Open Source Applications Foundation "Dev" mailing list http://lists.osafoundation.org/mailman/listinfo/dev
