[Dev] Milestone numbering going forward
heikki at osafoundation.org
Wed Nov 30 21:22:40 PST 2005
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
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.
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 253 bytes
Desc: OpenPGP digital signature
Url : http://lists.osafoundation.org/pipermail/dev/attachments/20051130/927efe3d/signature.pgp
More information about the Dev