Policy RFC: branches/2.0 change process

[Derek Atkins]

Quoting Chris Shoemaker <c.shoemaker at cox.net>:

> I think we can just agree that /trunk is for development and
> /branches/2.0 is for bugfixes only.

Yes, but an attempted bugfix IS development.  How are you supposed to
get it tested /before/ it gets into the branch if you don't commit it
somewhere?  How are you supposed to get it audited?

> Also, I would rather not commit changes eventually destined for
> /branches/2.0 to trunk first and then merge individual changesets to
> the branch.  That will become increasingly fuzzy as trunk diverges.

The merge problem is problematic regardless of which direction we go.
I'm trying to protect the 2.0 branch from regressions due to unaudited
changes.  The best way to get a proposed change audited is to commit
it to trunk first.

Honestly, I don't expect lots of "bugfixes" in the next four months
before our planned 2.1.0 release.  I'm just trying to get a more formal
procedure in place to make sure stable branches remain stable.

> Instead, if the fixes are made on /branches/2.0, then the branch can
> be repeatedly pulled into trunk.  Essentially, /trunk is constantly
> being rebased off the tip of /branches/2.0.  This won't suffer any
> divergence, because all previous changes to /branches/2.0 will already
> be in /trunk.

This is why I'd like a real process..  If each change destined for
2.0 requires a bugzilla report, then that bugzilla report can contain
the changeset revision(s) in trunk.  The work required is the same
regardless of whether you merge that changeset from trunk->branches/2.0
or from branches/2.0->trunk -- as the branches diverge it's going to be
the same amount of work.

Besides, I see no reason to ever apply a bugfix to branches/2.0 without
it also being applied to trunk.  Even moreso, I can see MANY reasons to
apply it to trunk first, to test it out, make sure it works, have people
test it, make sure there's no collateral damange.  And then all you need
to do is merge that single changeset from trunk to branches/2.0 to
queue it up for the next release.

Merging a single changeset is very simple so long as you know what that
changeset is.

> I don't see any need to "backport" changesets at all.

Then how do we get a proposed change audited before it's commited to
the 2.0 branch?

> -chris

-derek

-- 
       Derek Atkins, SB '93 MIT EE, SM '95 MIT Media Laboratory
       Member, MIT Student Information Processing Board  (SIPB)
       URL: http://web.mit.edu/warlord/    PP-ASEL-IA     N1NWH
       warlord at MIT.EDU                        PGP key available