Tallying the quality of package descriptions

classic Classic list List threaded Threaded
44 messages Options
123
Reply | Threaded
Open this post in threaded view
|

Tallying the quality of package descriptions

Jan Engelhardt-4

I just felt like hacking up, and now sharing, a script to gauge where there is
overly much advertisement language in the descriptions of openSUSE TW packages.

It processes descriptions with a boring /\b$words\b/ regex match and awards
painpoints for trigger words or word groups in multiple differently-weighted
categories. For a start, that seems like a reasonable approach for finding
descriptions that are in need of repair.

> ./bullshit_graph.pl openSUSE/specs/*.spec | sort -gk2 | grep -v texlive- | grep -v ghc- | tail -n 15
transmission.spec                  140  ▒▒▒▒▒▒▒▒▒▒▒░░░░░░
OpenColorIO.spec                   145  █████████▒▒▒▒▒▒▒▒▒
perl-XML-SimpleObject-LibXML.spec  145  █████▒▒▒▒▒▒▒░░░░░
gtk2-engines.spec                  147  █████████▒▒▒▒▒▒▒▒░
perl-Carp-Assert.spec              148  ███░░░░░░░░░░░░░░░
quassel.spec                       148  █████▒▒▒▒▒▒▒▒▒░░░░
python-scipy.spec                  150  ▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒░░
leechcraft.spec                    162  █████▒▒▒▒▒▒▒▒▒▒▒▒▒▒
php5-smarty3.spec                  163  ███▒▒▒▒▒▒▒▒▒▒░░░░░░
php5.spec                          163  ▒▒▒▒▒▒▒▒▒▒▒░░░░░░░░░
php7.spec                          163  ▒▒▒▒▒▒▒▒▒▒▒░░░░░░░░░
judy.spec                          170  ███████████▒▒▒▒▒▒▒░░
perl-IO-Tty.spec                   177  █████▒▒▒▒▒▒▒░░░░░░░░░
vim-plugins.spec                   212  ███▒▒▒▒▒▒▒▒▒▒▒▒▒▒░░░░░░░░░
courier-imap.spec                  275  █████████████████████▒▒▒▒▒▒▒▒▒▒▒▒▒░

I think we found some winners.

"""Courier-IMAP is a fast, scalable, enterprise …
seamless process …
sound a bit intimidating. …
Start by taking small, easy steps. …
experience and become comfortable …
If you already have Courier installed, you do not need to download this …
If you install this version, you must remove it …

http://inai.de/files/bullshit_graph.pl
Enjoy.
--
To unsubscribe, e-mail: [hidden email]
To contact the owner, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: Tallying the quality of package descriptions

Andrea Controzzi - LedMania.it
On 18/05/2017 14:05, Jan Engelhardt wrote:

> I just felt like hacking up, and now sharing, a script to gauge where there is
> overly much advertisement language in the descriptions of openSUSE TW packages.
>
> It processes descriptions with a boring /\b$words\b/ regex match and awards
> painpoints for trigger words or word groups in multiple differently-weighted
> categories. For a start, that seems like a reasonable approach for finding
> descriptions that are in need of repair.
>
>> ./bullshit_graph.pl openSUSE/specs/*.spec | sort -gk2 | grep -v texlive- | grep -v ghc- | tail -n 15
> transmission.spec                  140  ▒▒▒▒▒▒▒▒▒▒▒░░░░░░
> OpenColorIO.spec                   145  █████████▒▒▒▒▒▒▒▒▒
> perl-XML-SimpleObject-LibXML.spec  145  █████▒▒▒▒▒▒▒░░░░░
> gtk2-engines.spec                  147  █████████▒▒▒▒▒▒▒▒░
> perl-Carp-Assert.spec              148  ███░░░░░░░░░░░░░░░
> quassel.spec                       148  █████▒▒▒▒▒▒▒▒▒░░░░
> python-scipy.spec                  150  ▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒░░
> leechcraft.spec                    162  █████▒▒▒▒▒▒▒▒▒▒▒▒▒▒
> php5-smarty3.spec                  163  ███▒▒▒▒▒▒▒▒▒▒░░░░░░
> php5.spec                          163  ▒▒▒▒▒▒▒▒▒▒▒░░░░░░░░░
> php7.spec                          163  ▒▒▒▒▒▒▒▒▒▒▒░░░░░░░░░
> judy.spec                          170  ███████████▒▒▒▒▒▒▒░░
> perl-IO-Tty.spec                   177  █████▒▒▒▒▒▒▒░░░░░░░░░
> vim-plugins.spec                   212  ███▒▒▒▒▒▒▒▒▒▒▒▒▒▒░░░░░░░░░
> courier-imap.spec                  275  █████████████████████▒▒▒▒▒▒▒▒▒▒▒▒▒░
>
> I think we found some winners.
>
> """Courier-IMAP is a fast, scalable, enterprise …
> seamless process …
> sound a bit intimidating. …
> Start by taking small, easy steps. …
> experience and become comfortable …
> If you already have Courier installed, you do not need to download this …
> If you install this version, you must remove it …
>
> http://inai.de/files/bullshit_graph.pl
> Enjoy.


LO, today you win :)


Andrea.



--
Andrea "Kontorotsui" Controzzi
Contact: +39 392 9989834 - +39 050 644097
Skype: Kontorotsui
Settore tecnico / Technical Department - www.LedMania.it
-----
LedMania SRL unipersonale
Via Galilei 27
56042 Lavoria (PI)
P.IVA: 01941970509

--
To unsubscribe, e-mail: [hidden email]
To contact the owner, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: Tallying the quality of package descriptions

Andreas Färber
In reply to this post by Jan Engelhardt-4
Hi Jan,

Am 18.05.2017 um 14:05 schrieb Jan Engelhardt:
>
> I just felt like hacking up, and now sharing, a script to gauge where there is
> overly much advertisement language in the descriptions of openSUSE TW packages.

I feel it would me more helpful to have some easily accessible
guidelines with good vs. bad examples for new packages being added...

rpmlint forces people to write or copy BS simply because minimal no-BS
descriptions result in length warnings.

Cheers,
Andreas

--
SUSE Linux GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany
GF: Felix Imendörffer, Jane Smithard, Graham Norton
HRB 21284 (AG Nürnberg)
--
To unsubscribe, e-mail: [hidden email]
To contact the owner, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: Tallying the quality of package descriptions

Jan Engelhardt-4
On Thursday 2017-05-18 16:38, Andreas Färber wrote:

>Hi Jan,
>
>Am 18.05.2017 um 14:05 schrieb Jan Engelhardt:
>>
>> I just felt like hacking up, and now sharing, a script to gauge where there is
>> overly much advertisement language in the descriptions of openSUSE TW packages.
>
>I feel it would me more helpful to have some easily accessible
>guidelines with good vs. bad examples for new packages being added...

https://en.opensuse.org/openSUSE:Package_description_guidelines ?

>rpmlint forces people to write or copy BS simply because minimal no-BS
>descriptions result in length warnings.

rpmlint is practically useless - people complete ignore it, even
for trivial things like "summary must not end in dot".
--
To unsubscribe, e-mail: [hidden email]
To contact the owner, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: Tallying the quality of package descriptions

Dominique Leuenberger / DimStar
On Thu, 2017-05-18 at 16:42 +0200, Jan Engelhardt wrote:

> On Thursday 2017-05-18 16:38, Andreas Färber wrote:
>
> > Hi Jan,
> >
> > Am 18.05.2017 um 14:05 schrieb Jan Engelhardt:
> > >
> > > I just felt like hacking up, and now sharing, a script to gauge
> > > where there is
> > > overly much advertisement language in the descriptions of
> > > openSUSE TW packages.
> >
> > I feel it would me more helpful to have some easily accessible
> > guidelines with good vs. bad examples for new packages being
> > added...
>
> https://en.opensuse.org/openSUSE:Package_description_guidelines ?
>
> > rpmlint forces people to write or copy BS simply because minimal
> > no-BS
> > descriptions result in length warnings.
>
> rpmlint is practically useless - people complete ignore it, even
> for trivial things like "summary must not end in dot".
You mean those 51 packages:
http://rpmlint.opensuse.org/openSUSE:Factory/x86_64/standard?rule=summa
ry-ended-with-dot

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

Cheers
Dominique

signature.asc (201 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Tallying the quality of package descriptions

Andreas Färber
In reply to this post by Jan Engelhardt-4
Am 18.05.2017 um 16:42 schrieb Jan Engelhardt:

> On Thursday 2017-05-18 16:38, Andreas Färber wrote:
>> Am 18.05.2017 um 14:05 schrieb Jan Engelhardt:
>>>
>>> I just felt like hacking up, and now sharing, a script to gauge where there is
>>> overly much advertisement language in the descriptions of openSUSE TW packages.
>>
>> I feel it would me more helpful to have some easily accessible
>> guidelines with good vs. bad examples for new packages being added...
>
> https://en.opensuse.org/openSUSE:Package_description_guidelines ?

Yes, like that (and I actually recall reading it at some point).

I meant something different than just _having_ a Wiki page though.

GitHub I believe has a feature that when someone does a pull request it
will show them a contributing.md file from that repository with any
specific requirements like Signed-off-by or Coding Style before it's
submitted.
In absence of such a feature for OBS submissions (there's just the small
grey box with target project, package name and summary) the first time a
new contributor learns about its existence will be when you as reviewer
complain about it and take the time to give them such a link (which I
don't think you do, you rather do SRs fixing things up yourself ;)).

So having some way for OBS to deliver a checklist for new packages
(description, groups, target project, ...) might be a good idea.

I.e., fix the problem at its source where new errors are being
introduced, rather than only running scripts after the fact.

>> rpmlint forces people to write or copy BS simply because minimal no-BS
>> descriptions result in length warnings.
>
> rpmlint is practically useless - people complete ignore it, even
> for trivial things like "summary must not end in dot".

Not entirely useless, but its output is too well hidden on the separate
tab and showing only one architecture at a time there. Some more
prominent, colored display of "n rpmlint warnings" might be sufficient
to make people aware.

Maybe an rpmlint rule or a review bot for certain buzzwords might work?
Just as with spell checkers that would surely run into false positives.

Regards,
Andreas

--
SUSE Linux GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany
GF: Felix Imendörffer, Jane Smithard, Graham Norton
HRB 21284 (AG Nürnberg)
--
To unsubscribe, e-mail: [hidden email]
To contact the owner, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: Tallying the quality of package descriptions

Simon Lees-3
In reply to this post by Dominique Leuenberger / DimStar


On 05/19/2017 12:30 AM, Dominique Leuenberger / DimStar wrote:

> On Thu, 2017-05-18 at 16:42 +0200, Jan Engelhardt wrote:
>> On Thursday 2017-05-18 16:38, Andreas Färber wrote:
>>
>>> Hi Jan,
>>>
>>> Am 18.05.2017 um 14:05 schrieb Jan Engelhardt:
>>>>
>>>> I just felt like hacking up, and now sharing, a script to gauge
>>>> where there is
>>>> overly much advertisement language in the descriptions of
>>>> openSUSE TW packages.
>>>
>>> I feel it would me more helpful to have some easily accessible
>>> guidelines with good vs. bad examples for new packages being
>>> added...
>>
>> https://en.opensuse.org/openSUSE:Package_description_guidelines ?
>>
>>> rpmlint forces people to write or copy BS simply because minimal
>>> no-BS
>>> descriptions result in length warnings.
>>
>> rpmlint is practically useless - people complete ignore it, even
>> for trivial things like "summary must not end in dot".
>
> You mean those 51 packages:
> http://rpmlint.opensuse.org/openSUSE:Factory/x86_64/standard?rule=summa
> ry-ended-with-dot
>
> Let's clean this up and change rpmlint from a warning to an error :)
> That will teach people.
>
> Cheers
> Dominique
>
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.

--

Simon Lees (Simotek)                            http://simotek.net

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


signature.asc (499 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Tallying the quality of package descriptions

Michal Kubecek
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:
> > http://rpmlint.opensuse.org/openSUSE:Factory/x86_64/standard?rule=su
> > mma ry-ended-with-dot
> >
> > Let's clean this up and change rpmlint from a warning to an error :)
> > That will teach people.
> >
> > Cheers
> > Dominique
>
> 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

--
To unsubscribe, e-mail: [hidden email]
To contact the owner, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: Tallying the quality of package descriptions

Johannes Meixner
In reply to this post by Simon Lees-3

Hello,

On May 19 10:58 Simon Lees wrote (excerpt):
> 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".
...
>> Let's clean this up and change rpmlint from a warning to an error :)
>> That will teach people.
...
> there are many rpmlint warnings that people ignore,
> but yes this should be a error, it takes 2 seconds to fix.

Yes, please make any trifle an error
to teach everybody to no longer pay attention
to what "that nitpickers rpmlint plaything" tells
and then you can fix all your stuff in 2 seconds on your own.

Very seriously:
If the openSUSE Build Service behaves unhelpful to its free users
so that they can no longer get software packages built easily
free users will go away and use another method
to get what they want.


Kind Regards
Johannes Meixner
--
SUSE LINUX GmbH - GF: Felix Imendoerffer, Jane Smithard,
Graham Norton - HRB 21284 (AG Nuernberg)

--
To unsubscribe, e-mail: [hidden email]
To contact the owner, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: Tallying the quality of package descriptions

Thorsten Kukuk
In reply to this post by Michal Kubecek
On Fri, May 19, Michal Kubecek wrote:

> 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).

I fully agree here.

  Thorsten

--
Thorsten Kukuk, Distinguished Engineer, Senior Architect SLES & CaaSP
SUSE LINUX GmbH, Maxfeldstr. 5, 90409 Nuernberg, Germany
GF: Felix Imendoerffer, Jane Smithard, Graham Norton, HRB 21284 (AG Nuernberg)
--
To unsubscribe, e-mail: [hidden email]
To contact the owner, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: Tallying the quality of package descriptions

Simon Lees-3
In reply to this post by Michal Kubecek


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:
>>> http://rpmlint.opensuse.org/openSUSE:Factory/x86_64/standard?rule=su
>>> mma ry-ended-with-dot
>>>
>>> Let's clean this up and change rpmlint from a warning to an error :)
>>> That will teach people.
>>>
>>> Cheers
>>> Dominique
>>
>> 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)                            http://simotek.net

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


signature.asc (499 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Tallying the quality of package descriptions

Stefan Knorr
In reply to this post by Michal Kubecek
Hi all,

On Fri, May 19, 2017 at 7:46 AM, Michal Kubecek <[hidden email]>
wrote:
> 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 would also be great to have some kind of overview over where your
package is right now in the process, sort of a simple flow diagram that
shows traffic lights in front of each item.
Each item should also clearly mark whether you personally have to do
something (what?) or whether someone else has to do something
(who and what?).


Stefan.

---                                                                    .
SUSE Linux GmbH. Geschäftsführer: Felix Imendörffer, Jane Smithard,
Graham Norton. HRB 21284 (AG Nürnberg).

--
To unsubscribe, e-mail: [hidden email]
To contact the owner, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: Tallying the quality of package descriptions

Michal Kubecek
In reply to this post by Simon Lees-3
On Friday, 19 May 2017 10:04 Simon Lees wrote:

> 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.

One more heretic idea... Can you possibly imagine a world where there
would be no such warning at all and you (and other reviewers) wouldn't
have to pester anyone about it? I can and I don't see it as a horrible
place where no packager would wan't to live. After all, when you brought
the topic of saving time... wouldn't dropping the warning save most?

> 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.

I'm afraid you completely missed the point. And, ironically, exactly in
the sense of what my e-mail was about: focusing on a completely
unimportant detail and missing the bigger picture.

I really didn't mind jumping from descriptions to summaries. The e-mail
was about my concern that openSUSE reviewers focus on fighting
completely irrelevant "problems", keep inventing new pointless checks
and enforcing existing ones harder. Concern that they convinced
themselves about importance of enforcing these formal requirements and
achieving absolute uniformity so much that they are unable to see how
annoying this has become for package maintainers.

Do not take me wrong; in no way I want to say all checks are pointless.
But some of them definitely are ("summary should not end with a period"
is one of them) and I'm really worried to see that the overall attitude
among reviewers is that they should be enforced even harder rather than
discarded. And that more and more should be added.

Michal Kubeček

--
To unsubscribe, e-mail: [hidden email]
To contact the owner, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: Tallying the quality of package descriptions

Michal Kubecek
In reply to this post by Stefan Knorr
On Friday, 19 May 2017 10:30 Stefan Knorr wrote:
> It would also be great to have some kind of overview over where your
> package is right now in the process, sort of a simple flow diagram
> that shows traffic lights in front of each item.
> Each item should also clearly mark whether you personally have to do
> something (what?) or whether someone else has to do something
> (who and what?).

It kind of exists, both in the web interface (right column) and on
command line (output of "osc rq show ..." command). But neither is
really easy to read; for me, "osc rq show" is easier to understand but
it still offers a lot of space for improvement. There is some logic
behind it but it's not really friendly even to someone who submits one
package per month or so.

Michal Kubeček

--
To unsubscribe, e-mail: [hidden email]
To contact the owner, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: Tallying the quality of package descriptions

Stephan Kulow-3
In reply to this post by Michal Kubecek
On 19.05.2017 10:44, Michal Kubecek wrote:
>
> Do not take me wrong; in no way I want to say all checks are pointless.
> But some of them definitely are ("summary should not end with a period"
> is one of them) and I'm really worried to see that the overall attitude

Hi Michal,

Put yourself in a reviewer's shoes for a moment. The rpmlint check about
this summary thing is pretty old - and afaik not even a SUSE thing, but
an upstream check.

Plus it's really easy to fix if you see it. And the fact that packages
are submitted without it being fixed indicates to reviewers that people
ignore rpmlint (and they are right as far as my person is concerned :).

But if packagers ignore rpmlint, it's up to the reviewers to have a look
if (more important) warnings were ignored. And this is a tiresome work
and if you do it often a day your focus shifts towards details.
Thankfully our review team *does* it often a day and it's an important
part of our development process. So bear with them heading into details
and support them by not questioning *everything* they say.

Now I would like to stress that this goes into both directions -
reviewers tend to forget how important the 99.9% are that make up
packaging and are not summaries with dots. So they need to put
themselves into 'imperfect packager's shows more often. Because I think
"that will teach them" is a) a signal of abuse of power and b) a signal
of 'us vs them', that is very unhealthy in this context.

So please guys: work together not against each other.

Thanks, Stephan

--
To unsubscribe, e-mail: [hidden email]
To contact the owner, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: Tallying the quality of package descriptions

Ludwig Nussel
In reply to this post by Michal Kubecek
Michal Kubecek schrieb:
> [...]
> Do not take me wrong; in no way I want to say all checks are pointless.
> But some of them definitely are ("summary should not end with a period"
> is one of them) and I'm really worried to see that the overall attitude
> among reviewers is that they should be enforced even harder rather than
> discarded. And that more and more should be added.

rpmlint moves rather slowly, I'm not aware of a constant flow of
annoying and useless tests coming in. There's quite a big number of
tests we 'always' had or for a long time though, most of them are
from upstream. It can't hurt to review the current state every once
in a while.

Mind compiling a list of pointless checks that should be removed? A
reasonable proposal can be discussed on the packaging list. Adding
some more ignore lines to the rpmlint package is easy once there is
consent.

rpmlint.opensuse.org¹ and whether or not a check is documented in
the wiki² can help with that. #1 failure in factory is
no-manual-page-for-binary for example.

cu
Ludwig

[1] http://rpmlint.opensuse.org/rules/openSUSE:Factory/x86_64/standard
[2] https://en.opensuse.org/openSUSE:Packaging_checks


--
  (o_   Ludwig Nussel
  //\
  V_/_  http://www.suse.com/
SUSE Linux GmbH, GF: Felix Imendörffer, Jane Smithard,
Graham Norton, HRB 21284 (AG Nürnberg)
--
To unsubscribe, e-mail: [hidden email]
To contact the owner, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: Tallying the quality of package descriptions

Michal Kubecek
In reply to this post by Stephan Kulow-3
On Friday, 19 May 2017 10:55 Stephan Kulow wrote:
> Put yourself in a reviewer's shoes for a moment. The rpmlint check
> about this summary thing is pretty old - and afaik not even a SUSE
> thing, but an upstream check.

Sure - but there was a proposal to promote this warning to an error.
I seriously doubt promoting it to an error would be significanly easier
than dropping it.

> Plus it's really easy to fix if you see it. And the fact that packages
> are submitted without it being fixed indicates to reviewers that
> people ignore rpmlint (and they are right as far as my person is
> concerned :).

Yes, easy to fix... Just talking about summary, IIRC it's

  - must not end with a period
  - must not start with uppercase (or lowercase? Can't remember) letter
  - must not start with an article
  - must not contain package name (which is funny if it's a common word)
  - must not be longer than description (even for subpackages)

Sometimes it's really frustrating; and after having to rebuild the whole
package just to hit another check, frustration quickly turns to anger.

> But if packagers ignore rpmlint, it's up to the reviewers to have a
> look if (more important) warnings were ignored. And this is a
> tiresome work and if you do it often a day your focus shifts towards
> details. Thankfully our review team *does* it often a day and it's an
> important part of our development process. So bear with them heading
> into details and support them by not questioning *everything* they
> say.

I do not question everything, far from it. As I said, I'm trying to
eliminate as many warnings as possible (except e.g. writing 20 manual
pages which do not exist in upstream). Even those I find pointless. But
if someone suggests to turn "summary should not end with a period" into
hard error, I'm sorry, that's way over the line.

Michal Kubeček

--
To unsubscribe, e-mail: [hidden email]
To contact the owner, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: Tallying the quality of package descriptions

Michal Kubecek
In reply to this post by Ludwig Nussel
On Friday, 19 May 2017 11:02 Ludwig Nussel wrote:
> rpmlint moves rather slowly, I'm not aware of a constant flow of
> annoying and useless tests coming in.

I have to admit I'm too lazy to distinguish between

  - rpmlint checks
  - OBS post build checks

Then there are also

  - spec cleaner quirks
  - personal quirks of a particular reviewer

While those groups are different in origin, in packager's eyes they all
add up to one pile of requirements he has to cope with.

> Mind compiling a list of pointless checks that should be removed? A
> reasonable proposal can be discussed on the packaging list. Adding
> some more ignore lines to the rpmlint package is easy once there is
> consent.

I'll try once I find some time for it.

Michal Kubeček

--
To unsubscribe, e-mail: [hidden email]
To contact the owner, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: Tallying the quality of package descriptions

Dominique Leuenberger / DimStar
In reply to this post by Stephan Kulow-3
On Fri, 2017-05-19 at 10:55 +0200, Stephan Kulow wrote:

> But if packagers ignore rpmlint, it's up to the reviewers to have a
> look
> if (more important) warnings were ignored. And this is a tiresome
> work
> and if you do it often a day your focus shifts towards details.
> Thankfully our review team *does* it often a day and it's an
> important
> part of our development process. So bear with them heading into
> details
> and support them by not questioning *everything* they say.
>
> Now I would like to stress that this goes into both directions -
> reviewers tend to forget how important the 99.9% are that make up
> packaging and are not summaries with dots. So they need to put
> themselves into 'imperfect packager's shows more often. Because I
> think
> "that will teach them" is a) a signal of abuse of power and b) a
> signal
> of 'us vs them', that is very unhealthy in this context.
>
> So please guys: work together not against each other.
I apologize for the bad wording in my mail - the ':)' after 'make it an
error' did obviously not give away sufficiently that this was not
entirely serious.

There are definitively other rpmlint warnings that would be worth more
effort than 'summary does not end in dot' (that one is a pure aesthetic
question - of course it appears 'weird' in YaST Software manager if the
packag summary is a sentence; and such details are in the end what
makes up a polished distro.

Keep in mind: you can have a technically perfect product, but if all
screens are full of spelling errors, you're still not going to take the
product serious.

The part which I was hiding in my message was rather: find an rpmlint
that is worth addressing to raise the quality, idnetify packages
currently failing the test and then start working on closing the gap.
Many of the rpmlints could simply do with 'more description' why
somebody thinks it is important. Once this becomes clear to packages,
many tend to actually have less trouble following them.

And, it does obviously not help that there are a bunch of rpmlint
checks that are simply wrong all the time (I mostly hit them around the
topics of shared library packages, where there keeps to be complaints
about missing deps in -devel and the like)

so recap: find hurting ones, fix them in the existing packages, find
false positives, report them as bug against rpmlint and get them away.
The more reliable rpmlint reports, the more we (the reviewers and
packagers) can actually take its output as reason for action.

Cheers,
Dominique

signature.asc (201 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Tallying the quality of package descriptions

Simon Lees-3
In reply to this post by Ludwig Nussel


On 05/19/2017 06:32 PM, Ludwig Nussel wrote:

> Michal Kubecek schrieb:
>> [...]
>> Do not take me wrong; in no way I want to say all checks are pointless.
>> But some of them definitely are ("summary should not end with a period"
>> is one of them) and I'm really worried to see that the overall attitude
>> among reviewers is that they should be enforced even harder rather than
>> discarded. And that more and more should be added.
>
> rpmlint moves rather slowly, I'm not aware of a constant flow of
> annoying and useless tests coming in. There's quite a big number of
> tests we 'always' had or for a long time though, most of them are
> from upstream. It can't hurt to review the current state every once
> in a while.
>
This is probably a reasonable step to take before making warnings more
visible.

> Mind compiling a list of pointless checks that should be removed? A
> reasonable proposal can be discussed on the packaging list. Adding
> some more ignore lines to the rpmlint package is easy once there is
> consent.

> rpmlint.opensuse.org¹ and whether or not a check is documented in
> the wiki² can help with that. #1 failure in factory is
> no-manual-page-for-binary for example.

I think that is certainly a candidate for removal, its certainly not
enforced or useful. Maybe we should consider patching rpmlint to add an
"Info" category, for example the "free software foundation address is
out of date" warning is a nice piece of info but we certainly shouldn't
be enforcing maintainers to go and fix it upstream but its still nice to
know it needs doing in case the packager feels like creating a upstream
bug for it.

>
> cu
> Ludwig
>
> [1] http://rpmlint.opensuse.org/rules/openSUSE:Factory/x86_64/standard
> [2] https://en.opensuse.org/openSUSE:Packaging_checks
>
>

--

Simon Lees (Simotek)                            http://simotek.net

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



signature.asc (499 bytes) Download Attachment
123