[Python-Dev] PEP 385: pruning/reorganizing branches

Dirkjan Ochtman dirkjan at ochtman.nl
Tue Aug 4 08:33:49 CEST 2009

On Tue, Aug 4, 2009 at 08:06, "Martin v. Löwis"<martin at v.loewis.de> wrote:
> I use that as a branch to tell build slaves to clean out their
> current checkouts. So keep-clone sounds right, assuming it is possible
> to target buildslaves at either clones or branches (which, IIUC, would
> be necessary anyway, since we are using a mix of branches and clones).

Yes, that should be straightforward.

>> amk-mailbox: keep-clone?
>> twouters-dictviews-backport: keep-clone?
>> bcannon-sandboxing: keep-clone?
>> bippolito-newstruct: merges?
> You'll probably need to explicitly ping the specific owners
> (Andrew Kuchling, Thomas Wouters, Brett Cannon, Bob Ippolito)
> to understand the fate of these branches.

Will do.

> This also raises the question how developers should publish their
> "own" branches. For the bzr setup, there was apparently a proposal
> to use directories for that, i.e. giving each developer a directory
> on code.python.org to publish branches.

User repositories has apparently worked well for Mozilla, so yeah,
it's worth discussing.

> Not doing that, but keeping owner information encoded in the clone
> name, would be fine as well.
>> release23-branch: merges?
>> r23b2-branch: merges?
>> r22rc1-branch: strip
>> r22b1-branch: merges?
>> r22a4-branch: merges?
>> r22a3-branch: merges?
>> r161-branch: merges?
> It seems we had been creating CVS branches for every release around
> that time; I don't remember the details. Each such branch should end
> up in a tag. For example, release23-branch should (and does) ultimately
> lead to tags/r23. cvs2svn wasn't able to recognize this correctly (as
> CVS branches apply to each file individually), so it created the r23
> tag out of various copies that were current when the tag was made.
> I don't know what your plan is wrt. release tags, i.e. whether you
> want to keep them all. If you are stripping out some of the branches,
> but plan to keep the release tags, I wonder what the tags look like.

The plan was to keep all maintenance branches and all release tags but
not all release branches (since they seem to contain few commits

>> release22-branch: merged-r24921
> Not really. Jack Jansen merged some changes that got first applied
> to the 2.2
>> r22b2-branch: merges? merged-r24426
>> r22b2-branch: merges? merged-r24426
>> release20-maint: keep-named
> See above. So you do plan to keep all past releases?
>> release152p1-patches: merges?
> Probably merged. I don't recall whether 1.5.2p1 really happened;
> in r14966, Fred claims that he merged all changes from 1.5.2p2 (!).
> "Hopefully I got all this right!"
> I surely hope the same - I doubt anybody would go back and check
> whether anything is missing.

Thanks for the thorough review,


More information about the Python-Dev mailing list