Mailing List Archive: Python: Dev

Re: [Python-checkins] r66863 - python/trunk/Modules/posixmodule.c

Index | Next | Previous | View Threaded

martin at v

Oct 9, 2008, 2:08 PM

Post #1 of 2 (137 views)
Permalink

Re: [Python-checkins] r66863 - python/trunk/Modules/posixmodule.c

[switching to python-dev]

Georg Brandl wrote:
> Martin v. Löwis schrieb:
>> Raymond Hettinger wrote:
>>>> Merges should be handled by the original committer.
>>> Respectfully disagree. Some people here having been taking
>>> responsibility for keeping the branches in-sync
>> Which people specifically?
>
> Specifically, Christian, Benjamin and myself have done larger merges
> to the 3k branch in the past, and if svnmerge is used, I suspect will
> do the same for 2.6.

That's different, though. Does any of you has actually taken
*responsibility* to do so, either unlimited, or with some limitation?
(e.g. for a year, or until 2.7 is released, or for all changes
but bsddb and Windows).
I would be (somewhat) happy to hear that, but I wouldn't really expect
it - we are all volunteers, and we typically consider taking
responsibility (e.g. as a release manager) very carefully.

Please don't get me wrong: I very much appreciate that you volunteer,
but I don't want to discharge any committer from merging on the
assumption that someone has formally taken responsibility.

I would be skeptical relying on such a commitment, knowing that RL
can get in the way too easily. E.g. Christian disappeared for some
time, and I completely sympathize with that - but it also tells
me that I can't trust on somebody doing something unless that someone
has explicitly said that he will do that, hoping that he will tell
me when the commitment is no longer valid (the same happened, e.g.,
in the Python job board, and happens all the time in other projects -
it took me about a year before I stepped back as the PyXML maintainer).

I can *also* sympathize with committers that say "we don't want to
backport, because we either don't have the time, or the expertise
(say, to install and run svnmerge on Windows)". I just accept that
not all patches that deserve backporting actually do get backported
(just as not all patches that deserve acceptance do get accepted,
in the first place).

Regards,
Martin

_______________________________________________
Python-Dev mailing list
Python-Dev[at]python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: http://mail.python.org/mailman/options/python-dev/list-python-dev%40lists.gossamer-threads.com

amauryfa at gmail

Oct 9, 2008, 3:43 PM

Post #2 of 2 (125 views)
Permalink

Re: [Python-checkins] r66863 - python/trunk/Modules/posixmodule.c [In reply to]

Hello,

Concerning the management of this particular change / development, I
see three additional issues:

- First, I think that the answer given here:
http://mail.python.org/pipermail/python-checkins/2008-October/074659.html
does not match the question.
It seems to me that Skip was asking whether the "memory leak" impacted
the 2.6 branch, and the answer should have been "No": the change that
introduced the memory leak had just been committed 10 minutes before.

- Because of this misunderstanding, the changes to this
GetCurrentDirectoryW were backported to the release2.6 branch, despite
the fact that it's not a regression from a previous version, the NEWS
entry explicitly expresses doubts about the correction (which I happen
to share), there is no unit test and no item in the issue tracker.

- The backport to release26-maint http://svn.python.org/view?rev=66865&view=rev
also merged other changes (new unrelated unit tests). IMO unrelated
changes should be committed separately: different commit messages help
to understand the motivation of each backport.

I'm not blaming anyone; my feelings are certainly biased by the
somewhat strict procedures that we recently followed when the trunk
was in "release candidate" mode (submit a patch, ask for a review, add
the reviewer's name in the commit message).
I think that some of these rules should still apply to the maintenance branches.
On the other hand, I am all for a trunk branch with few restrictions:
it's here to share code with others and experiment with the next
python release. The need for stability is much lower.

--
Amaury Forgeot d'Arc
_______________________________________________
Python-Dev mailing list
Python-Dev[at]python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: http://mail.python.org/mailman/options/python-dev/list-python-dev%40lists.gossamer-threads.com

Index | Next | Previous | View Threaded

Interested in having your list archived? Contact lists@gossamer-threads.com