RetroSearch Browse

Tue Nov 4 16:59:19 EST 2003 · https://mail.python.org/pipermail/python-dev/2003-November/039972.html

On Tue, 2003-11-04 at 15:33, Jack Diederich wrote:
> On Mon, Nov 03, 2003 at 10:36:33AM -0500, Jeremy Hylton wrote:
> > On Mon, 2003-11-03 at 07:47, Alex Martelli wrote:
> > > I made a few bugfix check-ins to the 2.3 maintenance branch this weekend and 
> > > Michael Hudson commented that he thinks that so doing is a bad idea, that bug
> > > fixes should filter from the 2.4 trunk to the 2.3 branch and not the other way 
> > > around.  Is this indeed the policy (have I missed some guidelines about it)? 
> > 
> > It is customary to fix things on the trunk first, then backport to
> > branches where it is needed.  People who maintain branches often watch
> > the trunk to look for things that need to be backported.  As far as I
> > know, no one watches the branches to look for things to port to the
> > trunk.  It may get lost if it's only on a branch.
> > 
> > The best thing to do is your option [a]: Fix it in both places at once. 
> > Then there's nothing to be forgotten when time for a release rolls
> > around.
> > 
> 
> If we aren't using CVS tagging features, it just falls under personal
> preference.

I think there's more than personal preference involved.  We ought to be
consistent in how we apply patches to avoid missing things.

>   If we are, it is easier to import all the changes from
> the branch to the trunk, tag it is 'import_to_trunk_N' and then
> next time something changes just look at the diff between the
> 'import_to_trunk_N' tag to now, mark as 'import_to_trunk_N+1', rinse
> and repeat.  Doing it w/ tags has the benefit that you can do
> a one-liner that says 'try to import any changes from the branch.'

The branch has bug fixes and changes that don't necessarily show up on
the trunk.  For example, a bug that exists in code that was removed or
completely rewritten on the trunk.  It also doesn't address the
stability issue: A maintenance branch gets less testing, and committers
should be cautious about changes.  Committing on the trunk first gives
you a chance to test out the changes there and get feedback.

Jeremy

Home - News ( United States | United Kingdom | Italy | Germany ) - Football scores

Showing content from https://mail.python.org/pipermail/python-dev/2003-November/039972.html below:

[Python-Dev] check-in policy, trunk vs maintenance branch