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
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.
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...
Cheers,
- Philippe
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
Open Source Applications Foundation "Dev" mailing list
http://lists.osafoundation.org/mailman/listinfo/dev
