+1 to all of Heikki's points.
...Bryan
Heikki Toivonen wrote:
Philippe Bossut wrote:
- S1: commit on the 0.7 Preview branch:
- Pros: simple topology, allow big change in trunk immediately, we
already know 0.7.1 will need all bug fixes plus those already targeted
- Cons: goes against C1 (we may destabilize the branch preventing a
quick fix to be released)
This isn't much of a con actually. We can easily create 0.7.0.x branch
from the 0.7 release tag without disrupting any other branches (like 0.7.1).
- S2: commit on the trunk:
- Pros: simple topology, keep everyone focused on the immediate short
term objective, no change required on TBox, build, etc... to get 0.7.1 out
- Cons: prevent big rework to be done (people will need to create
private branches)
I prefer S2. Looking at 0.7.1 bugs, most developers actually have some
bugs in that milestone. Those that don't/won't have any 0.7.1 work can
work on a branch until we open the trunk for 0.8.
Keeping 0.7.1 on trunk (at least for a while) also means that it gets
the most testing, and we don't need to do anything special about
Tinderboxes.
The plan is also to do a quick 0.7.1 (like a month of work), so it
shouldn't impact 0.8 much.
I'd still leave open the option of branching 0.7.1 a little later, say
when we get to 15 code bugs. At that point we'd then probably want some
Tinderbox support for that branch as well, which would mean that
Tinderbox cycle times would increase while the branch Tboxes were
operational.
All in all, in my opinion S2 would mean the least disruption for most
people.
------------------------------------------------------------------------
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
Open Source Applications Foundation "chandler-dev" mailing list
http://lists.osafoundation.org/mailman/listinfo/chandler-dev
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
Open Source Applications Foundation "chandler-dev" mailing list
http://lists.osafoundation.org/mailman/listinfo/chandler-dev
