On Thu, Dec 4, 2008 at 13:21, Georg Brandl <[EMAIL PROTECTED]> wrote: > Benjamin Peterson schrieb: >> On Thu, Dec 4, 2008 at 12:52 PM, Eric Smith <[EMAIL PROTECTED]> wrote: >>> Christian Heimes wrote: >>>> >>>> Several people have asked about the patch and merge flow. Now that Python >>>> 3.0 is out it's a bit more complicated. >>>> >>>> Flow diagram >>>> ------------ >>>> >>>> trunk ---> release26-maint >>>> \-> py3k ---> release30-maint >>>> >>>> >>>> Patches for all versions of Python should land in the trunk. They are then >>>> merged into release26-maint and py3k branches. Changes for Python 3.0 are >>>> merged via the py3k branch. >>> >>> Apologies if this has been discussed before. I looked but didn't see >>> anything. >>> >>> Given that at least 99% of the changes for the trunk will not get merged >>> into release26-maint, doesn't it make more sense to merge the other way? >>> That is, anything that gets checked in to release26-maint would potentially >>> be merged into trunk. That would remove the huge number of merge blocks that >>> will otherwise be required. Same fore py3k and release30-maint. > > I've suggested that too; the counter-argument was that "most people don't > want to care in which branch to commit something". I'm not too comfortable > with this argument as it implies a certain ignorance on the part of our > committers. As Fred says, it wasn't discussed anyway. >
That would make the rule for choosing which branch to first commit to be the one with the smallest version: 2.6 -> trunk -> 3.0 -> py3k That seems reasonable to me since that is really what the code branching is and how I suspect we will do things with a DVCS. > Also, with svnmerge, it is not too late to change merging direction. > If changing it to be like above is not an issue then I vote for the change. >> I think the percentage is a bit lower than that. Also, we haven't been >> using blocking with the maintenance branch so far; svnmerge.py is just >> a convenience. (It generates commit messages and has a simpler >> interface than a simple "svn merge" command.) > > I *did* use blocking with the 2.6 branch when I last merged a whole batch > of commits. As you say, by using svnmerge without blocking we only get a > tool that can generate commit messages. However, with blocking we get > something more valuable: we don't overlook backportable fixes anymore. > > So: yes, blocking is more work, but it gives something important in return. The other perk of this ordering is you should be able to place a single block along the chain where the patch should stop and potentially be done with the merges if you are in a rush. That way people who do mass merges can just sequentially merge and not worry about where a patch should stop. -Brett _______________________________________________ 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