Control: forecemerge -1 886210
Control: tag -1 pending
the previous merge from Holger failed due to mismatching severities.
On Wed, Jan 03, 2018 at 02:24:46PM +0000, Sean Whitton wrote:
> Mattia and I are in significant disagreement over this and both feel
> quite strongly about the topic (hence the severity bump -- I think this
> moderately important for Debian). In this e-mail I want to lay out in
> full detail why I would like to see this change in Lintian.
Whilst that might be true, I don't think it's actually worth discussing,
we can get along pretty fine anyway :)
But let me answer some of your points.
> Let me first say exactly what change I'd recommend:
>
> - out-of-date-standards-version should be I: or P: instead of W:
This happened:
https://anonscm.debian.org/git/lintian/lintian.git/commit/?id=97912d84cf49d35188ac91ed3a50357095400386
https://anonscm.debian.org/git/lintian/lintian.git/commit/?id=098ceec8af75aae4d228c634fc1b19224b0e9273
It will be in the next Lintian release.
So please let's not lose our heads in discussing this to death.
> > remember 3.9.{6,7,8} changes by heart, I can't with the latest…). But
> > it doesn't mean that I as a maintainer should make an effort to keep
here I forgot a negation ↑↑↑↑↑↑↑↑↑
It should read "it doesn't mean that I shouldn't make an effort".
> > up and check for Policy compliance at each package update.
>
> You argue that
> - whenever a maintainer uploads a package and S-V is out-of-date, they
> should work through the relevant entries in the Policy Manual's
> Upgrading Checklist
Yes.
> - Policy Manual releases should be infrequent to avoid maintainers
> having to do this too often
That would be nice, but I'm don't have a strong opinion on it.
> On the contrary, I argue that
> - the only thing that should be /required/ when uploading a package is
> making the package non-trivially better than the current version in
> unstable
> - updating S-V should never block uploading other improvements
I agree with all of this. I say that a maintainer *should* do that
work. If he doesn't because he believe his other changes are more
important and he wants to upload nonetheless, by all means, please do!
But then, be prepared for people and tools who look at your package to
notice that nobody checked whether it complies with the latest Policy.
That's all about it. You haven't done something that you should do,
that's reflected.
For example, I often deferred bumping std-ver on packages which lagged a
lot behind and it would have take me too much time to through several
screenful of upgrading checklist, because I believed delivering other
fixes were more important at that time.
I personally am not too attached to lintian severities. I keep all
pedantic and wishlist tags on, and always go through all of them
whenever I upload anything.
> - there are good reasons to release the Policy Manual frequently, and
> this should not be blocked by the expectation that everyone respond to
> those new versions in their very next uploads.
Sure.
> ISTM that requiring maintainers to check packages against the upgrading
> checklist before they can upload other improvements is an example of
> requiring prerequisite work of volunteers that is not needed for
> co-ordinating with other volunteers. So we should not require it.
Agree, we should not require it. But I believe we should definitely
(more or less strongly) recommend it.
--
regards,
Mattia Rizzolo
GPG Key: 66AE 2B4A FCCF 3F52 DA18 4D18 4B04 3FCD B944 4540 .''`.
more about me: https://mapreri.org : :' :
Launchpad user: https://launchpad.net/~mapreri `. `'`
Debian QA page: https://qa.debian.org/developer.php?login=mattia `-
Attachment:
signature.asc
Description: PGP signature