g.brandl at gmx.net
Thu Sep 23 21:50:50 CEST 2010
Am 23.09.2010 19:22, schrieb Terry Reedy:
>> Asking every now and then "is this still an issue", or setting
>> the version number, doesn't really advance the issue.
> Numerous issues have been advanced by the questions I and Mark have
> asked. Some were legitimately closed as out of date (the bug reported
> for 2.4/5/6 had already been fixed). Others were closed as fixed when
> someone committed something. The fact that Mark got over-zealous in
> closing issues too soon does not negate this. Some of our questions were
> more specific, and asking questions was not the only things we did. I
> tested some old reports against 3.1 and I believe Mark also did some
> testing himself.
> Setting Versions properly helps anyone searching for issues relevant to
> a particular version. If having a field set properly does not matter,
> then is should not be there. Are you suggesting that Versions be deleted?
ISTM that the "versions" field is not very useful if the other fields are
For example, feature requests almost always only belong to the current trunk.
Yes, for features that fall under the moratorium, the "versions" field would
be different; however, we already have an "after moratorium" keyword that
signifies this. Other than this, we currently don't assign feature requests
to specific milestones, and I don't ever see us doing that.
Bug reports by nature almost always belong to all branches in maintenance; if
the bug in question is a regression, the reporter will usually report that;
if it is in a new feature, a) the reporter might not know that anyway, but
b) the committer fixing it will without looking at "versions".
Security bugs are the last category, but they are also better served with a
"security" keyword than with specific "versions" settings.
The only use I see in the field is for the reporter to indicate which version
he used when finding a bug; however this is next to useless since you have
to reproduce it anyway, and ask for more detail when you can't.
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.
More information about the Python-Dev