Re: Lintian based autorejects
On Wed, Nov 04 2009, Steve Langasek wrote:
> On Tue, Nov 03, 2009 at 11:29:53PM -0600, Manoj Srivastava wrote:
>
>> > Do you understand why people are getting annoyed ?
>
>> They have a lot of bloody gall to be annoyed thatpeople file
>> bugs about serious policy violations that they have signed up to
>> follow, and neglected in their packages, and instead of thanking peple
>> who find out and point to these policy violations, they feel angry at
>> the bug reporter, instead of ashamed at how they neglect bugs in their
>> packages.
>
> Yes, you have completely failed to understand the issue.
>
> I'm not complaining about you filing bugs on *my* packages. I'm
> complaining about a mass bug filing on *any* packages, using standards
> that have not previously been approved by the project, because *doing
> so skews priorities for the project as a whole*. Marking bugs as
> severity: serious means *the project* has to deal with the resulting
I think this is mostly false. 90% of the bugs filed were on
target, and the remaining were only bumped up one level; and usertagged
for easy changes.
Note that the vast majority of bugs I have filed as serious are
violations of Must directives:
,----[ http://www.debian.org/Bugs/Developer#severities ]
| serious
| is a severe violation of Debian policy (roughly, it violates a
| "must" or "required" directive), or, in the package maintainer's or
| release manager's opinion, makes the package unsuitable for release.
`----
25 out of 240 bugs were upgraded from important to serious, and
these are the tags in these 25 bugs:
arch-dependent-file-in-usr-share
binary-with-bad-dynamic-table
control-file-has-bad-permissions
depends-on-build-essential-package-without-using-version
dir-or-file-in-tmp
invalid-standards-version
missing-build-dependency
missing-build-dependency-for-dh_-command
no-standards-version-field
package-installs-python-pyc
All of these are policy violations, and would normally result in
at least important bugs.
> bugs. The bugs get mixed into the RC bug list and take up resources
> of participants in bug squashing parties; the release team has to go
> back and mark bugs as release-ignore or downgrade them if they're not
> actually release-critical issues;
The amount of effort needed to fix these is about comparable to
kvetching about it or downgrading them, And, anyway, given that the
bugs are all usertagged, it is trivial to reset them. These would be
low hanging fruit in bug squash parties, and
> the QA team winds up with these packages on their radar even if the
> package quality doesn't warrant it.
None of the packages belonging to the QA team are affected.
> All because you're jumping at the chance to slap serious bugs on
> people's packages without waiting for consensus to emerge on whether
> those issues, some of which are entirely cosmetic, should actually be
> serious.
There is already consensus on the severity of bugs that violate
must directives in policy. That is 90% of the bugs filed.
The other bugs are still important. And trivial for the
maintainer to download/
> That's not improving the quality of Debian, that's just being a jerk.
Bullshit. A researched, usertagged set of bugs that takes 5
minutes to change the severity gets your panties in such a twist?
Where rules lawyering about who is entitled to file what bugs is more
important than discovering long neglected bugs?
>> Finally, these violations of policy are added to the blacklist,
>> since these serious policy violations are adjudged too buggy for Debian
>
> The use of passive voice here masks the fact that the adjuge-er is not the
> Debian project as a whole.
The debian project as a whole does not adjudicate a whole lot
of things -- like which bugs ought to get a pass in a release. There
are a whole lot of decisions made by the DPL and delegates, and I for
one think that the people in charge of the archive get the same leeway
that the people in charge of the release do.
manoj
--
Professional wrestling: ballet for the common man.
Manoj Srivastava <srivasta@debian.org> <http://www.debian.org/~srivasta/>
1024D/BF24424C print 4966 F272 D093 B493 410B 924B 21BA DABB BF24 424C
Reply to: