Martin v. Löwis schrieb: >> It will handle it, for sure, but I think it would all go easier if we >> could work with stricter subset branches (and leave the effective >> cherrypicking for the occasional problem). > > So I think the PEP should propose a workflow (or: merge flow) if you > think we would be better off with a different one. > > In proposing such a workflow, consider these requirements: > - we current have four active "maintenance" branches (i.e. where > the entire code basis evolves): trunk, 3k, 2.6, and 3.1 (3.0 > also until this morning).
It seems that there is a consensus to separate the 2.x and 3.x repos, and that also makes sense to me. Using named branches for the maintenance branches should be possible, but I'm not opposed to using cloned branches either. What I really want to see is the common-subset approach for maintenance branches. Changesets still have to be transplanted from 2.x to 3.x or the other way round. > - in addition, we have two security branches currently: 2.4 and > 2.5, although 2.4 will be closed soon. > - our committers consistently refuse to merge changes across > branches themselves, and likely continue to do so unless there > is some feature of hg that I missed (e.g. one were merging > would happen without any user specifically asking for it) If the checkin is done in the proper (the maint) branch, at least merging of that change is automatic whenever someone does a hg merge. Georg -- Thus spake the Lord: Thou shalt indent with four spaces. No more, no less. Four shall be the number of spaces thou shalt indent, and the number of thy indenting shall be four. Eight shalt thou not indent, nor either indent thou two, excepting that thou then proceed to four. Tabs are right out. _______________________________________________ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
