[opensuse-factory] Tallying the quality of package descriptions
./bullshit_graph.pl openSUSE/specs/*.spec | sort -gk2 | grep -v texlive- | grep -v ghc- | tail -n 15
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. 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: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
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 …
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: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
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: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
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: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
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
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
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: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
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: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
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
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: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
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: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
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: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On 05/19/2017 07:02 PM, Michal Kubecek wrote:
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)
Other then the "must not start with an article" which even I as a native English speaker don't understand, I think these are reasonable, when loading Yast to search for something the first thing you see is the package summary so personally I think maintaining reasonable quality summaries is important. Its also something that -- 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
On Fri, May 19, 2017 at 07:28:38PM +0930, Simon Lees wrote:
On 05/19/2017 07:02 PM, Michal Kubecek wrote:
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)
Other then the "must not start with an article" which even I as a native English speaker don't understand, I think these are reasonable, when loading Yast to search for something the first thing you see is the package summary so personally I think maintaining reasonable quality summaries is important. Its also something that
Such kind of "beautification" can however be just warnings and addressed by submission from people that care about them. Like Jan does for %description rewrites. Ciao, Marcus -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On 05/19/2017 11:58 AM, Simon Lees wrote:
On 05/19/2017 07:02 PM, Michal Kubecek wrote:
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)
Other then the "must not start with an article" which even I as a native English speaker don't understand, I think these are reasonable, when loading Yast to search for something the first thing you see is the package summary so personally I think maintaining reasonable quality summaries is important. Its also something that
Why is it not allowed to spell words with correct case-sensitivity, like iPhone, openSUSE or strerror(3)? Don't understand this especially because we don't even want real sentences ending with period. On the other hand spec-cleaner always translates the tag "URL:" into "Url:" although even "rpm -qi" shows URL. IMO it's more important to write technically correct rather than following all grammar rules strictly. Many of our implemented checks and services are not predictable and just annoying, non-understandable surprises when they appear as warnings, errors or even worse as silent auto re-formatting. cu, Rudi -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On Friday 2017-05-19 12:27, Rüdiger Meier wrote:
Other then the "must not start with an article" which even I as a native English speaker don't understand, I think these are reasonable, when loading Yast to search for something the first thing you see is the package summary so personally I think maintaining reasonable quality summaries is important. Its also something that
Why is it not allowed to spell words with correct case-sensitivity, like iPhone, openSUSE or strerror(3)?
That is a real rpmlint bug. The intent was probably to be helpful, but they botched it.
Don't understand this especially because we don't even want real sentences ending with period.
The summary is not a regular sentence. It need not have a subject nor a verb. Like with music pieces, it is something of a title (and before you ask, I am not going to enforce the camelugly Title Casing either, thankyouverymuch). For the same reason, they also do not need an article. In fact, such feels rather squatty and redundant in a list like kbounce A bounce ball game aisleriot A solitaire game for KDE dustrac A tile-based 2D racing game freeciv A Qt client for Freeciv freeciv A Gtk client for Freeciv ... ... 0ad-data The Data Files for 0 AD marble The KDE frontend for a globe thing tetrinet-server The GNU TetriNet server ... ... And if you have a case where the plural is used, there just is no room for an article anyway. blasphere Replacement files for "Heretic"
On the other hand spec-cleaner always translates the tag "URL:" into "Url:"
They redeclared that a "feature" (like some other issues) https://github.com/openSUSE/spec-cleaner/issues/55 I'd probably say: don't use that tool. -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On 05/19/2017 12:45 PM, Jan Engelhardt wrote:
On Friday 2017-05-19 12:27, Rüdiger Meier wrote:
Other then the "must not start with an article" which even I as a native English speaker don't understand, I think these are reasonable, when loading Yast to search for something the first thing you see is the package summary so personally I think maintaining reasonable quality summaries is important. Its also something that
Why is it not allowed to spell words with correct case-sensitivity, like iPhone, openSUSE or strerror(3)?
That is a real rpmlint bug. The intent was probably to be helpful, but they botched it.
Don't understand this especially because we don't even want real sentences ending with period.
The summary is not a regular sentence. It need not have a subject nor a verb. Like with music pieces, it is something of a title (and before you ask, I am not going to enforce the camelugly Title Casing either, thankyouverymuch). For the same reason, they also do not need an article. In fact, such feels rather squatty and redundant in a list like
kbounce A bounce ball game aisleriot A solitaire game for KDE dustrac A tile-based 2D racing game freeciv A Qt client for Freeciv freeciv A Gtk client for Freeciv
I wonder what's wrong here? Better "Yet another bounce ball game"? Just "bounce ball game" would sound odd to me. For me it's a valuable information that something is just *a* bounce ball game among others. "A bounce ball game" is IMO a very good summary and could be used for any other bounce ball game too.
... 0ad-data The Data Files for 0 AD marble The KDE frontend for a globe thing tetrinet-server The GNU TetriNet server ... ...
And if you have a case where the plural is used, there just is no room for an article anyway.
"A collection of bounce ball games" "Various bounce ball games" At the end it's just a matter of taste. Also note that sometimes such summaries or descriptions are just copy/pasted from upstream home pages. And why would I want to waste time rewording the upstream summary. For example echse: A cron daemon on RFC 5545 (ical) files It's perfect IMO. cu, Rudi
blasphere Replacement files for "Heretic"
On the other hand spec-cleaner always translates the tag "URL:" into "Url:"
They redeclared that a "feature" (like some other issues) https://github.com/openSUSE/spec-cleaner/issues/55 I'd probably say: don't use that tool.
-- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On 19.05.2017 14:56, Rüdiger Meier wrote:
At the end it's just a matter of taste.
And that's why a reviewer team harmonizing this is so valuable. And that's why it's good not to argue every little detail with them, but put some trust in *their* judgement. Greetings, Stephan -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On 19/05/17 08:56 AM, Rüdiger Meier wrote:
On 05/19/2017 12:45 PM, Jan Engelhardt wrote:
On Friday 2017-05-19 12:27, Rüdiger Meier wrote:
Other then the "must not start with an article" which even I as a native English speaker don't understand, I think these are reasonable, when loading Yast to search for something the first thing you see is the package summary so personally I think maintaining reasonable quality summaries is important. Its also something that
Why is it not allowed to spell words with correct case-sensitivity, like iPhone, openSUSE or strerror(3)?
That is a real rpmlint bug. The intent was probably to be helpful, but they botched it.
Don't understand this especially because we don't even want real sentences ending with period.
The summary is not a regular sentence. It need not have a subject nor a verb. Like with music pieces, it is something of a title (and before you ask, I am not going to enforce the camelugly Title Casing either, thankyouverymuch). For the same reason, they also do not need an article. In fact, such feels rather squatty and redundant in a list like
kbounce A bounce ball game aisleriot A solitaire game for KDE dustrac A tile-based 2D racing game freeciv A Qt client for Freeciv freeciv A Gtk client for Freeciv
I wonder what's wrong here? Better "Yet another bounce ball game"? Just "bounce ball game" would sound odd to me.
For me it's a valuable information that something is just *a* bounce ball game among others. "A bounce ball game" is IMO a very good summary and could be used for any other bounce ball game too.
... 0ad-data The Data Files for 0 AD marble The KDE frontend for a globe thing tetrinet-server The GNU TetriNet server ... ...
And if you have a case where the plural is used, there just is no room for an article anyway.
"A collection of bounce ball games" "Various bounce ball games"
At the end it's just a matter of taste. Also note that sometimes such summaries or descriptions are just copy/pasted from upstream home pages. And why would I want to waste time rewording the upstream summary. For example
echse: A cron daemon on RFC 5545 (ical) files
It's perfect IMO.
cu, Rudi
blasphere Replacement files for "Heretic"
On the other hand spec-cleaner always translates the tag "URL:" into "Url:"
They redeclared that a "feature" (like some other issues) https://github.com/openSUSE/spec-cleaner/issues/55 I'd probably say: don't use that tool.
What if it was named ball bounce game? -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
* Roman Bysh
On 05/20/2017 04:32 AM, Roman Bysh wrote:
On 19/05/17 08:56 AM, Rüdiger Meier wrote:
On 05/19/2017 12:45 PM, Jan Engelhardt wrote:
On Friday 2017-05-19 12:27, Rüdiger Meier wrote:
The summary is not a regular sentence. It need not have a subject nor a verb. Like with music pieces, it is something of a title (and before you ask, I am not going to enforce the camelugly Title Casing either, thankyouverymuch). For the same reason, they also do not need an article. In fact, such feels rather squatty and redundant in a list like
kbounce A bounce ball game aisleriot A solitaire game for KDE dustrac A tile-based 2D racing game freeciv A Qt client for Freeciv freeciv A Gtk client for Freeciv
I wonder what's wrong here? Better "Yet another bounce ball game"? Just "bounce ball game" would sound odd to me.
For me it's a valuable information that something is just *a* bounce ball game among others. "A bounce ball game" is IMO a very good summary and could be used for any other bounce ball game too.
What if it was named ball bounce game?
We would probably allow it and maybe ask you to suppress that particular warning. -- 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
On Fri, 2017-05-19 at 12:45 +0200, Jan Engelhardt wrote:
aisleriot A solitaire game for KDE
That's fake news - aisleriot is a GNOME App. (and I think you just wanted to make a point, right? because that's not the summary aisleriot has: Name : aisleriot Summary : Solitaire Card Games for GNOME Cheers, Dominique
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
On 05/19/2017 11:56 AM, Dominique Leuenberger / DimStar wrote:
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.
I can recommend "codespell" to find typos or other simple spelling errors often made by developers. Maybe we could run this a few times per year manually on the whole project.
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
-- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On 5/19/2017 5:56 AM, Dominique Leuenberger / DimStar wrote: 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.
Yast software manager could strip a trailing dot from it's own display itself if that is the special context where a trailing dot is undesired. Make the computer work for the humans, not the other way around. -- bkw -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
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: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
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: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
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
Simon Lees schrieb:
[...] Maybe we should consider patching rpmlint to add an "Info" category, for example the "free software foundation address is
rpmlint does have an info category but this particular test reports an error: https://github.com/rpm-software-management/rpmlint/blob/master/Filter.py#L45 https://github.com/rpm-software-management/rpmlint/blob/master/FilesCheck.py... cu Ludwig -- (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: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
Apologies these are coming through out of order, thunderbird had a Heart attack On 05/19/2017 06:14 PM, Michal Kubecek wrote:
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.
Well as someone who is mostly a package maintainer (and only joined the review team 3 months ago) the only ones I find really annoying are the .desktop file related ones there annoying as (but at the same time those ones are important). All the rest I check the first time I create a package which generally takes 5 minutes and then you don't need to bother again.
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.
Well as reviewers our job is to enforce the "standard of quality" that the project has decided it wants to keep as the saying goes "we don't make the rules we just enforce them." The right place to change those rules is here so atleast were discussing it in the right place :-) As for the rule in question personally I don't mind either way but i'm hardly one who cares to use correct proper english all the time. There are other people, however, who do care about these things and want summaries to be consistent (same with desktop files) -- 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
Hi all,
On Fri, May 19, 2017 at 7:46 AM, Michal Kubecek
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: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
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: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
Hello, On May 19 10:58 Simon Lees wrote (excerpt):
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. ...
On 05/19/2017 12:30 AM, Dominique Leuenberger / DimStar wrote: 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: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On 18/05/2017 17:00, 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
obs-service-format_spec_file fixes the copyright date, why can't it remove the summary dot? Dave P -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
Hello, Am Sonntag, 21. Mai 2017, 08:51:14 CEST schrieb Dave Plater:
obs-service-format_spec_file fixes the copyright date, why can't it remove the summary dot?
I'm afraid it isn't that easy ;-) I'd guess (without having checked all the 51 packages) that the dot indicates the summary is a full sentence, which it shouldn't be. So removing the dot will cure the symptoms, but it won't rewrite the summary to something better. Besides that - we are talking about 51 packages here. Changing them manually (and, while on it, rewriting the summary if necessary) might be a boring task, but it's probably faster than adding the "goodbye dots" feature to obs-service-format_spec_file ;-) And if you find a package where the dot in the summary really makes sense, I'd recommend to add a rpmlintrc. This will hide the warning and make the reviewer's job easier (less rpmlint "noise"). No, I don't expect to see a package which really needs a summary ending with a dot, but I'm sure there are false positive rpmlint warnings where a rpmlintrc makes sense. Just as a very obvious (and funny) example, have a look at the libreoffice rpmlint results: [...] libreoffice-math.i586: W: shlib-policy-nonversioned-dir /usr/lib/libreoffice Your shared library package contains non-versioned directories. Those will not allow to install multiple versions of the package in parallel. [...] libreoffice-math.i586: W: shlib-policy-missing-lib Your package starts with 'lib' as part of its name, but does not provide any libraries. It must not be called a lib-package then. Give it a more sensible name. [...] Looks like libreoffice is terribly violating the policy for packaging shared libraries ;-) No, it's not, it "just" has package names starting with "lib", so this would be a perfect candidate for a rpmlintrc ;-) Regards, Christian Boltz -- Some gone-crazy stupid laywer filled tags with *PAGES* of license restriction. Overwhelming mass of data made fontlinge_base believe the font to be broken. - increased limits - going to get a gun [Ratti in fontlinge-cvs] -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
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: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 On 2017-05-18 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.
What about those plugins that get the exact same description as the main package? There is no way to know what the add on is for except guessing from its name. - -- Cheers / Saludos, Carlos E. R. (from 42.2 x86_64 "Malachite" (Minas Tirith)) -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iF4EAREIAAYFAlke0VsACgkQja8UbcUWM1yzfwD/beXuvaKbEMfreRIVDtN7dOiB BuakSiXOsbIfoMNJ+FoA/0a2YVUJ/nptnvvdKwUPT6fKJY/Rqwzf1/lqpQQTiVwz =Uq8B -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On 05/19/2017 08:34 PM, Carlos E. R. wrote:
On 2017-05-18 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.
What about those plugins that get the exact same description as the main package? There is no way to know what the add on is for except guessing from its name.
If someone goes to the effort of creating better descriptions and files a bug report with them then they'll probably get updated, alternatively creating a OBS account and submitting new descriptions is probably easier. -- 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
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 On 2017-05-19 13:27, Simon Lees wrote:
On 05/19/2017 08:34 PM, Carlos E. R. wrote:
What about those plugins that get the exact same description as the main package? There is no way to know what the add on is for except guessing from its name.
If someone goes to the effort of creating better descriptions and files a bug report with them then they'll probably get updated, alternatively creating a OBS account and submitting new descriptions is probably easier.
That might be if I knew the appropriate descriptions. - -- Cheers / Saludos, Carlos E. R. (from 42.2 x86_64 "Malachite" (Minas Tirith)) -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iF4EAREIAAYFAlke2TwACgkQja8UbcUWM1zDKwD+JI1O/JF2bc2PI8dEJyIymNyb Mr+nPpi2ovKunqjs294A/A0YvmnaQEw6iPvV3aJxnfizlV254H2uvOqfyjviLOGt =1SON -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On Friday 2017-05-19 13:38, Carlos E. R. wrote:
If someone goes to the effort of creating better descriptions and files a bug report with them then they'll probably get updated, alternatively creating a OBS account and submitting new descriptions is probably easier.
That might be if I knew the appropriate descriptions.
If you cannot describe what a software does (or at least: is supposed to do) in your own terms, should you even be running that software on your computer which has all your zeecret data? I know that doing so is popular on Windows, but let's not lower the bar further ;-) -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 On 2017-05-19 14:08, Jan Engelhardt wrote:
On Friday 2017-05-19 13:38, Carlos E. R. wrote:
If someone goes to the effort of creating better descriptions and files a bug report with them then they'll probably get updated, alternatively creating a OBS account and submitting new descriptions is probably easier.
That might be if I knew the appropriate descriptions.
If you cannot describe what a software does (or at least: is supposed to do) in your own terms, should you even be running that software on your computer which has all your zeecret data?
I know that doing so is popular on Windows, but let's not lower the bar further ;-)
How am I to know? That's why I read the descriptions. I suppose the maintainer may know, but not me. I have to guess what the plugin does, and if not sure, install them all, just in case. One example: kodi. Yes, this one is in packman, so not an official package, but it is the easiest to find for this example. kodi.binary-addons-audiodecoder.2sf - Kodi audiodecoder.2sf binary addon Kodi audiodecoder.2sf binary addon .. kodi.binary-addons-audiodecoder.fluidsynth - Kodi audiodecoder.fluidsynth binary addon Kodi audiodecoder.fluidsynth binary addon .. kodi.binary-addons-audiodecoder.gme - Kodi audiodecoder.gme binary addon Kodi audiodecoder.gme binary addon Frankly, as a user I don't care if the summary ends in a dot or not. But the above descriptions, and there are a dozen or two addons, are useless. On some packages (no, sorry, I don't remember names) the description for the plugins are exactly the same as for the main package. I looked at some others. Thunar, libreoffice, dolphin, nautilus have small but useful descriptions. There was one - -- Cheers / Saludos, Carlos E. R. (from 42.2 x86_64 "Malachite" (Minas Tirith)) -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iF4EAREIAAYFAlkfCdUACgkQja8UbcUWM1xrfAD+IPKCfNpC74gm/+0zkdbffHHc 2wp10F4E2hEdBZpW9WMBAIUG8FHqaLipQgP3j1G322yJJzVNUJRpF0hk8VnRpazt =Jdad -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On 5/19/2017 8:08 AM, Jan Engelhardt wrote:
On Friday 2017-05-19 13:38, Carlos E. R. wrote:
If someone goes to the effort of creating better descriptions and files a bug report with them then they'll probably get updated, alternatively creating a OBS account and submitting new descriptions is probably easier.
That might be if I knew the appropriate descriptions.
If you cannot describe what a software does (or at least: is supposed to do) in your own terms, should you even be running that software on your computer which has all your zeecret data?
I know that doing so is popular on Windows, but let's not lower the bar further ;-)
Spoken like someone who has not installed software since 1978 when there used to be such things as discreet programs that didn't have 400 dependencies. It's not helping anyone to pretend the complaint has no basis. -- bkw -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On 05/19/2017 07:08 AM, Jan Engelhardt wrote:
If you cannot describe what a software does (or at least: is supposed to do) in your own terms,
Ahh, But the issue is "If you cannot describe what a software does (or at least: is supposed to do) in your own terms"... and within the confines of what some else's cobbled together python script decides it needs to be described as... 1) do you get frustrated with the additional hour trying to figure out why you continue to get obscure warnings -- and say F'it? ; or 2) do you continue picking through the awkwardly worded constraints and warnings until you hit of a description that the script likes -- because you have an endless amount of free time to play with such things? ... Yes, an acceptable level of uniformity is a good thing, and is required, but when the constraints multiply like weeds in a vacant lot and become a collection of checks overly concerned with trivial details -- you will lose a lot of needed help from those without endless time or patients from a frustration standpoint. Balance and sanity are sometimes needed. After all, whether the description ends with a '.' or not, doesn't make a damn bit of difference to how the software preforms, but the continual warnings that send someone back to a clumsy OBS editor time after time, or require multiple resubmission of packages may just lead to a F'it! That is what I see the proliferation of constraints balanced against. Just my 0.02. I hit this issue about a year ago, maybe more, and I don't recall the exact package, but I think it was libharu (pdf library). I built it locally with the provides .spec and it worked flawlessly, but OBS choked with reams of warnings and errors. After license lookups (that IS important) and some other relevant changes, the nit-picking simply became an effort in futility and I had no more time to devote to the OBS build of that one package. 5 years ago, there wouldn't have been an issue and at least the community could have had the benefit of the package and submitted changes for those additional nits that needed attention. Just something to consider as you weigh turning another nit into a hard constraint. -- David C. Rankin, J.D.,P.E. -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
Am 21.05.2017 um 03:36 schrieb David C. Rankin:
On 05/19/2017 07:08 AM, Jan Engelhardt wrote:
If you cannot describe what a software does (or at least: is supposed to do) in your own terms,
Ahh,
But the issue is "If you cannot describe what a software does (or at least: is supposed to do) in your own terms"... and within the confines of what some else's cobbled together python script decides it needs to be described as...
1) do you get frustrated with the additional hour trying to figure out why you continue to get obscure warnings -- and say F'it? ; or
2) do you continue picking through the awkwardly worded constraints and warnings until you hit of a description that the script likes -- because you have an endless amount of free time to play with such things? ...
Yes, an acceptable level of uniformity is a good thing, and is required, but when the constraints multiply like weeds in a vacant lot and become a collection of checks overly concerned with trivial details -- you will lose a lot of needed help from those without endless time or patients from a frustration standpoint.
Balance and sanity are sometimes needed. After all, whether the description ends with a '.' or not, doesn't make a damn bit of difference to how the software preforms, but the continual warnings that send someone back to a clumsy OBS editor time after time, or require multiple resubmission of packages may just lead to a F'it!
That is what I see the proliferation of constraints balanced against. Just my 0.02.
I hit this issue about a year ago, maybe more, and I don't recall the exact package, but I think it was libharu (pdf library). I built it locally with the provides .spec and it worked flawlessly, but OBS choked with reams of warnings and errors. After license lookups (that IS important) and some other relevant changes, the nit-picking simply became an effort in futility and I had no more time to devote to the OBS build of that one package.
5 years ago, there wouldn't have been an issue and at least the community could have had the benefit of the package and submitted changes for those additional nits that needed attention. Just something to consider as you weigh turning another nit into a hard constraint.
+1 This is a community distro and not a uniform coroporate distro. Please consider allowing the packagers some more headroom and remove some of those warnings or turn them into infos. If a script would try to teach me how to write the perfect package description I may just leave, because I did not come to be tought but to add something useful. Of course some rules of contribution are needed, but the less, the better those few rules are heard by the many because they seem or even are more important. And to me as a user the polish/quality of a distro is more determined by the amount of software thats included in official repos than the uniformity of their description. Thx for all your hard work! -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
participants (21)
-
Andrea Controzzi - LedMania.it -
Andreas Färber -
Brian K. White -
Carlos E. R. -
Christian Boltz -
Dave Plater -
David C. Rankin -
Dominique Leuenberger / DimStar -
Jan Engelhardt -
Johannes Meixner -
Ludwig Nussel -
Marcus Meissner -
Michal Kubecek -
Patrick Shanahan -
Roman Bysh -
Rüdiger Meier -
Simon Lees -
Stefan Knorr -
Stephan Kulow -
Thomas Langkamp -
Thorsten Kukuk