On Thu, Dec 4, 2008 at 12:52 PM, Eric Smith <eric at trueblade.com> 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 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.) -- Cheers, Benjamin Peterson "There's nothing quite as beautiful as an oboe... except a chicken stuck in a vacuum cleaner."
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4