Le vendredi 25 août 2006 à 17:09 -0700, Steve Langasek a écrit : > > This decision was not unilateral, sorry. > > It was a decision, made by you as python-support maintainer, in direct > contradiction to what Matthias and I had discussed before DebConf and the > conclusions of the DebConf python BoF, without any consideration given to > the original goal of these fields. That's unilateral. If "unilateral" means that some people were disagreeing, you could also say the decision to implement them at first was unilateral. > > As long as these fields don't even have clear semantics, implementing > > them is, at best, useless. > > So, why has there been no discussion about the problems with the semantics > and how they might be *fixed*? As they are fundamentally broken (especially by bringing things at the package level when they should have stayed at the module level), the best fix is to remove them instead of asking package maintainers to change all their packages when it is not needed. > > > without offering any alternative > > > suitable for mass-detection of binNMU candidates. > > > What if I provide you with a script that does the same without the > > fields? > > So I get to unpack a couple hundred source packages on ftp-master/bugs.d.o > for each transition in order to inspect debian/pyversions in each one (and > who knows what else at this point) to identify the packages that are > binNMUable, instead of being able to get the same information out of > Packages+Sources? I don't find this plan particularly impressive. Given it has to be done about once or twice a year, I find it slightly better than asking a couple hundred maintainers to change their packages to add (among other things) fields with unclear definition and questionable usefulness. With the net result of having several maintainers stepping back from maintaining python packages because they find it too complicated. -- .''`. Josselin Mouette /\./\ : :' : josselin.mouette@ens-lyon.org `. `' joss@debian.org `- Debian GNU/Linux -- The power of freedom
Attachment:
signature.asc
Description: Ceci est une partie de message =?ISO-8859-1?Q?num=E9riquement?= =?ISO-8859-1?Q?_sign=E9e?=