[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 specifi
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 whet
> 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.
You are probably right (although it's not quite clear from Skip's question).
> -
On 11:12 pm, [EMAIL PROTECTED] wrote:
- 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
"Martin v. Löwis" writes:
> I'm skeptical that new tests actually need backporting at all. Python
> doesn't really get better by new tests being added to an old branch.
> Near-term, it might get worse because the new tests might cause false
> positives, making users worried for no reason.
If
> If they do fail, they're not "false" positives. If they're "false",
> then the test is broken, no?
Correct. But they might well be broken, no?
> So find a way to label them as tests
> added ex-post, with the failures *not* being regressions but rather
> latent bugs newly detected, and (presuma
> Presumably if the new tests cover functionality that somebody cares
> about, it would be valuable to make sure that maintenance bugfixes don't
> break this functionality in maintenance branches either?
Yes. At the same time, there is also a risk that the new tests just fail
because they are not
"Martin v. Löwis" wrote:
[...]
> There is a certain prevention already that later maintenance fixes don't
> break the earlier ones: those fixes typically get checked into the trunk
> also, where the tests do exist. So the committer would find out even
> before the patch gets to the maintenance bran
Andrew Bennetts wrote:
> "Martin v. Löwis" wrote:
> [...]
>> There is a certain prevention already that later maintenance fixes don't
>> break the earlier ones: those fixes typically get checked into the trunk
>> also, where the tests do exist. So the committer would find out even
>> before the pat
"Martin v. Löwis" writes:
> > If they do fail, they're not "false" positives. If they're "false",
> > then the test is broken, no?
>
> Correct. But they might well be broken, no?
I would hope some effort is made that they not be. If they generate a
positive, I would expect that the contrib
> > Correct. But they might well be broken, no?
>
> I would hope some effort is made that they not be. If they generate a
> positive, I would expect that the contributor would try to fix that
> before committing, no? If they discover that it's "false", they fix
> or remove the test; otherwise t
On Fri, Oct 10, 2008 at 08:44:38AM +0200, "Martin v. Löwis" wrote:
> So 2.6.0 will contain a lot of tests that have never been tested in
> a wide variety of systems. Some are incorrect, and get fixed in 2.6.1,
> and stay fixed afterwards. This is completely different from somebody
> introducing a n
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.
You are probably right (although it's not quite clear from Skip's question).
> (2.5.3 reminder: there are lists of commits in sandbox/py2.5.3 to be
> considered. I've seen no reactions on python-dev or modifications to
> those files, so I don't think anyone else is looking at them. Is
> everyone waiting for the weekend, maybe?)
I may have said that before: I don't have a
14 matches
Mail list logo
