On Wed, Aug 12 2009, Josselin Mouette wrote:
> Le mercredi 12 août 2009 à 08:16 -0500, Manoj Srivastava a écrit :
>> > AIUI, this header is here to indicate which version of the policy the
>> > package is supposed to conform to. This way, we have a way to enforce
>> > which policy versions are supported, e.g. in a stable release, by
>> > forbidding the too old versions.
>>
>> No, that is wrong. The reason we put in the Standards version is
>> to let the next developer know what to look for in the upgrading
>> checklist in policy in order to bring the package up to date with policy
>
> This assumes that the previous developer has correctly updated the
> package according to the stated Standards version. Which is, in the
> general case, wrong.
Firstly, when you update a package, the previous maintainer
could have done all kinds of things wrong. If you do not trust the
maintainer, you check. The chances are that they did not update the
standards version, so youhave more checking to do from upgrading
checklist. More work for you, but no other downside. If you think the
maintainer was malicious, and updated the standards version without
making changes to the package, you are stuck with a full review of
policy and the package. And report the maintainer.
If you think the majority of the maintainers upo blindly
upgrading the standards version and not the package, we need to do some
maintainer purging.
In my experience, the packages I have worked with, the standards
version has not been upgraded without the package itself.
> This also assumes that the upgrading checklist contains all relevant
> information, which is also wrong for real cases.
Frankly, if you think that upgrading checklist does not contain
everything relevant a maintainer has to check for the policy update in
question, this is a bug, and I do not se that you have filed any. And
can you point to a concrete case, please? Which policy upgrade came
with a deficient upgrading checklist?
> If you want to bring a random package up-to-date with the policy, it is
> generally more useful to look at its RC bugs, and also at its other
> bugs.
Heh. You have a far greater faith in people discovering and
filing RC bugs. Lookgin at RC bugs is of course a necessary, but not,
in my opinion, a sufficient, condition for bringing the package up to
date. If a maintainer are not looking at the standards version, then
the packages they maintain are suspect.
> Said otherwise, with the current state of our practice, the workflow you
> describe is flawed. Which makes the standards version declaration
> useless.
I beg to differ. The standards version is a useful tool for
people who follow the (simple) rules, and just because there are lazy
(and perhaps malicious) maintainers out there does not mean the
work-flow is broken.
I hope that the majority of developers are not as lazy,
incompetent, or malicious as you imply, and do not update the standards
version without actually updating the packages in question.
manoj
--
Bachelor: A guy who is footloose and fiancee-free.
Manoj Srivastava <sriva...@debian.org> <http://www.debian.org/~srivasta/>
1024D/BF24424C print 4966 F272 D093 B493 410B 924B 21BA DABB BF24 424C
--
To UNSUBSCRIBE, email to debian-policy-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
