After I tag 2.7 this Saturday, I will effect the following changes in the repository: trunk working copies (or switch them anyway) because a commit hook
- 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
will be in place to prevent commits to it.
-- Regards, Benjamin
On Thu, Jul 1, 2010 at 20:17, Benjamin Peterson <benjamin@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.
- 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.
On Fri, Jul 2, 2010 at 01:57, Antoine Pitrou <solipsis@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
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
Benjamin Peterson wrote:
After I tag 2.7 this Saturday, I will effect the following changes in the repository: trunk working copies (or switch them anyway) because a commit hook
- 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
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 ?
-- 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, UK 16 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/
M.-A. Lemburg wrote:
Benjamin Peterson wrote:
After I tag 2.7 this Saturday, I will effect the following changes in the repository: trunk working copies (or switch them anyway) because a commit hook
- 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
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, UK 16 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/
Am 02.07.2010 09:53, schrieb M.-A. Lemburg:
M.-A. Lemburg wrote:
Benjamin Peterson wrote:
After I tag 2.7 this Saturday, I will effect the following changes in the repository: trunk working copies (or switch them anyway) because a commit hook
- 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
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
While that would be logical if we continued to use SVN, it's probably not worth it when we switch to Hg anyway a short time later, so avoiding the potential confusion is better.
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.
On Fri, Jul 2, 2010 at 11:02, Georg Brandl <g.brandl@gmx.net> wrote:
While that would be logical if we continued to use SVN, it's probably not worth it when we switch to Hg anyway a short time later, so avoiding the potential confusion is better.
Agreed, renaming the branch has the potential of making the conversion harder/worse.
Cheers,
Dirkjan
participants (7)
-
"Martin v. Löwis" -
Antoine Pitrou -
Benjamin Peterson -
Brett Cannon -
Dirkjan Ochtman -
Georg Brandl -
M.-A. Lemburg