[python-committers] [PSF-Members] Code Simplicity » Open Source Community, Simplified
solipsis at pitrou.net
Wed Feb 2 20:10:11 CET 2011
Le mercredi 02 février 2011 à 13:59 -0500, Steve Holden a écrit :
> On Feb 2, 2011, at 1:47 PM, Antoine Pitrou wrote:
> > Le mercredi 02 février 2011 à 19:39 +0100, Jesus Cea a écrit :
> >> -----BEGIN PGP SIGNED MESSAGE-----
> >> Hash: SHA1
> >> On 02/02/11 19:28, Antoine Pitrou wrote:
> >>>> The merge here is mostly automatic. In fact, if the RM doesn't change
> >>>> his/her clone at all, the merge is "null", even if devel repository has
> >>>> evolved a lot in the meantime.
> >>> By merge I meant the cherry picking operation itself ("svnmerge").
> >> To be concrete, how many patches went inside 2.7.0 after cutting the
> >> "rc1"?. Ideally, the answer should be "a handful".
> > I don't think we are talking about branching after rc1 but after beta1,
> > so that the feature branch can continue receive non-bugfix patches.
> > That's quite many changesets to review.
> The paper I referenced talks about branching after tagging the release
> candidate. It seemed trivially obvious to me that you wouldn't want to
> branch while the feature set code is still being modified.
Ok, my bad. Perhaps they have different rules about what goes in between
beta and rc, though? I don't know the Bugzilla project.
> That way the only things that (might) need merging would be late-stage
> and hopefully minor fixes from the released branch to the main trunk.
> With release candidates of sufficiently high quality there should be
> nothing to do.
More information about the python-committers