On May 22, 2018, at 18:51, Skip Montanaro <skip.montan...@gmail.com> wrote: > [Ivan Pozdeev]: >> You don't really need copies of official branches on your Github fork >> if you're not a maintainer for these branches. > I explicitly wanted to run with 3.7 in the run-up to release. On that > branch, the built ./python reports 3.7.0b4+ at startup. Master tells me > 3.8.0a0 on startup. Since my local repo is a clone of my fork, it made > sense to me to have a 3.7 branch on my fork which I could switch to. Am I > only nutcase who thinks that might be mildly useful? (Or that if I want to > test an application across multiple versions using tox that it makes sense > to have pre-release visibility of point releases.)
No, what you what you want to do makes perfect sense. It sounds like Ivan is used to projects with a somewhat different workflow than ours. We don't have "branch maintainers"; core-developers are responsible themselves for merging changes into all appropriate branches. While these days some of the backporting can be semi-automated, thanks to the backport bot, but it is still up to the core developer to decide whether a change can and should be backported, so having all active branches available in a local repo is a pretty much a necessity. As always, the Developer's Guide should be able to answer questions like this: https://devguide.python.org/devcycle/ -- Ned Deily n...@python.org -- [] _______________________________________________ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
