Hi all,
I'm a little worried about the lack of checkin and review process on
the dev branch, that we semi-agreed on for TS development. This is
partially my fault, I initially assumed the dev branch was going to be
for John's cache work, but it got turned into a kitchen sink for lots of
development. As such, I'm concerned how we are going to merge this back
to trunk. I guess it's up to the people working on the dev branch, but
I see three possible alternatives:
1) Review of bugs / fixes going into dev branch as they are prepared,
before checkins (we'd have to retrofit a few commits that have already
happened).
2) Do a complete review of the dev branch before we merge to trunk, as
one big "review". This would be massive undertaking...
3) Owners of code on trunk reopens bugs, with patches, and requests
review for migration to trunk. I.e. single bugs / commits are migrated
to trunk as requested by the people who have committed to dev branch.
Please vote / pick one :). My +1 is for #1. In the future, I hope we can
avoid a "dev" branch entirely, and only use branches for single, large
feature rewrites (e.g. one branch for rewriting the HTTP SM). We'd
still, of course, create release branches (e.g. release_2_0,
release_2_1, etc).
Also, remember the trunk is in no way closed, yet. Don't assume that all
fixes has to go into dev, again, it was primarily created to avoid a
massive and potentially disruptive change to land on trunk before the
2.0 release. I think several of the bugs committed to dev branch should
have gone through reviews and checkins straight to the trunk.
I'm going to work on finalizing a "roadmap" for getting 2.0 for Q1,
based on our Hackathon discussions. I hope to have that out early next
week, together with bug lists etc.
Cheers,
-- Leif
- Dev branch "checkin" policy Leif Hedstrom
-
