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

[Dirkjan Ochtman]

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
anyway).

>> 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,

Dirkjan