[Python-Dev] Goodbye
Éric Araujo
merwok at netwok.org
Thu Sep 23 22:51:57 CEST 2010
Le 23/09/2010 19:22, Terry Reedy a écrit :
> As of just now, if you were to wonder "What (security) bugs are open for
> 2.5" and search on open 2.5 issues, you would get a list of 44 issues.
> It is only 44 instead of hundreds because of the work I and Mark have
> done in the last 4 months. It it 44 instead of perhaps 5 because Tarek
> and Eric insist on marking all disutils2 issues for all versions even
> though though these issues have nothing to do with maintenance releases.
> It is a real nuisance when trying to do tracker cleanup.
Let’s fix this. Two days ago, I said this in
http://bugs.python.org/issue2200#msg117003 :
distutils2 has to work with 2.4-2.7 and (soon) 3.1-3.2, so Tarek told
me to set all available versions for those bugs (2.5-py3k), even if I
think “3rd party” is more appropriate and useful (since a distutils2
bug would not for example block a CPython 3.2 release).
I’ve been following these rules since before GSoC, when I had less
confidence and no will to conflict with Tarek on such a small thing
<wink>. Now I argue that the versions field is not really useful for
d2, since it lacks 2.4 which we support and chiefly because it does not
actually help our workflow: We don’t have separate branches for
backporting fixes, we apply patches and run tests for all supported
versions before committing on a single branch. There is no use case of
setting a version to remind that a port needs to be done. For bug
purposes, I actually see distutils2 as a value for the versions field of
distutils bugs.
In short, setting versions other than “3rd party” for distutils2 bugs
does not help distutils2 and raises unhelpful results for people
querying the status of CPython releases. +1 on changing that.
respect-my-non-ASCII-diversity-write-my-acute-accent-thanks’ly yours,
Éric
More information about the Python-Dev
mailing list