[Dev] Milestone numbering going forward
pbossut at osafoundation.org
Wed Nov 30 21:46:12 PST 2005
Heikki Toivonen wrote:
>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
>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.
All good points and I agree with every single one of them. I'm not
advocating that we maintain the trunk stable at any time so that we can
spin an update (especially a security update) at the drop of a hat. It
is perfectly licit I think to create 0.6 updates from the last stable
branch as long as the trunk is unstable (something we'll have to do
tomorrow for instance if a major 0.6 issue would crop up).
My point is: if we think we will make development milestones the source
of 0.6.x updates, then we should choose a (2-Forward) numbering scheme.
Note that I also said that doing so will require more work from devs to
stabilize the code base on a regular basis. It's more work for sure but
it's also more useful feedback, more excited users, more new stuff out
there more often...
More information about the Dev