Re: [python-committers] changes after 2.7 final
M.-A. Lemburg wrote: Benjamin Peterson wrote: After I tag 2.7 this Saturday, I will effect the following changes in the repository: - I will make the 2.7 maintenance branch. - I will remove svnmerge from trunk - py3k. - I will initialize svnmerge from py3k - 2.7maint. - The trunk will be officially closed. I suggest you just delete your trunk working copies (or switch them anyway) because a commit hook will be in place to prevent commits to it. Wouldn't it be better to make the py3k branch the new trunk by removing the 2.7 code and moving the Python3 code into that directory ? With that directory I meant trunk/, i.e. along the lines of: svn remove trunk svn move branches/py3k trunk -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jul 02 2010) Python/Zope Consulting and Support ...http://www.egenix.com/ mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ mxODBC, mxDateTime, mxTextTools ...http://python.egenix.com/ 2010-07-19: EuroPython 2010, Birmingham, UK16 days to go ::: Try our new mxODBC.Connect Python Database Interface for free ! eGenix.com Software, Skills and Services GmbH Pastor-Loeh-Str.48 D-40764 Langenfeld, Germany. CEO Dipl.-Math. Marc-Andre Lemburg Registered at Amtsgericht Duesseldorf: HRB 46611 http://www.egenix.com/company/contact/ ___ python-committers mailing list python-committers@python.org http://mail.python.org/mailman/listinfo/python-committers
Re: [python-committers] changes after 2.7 final
- I will initialize svnmerge from py3k - 2.7maint. We should probably all get into the habit of making sure that we leave any issues open with Python 2.7 flagged as an effected version to get fixes ported. These then could become easy issues for people to contribute through by letting others create a backport patch. Else we could think about introducing a 2.x backport (or simply backport) keyword to flag such open issues. What do you mean by that? Why wouldn't we just do the backports ourselves? (I don't understand what effected means here) For the record, the 2.6 backport keyword on the tracker ended up mostly unused. Good practice is to backport just after you commit on trunk/py3k, not months later. ___ python-committers mailing list python-committers@python.org http://mail.python.org/mailman/listinfo/python-committers
Re: [python-committers] changes after 2.7 final
On Fri, Jul 2, 2010 at 01:57, Antoine Pitrou solip...@pitrou.net wrote: - I will initialize svnmerge from py3k - 2.7maint. We should probably all get into the habit of making sure that we leave any issues open with Python 2.7 flagged as an effected version to get fixes ported. These then could become easy issues for people to contribute through by letting others create a backport patch. Else we could think about introducing a 2.x backport (or simply backport) keyword to flag such open issues. What do you mean by that? Why wouldn't we just do the backports ourselves? People forget or don't view it as important enough to do. Just look at home many merges Benjamin did last week into py3k from trunk because people didn't do a merge. (I don't understand what effected means here) That should have been affected. For the record, the 2.6 backport keyword on the tracker ended up mostly unused. I supported its removal. =) Good practice is to backport just after you commit on trunk/py3k, not months later. Obviously, but people forget or simply choose not to. -Brett ___ python-committers mailing list python-committers@python.org http://mail.python.org/mailman/listinfo/python-committers ___ python-committers mailing list python-committers@python.org http://mail.python.org/mailman/listinfo/python-committers
Re: [python-committers] changes after 2.7 final
Good practice is to backport just after you commit on trunk/py3k, not months later. Obviously, but people forget or simply choose not to. I'd say: tough luck, then. If people don't port a fix in some branch, the bug stays unfixed in that branch. So what: if somebody runs into the bug again, it will get fixed again - perhaps by the same person who failed to backport in the first place. Or perhaps in an entirely different way, possibly better. I think it's perfectly fine that people have different notions of quality and process. If we impose some notion of quality and process on everybody, it better be widely agreed (i.e. the people being forced to do things should, in principle, agree that these are good things). Regards, Martin ___ python-committers mailing list python-committers@python.org http://mail.python.org/mailman/listinfo/python-committers
Re: [python-committers] changes after 2.7 final
On Thu, Jul 1, 2010 at 20:17, Benjamin Peterson benja...@python.org wrote: After I tag 2.7 this Saturday, I will effect the following changes in the repository: - I will make the 2.7 maintenance branch. - I will remove svnmerge from trunk - py3k. Thanks for going through to make sure no commits were going to be lost. - I will initialize svnmerge from py3k - 2.7maint. We should probably all get into the habit of making sure that we leave any issues open with Python 2.7 flagged as an effected version to get fixes ported. These then could become easy issues for people to contribute through by letting others create a backport patch. Else we could think about introducing a 2.x backport (or simply backport) keyword to flag such open issues. - The trunk will be officially closed. I suggest you just delete your trunk working copies (or switch them anyway) because a commit hook will be in place to prevent commits to it. Boy will it be nice to be down to only three official branches. Can't wait until we can drop Python 2.7 as well and really only have two branches to care about. ___ python-committers mailing list python-committers@python.org http://mail.python.org/mailman/listinfo/python-committers
