[Python-Dev] What to do with languishing patches?

Terry Reedy tjreedy at udel.edu
Mon Jul 19 05:02:57 CEST 2010


On 7/18/2010 5:05 PM, Alexander Belopolsky wrote:
> On Sun, Jul 18, 2010 at 4:32 PM, Paul Moore<p.f.moore at gmail.com>  wrote:
>> On 18 July 2010 20:57, Glyph Lefkowitz<glyph at twistedmatrix.com>  wrote:
> ..
>>> This is what branches are for.
>>> When the X.Y release cycle starts, there should be a branch for X.Y.  Any
>>> "would be applied" patches can simply be applied to trunk without
>>> interrupting anything; the X.Y release branch can be merged back into trunk
>>> as necessary.
>>
>> Agreed. If that isn't already the recommended workflow under
>> Mercurial, I'd suggest making it so. (I can imagine that under
>> Subversion, where branching and merging is more awkward, it might have
>> been deemed not worth doing).
>
> Do I understand it correctly that the proposal is to create an
> X.Y-maint branch at the time when alpha (or beta) release goes out
> rather than the current practice of creating the branch at the time of
> the final release?

I would understand it to be at the point when some commits would 
otherwise be deferred and possibly forgotten.  Whick is to say, first 
beta. I would expect that partial and then nearly complete closure of 
'trunk' would work best if there were only a few committers who nearly 
all turn to bugs and then critical bugs during the beta and rc phases 
and who would not look at anything else during those phases. Of course, 
it would be best if pending patches for known bugs were applied before 
the split, so that the only patches applied to the new branch were for 
newly discovered bugs.

-- 
Terry Jan Reedy



More information about the Python-Dev mailing list