Hi,
I finally synthesize the whole set of notes, meeting notes and
discussions about the Desktop Scheduled Release processes in a single
Wiki page:
http://chandlerproject.org/Developers/DesktopReleaseProcess
I tried to be exhaustive in my writing so there are some info that are
duped throughout the page so that looking into one section, one can have
a good idea of everything that needs to be taken into account at that point.
One thing I stumbled upon while writing this is the problem of tracking
Development Branches. We haven't really talked about this before so I
went ahead and made a proposal in the doc but it's worth discussing here.
Here's the problem:
- we want to keep track of dev branches wrt to target release so we have
an idea of what's worked on at any time
- it's unclear how to treat bugs that are fixed on branches in Bugzilla
Proposal:
- create a "superbug" in Bugzilla for each dev branch
- mark all bugs related to that branch as "blocking" the superbug
- the superbug gets a keyword "branch_node" set to it (so we can easily
find them)
- only when the branch is merged into the trunk is the superbug marked fixed
- bugs blocking a superbug can be marked fixed when fixed in the branch,
their target_release though should be something else than "0.7.x" (since
we don't know when it's going to land really and I could pick them up by
mistake when creating the release note) so I'm proposing "0.7.future"
for those. I'm not thrilled by this idea though. Better ideas welcome
(I'm trying not to create another target milestone to park those bugs...)
- symmetrically, the branch should be named with a reference to its
superbug so that one can easily check the details and status of a
branch. I'm proposing to use a human readable name and the superbug
reference, i.e. <name>_<bugnumber> for the branch name
What do you guys think?
Cheers,
- Philippe
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
Open Source Applications Foundation "chandler-dev" mailing list
http://lists.osafoundation.org/mailman/listinfo/chandler-dev
