[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: Subversion 1.5 Release decision?

From: Hyrum K. Wright <hyrum_wright_at_mail.utexas.edu>
Date: Thu, 22 May 2008 12:36:57 -0700

> -------Original Message-------
> From: Karl Fogel <kfogel_at_red-bean.com>
> Subject: Re: Subversion 1.5 Release decision?
> Sent: 22 May '08 12:29
>
> "Mark Phippard" <markphip_at_gmail.com> writes:
> > I put this one in the conservative-fixes.txt.  I definitely think it
> > is trivial.  It was a minor change, the rest was indentation mess-up.
> > Here is the log:
> >
> > r31186 | hwright | 2008-05-15 00:00:53 EDT
> > Changed paths:
> > M /branches/1.5.x/subversion/libsvn_client/merge.c
> > M /branches/1.5.x/subversion/tests/cmdline/merge_tests.py
> >
> > Merge r30746, r30747 from trunk:
> >
> >  * r30746, r30747
> >    Fix a minor merge range notification header bug.
> >    Notes:
> >      r30747 is just cleanup of some cruft that snuck in with r30746,
> >      thus adhering to my "every commit should need a follow-up" ethos.
> >      r30746 contains, like, one tiny *real* change, then a whole bunch
> >      of bogus indentation changes that were supposed to be part of
> >      r30748.  Probably best to not fix that indentation during
> >      backport, in case we later backport r30748.
> >    Votes:
> >      +1: pburba, markphip, cmpilato
> >
> > I am not saying this has to go into .0 either, just that I do not
> > think it needs more review.
>
> Sure.  The question is also about soak time, not just about review.
>
> I was ignoring the whitespace changes; I'm talking about the change
> itself.  And if it's so trivial, then why has it had a followup on trunk
> further modifying that same conditional? :-)  See r31312, which has now
> also been nominated in STATUS.
>
> > So should we just back out the two changes we are concerned with?
> > Looking at what those two fixed, I still think they are not worthy of
> > a new soak if we included them.  I agree about 3157, so I would say
> > just leave it out.  I'd be OK with backing out the other two (or any
> > others).  I am not sure we really need to.
>
> I'd prefer to back them out.
>
> > We need to be more conservative about what is getting back ported now
> > too, and just encourage people to move them to the approved section in
> > STATUS.
>
> Do we need to be more conservative about backporting?  We have
> merge-tracking, let's use it.  We can make a release starting from any
> tag or rev we want, merge stuff into it, etc.  I don't see any need to
> slow down 1.5.x merging activity just because we're trying to make a .0
> release.  If something gets the votes, let's merge it.  *But* that
> shouldn't have any bearing on what gets released in 1.5.0.

Huh? We've *always* released from the tip of the 1.y.x branch. Releasing from something other than that seems like it would involve a bit more process than we currently use, but maybe the new features make that possible now. Personally, I'd rather not mess with additional release branches; if we don't want to include stuff that's already been merged, let's just back it out, cut the tarball, and then remerge it (and pray mergetracking works as advertised).

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe_at_subversion.tigris.org
For additional commands, e-mail: dev-help_at_subversion.tigris.org
Received on 2008-05-22 21:37:13 CEST

This is an archived mail posted to the Subversion Dev mailing list.