Mailinglist Archive: opensuse-factory (520 mails)

< Previous Next >
Re: [opensuse-factory] Tallying the quality of package descriptions

On 05/19/2017 03:16 PM, Michal Kubecek wrote:
On Friday, 19 May 2017 3:28 Simon Lees wrote:
On 05/19/2017 12:30 AM, Dominique Leuenberger / DimStar wrote:
On Thu, 2017-05-18 at 16:42 +0200, Jan Engelhardt wrote:
rpmlint is practically useless - people complete ignore it, even
for trivial things like "summary must not end in dot".

You mean those 51 packages:
mma ry-ended-with-dot

Let's clean this up and change rpmlint from a warning to an error :)
That will teach people.


See my thread in the buildservice list the other week about making
packages with rpmlint show up in status areas in yellow with "Warning"
rather then in green with "Succeeded", there are many rpmlint
warnings that people ignore, but yes this should be a error, it takes
2 seconds to fix.

An error? This? Seriously?

What is wrong with you, people? Jan pointed to a problem that some
package descriptions look rather like marketing texts (and some focus on
praising so hard that they forget to tell you what the package is good
for) and the result of the discussion is: let's make "summary ends with
a period" hard error rather than warning.

"That will teach people" -- Yes, right. It's going to teach them that
some pointless (pun not inteded but appreciated) automated check is more
important than summary and description being actually meaningful. And
that's not talking about how the maintainer cares about the package, how
(or if) he responds to bug reports, if he follows upstreams etc. No, as
long as your summary doesn't end with a period, you are fine. If it
does, you are doomed, they are going to "teach you". (OK, to be fair, if
your package doesn't build in Factory for 3 months, you may get into
trouble too. But don't dare to leave the dreadful period in place when
fixing the build. Or a security bug.)

Each time I submit a package, I fear there will be another crazy check,
another hoop I'll have to hop through to get it built (or even
accepted). It's getting more and more annoying with time. Last time I
tried to raise this concern, I was shouted down that I'm imagining
things, that there is absolutely no pointless bureaucracy and all those
checks and specfile style requirements are absolutely necessary to make
openSUSE great. Yet I know real people (even SUSE employees) who are so
annoyed by this non-existing problem that they refuse to submit anything
exactly for this reason. And to be honest, I can't blame them - even
less after reading things like "that will teach people" (and often
hearing much worse things).

For the record: I'm not ignoring warnings and I'm trying to get the
number of warnings as low as possible, even if it often means spending
ridiculously long on some tasks like writing the summary (because "do
not end with a period" is just one of the requirements). That's why I
know how ridiculous some of them are and how frustrating it is to make
all checkers (both software and human) happy.

Michal Kubeček

I'm not saying every warning should be fixed, from the perspective of
someone on the review team it does make our jobs much easier when there
are less warnings, we then have to go through and work out if the
warning is an actual issue or not so it would be much nicer if warnings
that aren't going to be fixed are properly suppressed. In most cases
when I see a warning for a . in the summary i'll probably ask you to go
back and fix it (or if I have the time i'll take the 5 mins to fix it
myself and create a new SR), having this particular one as a error
instead of a warning would just save us a little time in the future and
lets face it the vast majority of packages are fine anyway.

And just because we are talking about the related topic of Summaries
doesn't mean we can't keep talking about descriptions as well, I just
didn't have much to add on that topic.


Simon Lees (Simotek)

Emergency Update Team
SUSE Linux Adelaide Australia, UTC+10:30
GPG Fingerprint: 5B87 DB9D 88DC F606 E489 CEC5 0922 C246 02F0 014B

< Previous Next >
Follow Ups