> (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
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 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
> > 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
"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
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" 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
> 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
> 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
"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
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
> 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).
> -
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
[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
14 matches
Mail list logo
