[opensuse-factory] why there are so few packages in Factory, revisited
Hello, you might remember recent discussion in opensuse-factory mailing list on this topic. While the statistics that started it were inherently flawed, there seemed to be a consensus that Factory doesn't have as many packages as it could and that there are many packages in devel projects or home projects that are never submitted to Factory. I considered sending my opinion why but I was afraid it might start a flame without any positive outcome. Recent experience conviced me to try anyway. Disclaimer: the sole purpose of this e-mail is to present my view on the problem and to give responsible people something to think about. It is definitely not meant as a complaint about the particular case (which serves only as an example) or some kind of pointing fingers. Short version: I believe main reason why too many packages never move from home or devel projects to Factory is that on one hand, OBS made it extremely easy to build a package for a set of distributions and even add your own repository with such packages; on the other hand, once you decide to get the Factory, you have to tackle constantly increasing amount of "bureaucracy" to even get the package in and then face a stream of pointless changes in the name of some high standards which are apparently constantly changing and actually not even universally accepted at any given moment. There is a popular phrase about "scratching an itch". The problem, as I see it, is that to scratch one's itch, home project is sufficient. If you are an altruist, you might even push the package into a devel project so that it stands out in the search. But getting it into Factory, that's no more about scratching your itch; you must have really strong motivation for that - and even stronger to do it again once you know what you are going to face. Let's look at an example. Few years ago, I discovered tcpreplay, a set of network utilities which are quite handy when investigating networking issues. I created a package, did my best to avoid OBS warnings and put it into a project under my home so that I could easily install it on my machines. That scratched my itch. Later some guy created a submit request for network:utilities; I checked the package, updated it to new versions, did some cleanup and package ended up in network:utilities. After the December discussion, I decided to submit the tcpreplay to Factory. I checked the build, polished the specfile a bit and submitted it. The request was declined by a check script because a copyright was missing. OK, fair enough, while I don't consider that particular specfile such a great piece of art to need a copyright, why not. I ran the specfile through the spec cleaner service (which often happens automatically with "osc build" but for some reason this wasn't the case). It did some rearrangement and style changes; some I didn't quite like but nothing crucial, so I resubmitted the package. With that submit request still waiting in staging repo, on Sunday I got a request against network:utilities. I didn't have time to review it so I left it to the morning. Before I could do so, 5 hours after creation of the request, to my surprise, it was accepted by the guy who originally poked me to submit the package to network:utilities (but never contributed to the package in any way since). I checked the changes anyway (after all, I'm bugowner so I feel responsible for the package) and I really don't know what to think: https://build.opensuse.org/package/rdiff/network:utilities/tcpreplay?linkrev=base&rev=5 - replace xz compressed tarball by the original gzipped one For years I've been told by OBS that I should repack gzipped tarballs to save resources. It's not true any more? OK, it allows for checking the signature so it makes sense. - make BuildRoot specification unconditional For years I've been told that it is obsolete. The only reason I keep it is to allow build for SLE11. Why forcing it on distributions that don't need it? - replace source files by full URL I don't like this change. More precisely: I hate it. - add "-q" to %setup Why? No idea. - add "V=1" to make Why? To make build warnings harder to see? - break configure line into two If it needed breaking, I would do so. This one had 32 characters... Seriously? - replace ${RPM_BUILD_ROOT} with %{buildroot} The only rule I have ever seen about this was there is no rule. - add %{?_smp_mflags} also to make install Well, why not. But definitely not _after_ the argument. - add LICENSE to the package OK, why not. - %files: expand wildcards to explicit lists Some people apparently prefer package build to fail whenever a file is added or renamed. I don't force them not to do so in their packages, could they respect my preferences in mine? Apparently not. - reorder tags in specfile header I'm confused. The previous order was what spec cleaner did. Wasn't it supposed to be The Right Order(TM)? And what happens next time spec cleaner service is run? Is it going to change the order back, masking real changes? Summary: lot of meaningless churn, one useful change, two I dislike and two (or two and a half) I really dislike. And a bad feeling that while I took responsibility for the package, I apparently have no say in what should its specfile look like. Don't understand me wrong: I have no problem with reasonable rules, even if they are quite strict (like the tagging policy in our kernel packages or strict coding style policy in kernel networking). But here I feel this crosses a line of harassment. OK, I'll learn to live with it. I'll bite the bullet with packages like firebird or twinkle which are kind of "heart thing". But next time I stumble upon a package that might be useful, I'll think twice before submitting it to Factory. Had I known what was going to happen, well, there would be one less package in Factory (assuming tcpreplay is going to make it). And just today, I got a reaction like "Been there. I know exactly what you are talking about." Sure, you may say that it's my fault I don't understand openSUSE high standards. You might even say openSUSE is not interested in packagers who don't understand its high standards. But you should understand in the end it's always packager's choice if he is going to submit the package to Factory or not. And remember, to "scratch an itch", putting it into a home project is enough in most cases; submitting to Factory is not about "scratching an itch", it's about helping others; things like this work as an active discouragement. Think about it next time you ask yourself why so many packages stay in home or devel project without ever being submitted to Factory. Or, even better, think about it next time you feel urge to completely rearrange a package you are not maintaining (and not going to) just to force your aesthetic criteria on it (and its maintainer). Michal Kubeček -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
Michal, et.al. Let me first tell you: I understand your frustration. And the fact that somebody with a project maintainer role oversteps the package maintainer, giving him 5 hours of notice period, is bad behavior. I stronlgy encourage the two of you to talk this out directly. As to the points you list in the 'change set', I only want to give some small words there (from a opensuse-review team perspective - but it's my own, which I hope the rest of the reviewer team shares). On Tue, 2016-02-02 at 00:10 +0100, Michal Kubecek wrote:
- replace xz compressed tarball by the original gzipped one For years I've been told by OBS that I should repack gzipped tarballs to save resources. It's not true any more? OK, it allows for checking the signature so it makes sense.
Most of the distro packages switched to using the prisitine upstream tarball quite a while ago, especially for checking signatures, and, as I will explain in pioint 3
- make BuildRoot specification unconditional For years I've been told that it is obsolete. The only reason I keep it is to allow build for SLE11. Why forcing it on distributions that don't need it?
It is indeed needed for SLE11; I have no strong pro or contra if it should be provided for non-SLE11 builds, but it's purely used during the build phase, so does not impact the resulting package. So it comes down to: do you prefer a condition without added value in your spec file? Or do you prefer a 'plain' readable one with as few churn as possible. As you stated: it's your package - your choice.
From a Factory Reviewer PoV: no objection either way. YOUR CHOICE!
- replace source files by full URL I don't like this change. More precisely: I hate it.
It has one big advantage: trust! Every package submitted to openSUSE:Factory, the review bot actually downloads the tarball from the URL in the Source line and verifies that the submitted one actually IS The one it's supposed to be. This avoids that a packager can inject anything into a tarball (as you can imagine, there are not sufficient resources to manually review all the submitted code - we need to be able to trust one another. The URL as Source allows to automate it)/
- add "-q" to %setup Why? No idea.
Again, personal choice. Factory Reviewer accepts either way. The most notable thing '-q' does here is not list the entire content of the extracted tarball... so making the build log 'neater'
- add "V=1" to make Why? To make build warnings harder to see?
A constant battle - I know that one. I myself consider V=1 great for debug perpose... as long as gcc's warnings are there if it's not specified, I don't enable it.
- break configure line into two If it needed breaking, I would do so. This one had 32 characters... Seriously?
That's really a strange one to even think to enforce. Certainly, no packaging guideline exists around this topic. And obviously, there are cases it makes sense to split the lines, there are others it's useless. Your case seems to be the latter.
- replace ${RPM_BUILD_ROOT} with %{buildroot} The only rule I have ever seen about this was there is no rule.
There is a small difference in the expansion of the variable: does bash do it (${}) or does rpm do it %{}. The value is the same. style-wise, many prefer the lower case writing style (spec-cleaner does change this one to).
- add %{?_smp_mflags} also to make install Well, why not. But definitely not _after_ the argument.
Parallel installation - how big is that package :) I doubt it makes much difference (but then: the latest version of spec-cleaner does this automatically IIRC - so the submitter might not have done this explicitly)
- add LICENSE to the package OK, why not.
Actually mandatory to pass legal review. Which, by the way, is what the current submission to openSUSE:Factory is pending at: https://build.ope nsuse.org/request/show/356511 (not staging per se.... just that it can only move out of staging once all review steps are handled)
- %files: expand wildcards to explicit lists Some people apparently prefer package build to fail whenever a file is added or renamed. I don't force them not to do so in their packages, could they respect my preferences in mine? Apparently not.
Indeed - personal style to chose. From experience, I use explicit lists when it's about a lot of plugin-style files that get auto-enabled based on deps. Like this, I see when a dep goes missing: the build fails.
- reorder tags in specfile header I'm confused. The previous order was what spec cleaner did. Wasn't it supposed to be The Right Order(TM)? And what happens next time spec cleaner service is run? Is it going to change the order back, masking real changes?
Sometimes, new version of spec cleaner might do it different. Only solution is for us all to run the same version of the tool.
Summary: lot of meaningless churn, one useful change, two I dislike and two (or two and a half) I really dislike. And a bad feeling that while I took responsibility for the package, I apparently have no say in what should its specfile look like. Don't understand me wrong: I have no problem with reasonable rules, even if they are quite strict (like the tagging policy in our kernel packages or strict coding style policy in kernel networking). But here I feel this crosses a line of harassment.
I agree that there are quite some questionable changes forced into your package. As an active maintainer, I actually suggest you to REVERT the change and implement the changes you like on your own. Don't play around: You are the maintainer of the package, you care for it. Show it - revert.
OK, I'll learn to live with it. I'll bite the bullet with packages like
Please don't just learn to live with it! Your approach to bring this up here is absolutely perfect and I hope peopple take this constructive critic on when they do changes. Do not step on each others feet, but collaborate!
firebird or twinkle which are kind of "heart thing". But next time I stumble upon a package that might be useful, I'll think twice before submitting it to Factory. Had I known what was going to happen, well, there would be one less package in Factory (assuming tcpreplay is going to make it). And just today, I got a reaction like "Been there. I know exactly what you are talking about."
In the hopes not to lose your spirit of helping others with your work: please re-consider... your packages are welcome in the distribution.
Sure, you may say that it's my fault I don't understand openSUSE high standards. You might even say openSUSE is not interested in packagers who don't understand its high standards. But you should understand in the end it's always packager's choice if he is going to submit the package to Factory or not. And remember, to "scratch an itch", putting it into a home project is enough in most cases; submitting to Factory is not about "scratching an itch", it's about helping others; things like this work as an active discouragement.
Whereas it's true that we have packaging guidelines, and some rules we enforce stricter than others: ever tried to submit something to Debian? :) Jokes aside: our guidelines are there to 'guide' - some of the rules are strictly enforced (most of them by a bot!), the review team tries to 'see more common errors' and things the bot might mis-understand (like: static libs: they are a no-go, except when done properly and documented and fully considered - so the bot can't know)
Think about it next time you ask yourself why so many packages stay in home or devel project without ever being submitted to Factory. Or, even better, think about it next time you feel urge to completely rearrange a package you are not maintaining (and not going to) just to force your aesthetic criteria on it (and its maintainer).
Thank you Michal for bringing this up! I agree: aestethics are not a reason for a decline (even though I can assure you that a spec that looks ugly and is more cryptic to read than needed will likely make it to the 'end of the review queue'). For me, the important message in this entire thing is to ALL contributors: contribute to any package you want - be active, but if there is a person dedicated to maintain it (and this person is still active): let this person have a word if he/she likes the change. There are 'teams' building around certain packages, where people talk together and come to a common view on how they want to maintain it - so they jointly do the work, sometimes with, sometimes without consulting. There are even larger projects where NO maintainer in the project is supposed to accept his own change! Strict 4-eye peer review even before stuff moves to Factory. This is not mandatory in OBS - but if the active maintainer so wishes, it is to be respected. Cheers, Dominqiue -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On Tuesday 2016-02-02 00:10, Michal Kubecek wrote:
Short version: I believe main reason why too many packages never move [...] to Factory is that [...] you have to tackle constantly increasing amount of "bureaucracy" to even get the package in
If you think openSUSE suffers from a bureaucracy problem, just wait until you look elsewhere. Fedora: https://fedoraproject.org/wiki/Join_the_package_collection_maintainers Let's just work down that list, and compare with openSUSE: * no hard requirement to join mailing lists * no hard requirement to inform upstream * no need for the sponsoring game (but maybe that's implicit in the review in openSUSE) * reviews usually go a lot faster than what I can find on [ https://fedoraproject.org/PackageReviewStatus/NEEDSPONSOR.html ], feels like a lot less bikeshedding in openSUSE:Factory. Debian: https://www.debian.org/devel/join/ https://www.debian.org/devel/join/newmaint * No "application", no "recommendation", no "membership" needed In a way, openSUSE is more like github. Register a (technical) account, create/fork, submit, and pretty much done.
Let's look at an example. [...] tcpreplay
- replace xz compressed tarball by the original gzipped one For years I've been told by OBS [...]
That's now years away. 4 maybe? Please don't tell me you just joined SUSE.
- make BuildRoot specification unconditional For years I've been told that it is obsolete. The only reason I keep it is to allow build for SLE11. Why forcing it on distributions that don't need it?
Not mandated by factory. Artifact of a bunch of formatter scripts that are advertised as helpful.
- replace source files by full URL I don't like this change. More precisely: I hate it.
Not mandated by factory. (But contributors will keep suggesting it to you.)
- add "-q" to %setup Why? No idea.
Not mandated by factory.
- add "V=1" to make Why? To make build warnings harder to see?
Neither V=0 nor V=1 is mandated by openSUSE:Factory. (Some contributors may suggest V=1 to you if they once ended in a position where they had to recompile your package just to verify their hypothesis that a bad compiler flag snuck in (or out).)
- break configure line into two If it needed breaking, I would do so. This one had 32 characters... Seriously?
Not mandated by factory. Talk to the guy who edited your package out-of-band / who made that funny SR to your package.
- replace ${RPM_BUILD_ROOT} with %{buildroot} The only rule I have ever seen about this was there is no rule.
1. Blame the formatting scripts you are running, explicitly or implicitly. 2. The guidelines can change over time. If you find time, please give new wiki page versions a read.
- add %{?_smp_mflags} also to make install Well, why not. But definitely not _after_ the argument.
No particular order is mandated by factory.
- %files: expand wildcards to explicit lists Some people apparently prefer package build to fail whenever a file is added or renamed. I don't force them not to do so in their packages, could they respect my preferences in mine? Apparently not.
Neither variant is mandated by factory.
- reorder tags in specfile header I'm confused. The previous order was what spec cleaner did. Wasn't it supposed to be The Right Order(TM)? And what happens next time spec cleaner service is run? Is it going to change the order back, masking real changes?
Yes of course. And they may change %rickastley to %{rickastley}. Let me repeat -- some cleaning tools suck, and you should avoid using them if they do not do what you want them to do.
Summary: lot of meaningless churn
Almost none of which are factory issues.
while I took responsibility for the package, I apparently have no say in what should its specfile look like.
If you are the Real Maintainer (socially), you get to decide. Do not let people with "maintainer" roles, and in particular, inherited prj-level "maintainer" roles, dictate you something. (Special exceptions for topical groups, like KDE:/, GNOME:/, but not the unordered hordes of devel:libraries:c_c++/, games/, science/... list is non-exhaustive.) If I may be so bold, I have been making examples of these stylistic freedoms for a long time. `osc my pkg` says something around 400, no idea what percentage is currently in factory, but it is sizable. That speaks. Your experience appears to have been an isolated incident not connected with factory, but with a prj-level "maintainer" role. Sometimes I really have to cringe at some specfiles and wonder how they got through the opensuse factory review team. I do not want to say openSUSE is the sloppiest distros of all, but claiming openSUSE has too high a specfile standard is just untrue. -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
Jan Engelhardt wrote:
Sometimes I really have to cringe at some specfiles and wonder how they got through the opensuse factory review team. I do not want to say openSUSE is the sloppiest distros of all, but claiming openSUSE has too high a specfile standard is just untrue.
Personally two things annoying me: 1. Some reviewers insist on adding a lot of lines to .changes files claiming that there are common practices to do so. But many packages do this differently. And personally I think it's plain wrong to add all upstream changes to fit into .changes when simply updating to a new upstream release. 2. Often I just want to contribute a new upstream release to an existing package and then after submitting it I'm expected to clean up the .spec (which I did not produce) to comply to new guide-lines. Sometimes I do but sometimes I just do not have the time and give up. Ciao, Michael.
Am Dienstag, 2. Februar 2016, 08:25:20 schrieb Michael Ströder:
Jan Engelhardt wrote:
Sometimes I really have to cringe at some specfiles and wonder how they got through the opensuse factory review team. I do not want to say openSUSE is the sloppiest distros of all, but claiming openSUSE has too high a specfile standard is just untrue.
Personally two things annoying me:
1. Some reviewers insist on adding a lot of lines to .changes files claiming that there are common practices to do so. But many packages do this differently. And personally I think it's plain wrong to add all upstream changes to fit into .changes when simply updating to a new upstream release.
+1 if someone is really interested in details, reading the changelog upstream should be sufficient. Axel -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On Tue, Feb 02, 2016 at 12:49:46AM +0100, Dominique Leuenberger / DimStar wrote:
Michal, et.al.
- add "V=1" to make Why? To make build warnings harder to see?
A constant battle - I know that one. I myself consider V=1 great for debug perpose... as long as gcc's warnings are there if it's not specified, I don't enable it.
Actually we are parsing the gcc commandline to spot if you are using optflags and do some post build checks. (post-build-checks, check_gcc)
- add %{?_smp_mflags} also to make install Well, why not. But definitely not _after_ the argument.
Parallel installation - how big is that package :) I doubt it makes much difference (but then: the latest version of spec-cleaner does this automatically IIRC - so the submitter might not have done this explicitly)
I fixed several packages that build fine with -j2 but did not with -j8, which was annoying. so this actually has the cause to break things, but it is rare. Ciao, Marcus -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On úterý 2. února 2016 8:35:56 CET Marcus Meissner wrote:
On Tue, Feb 02, 2016 at 12:49:46AM +0100, Dominique Leuenberger / DimStar wrote:
Michal, et.al.
- add "V=1" to make Why? To make build warnings harder to see?
A constant battle - I know that one. I myself consider V=1 great for debug perpose... as long as gcc's warnings are there if it's not specified, I don't enable it.
Actually we are parsing the gcc commandline to spot if you are using optflags and do some post build checks. (post-build-checks, check_gcc) Indeed there are actually several cases when lack of of usage of optflags was not observed due to silent build, such as in ninja, thin-provisioning tools and himeno - and those are just few cases which I noticed in last few days.
- add %{?_smp_mflags} also to make install Well, why not. But definitely not _after_ the argument.
Parallel installation - how big is that package :) I doubt it makes much difference (but then: the latest version of spec-cleaner does this automatically IIRC - so the submitter might not have done this explicitly)
I fixed several packages that build fine with -j2 but did not with -j8, which was annoying. so this actually has the cause to break things, but it is rare.
Ciao, Marcus
On Tue, 02 Feb 2016 00:10:13 +0100, Michal Kubecek wrote:
I checked the changes anyway (after all, I'm bugowner so I feel responsible for the package) and I really don't know what to think:
Looking at each point, some of them seem to make sense to me. Let's see:
https://build.opensuse.org/package/rdiff/network:utilities/tcpreplay?linkrev=base&rev=5
- replace xz compressed tarball by the original gzipped one For years I've been told by OBS that I should repack gzipped tarballs to save resources. It's not true any more? OK, it allows for checking the signature so it makes sense.
Yeah, recently the original tarball is more recommended. It allows to check the validity of the included source. I thought there is even an automatic service to do that.
- make BuildRoot specification unconditional For years I've been told that it is obsolete. The only reason I keep it is to allow build for SLE11. Why forcing it on distributions that don't need it?
This is a matter of taste, IMO.
- replace source files by full URL I don't like this change. More precisely: I hate it.
It looks ugly, but it allows again the automatic source tarball check. It's good for security.
- add "-q" to %setup Why? No idea.
For reducing the many lines in the log. Mostly a matter of taste, though.
- add "V=1" to make Why? To make build warnings harder to see?
It shows the compile flags so that the build service can catch incompatible or missing compile flags (like PIE or such). So, this is safer to set for most cases.
- break configure line into two If it needed breaking, I would do so. This one had 32 characters... Seriously?
Really a matter of taste. I can imagine that breaking per word would make patching easier, but nothing more than that.
- replace ${RPM_BUILD_ROOT} with %{buildroot} The only rule I have ever seen about this was there is no rule.
Some people are too stubborn :)
- add %{?_smp_mflags} also to make install Well, why not. But definitely not _after_ the argument.
Hmm, does the order of option have influence on make's behavior?
- add LICENSE to the package OK, why not.
IIRC, this is mandatory nowadays because OBS won't modify the spec file any longer like before.
- %files: expand wildcards to explicit lists Some people apparently prefer package build to fail whenever a file is added or renamed. I don't force them not to do so in their packages, could they respect my preferences in mine? Apparently not.
Yeah, I prefer wildcards, too.
- reorder tags in specfile header I'm confused. The previous order was what spec cleaner did. Wasn't it supposed to be The Right Order(TM)? And what happens next time spec cleaner service is run? Is it going to change the order back, masking real changes?
It's annoying, indeed. Apart of some improvements in the above, the rest are a matter of taste. It should be avoidable simply by communication between you and the project maintainer. When the same problem happens again and again, it should be treated more commonly. But unless it, I don't see this as a generic problem of submitting to FACTORY... thanks, Takashi -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On úterý 2. února 2016 9:03:04 CET Takashi Iwai wrote:
On Tue, 02 Feb 2016 00:10:13 +0100,
Michal Kubecek wrote:
I checked the changes anyway (after all, I'm bugowner so I feel
responsible for the package) and I really don't know what to think: Looking at each point, some of them seem to make sense to me.
Let's see:
https://build.opensuse.org/package/rdiff/network:utilities/tcpreplay?lin krev=base&rev=5
- replace xz compressed tarball by the original gzipped one
For years I've been told by OBS that I should repack gzipped tarballs to save resources. It's not true any more? OK, it allows for checking the signature so it makes sense.
Yeah, recently the original tarball is more recommended. It allows to check the validity of the included source. I thought there is even an automatic service to do that.
- make BuildRoot specification unconditional
For years I've been told that it is obsolete. The only reason I keep it is to allow build for SLE11. Why forcing it on distributions that don't need it?
This is a matter of taste, IMO.
- replace source files by full URL
I don't like this change. More precisely: I hate it.
It looks ugly, but it allows again the automatic source tarball check. It's good for security.
- add "-q" to %setup
Why? No idea.
For reducing the many lines in the log. Mostly a matter of taste, though.
- add "V=1" to make
Why? To make build warnings harder to see?
It shows the compile flags so that the build service can catch incompatible or missing compile flags (like PIE or such). So, this is safer to set for most cases.
- break configure line into two
If it needed breaking, I would do so. This one had 32 characters... Seriously?
Really a matter of taste. I can imagine that breaking per word would make patching easier, but nothing more than that.
- replace ${RPM_BUILD_ROOT} with %{buildroot}
The only rule I have ever seen about this was there is no rule.
Some people are too stubborn :)
- add %{?_smp_mflags} also to make install
Well, why not. But definitely not _after_ the argument.
Hmm, does the order of option have influence on make's behavior?
- add LICENSE to the package
OK, why not.
IIRC, this is mandatory nowadays because OBS won't modify the spec file any longer like before.
- %files: expand wildcards to explicit lists
Some people apparently prefer package build to fail whenever a file is added or renamed. I don't force them not to do so in their packages, could they respect my preferences in mine? Apparently not.
Yeah, I prefer wildcards, too. To be honest I already had some bad experience with trusting wildcards - build failing instead of incorrect package being shiped is imho better way to go.
- reorder tags in specfile header
I'm confused. The previous order was what spec cleaner did. Wasn't it supposed to be The Right Order(TM)? And what happens next time spec cleaner service is run? Is it going to change the order back, masking real changes?
It's annoying, indeed. This is matter of perspective, if you are contributing to multiple packages, reviewing more requests, "uniformity" of packages makes both a bit more easy. To be honest I do not consider packaging to be place where creativity/ uniqueness in packaging style is actually desirable.
Furthermore, there has been ongoing debate in matter of rights/duties of package maintainers - it seems that some package maintainers consider themselves to be owners of said packages, while in my opinion maintainer is more like a custodian/curator of package - so all matters of personal taste are secondary to actuall functional improvements.
Apart of some improvements in the above, the rest are a matter of taste. It should be avoidable simply by communication between you and the project maintainer. When the same problem happens again and again, it should be treated more commonly. But unless it, I don't see this as a generic problem of submitting to FACTORY...
Indeed I fail to see connection between openSUSE factory/tubmleweed submision rules, packaging guidelines and amount of packages in factory. Cheers Martin
On Tuesday 02 of February 2016 00:49:46 Dominique Leuenberger / DimStar wrote:
Let me first tell you: I understand your frustration. And the fact that somebody with a project maintainer role oversteps the package maintainer, giving him 5 hours of notice period, is bad behavior. I stronlgy encourage the two of you to talk this out directly.
To be precise, the request was accepted by someone else. But in general, people not actively maintaining a package accepting requests without giving maintainers enough time to react, is kind of pattern I see too often to my liking.
As to the points you list in the 'change set', I only want to give some small words there (from a opensuse-review team perspective - but it's my own, which I hope the rest of the reviewer team shares).
On Tue, 2016-02-02 at 00:10 +0100, Michal Kubecek wrote:
- replace xz compressed tarball by the original gzipped one For years I've been told by OBS that I should repack gzipped tarballs to save resources. It's not true any more? OK, it allows for checking the signature so it makes sense.
Most of the distro packages switched to using the prisitine upstream tarball quite a while ago, especially for checking signatures, and, as I will explain in pioint 3
I guess it wasn't completely clear from my previous mail: this particular change I understand and appreciate. I just wanted to list even the changes I have no objections to so that it didn't look like I disliked everything. Actually, I never liked the policy of recompressing (or even repacking) upstream tarballs.
- make BuildRoot specification unconditional For years I've been told that it is obsolete. The only reason I keep it is to allow build for SLE11. Why forcing it on distributions that don't need it?
It is indeed needed for SLE11; I have no strong pro or contra if it should be provided for non-SLE11 builds, but it's purely used during the build phase, so does not impact the resulting package. So it comes down to: do you prefer a condition without added value in your spec file? Or do you prefer a 'plain' readable one with as few churn as possible. As you stated: it's your package - your choice.
As it does no harm (and it's unlikely to in a foreseeable future), I take the conditional mostly as a reminder that it's temporary and it's going away one day. I guess a comment would be sufficient for that purpose.
- replace source files by full URL I don't like this change. More precisely: I hate it.
It has one big advantage: trust! Every package submitted to openSUSE:Factory, the review bot actually downloads the tarball from the URL in the Source line and verifies that the submitted one actually IS The one it's supposed to be. This avoids that a packager can inject anything into a tarball (as you can imagine, there are not sufficient resources to manually review all the submitted code - we need to be able to trust one another. The URL as Source allows to automate it)/
OK, this changes things. If the URL is actually used for something meaningful, I have no problem with using it.
- add LICENSE to the package OK, why not.
Actually mandatory to pass legal review.
I was afraid so. While I find the overall obsession with licenses a bit sad, I understand that (open)SUSE has to live with it and watch its back.
- reorder tags in specfile header I'm confused. The previous order was what spec cleaner did. Wasn't it supposed to be The Right Order(TM)? And what happens next time spec cleaner service is run? Is it going to change the order back, masking real changes?
Sometimes, new version of spec cleaner might do it different. Only solution is for us all to run the same version of the tool.
Perhaps changing the preferred order only if there is a really strong reason to might help a bit.
I agree that there are quite some questionable changes forced into your package. As an active maintainer, I actually suggest you to REVERT the change and implement the changes you like on your own. Don't play around: You are the maintainer of the package, you care for it. Show it - revert.
I'll revert the changes I object to and probably keep those I only find useless but the result does not particularly bother me (e.g. the tags order).
For me, the important message in this entire thing is to ALL contributors: contribute to any package you want - be active, but if there is a person dedicated to maintain it (and this person is still active): let this person have a word if he/she likes the change. There are 'teams' building around certain packages, where people talk together and come to a common view on how they want to maintain it - so they jointly do the work, sometimes with, sometimes without consulting. There are even larger projects where NO maintainer in the project is supposed to accept his own change! Strict 4-eye peer review even before stuff moves to Factory. This is not mandatory in OBS - but if the active maintainer so wishes, it is to be respected.
Agreed. And I'm glad to hear that. Michal Kubeček -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On Tuesday 02 of February 2016 01:21:42 Jan Engelhardt wrote:
If you think openSUSE suffers from a bureaucracy problem, just wait until you look elsewhere. ... Fedora: ... Debian: ...
Perhaps the difference is that they don't have OBS so that setting up one's personal toolbox repositories is much more complicated for their users, giving them more incentive to get their packages into the distribution. :-) (Which doesn't mean I would like to see this option go, no way, it's too addictive.)
On Tuesday 2016-02-02 00:10, Michal Kubecek wrote:
- replace xz compressed tarball by the original gzipped one
For years I've been told by OBS [...]
That's now years away. 4 maybe? Please don't tell me you just joined SUSE.
I'm pretty sure I still got that warning less than two years ago. Anyway, I never liked the policy so I appreciate the change.
- add "V=1" to make
Why? To make build warnings harder to see?
Neither V=0 nor V=1 is mandated by openSUSE:Factory. (Some contributors may suggest V=1 to you if they once ended in a position where they had to recompile your package just to verify their hypothesis that a bad compiler flag snuck in (or out).)
In my experience, with this kind of problem, I usually have to run a local build and examine the buildroot anyway - and sometimes even chroot into it to do some tests.
- add %{?_smp_mflags} also to make install
Well, why not. But definitely not _after_ the argument.
No particular order is mandated by factory.
This is not about style, this is about POSIX compliance. Personally, I find things like "ls dirname -l" a really bad habit. It relies on a non- standard behaviour of GNU getopt (which can be disabled by setting the POSIXLY_CORECT environment variable).
Your experience appears to have been an isolated incident not connected with factory, but with a prj-level "maintainer" role.
My experience is a bit different but I only maintain a few packages so that it might just have been a bad luck. However, the pattern of people who are not actively maintaining a package accepting requests within hours is, AFAICS, disturbingly frequent. Michal Kubeček -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On Tue, Feb 02, Michal Kubecek wrote:
- replace xz compressed tarball by the original gzipped one For years I've been told by OBS that I should repack gzipped tarballs to save resources. It's not true any more? OK, it allows for checking the signature so it makes sense.
Before anyone jumps in to "improve security": not using .xz wastes alot of (local) diskspace and download bandwidth. Olaf -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On Tuesday 2016-02-02 08:25, Michael Ströder wrote:
Jan Engelhardt wrote:
Sometimes I really have to cringe at some specfiles and wonder how they got through the opensuse factory review team. I do not want to say openSUSE is the sloppiest distros of all, but claiming openSUSE has too high a specfile standard is just untrue.
Personally two things annoying me:
1. Some reviewers insist on adding a lot of lines to .changes files claiming that there are common practices to do so. [...] for all upstream changes to fit into .changes when simply updating to a new upstream release.
That is utterly nonsensical to do. Call those maintainers out. 1. The package maintainer may not have as much understanding what each upstream changelog entry is supposed to mean 2. The reader of rpm -q --changelog may have even lesser understanding than that 3. Avoid redundant information. Especially point #3 mandates that the full changelog with technobabble should, if so desired, provided via %files, and the rpm-changelog be short and concise. Like freshcode.club messages. Because #2.
2. Often I just want to contribute a new upstream release to an existing package and then after submitting it I'm expected to clean up the .spec (which I did not produce) to comply to new guide-lines. Sometimes I do but sometimes I just do not have the time and give up.
Indeed an issue.. -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On Tue, 02 Feb 2016 09:25:55 +0100, Martin Pluskal wrote:
- %files: expand wildcards to explicit lists
Some people apparently prefer package build to fail whenever a file is added or renamed. I don't force them not to do so in their packages, could they respect my preferences in mine? Apparently not.
Yeah, I prefer wildcards, too. To be honest I already had some bad experience with trusting wildcards - build failing instead of incorrect package being shiped is imho better way to go.
I was also bitten a couple of times, too. But it's a kind of question like whether to enable -i option of rm as default or not.
- reorder tags in specfile header
I'm confused. The previous order was what spec cleaner did. Wasn't it supposed to be The Right Order(TM)? And what happens next time spec cleaner service is run? Is it going to change the order back, masking real changes?
It's annoying, indeed. This is matter of perspective, if you are contributing to multiple packages, reviewing more requests, "uniformity" of packages makes both a bit more easy. To be honest I do not consider packaging to be place where creativity/ uniqueness in packaging style is actually desirable.
Well, in this case, the previous order was the canonical one by spec-cleaner. If the order is "wrong", spec-cleaner should be fixed at first :) Takashi -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
Dne Út 2. února 2016 10:13:55, Takashi Iwai napsal(a):
On Tue, 02 Feb 2016 09:25:55 +0100,
- %files: expand wildcards to explicit lists
Some people apparently prefer package build to fail whenever a file is added or renamed. I don't force them not to do so in their packages, could they respect my preferences in mine? Apparently not.
Yeah, I prefer wildcards, too.
To be honest I already had some bad experience with trusting wildcards - build failing instead of incorrect package being shiped is imho better way to go. I was also bitten a couple of times, too. But it's a kind of question
Martin Pluskal wrote: like whether to enable -i option of rm as default or not.
- reorder tags in specfile header
I'm confused. The previous order was what spec cleaner did. Wasn't it supposed to be The Right Order(TM)? And what happens next time spec cleaner service is run? Is it going to change the order back, masking real changes?
It's annoying, indeed.
This is matter of perspective, if you are contributing to multiple packages, reviewing more requests, "uniformity" of packages makes both a bit more easy. To be honest I do not consider packaging to be place where creativity/ uniqueness in packaging style is actually desirable.
Well, in this case, the previous order was the canonical one by spec-cleaner. If the order is "wrong", spec-cleaner should be fixed at first :)
So just to be clear here. Michal never used spec-cleaner on the package. Because if he did he would get most of the stuff he done to look like Martin did. He used the format_spec_file service that comes from obs-format_spec_file package that me and others are trying to slowly obsolete. Also format_spec_file does not change header order, just splits lines on BuildRequires and few other tweaks. If you indeed find a bug in spec-cleaner feel free to report a bug at: https://github.com/openSUSE/spec-cleaner/issues Note the bug #76 for the obsoletion. The spec-cleaner is also always updated on all supported products so it does output exactly same result no matter what distro version you start it from. Cheers Tom -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On Tuesday 02 of February 2016 09:25:55 Martin Pluskal wrote:
This is matter of perspective, if you are contributing to multiple packages, reviewing more requests, "uniformity" of packages makes both a bit more easy. To be honest I do not consider packaging to be place where creativity/ uniqueness in packaging style is actually desirable.
OK, let's repeat the important point: the order was not a result of my creativity or uniqueness. The tag order was result of osc service localrun format_spec_file i.e. exactly the command I was told to run by the message of first declined request. (Actually, neither was the original tag order, that came from our vim template.) No creativity, no trying to be unique, exactly the opposite. And seeing that at any time I'm supposed to expect a request with some small change hidden behind a massive reshuffle, that is really annoying.
Furthermore, there has been ongoing debate in matter of rights/duties of package maintainers - it seems that some package maintainers consider themselves to be owners of said packages, while in my opinion maintainer is more like a custodian/curator of package - so all matters of personal taste are secondary to actuall functional improvements.
I do _not_ oppose "actual functional improvements". What I oppose is deliberately overriding package maintainer's personal tastes and imposing personal tastes of someone who is not actively maintaining the package (and not going to). I would even go as far as calling that disrespectful and rude. Unless I have reason to believe the package is not actively maintained, I try to respect maintainer's preferences and keep the "minimum impact" approach. I wouldn't dare to do a complete specfile rework just to make it more likeable for me. Another popular phrase around here is "doocracy: those who do, decide". Ask yourself: who (apart from upstream authors) did most work on packaging the software and making it build and work? Who did test it? Who is going to get bugs assigned? Who is supposed to fix build broken by a Factory update? Who is supposed to do version updates and make sure they build and work? Is it you? If not, please do not force your personal preferences on that package and respect the right to decide of those "who do".
Indeed I fail to see connection between openSUSE factory/tubmleweed submision rules, packaging guidelines and amount of packages in factory.
Well, that's a pity. This means all the time I spent on polishing my yesterday's mail went in vain, at least as long as you are concerned. And it shows that the problem that discourages (not only) me from submitting packages to Factory, does exist, even if, thankfully, not all project maintainers feel the same way as you. Michal Kubeček -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On Tuesday 2016-02-02 09:45, Michal Kubecek wrote:
On Tuesday 02 of February 2016 01:21:42 Jan Engelhardt wrote:
- add %{?_smp_mflags} also to make install
Well, why not. But definitely not _after_ the argument.
No particular order is mandated by factory.
This is not about style, this is about POSIX compliance. Personally, I find things like "ls dirname -l" a really bad habit. It relies on a non- standard behaviour of GNU getopt (which can be disabled by setting the POSIXLY_CORECT environment variable).
If anyone wants to tackle posix correctness, they would better spend their time identifying scriptlets (%prep, %setup, etc.) for bashisms and set -p /bin/bash or fix em up, because they are not really sh-compatible at times. -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
Jan Engelhardt wrote:
On Tuesday 2016-02-02 08:25, Michael Ströder wrote:
Jan Engelhardt wrote:
Sometimes I really have to cringe at some specfiles and wonder how they got through the opensuse factory review team. I do not want to say openSUSE is the sloppiest distros of all, but claiming openSUSE has too high a specfile standard is just untrue.
Personally two things annoying me:
1. Some reviewers insist on adding a lot of lines to .changes files claiming that there are common practices to do so. [...] for all upstream changes to fit into .changes when simply updating to a new upstream release.
That is utterly nonsensical to do. Call those maintainers out. 1. The package maintainer may not have as much understanding what each upstream changelog entry is supposed to mean 2. The reader of rpm -q --changelog may have even lesser understanding than that 3. Avoid redundant information.
Especially point #3 mandates that the full changelog with technobabble should, if so desired, provided via %files, and the rpm-changelog be short and concise. Like freshcode.club messages. Because #2.
Exactly my point of view. Next time someone hits [Decline] I will point to your message in the list archive. Ciao, Michael.
On Tuesday 2016-02-02 09:52, Olaf Hering wrote:
On Tue, Feb 02, Michal Kubecek wrote:
- replace xz compressed tarball by the original gzipped one For years I've been told by OBS that I should repack gzipped tarballs to save resources. It's not true any more? OK, it allows for checking the signature so it makes sense.
Before anyone jumps in to "improve security": not using .xz wastes alot of (local) diskspace and download bandwidth.
Not using brotli wastes diskspace (and time). It's kind of new, but compressed as well as xz, but in the time that it would take gzip. Try it with linux-4*.tar. And anyone who wants speed should be on LZO rather than gzip. Anyhow, you need to tell upstream those things. THEY are the ones who should be using efficient compression. THEY are the ones who should be creating .sig/.asc files for the uncompressed archive (like kernel.org). But upstream is a denomination of people which often tend to ignore all these matters, just like the symbol versioning thing. -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On 02 Feb 09:59, Jan Engelhardt wrote:
On Tuesday 2016-02-02 08:25, Michael Ströder wrote:
Jan Engelhardt wrote:
Sometimes I really have to cringe at some specfiles and wonder how they got through the opensuse factory review team. I do not want to say openSUSE is the sloppiest distros of all, but claiming openSUSE has too high a specfile standard is just untrue.
Personally two things annoying me:
1. Some reviewers insist on adding a lot of lines to .changes files claiming that there are common practices to do so. [...] for all upstream changes to fit into .changes when simply updating to a new upstream release.
That is utterly nonsensical to do. Call those maintainers out. 1. The package maintainer may not have as much understanding what each upstream changelog entry is supposed to mean 2. The reader of rpm -q --changelog may have even lesser understanding than that 3. Avoid redundant information.
Especially point #3 mandates that the full changelog with technobabble should, if so desired, provided via %files, and the rpm-changelog be short and concise. Like freshcode.club messages. Because #2.
Just to add my point here. We don't want the ChangeLog, nor output of the git log, svn log whatever. We want the useful stuff which is mostly included in the NEWS file and/or the release announcement. ismail
On Tuesday 02 of February 2016 09:25:55 Martin Pluskal wrote:
This is matter of perspective, if you are contributing to multiple packages, reviewing more requests, "uniformity" of packages makes both a bit more easy. To be honest I do not consider packaging to be place where creativity/ uniqueness in packaging style is actually desirable.
OK, let's repeat the important point: the order was not a result of my creativity or uniqueness. The tag order was result of
osc service localrun format_spec_file
i.e. exactly the command I was told to run by the message of first declined request. (Actually, neither was the original tag order, that came from our vim template.) No creativity, no trying to be unique, exactly the opposite. And seeing that at any time I'm supposed to expect a request with some small change hidden behind a massive reshuffle, that is really annoying.
Furthermore, there has been ongoing debate in matter of rights/duties of package maintainers - it seems that some package maintainers consider themselves to be owners of said packages, while in my opinion maintainer is more like a custodian/curator of package - so all matters of personal taste are secondary to actuall functional improvements.
I do _not_ oppose "actual functional improvements". What I oppose is deliberately overriding package maintainer's personal tastes and imposing personal tastes of someone who is not actively maintaining the package (and not going to). I would even go as far as calling that disrespectful and rude.
Unless I have reason to believe the package is not actively maintained, I try to respect maintainer's preferences and keep the "minimum impact" approach. I wouldn't dare to do a complete specfile rework just to make it more likeable for me.
Another popular phrase around here is "doocracy: those who do, decide". Ask yourself: who (apart from upstream authors) did most work on packaging the software and making it build and work? Who did test it? Who is going to get bugs assigned? Who is supposed to fix build broken by a Factory update? Who is supposed to do version updates and make sure they build and work? Is it you? If not, please do not force your personal preferences on that package and respect the right to decide of those "who do". Where did I force something to your package - please elaborate.
Indeed I fail to see connection between openSUSE factory/tubmleweed submision rules, packaging guidelines and amount of packages in factory.
Well, that's a pity. This means all the time I spent on polishing my yesterday's mail went in vain, at least as long as you are concerned. And it shows that the problem that discourages (not only) me from submitting packages to Factory, does exist, even if, thankfully, not all project maintainers feel the same way as you. I am not sure I understand what you are trying to say here - in projects where I am maintainer, I allways tried to get as many packages as possible to Factory/Tumbleweed, in cases where someone from project where I am maintaner
On úterý 2. února 2016 10:28:03 CET Michal Kubecek wrote: tried to submit something to factory, I tried to help him (and although it might surprise you, did not force my personal tastes on them), in case when discussion in sr was not enough I tried to get in contact with this maintainer - did I not do enough? I am still not sure how my personal opinions/tastes in regard of packaging, or my feeling are either symptom or cause of lack of packages in Factory. Anyway, if it either makes you feel better or will improve amount of packages in Factory, feel free to blame either me or my stupidity. Cheers Martin
On Tuesday 02 of February 2016 10:20:37 Tomáš Chvátal wrote:
So just to be clear here. Michal never used spec-cleaner on the package. Because if he did he would get most of the stuff he done to look like Martin did.
He used the format_spec_file service that comes from obs-format_spec_file package that me and others are trying to slowly obsolete. Also format_spec_file does not change header order, just splits lines on BuildRequires and few other tweaks.
Let me repeat: I did run exactly the command I was asked to run by the message I got when my first submit request was declined. If I was told to run some other tool, I would have. On the other hand, if all changes from that request really come from spec-cleaner tool, it would only support my point that forcing such strict formatting policy actively discourages people from submitting their packages to Factory. Michal Kubeček -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
İsmail Dönmez wrote:
On 02 Feb 09:59, Jan Engelhardt wrote:
On Tuesday 2016-02-02 08:25, Michael Ströder wrote:
Jan Engelhardt wrote:
Sometimes I really have to cringe at some specfiles and wonder how they got through the opensuse factory review team. I do not want to say openSUSE is the sloppiest distros of all, but claiming openSUSE has too high a specfile standard is just untrue.
Personally two things annoying me:
1. Some reviewers insist on adding a lot of lines to .changes files claiming that there are common practices to do so. [...] for all upstream changes to fit into .changes when simply updating to a new upstream release.
That is utterly nonsensical to do. Call those maintainers out. 1. The package maintainer may not have as much understanding what each upstream changelog entry is supposed to mean 2. The reader of rpm -q --changelog may have even lesser understanding than that 3. Avoid redundant information.
Especially point #3 mandates that the full changelog with technobabble should, if so desired, provided via %files, and the rpm-changelog be short and concise. Like freshcode.club messages. Because #2.
Just to add my point here. We don't want the ChangeLog, nor output of the git log, svn log whatever. We want the useful stuff which is mostly included in the NEWS file and/or the release announcement.
Sorry, given the wide range of variants in upstream release this advice is very blurry. Ciao, Michael.
On úterý 2. února 2016 10:45:51 CET Michal Kubecek wrote:
On Tuesday 02 of February 2016 10:20:37 Tomáš Chvátal wrote:
So just to be clear here. Michal never used spec-cleaner on the package. Because if he did he would get most of the stuff he done to look like Martin did.
He used the format_spec_file service that comes from obs-format_spec_file package that me and others are trying to slowly obsolete. Also format_spec_file does not change header order, just splits lines on BuildRequires and few other tweaks.
Let me repeat: I did run exactly the command I was asked to run by the message I got when my first submit request was declined. If I was told to run some other tool, I would have.
On the other hand, if all changes from that request really come from spec-cleaner tool, it would only support my point that forcing such strict formatting policy actively discourages people from submitting their packages to Factory. Is this your opinion or are you aware of others feeling same? Also note that usage of spec-cleaner is not mandatory but just adviced, and not in all cases, as it would mess up some more complex packages.
Cheers Martin
On 02.02.2016 14:56, Martin Pluskal wrote:
On úterý 2. února 2016 10:45:51 CET Michal Kubecek wrote: Is this your opinion or are you aware of others feeling same? Also note that usage of spec-cleaner is not mandatory but just adviced, and not in all cases, as it would mess up some more complex packages.
Cheers
Martin
Well, I too complained about that here quite vehemently. So, now you are aware of others feeling same. It wouldn't be a problem if usage of repoes wouldn't be artificially complicated. As far as shaming people for not using their own build cluster for publicising their dirty, un-submitted packages.
On Tuesday 02 of February 2016 10:56:36 Martin Pluskal wrote:
On úterý 2. února 2016 10:45:51 CET Michal Kubecek wrote:
On the other hand, if all changes from that request really come from spec-cleaner tool, it would only support my point that forcing such strict formatting policy actively discourages people from submitting their packages to Factory.
Is this your opinion or are you aware of others feeling same?
Not only me. Michal Kubeček -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On úterý 2. února 2016 15:21:07 CET Sergey Kondakov wrote:
On 02.02.2016 14:56, Martin Pluskal wrote:
On úterý 2. února 2016 10:45:51 CET Michal Kubecek wrote: Is this your opinion or are you aware of others feeling same? Also note that usage of spec-cleaner is not mandatory but just adviced, and not in all cases, as it would mess up some more complex packages.
Cheers
Martin
Well, I too complained about that here quite vehemently. So, now you are aware of others feeling same. You complained about rules for factory submission being to difficult? You complained about something done by rep-clean? Where and when? It wouldn't be a problem if usage of repoes wouldn't be artificially complicated. That is kinda different topic As far as shaming people for not using their own build cluster for publicising their dirty, un-submitted packages. That is different topic as well, also I don't recall any shaming, if I recall correctly, you were only advised to use your own factory instance if you have such strong objections against current setup - where is shaming in that?
Cheers Martin
On úterý 2. února 2016 11:24:35 CET Michal Kubecek wrote:
On Tuesday 02 of February 2016 10:56:36 Martin Pluskal wrote:
On úterý 2. února 2016 10:45:51 CET Michal Kubecek wrote:
On the other hand, if all changes from that request really come from spec-cleaner tool, it would only support my point that forcing such strict formatting policy actively discourages people from submitting their packages to Factory.
Is this your opinion or are you aware of others feeling same?
Not only me.
Michal Kubeček
I would ask those having same feeling as you to speak up, but I am afraid that it would changes this thread to something like "what I don't like about Factory review" or "what I don't like about openSUSE" Martin
On Tuesday 02 of February 2016 10:41:06 Martin Pluskal wrote:
Anyway, if it either makes you feel better or will improve amount of packages in Factory, feel free to blame either me or my stupidity.
Let me quote from my initial e-mail (I know it was long and boring but it's second paragraph): Disclaimer: the sole purpose of this e-mail is to present my view on the problem and to give responsible people something to think about. It is definitely not meant as a complaint about the particular case (which serves only as an example) or some kind of pointing fingers. If it was about you or that one particular request, I would discuss it with you directly. To simplify the problem to the core, what I find discouraging are two patterns: 1. People doing (trying to do) unnecessary changes from the "personal preferences" category in packages they are not actively maintaining (or intending to). 2. People eagerly accepting requests for packages they are not actively maintaining so that the real maintainer doesn't have chance to respond. (I can understand this if maintainer does not respond for, say, a week; but five hours on Sunday?) When these two meet for one request, the result is really frustrating. Michal Kubeček -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On 02.02.2016 15:27, Martin Pluskal wrote:
On úterý 2. února 2016 15:21:07 CET Sergey Kondakov wrote:
On 02.02.2016 14:56, Martin Pluskal wrote:
On úterý 2. února 2016 10:45:51 CET Michal Kubecek wrote: Is this your opinion or are you aware of others feeling same? Also note that usage of spec-cleaner is not mandatory but just adviced, and not in all cases, as it would mess up some more complex packages.
Cheers
Martin
Well, I too complained about that here quite vehemently. So, now you are aware of others feeling same. You complained about rules for factory submission being to difficult? You complained about something done by rep-clean? Where and when? It wouldn't be a problem if usage of repoes wouldn't be artificially complicated. That is kinda different topic As far as shaming people for not using their own build cluster for publicising their dirty, un-submitted packages. That is different topic as well, also I don't recall any shaming, if I recall correctly, you were only advised to use your own factory instance if you have such strong objections against current setup - where is shaming in that?
Cheers
Martin
Oh, first you "fail to see" the connection and now the argument is not to your liking (I quite clearly stated in the past that I don't submit my packages yet because of how time their "proper" "cleaning" will consume) ? I'm not going to prance around you anymore. The fact is: he's far from being alone and you are not an authority on how people should evaluate needless obstacles in their work of common good that they are doing for free (which accidentally is also popularizing openSUSE). Moreover, quantity of discontented is irrelevant to legitimacy of the issue in the first place. It's great that someone is willing to address issues of "spec cleaning" point by point. Personally, I don't have moral strength in me for that, long discussion and won't any time soon.
On Tue, Feb 02, 2016 at 08:29:15AM +0100, Axel Braun wrote:
Am Dienstag, 2. Februar 2016, 08:25:20 schrieb Michael Ströder:
Jan Engelhardt wrote:
Sometimes I really have to cringe at some specfiles and wonder how they got through the opensuse factory review team. I do not want to say openSUSE is the sloppiest distros of all, but claiming openSUSE has too high a specfile standard is just untrue.
Personally two things annoying me:
1. Some reviewers insist on adding a lot of lines to .changes files claiming that there are common practices to do so. But many packages do this differently. And personally I think it's plain wrong to add all upstream changes to fit into .changes when simply updating to a new upstream release.
+1 if someone is really interested in details, reading the changelog upstream should be sufficient.
-1 That requires a user to download the upstream package independently just because the packaging process has intentionally truncated or abridged the information - "updated from upstream" is about as useful as the "fixed some bugs" message popular on some mobile appstores. Or am I misunderstanding how an end-user is supposed to inspect/query what has changed in a pre-built package using the tools provided by the package manager? Daniel -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
Daniel Morris wrote:
On Tue, Feb 02, 2016 at 08:29:15AM +0100, Axel Braun wrote:
Am Dienstag, 2. Februar 2016, 08:25:20 schrieb Michael Ströder:
Personally two things annoying me: 1. Some reviewers insist on adding a lot of lines to .changes files claiming that there are common practices to do so. But many packages do this differently. And personally I think it's plain wrong to add all upstream changes to fit into .changes when simply updating to a new upstream release.
+1 if someone is really interested in details, reading the changelog upstream should be sufficient.
-1 That requires a user to download the upstream package independently just because the packaging process has intentionally truncated or abridged the information - "updated from upstream" is about as useful as the "fixed some bugs" message popular on some mobile appstores.
It's not a big deal for a package foo to add the upstream changes file in /usr/share/doc/packages/foo
Or am I misunderstanding how an end-user is supposed to inspect/query what has changed in a pre-built package using the tools provided by the package manager?
Could you please elaborate on what's an "end-user"? Ciao, Michael.
On Tue, 2016-02-02 at 08:25 +0100, Michael Ströder wrote:
1. Some reviewers insist on adding a lot of lines to .changes files claiming that there are common practices to do so. But many packages do this differently. And personally I think it's plain wrong to add all upstream changes to fit into .changes when simply updating to a new upstream release.
The big problem is that packagers are just too lazy to UNDERSTAND and READ what is written in the release announcemnts. So the review team has to do the job for you! Not seldom there is stuff written about new features that can be enabled if this and that is added as a build dep. Or other interesting stuff. It's not about COPYING it in, but actually putting in what is important to know about the release... if you copy, that's fine, BUT: take the time to read and understand the implications of the update. A pkg update is done in 30 seconds - doing it proper and understanding what other changes need to be done, takes a bit more time (I for one use the diff of 'old' and 'new' configure.ac to update build dependencies for example... does it take time? yes. Does it improve quality? Maybe not 'obvious' when I just rely that stuff in Factory is there as I expect it to be... but if my packages are branched, they don't just fail in weird ways for missing deps - or worse: silently disable features which nobody understands why. Packaging takes brain, just as many other task does... where upstream specifies well enough the deps, even ideas like the automatic perl and ruby updaters are doable... so updating them becomes a 0s task, and STILL conforms to the packaging guidelines... so if a BOT can do it: wht can't you? Too boring? Write a bot for your packages. Cheers, Dominique -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On 02.02.2016 15:27, Martin Pluskal wrote:
On úterý 2. února 2016 15:21:07 CET Sergey Kondakov wrote:
On 02.02.2016 14:56, Martin Pluskal wrote:
On úterý 2. února 2016 10:45:51 CET Michal Kubecek wrote: Is this your opinion or are you aware of others feeling same? Also note that usage of spec-cleaner is not mandatory but just adviced, and not in all cases, as it would mess up some more complex packages.
Cheers
Martin
Well, I too complained about that here quite vehemently. So, now you are aware of others feeling same.
You complained about rules for factory submission being to difficult? You complained about something done by rep-clean? Where and when?
It wouldn't be a problem if usage of repoes wouldn't be artificially complicated.
That is kinda different topic
As far as shaming people for not using their own build cluster for publicising their dirty, un-submitted packages.
That is different topic as well, also I don't recall any shaming, if I recall correctly, you were only advised to use your own factory instance if you have such strong objections against current setup - where is shaming in that?
Cheers
Martin
Oh, first you "fail to see" the connection and now the argument is not to your liking Not that its not to my liking but I remember that your major complain was about dicrepancies between Factory and Tumbleweed repositories in OBS prior Tumbleweed snapshot is published. (I quite clearly stated in the past that I don't submit my packages yet because of how time their "proper" "cleaning" will consume) ? Sorry did not remember that. I'm not going to prance around you anymore. The fact is: he's far from being alone and you are not an authority on how people should evaluate needless obstacles in their work of common good that they are doing for free (which accidentally is also popularizing openSUSE). That I am definitely not, nor do I pretend to be. Needless obstacles is however something that everybody can imagine something different (and I guess
On úterý 2. února 2016 15:54:30 CET Sergey Kondakov wrote: that my and your opinion on this topic would be different).
Moreover, quantity of discontented is irrelevant to legitimacy of the issue in the first place. Well claiming causality when not even corelation is established is bogus. Providing empirical proof for claim that "number of packages in Factory is low due to review process being too difficult" is quiet challenging. Furthermore as already stated in this discussion, review and rules for Debian are much more strict that ones for openSUSE, yet it seems that there are more packages in Debian, which would suggest that difficulty of review is not that big obstacle for most.
It's great that someone is willing to address issues of "spec cleaning" point by point. Personally, I don't have moral strength in me for that, long discussion and won't any time soon. Meh
Martin Pluskal
On úterý 2. února 2016 11:39:40 CET Michal Kubecek wrote:
On Tuesday 02 of February 2016 10:41:06 Martin Pluskal wrote:
Anyway, if it either makes you feel better or will improve amount of packages in Factory, feel free to blame either me or my stupidity.
Let me quote from my initial e-mail (I know it was long and boring but it's second paragraph):
Disclaimer: the sole purpose of this e-mail is to present my view on the problem and to give responsible people something to think about. It is definitely not meant as a complaint about the particular case (which serves only as an example) or some kind of pointing fingers.
If it was about you or that one particular request, I would discuss it with you directly. OK, first let me clarify that my request consisted of several changes, some which I would consider beneficial, some were in my opinion very tiny improvements. I was actually expecting this sr to be declined and to discuss changes with you, and I was surprised when it was accepted after few hours. Given that despite your disclaimer, I am not aware of any similar issues that would occur to you, and given that you decided to use changes done by me as example, it is difficult for me not to step into debate, somehow feeling that I have been pulled into something different that I was hoping to accomplish in first place.
To simplify the problem to the core, what I find discouraging are two patterns:
1. People doing (trying to do) unnecessary changes from the "personal preferences" category in packages they are not actively maintaining (or intending to). 2. People eagerly accepting requests for packages they are not actively maintaining so that the real maintainer doesn't have chance to respond. (I can understand this if maintainer does not respond for, say, a week; but five hours on Sunday?)
When these two meet for one request, the result is really frustrating. I understand your frustration, but please also try to unedrstand my suprise and perhaps dissapointment when this topic appeared on mailing lists.
Michal Kubeček
Martin
On úterý 2. února 2016 15:54:30 CET Sergey Kondakov wrote:
On 02.02.2016 15:27, Martin Pluskal wrote:
On úterý 2. února 2016 15:21:07 CET Sergey Kondakov wrote:
On 02.02.2016 14:56, Martin Pluskal wrote:
On úterý 2. února 2016 10:45:51 CET Michal Kubecek wrote: Is this your opinion or are you aware of others feeling same? Also note that usage of spec-cleaner is not mandatory but just adviced, and not in all cases, as it would mess up some more complex packages.
Cheers
Martin
Well, I too complained about that here quite vehemently. So, now you are aware of others feeling same.
You complained about rules for factory submission being to difficult? You complained about something done by rep-clean? Where and when?
It wouldn't be a problem if usage of repoes wouldn't be artificially complicated.
That is kinda different topic
As far as shaming people for not using their own build cluster for publicising their dirty, un-submitted packages.
That is different topic as well, also I don't recall any shaming, if I recall correctly, you were only advised to use your own factory instance if you have such strong objections against current setup - where is shaming in that?
Cheers
Martin
Oh, first you "fail to see" the connection and now the argument is not to your liking (I quite clearly stated in the past that I don't submit my packages yet because of how time their "proper" "cleaning" will consume) ? I'm not going to prance around you anymore. The fact is: he's far from being alone and you are not an authority on how people should evaluate needless obstacles in their work of common good that they are doing for free (which accidentally is also popularizing openSUSE). Moreover, quantity of discontented is irrelevant to legitimacy of the issue in the first place.
It's great that someone is willing to address issues of "spec cleaning" point by point. Personally, I don't have moral strength in me for that, long discussion and won't any time soon. Wait a minute, at first you state that "I don't submit my packages yet because of how time their "proper" "cleaning" will consume" and then you object "spec cleaning" - so you don't have time/will to get your packages to factory, but should someone want to help you or do it instead of you, you would not like it? If I decided to branch one of your packages and get it to state where it would be acceptable to Factory on first attemt, you would not accept such changes?
Martin
On Tue, Feb 02, 2016 at 08:29:15AM +0100, Axel Braun wrote:
Am Dienstag, 2. Februar 2016, 08:25:20 schrieb Michael Ströder:
Jan Engelhardt wrote:
Sometimes I really have to cringe at some specfiles and wonder how they got through the opensuse factory review team. I do not want to say openSUSE is the sloppiest distros of all, but claiming openSUSE has too high a specfile standard is just untrue.
Personally two things annoying me:
1. Some reviewers insist on adding a lot of lines to .changes files claiming that there are common practices to do so. But many packages do this differently. And personally I think it's plain wrong to add all upstream changes to fit into .changes when simply updating to a new upstream release.
+1 if someone is really interested in details, reading the changelog upstream should be sufficient.
-1 That requires a user to download the upstream package independently just because the packaging process has intentionally truncated or abridged the information - "updated from upstream" is about as useful as the "fixed some bugs" message popular on some mobile appstores. Not necessarily, upstream changelog is often attached to package unformated - what I do in cases where converting upstream changelog to .changes would be too difficult is to add something like "see attached Changes" - while I understat that it is not helpfull to all end users, I also recognise that most
On úterý 2. února 2016 11:16:34 CET Daniel Morris wrote: people are actually not reading rpm changelogs anyway. Martin
On Tue, Feb 02, 2016 at 12:22:27PM +0100, Michael Ströder wrote:
Daniel Morris wrote:
On Tue, Feb 02, 2016 at 08:29:15AM +0100, Axel Braun wrote:
Am Dienstag, 2. Februar 2016, 08:25:20 schrieb Michael Ströder:
Personally two things annoying me: 1. Some reviewers insist on adding a lot of lines to .changes files claiming that there are common practices to do so. But many packages do this differently. And personally I think it's plain wrong to add all upstream changes to fit into .changes when simply updating to a new upstream release.
+1 if someone is really interested in details, reading the changelog upstream should be sufficient.
-1 That requires a user to download the upstream package independently just because the packaging process has intentionally truncated or abridged the information - "updated from upstream" is about as useful as the "fixed some bugs" message popular on some mobile appstores.
It's not a big deal for a package foo to add the upstream changes file in /usr/share/doc/packages/foo
But that only works post-install, and I'm not sure it is safe for multiple versions of foo. Out of curiosity, from 2108 rpm packages installed on this tumbleweed system, 1128 have a directory under /usr/share/docs/packages and 329 of those have a (case insensitive) file named changelog.
Or am I misunderstanding how an end-user is supposed to inspect/query what has changed in a pre-built package using the tools provided by the package manager?
Could you please elaborate on what's an "end-user"?
Great question - in the broadest terms I expect the prospective or actual consumer of a piece of software that has been pre-built and distributed in the RPM Package Manager format :) That might include a user who is happier using a graphical front-end to either inspect software on an existing system or is looking for new/newer great software. As well as those that might want to sanity check what whizo feature $BLING is likely to come, maybe with some potential breakage/interaction ahead of installation from a command line with something like 'rpm -qp --changelog foo-x.y.z+3.rpm'. Right through to the poor sysadmin firefighting in an unconnected inhospitable windowless void wondering why a twenty year convention of passing --changelog into the RPM packaging tools returns "updated from upstream" after $EXsysadmin caused some breakage on a production system that wasn't supposed to be changed. I'm sure there are other types of end-users too. Is there concensus in the LSB & RPM specs for what is the intended and/or expected behaviour? Does the map match the terrain? Daniel -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On Tuesday 2016-02-02 13:45, Daniel Morris wrote:
It's not a big deal for a package foo to add the upstream changes file in /usr/share/doc/packages/foo
But that only works post-install, and I'm not sure it is safe for multiple versions of foo.
Why would that only work after the installation? "%doc ChangeLog" in your .spec - done. Even works for multiple library versions If Done Right™. (lands in /usr/share/doc/packages/libnl3/ChangeLog and /usr/share/doc/packages/libnl-1_1/ChangeLog for example.) -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On 02/02/2016 03:25 AM, Martin Pluskal wrote: <snip>
It's annoying, indeed.
This is matter of perspective, if you are contributing to multiple packages, reviewing more requests, "uniformity" of packages makes both a bit more easy. To be honest I do not consider packaging to be place where creativity/ uniqueness in packaging style is actually desirable.
Furthermore, there has been ongoing debate in matter of rights/duties of package maintainers - it seems that some package maintainers consider themselves to be owners of said packages, while in my opinion maintainer is more like a custodian/curator of package - so all matters of personal taste are secondary to actuall functional improvements.
While I agree with the notion that uniformity w.r.t. the boiler plate stuff (Requires, BuildRequires, use of macros....) is desirable and makes reviewers jobs easier I strongly disagree with the idea that project maintainers somehow have a better understanding of the functionality of every package in a given project. If the goal is simply to always have the latest version in the devel project and no one cares if dependent things break then lets have a bot for all devel projects like we do for d:l:perl. However, if we care that higher level packages actually work then bots may not be the greatest thing in the world unless we back the bots up by a database that maps out all the dependencies and then write a solver that can comprehend whether a given package can automatically be pushed to the next upstream released version. AFAIK that does not exist yet, thus the role of the package maintainer, who hopefully understands the package upstream dependencies to a certain extend and within reason is quite valuable, IMHO. Therefore, project maintainers should encourage active package maintainership in their projects rather then stepping in and ignoring package maintainers. The latter will only lead to the point where project maintainers end up being responsible for all packages in a project as package maintainers will just walk away. Later, Robert -- Robert Schweikert MAY THE SOURCE BE WITH YOU Public Cloud Architect LINUX rjschwei@suse.com IRC: robjo
On Tue, Feb 2, 2016 at 1:05 PM, Martin Pluskal
1. Some reviewers insist on adding a lot of lines to .changes files claiming that there are common practices to do so. But many packages do this differently. And personally I think it's plain wrong to add all upstream changes to fit into .changes when simply updating to a new upstream release.
+1 if someone is really interested in details, reading the changelog upstream should be sufficient.
-1 That requires a user to download the upstream package independently just because the packaging process has intentionally truncated or abridged the information - "updated from upstream" is about as useful as the "fixed some bugs" message popular on some mobile appstores.
Not necessarily, upstream changelog is often attached to package unformated - what I do in cases where converting upstream changelog to .changes would be too difficult is to add something like "see attached Changes" - while I understat that it is not helpfull to all end users, I also recognise that most people are actually not reading rpm changelogs anyway.
My opinion (as complete packaging newbie) is, that fill properly .changes file can be difficult. Sometimes is upstream changelog very long, sometimes is almost empty. You can cherry pick interesting points, but i guess that line "updated to version X.Y.Z" should be sufficient. Well, it is change file for package in obs, so anything related to creation of the package should be there. Like added/removed specific patches, cleaned spec file, package split, specifics related to openSUSE..etc... So I would vote, that comments "updated from upstream", "see attached Changes" should be enough. Petr -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On Tue, Feb 02, 2016 at 03:14:53PM +0100, Jan Engelhardt wrote:
On Tuesday 2016-02-02 13:45, Daniel Morris wrote:
It's not a big deal for a package foo to add the upstream changes file in /usr/share/doc/packages/foo
But that only works post-install, and I'm not sure it is safe for multiple versions of foo.
Why would that only work after the installation? "%doc ChangeLog"
How would any file from foo.rpm arrive in /usr/share/doc/packages/foo before a directive to install (or update)? That would be really worrying! I was thinking just about querying. However, having poked around a few packages I now see how horribly inconsistent the whole ChangeLog handling is. In my limited sample of one system, less than 1/6th of installed packages had a corresponding upstream changelog copied to /usr/share/doc/packages/foo. Even finding a changelog, instead of Changes etc. is hit and miss. That could be simple reflection of upstream where tarball producers don't want to repeat information already held in their source, revision control, configuration management or bug-tracking processes. I guess I've been fortunate to only be sufficiently interested in the changelog output from rpm for packages that had a good level of detail rippled through, as per the simple suggestions in the "Referring to upstream ChangeLog" guidance on the twiki. As a simple end-user I'd like to say a big thank you to all the packagers that work so hard to get that balance right. Daniel -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
Hi Michal, first: in general, I agree mostly with your sentiment, and these things have kept me keeping some things out of Factory but well maintained in a "devel project" (e.g. most of the stuff in the "vdr" repo is not in Fatory and will not be until someone steps up to maintain it there who is not me) On 02.02.2016 11:39, Michal Kubecek wrote:
To simplify the problem to the core, what I find discouraging are two patterns:
2. People eagerly accepting requests for packages they are not actively maintaining so that the real maintainer doesn't have chance to respond.
As one of the people with maintainer power over Base:System and a few other "garbage can" projects, I sometime also accept submissions for packages that I'm not connected with. However, because I feel your pain, I usually only pick the ones with trivial changes -- a missing buildrequires or a changed library name for Factory or such. As soon as I cannot quickly find out what the change is doing with a look at the diff (and a "spec-cleaner" run clearly makes this impossible), I will not dare accepting the package. Well, unless it's lying around for a long time and was clearly broken before (e.g. build failure).
(I can understand this if maintainer does not respond for, say, a week; but five hours on Sunday?)
When these two meet for one request, the result is really frustrating.
I'm totally with you on that one :-) -- Stefan Seyfried "For a successful technology, reality must take precedence over public relations, for nature cannot be fooled." -- Richard Feynman -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
*snip* Just to reduce the length and fuzz I deleted the whole thread. After checking this in depth myself there are few facts that Michal decided politely to ignore. First and utmost is that Martin created the sr# like any other contributor which was then accepted to the project. Funny thing is that the accepter is actually also PACKAGE maintainer, not just project maintainer, so nobody violated any rule about project maintainer abusing package maintainer. Then he spents almost entire email complaining about arbitrary changes to the spec file that he didn't agree on and basically deride Martin's changes because he feels they are not same like he would do them. That is seriously ugly thing to do over public channel, and if one really feels like doing so he should first actually clarify with the author of the changes privately via email/irc/whatever rather than start a full blown flame on 2 mailinglists at once. Especialy since his co-maintainer actually approved the changes, thus he should first speak with him to figure out why/what was done. I would say now Michal should come forward and apologize for actually starting flamewar that was based on basically completely false claim. One part of Michal's complain has merit regardless of wether there was something wrong done or not. We should've had already docummented what are roles and responsibilities of packagers and project maintainers. For that I will create a wiki page that will try to explain the difference and expectations. Later on we could even get OBS to implement the rules written there with some checks so noone could by accident breakt them. But for that we would need to bribe the OBS with cookies. :-) I will write this wiki draft Today in the evening (CEST) or Tomorrow in the afternoon. Cheers Tom -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On Wednesday 03 of February 2016 15:03:07 Tomáš Chvátal wrote: ...
I would say now Michal should come forward and apologize for actually starting flamewar that was based on basically completely false claim. ...
Perhaps you should rather apologize for trying to publicly accuse me of things that are not true, without trying to understand what I wrote and why - and completely ignoring the even the preliminary explanation in the beginning of the first mail. But based on my previous experience, I can't say I'm surprised. Anyway, thanks for confirming the fears I had before trying to open the discussion (and which prevented me from joining the previous one) were well founded. I'm just really sad that I spent two hours trying to carefully formulate the e-mail so that everyone understands it's not meant as an attack against a particular person but a demonstration of a generic problem (problem which several people already confirmed to see) - and still some people completely missed the point. Michal Kubeček -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On 02/03/2016 09:03 AM, Tomáš Chvátal wrote:
*snip* <snip> One part of Michal's complain has merit regardless of wether there was something wrong done or not. We should've had already docummented what are roles and responsibilities of packagers and project maintainers. For that I will create a wiki page that will try to explain the difference and expectations.
You don't have to start from scrtch. Here is a start that I had circulated to a few people but we never got finish it. The development of openSUSE Factory and the subsequent release of the distribution is supported the technical roles outlined below. The roles definition provide a general guidline and set basic expectetions. Each person filling any one or multiple roles has the freedom to interpret these guideline to fit her or his desired participation level. Role: Package maintainer for a package in a devel project for factory: - You are generally encouraged to submit your package to factory and follow the factory maintenance process - Your package should always build in the devel project and in factory, if applicable, build failures should be addressed in a reasonable time frame, 8-10 days - You are encouraged to respond to e-mail about quesntions or concerns with your package within a reasonable time frame (5 days) - You should review and accept submit request in a reasonable amount of time, 8-10 days from the time the submit request is posted - Preferably you will have 2-4 co-maintainers for the package - You have sufficient knowledge about the package to file valid upstream bug reports that are usable by the upstream developers to fix the problem - You respond to bug reports on you package(s) within a reasonable amount of time, 8-10 days - You keep the package reasonably up to date taking into consideration the upstream release cycle, the openSUSE release cycle and the general stbility of upstream releases - You develop a general understanding of the impact of changes to your package on the distribution. For example a "broken" package in a scripting language will have less impact on the distribution than a broken compiler of C runtime environment. Role: Devel project maintainer: - You do not have to maintain any packages, but you may - You should not accept submit requests until the package maintainer in your project had a chance to review and accept the request. If after a reasonable amount of time the SR has not been reviewed or accepted you may accept the SR without review, if the package still builds - You are responsible to follow up with package maintainers for packages that show breakage for more than a reasonable amount of time (8-10 days) - You may need to communicate or facilitate communication if there are major changes in your devel project that have an impact on the distribution - You should be able to communicate clearly with the package maintainers Role: Factory Reviewer: - Review packages submissions to openSUSE:Factory, openSUSE:Factory:NonFree and maintained products based on the guidlines at http://en.opensuse.org/openSUSE:Factory_review - communicate with the submitter in case of problems Role: Factory Maintainer/Release team member: Later, Robert -- Robert Schweikert MAY THE SOURCE BE WITH YOU Public Cloud Architect LINUX rjschwei@suse.com IRC: robjo
Dne St 3. února 2016 15:19:08, Michal Kubecek napsal(a):
On Wednesday 03 of February 2016 15:03:07 Tomáš Chvátal wrote: ...
I would say now Michal should come forward and apologize for actually starting flamewar that was based on basically completely false claim.
...
Perhaps you should rather apologize for trying to publicly accuse me of things that are not true, without trying to understand what I wrote and why - and completely ignoring the even the preliminary explanation in the beginning of the first mail. But based on my previous experience, I can't say I'm surprised.
Anyway, thanks for confirming the fears I had before trying to open the discussion (and which prevented me from joining the previous one) were well founded. I'm just really sad that I spent two hours trying to carefully formulate the e-mail so that everyone understands it's not meant as an attack against a particular person but a demonstration of a generic problem (problem which several people already confirmed to see) - and still some people completely missed the point.
Michal, do you seriously consider writing 1 paragraf stating "this is to improve situation" and then actually spent 15 paragrafs just bashing the guys for something that was completely correct according to all the rules as positive feedback? You used FALSE claim just to proceed with your agenda and actually most people chipped in to your train on that false assumption. Just notice Dominique actually appologizing when he realized the fact. If you would really want to change anything and being decent about it you could just write down 2 mails. 1st focusing on that you foresee the need for documented process for updates wihtout using any examples or actually thinking up one completely unrelated to the reality. 2nd to packaging if you really want to change the rules and requirements on how specs should look like, where it would be discussed like any other rule that is changed or added. Honestly tell me that you would not feel offended if somebody started with "please take this as example and not as insult" and then bashed completely for example week of your work? Tomas -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On Wednesday 03 of February 2016 15:33:18 Tomáš Chvátal wrote:
do you seriously consider writing 1 paragraf stating "this is to improve situation" and then actually spent 15 paragrafs just bashing the guys for something that was completely correct according to all the rules as positive feedback?
It was no bashing. I'm sorry you can't see it or don't want to see it.
You used FALSE claim just to proceed with your agenda and actually most people chipped in to your train on that false assumption. Just notice Dominique actually appologizing when he realized the fact.
No "FALSE claim". I can't read and understand mails for you. I really can't. Yes, the person who accepted the request was by mistake assigned a maintainer role. I know it (I did take a look once the request was accepted) - and I knew it when I wrote the e-mail (I might have even mentioned it once). But that doesn't really change anything. If you tried understand the problem, you might have seen it.
Honestly tell me that you would not feel offended if somebody started with "please take this as example and not as insult" and then bashed completely for example week of your work?
Hm... so I didn't just write "a request full of changes adjusting the specfile according to one's personal preferences". Instead, I tried to explain why I see it as one. And all this effort bought me an accusation of "bashing". The reality is that there are people (not only me) who find what I described a problem which can discourage people from submitting packages to Factory. And "people" is definitely not only me, I already received mails confirming other people feel the same. You can either learn from it or just wave your hand and try to shoot the messenger. Pity you chose the latter, hopefully there are others who won't. Michal Kubeček -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On Tue, Feb 02, 2016 at 03:27:30PM +0100, Petr Červinka wrote:
My opinion (as complete packaging newbie) is, that fill properly .changes file can be difficult. Sometimes is upstream changelog very long, sometimes is almost empty. You can cherry pick interesting points, but i guess that line "updated to version X.Y.Z" should be sufficient.
That's going to far, IMHO. You should at least give reader some hint what to expect, e.g. if it's only a bugfix release or if it brings some incompatible changes of behaviour or config file syntax or semantics, if it fixes some critical (possibly security) bugs etc. You are right that upstream changelogs vary a lot, I guess you need to apply common sense. If the changelog has 5 entries, just copy it. If it has 50 or even 500 entries, you can e.g. pick security bugs, most important new features and possible risks (like incompatible behaviour or syntax).
Well, it is change file for package in obs, so anything related to creation of the package should be there. Like added/removed specific patches, cleaned spec file, package split, specifics related to openSUSE..etc...
Definitely. This packaging related information is very important and unfortunately often forgotten.
So I would vote, that comments "updated from upstream", "see attached Changes" should be enough.
It depends, IMHO. If there is a reasonable upstream changelog, this can suffice. But often this changelog is too detailed and picking the most imoportant points is a valuable service. This is often the case if upstream either doesn't keep a changelog ("it's all in git") or generates it from VCS history. Michal Kubeček -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
Stefan Seyfried wrote:
first: in general, I agree mostly with your sentiment, and these things have kept me keeping some things out of Factory but well maintained in a "devel project" (e.g. most of the stuff in the "vdr" repo is not in Fatory and will not be until someone steps up to maintain it there who is not me)
Huh? IIUC Michal's main concern was the feeling of losing control over his package. In the vdr project there are only two maintainers, you and me. I didn't do anything actually wrt vdr the last few years. Ie in practice there's a monarchy with you as the king of vdr land. So overly eager project maintainers can hardly serve as excuse there :-) 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
On 04.02.2016 09:50, Ludwig Nussel wrote:
Stefan Seyfried wrote:
first: in general, I agree mostly with your sentiment, and these things have kept me keeping some things out of Factory but well maintained in a "devel project" (e.g. most of the stuff in the "vdr" repo is not in Fatory and will not be until someone steps up to maintain it there who is not me)
Huh? IIUC Michal's main concern was the feeling of losing control over his package. In the vdr project there are only two maintainers, you and me. I didn't do anything actually wrt vdr the last few years. Ie in practice there's a monarchy with you as the king of vdr land. So overly eager project maintainers can hardly serve as excuse there :-)
No, my answer was to the question "why are these packages not in Factory". And bureaucracy is one of the reasons. I'm totally fine with your co-maintainership of the vdr repos :-) -- Stefan Seyfried "For a successful technology, reality must take precedence over public relations, for nature cannot be fooled." -- Richard Feynman -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
Gesendet: Dienstag, 02. Februar 2016 um 12:16 Uhr Von: "Daniel Morris"
An: "Axel Braun" Cc: opensuse-packaging@opensuse.org, opensuse-factory@opensuse.org Betreff: Re: [opensuse-packaging] Re: [opensuse-factory] why there are so few packages in Factory, revisited
1. Some reviewers insist on adding a lot of lines to .changes files claiming that there are common practices to do so. But many packages do this differently. And personally I think it's plain wrong to add all upstream changes to fit into .changes when simply updating to a new upstream release.
+1 if someone is really interested in details, reading the changelog upstream should be sufficient.
-1 That requires a user to download the upstream package independently just because the packaging process has intentionally truncated or abridged the information - "updated from upstream" is about as useful as the "fixed some bugs" message popular on some mobile appstores.
Or am I misunderstanding how an end-user is supposed to inspect/query what has changed in a pre-built package using the tools provided by the package manager?
I feel so. An end user is not interested in the change log at all. A developer or packer may be interested, but mostly in case some things dont work. And in this case you have to dig deeper anyway.... Cheers Axel -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On Wed, Feb 3, 2016 at 10:05 PM, Michal Kubecek
On Tue, Feb 02, 2016 at 03:27:30PM +0100, Petr Červinka wrote:
My opinion (as complete packaging newbie) is, that fill properly .changes file can be difficult. Sometimes is upstream changelog very long, sometimes is almost empty. You can cherry pick interesting points, but i guess that line "updated to version X.Y.Z" should be sufficient.
That's going to far, IMHO. You should at least give reader some hint what to expect, e.g. if it's only a bugfix release or if it brings some incompatible changes of behaviour or config file syntax or semantics, if it fixes some critical (possibly security) bugs etc.
This seems to be good idea, the use of common sense and avoid bad attitude (laziness). Cherry pick bug fixes and new interesting features and ALL actions related to package itself in obs. P. -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
OK, let's repeat the important point: the order was not a result of my creativity or uniqueness. The tag order was result of
osc service localrun format_spec_file
i.e. exactly the command I was told to run by the message of first declined request. (Actually, neither was the original tag order, that came from our vim template.) No creativity, no trying to be unique, exactly the opposite. And seeing that at any time I'm supposed to expect a request with some small change hidden behind a massive reshuffle, that is really annoying. I inadvertently installed spec-cleaner-format_spec_file which replaces obs-service-format_spec_file and gives the service message you indicate above. It kept on moving an %ifarch conditional from the cmake flags down to the bottom of the %build section in a package I was trying to submit to factory, I tore my hair out trying to stop it. obs-service-format_spec_file isn't intrusive and mostly just changes the
On 02/02/2016 11:28, Michal Kubecek wrote: header and brings up real mistakes sometimes. After filing a bug I was told that it's still under development. Spec cleaner needs to be run and then diffed against the old spec file to check for unwanted changes, putting buildrequires in alphabetical order is nice and it also converts some buildrequires to pkgconfig but it doesn't work well with conditionals that make packages build on lower versions of openSUSE. Dave -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
Jan Engelhardt wrote:
Not using brotli wastes diskspace (and time). It's kind of new, but compressed as well as xz, but in the time that it would take gzip. Try it with linux-4*.tar.
Jan, which command line client did you use? I tried brotli with the one from https://github.com/google/brotli but the compression times are not exactly impressive. (much slower than lzma). -- Per Jessen, Zürich (9.6°C) http://www.dns24.ch/ - free dynamic DNS, made in Switzerland. -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
Jan mixed compression and decompression time ...
brotli is designed for use in WWW , one compression ( slow and high
demad on server), in format very similar to gzip ....
and very fast decompression in web browser ...
brotli isn't successor for xz (general compression) , is successor for
GZip in http...
On 6 February 2016 at 13:18, Per Jessen
Jan Engelhardt wrote:
Not using brotli wastes diskspace (and time). It's kind of new, but compressed as well as xz, but in the time that it would take gzip. Try it with linux-4*.tar.
Jan, which command line client did you use? I tried brotli with the one from https://github.com/google/brotli but the compression times are not exactly impressive. (much slower than lzma).
-- Per Jessen, Zürich (9.6°C) http://www.dns24.ch/ - free dynamic DNS, made in Switzerland.
-- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
-- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On Saturday 2016-02-06 13:18, Per Jessen wrote:
Jan Engelhardt wrote:
Not using brotli wastes diskspace (and time). It's kind of new, but compressed as well as xz, but in the time that it would take gzip. Try it with linux-4*.tar.
Jan, which command line client did you use? I tried brotli with the one from https://github.com/google/brotli but the compression times are not exactly impressive. (much slower than lzma).
The google "bro"mance encoder defaults to Q11. The competetive comparison
is achieved with something like Q5/Q6
(Q6 is the defalut for gzip and xz anyway).
$ time (compr)
On Saturday 2016-02-06 16:10, Ondřej Súkup wrote:
Jan mixed compression and decompression time ...
I did not.
brotli isn't successor for xz (general compression) , is successor for GZip in http...
All three of them are general compression algorithms. Your statement is pointless. -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
Jan Engelhardt wrote:
On Saturday 2016-02-06 13:18, Per Jessen wrote:
Jan Engelhardt wrote:
Not using brotli wastes diskspace (and time). It's kind of new, but compressed as well as xz, but in the time that it would take gzip. Try it with linux-4*.tar.
Jan, which command line client did you use? I tried brotli with the one from https://github.com/google/brotli but the compression times are not exactly impressive. (much slower than lzma).
The google "bro"mance encoder defaults to Q11. The competetive comparison is achieved with something like Q5/Q6 (Q6 is the defalut for gzip and xz anyway).
Ahaaa. Much better! Thanks - seems silly to default to q11, I have to say. With the default, I was getting the same compression ratio, but it took 10times longer. I'm testing with a 500Mb mail-log, which lzma will typically compress to 37-38Mb in 6-10mins, depending on the processor. With q6, bro just did 49Mb in 52secs. Wow. For my purposes, that's a significant improvement over xz. Compression time reduced by an order of magnitude or more, at the cost of 10Mb. I notice that bro is seeded with stats from webpages, but I see no way of generating such stats? I have often thought compression could be improved if you know beforehand what's being compressed. -- Per Jessen, Zürich (5.4°C) http://www.hostsuisse.com/ - virtual servers, made in Switzerland. -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
Per Jessen wrote:
Jan Engelhardt wrote:
On Saturday 2016-02-06 13:18, Per Jessen wrote:
Jan Engelhardt wrote:
Not using brotli wastes diskspace (and time). It's kind of new, but compressed as well as xz, but in the time that it would take gzip. Try it with linux-4*.tar.
Jan, which command line client did you use? I tried brotli with the one from https://github.com/google/brotli but the compression times are not exactly impressive. (much slower than lzma).
The google "bro"mance encoder defaults to Q11. The competetive comparison is achieved with something like Q5/Q6 (Q6 is the defalut for gzip and xz anyway).
Ahaaa. Much better! Thanks - seems silly to default to q11, I have to say. With the default, I was getting the same compression ratio, but it took 10times longer.
I'm testing with a 500Mb mail-log, which lzma will typically compress to 37-38Mb in 6-10mins, depending on the processor. With q6, bro just did 49Mb in 52secs. Wow.
Varying the quality setting from 6 to 9 shaves off about 1Mb per level, at a cost of up to 2 minutes runtime. Going to q10 gives me a compression size very close to lzmaq6, but the runtime jumps by an hour. -- Per Jessen, Zürich (8.8°C) http://www.dns24.ch/ - free dynamic DNS, made in Switzerland. -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On Saturday 06 February 2016, Jan Engelhardt wrote:
The google "bro"mance encoder defaults to Q11. The competetive comparison is achieved with something like Q5/Q6 (Q6 is the defalut for gzip and xz anyway).
$ time (compr)
linux-4.4.tar.gz gzip -6: real 0m19.805s; user 0m19.612s; sys 0m00.164s gzip -9: real 0m36.564s; user 0m36.240s; sys 0m00.264s bro -q6: real 0m30.146s; user 0m29.480s; sys 0m00.628s bro -q9: real 1m48.316s; user 1m46.616s; sys 0m01.600s bzip -9: real 1m02.094s; user 1m01.856s; sys 0m00.176s xz -6: real 5m24.331s; user 5m21.264s; sys 0m02.760s xz -9: real 7m21.610s; user 7m00.148s; sys 0m20.984s lzop -6: real 0m1.941s; user 0m01.764s; sys 0m00.172s
On my machine my xz timeings are faster than your's but my gzip timings are slower than yours. Have you really used original gzip? xz -0 is about as fast as gzip -9 but compression is slightly better. In practice I use xz -3 very often because it's about 3 times as fast as xz -6. Should be similar to your bro -q9 compression and time.
$ ls -l -rw-r--r-- 1 648355840 Jan 11 00:12 linux-4.4.tar -rw-r--r-- 1 108864919 Feb 6 17:47 linux-4.4.tar.bro6 -rw-r--r-- 1 102278771 Feb 6 18:09 linux-4.4.tar.bro9 -rw-r--r-- 1 104404286 Feb 6 18:10 linux-4.4.tar.bz2_9 -rw-r--r-- 1 134124849 Feb 6 17:49 linux-4.4.tar.gz6 -rw-r--r-- 1 132860730 Feb 6 18:07 linux-4.4.tar.gz9 -rw-r--r-- 1 224389488 Feb 6 18:02 linux-4.4.tar.lzo6 -rw-r--r-- 1 153760243 Feb 6 18:04 linux-4.4.tar.lzo9 -rw-r--r-- 1 89946128 Feb 6 17:55 linux-4.4.tar.xz6 -rw-r--r-- 1 86729768 Feb 6 18:17 linux-4.4.tar.xz9
compression speed: gzip6: 33.05 MB/user sec; gzip9: 17.89 bro6: 21.99 bro9: 6.08 xz: 2.01
result size × time = "pain points" (lower is better); gzip: 2.6 * 10^9 bro6: 3.2 * 10^9 xz: 28.8 * 10^9
(you can calculate the rest)
Err ... do you really think that your "pain points" definition makes any sense? The worst compression would always win. No-compressesion (do nothing with the original file) takes 0 time, means 0 pain. Who could beat that? Even if no-compression would take 4 secs then it would have less than your gzip's 2.6 giga points :) cu, Rudi -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On Monday 2016-02-08 11:01, Ruediger Meier wrote:
On Saturday 06 February 2016, Jan Engelhardt wrote:
The google "bro"mance encoder defaults to Q11. The competetive comparison is achieved with something like Q5/Q6 (Q6 is the defalut for gzip and xz anyway).
$ time (compr)
linux-4.4.tar.gz gzip -6: real 0m19.805s; user 0m19.612s; sys 0m00.164s gzip -9: real 0m36.564s; user 0m36.240s; sys 0m00.264s bro -q6: real 0m30.146s; user 0m29.480s; sys 0m00.628s bro -q9: real 1m48.316s; user 1m46.616s; sys 0m01.600s bzip -9: real 1m02.094s; user 1m01.856s; sys 0m00.176s xz -6: real 5m24.331s; user 5m21.264s; sys 0m02.760s xz -9: real 7m21.610s; user 7m00.148s; sys 0m20.984s lzop -6: real 0m1.941s; user 0m01.764s; sys 0m00.172s On my machine my xz timeings are faster than your's but my gzip timings are slower than yours. Have you really used original gzip?
No pigz, pixz. L2 size 256K, system laden with boinc running. YTMV. -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On 2016-02-01 23:10, Michal Kubecek wrote:
Hello,
you might remember recent discussion in opensuse-factory mailing list on this topic. While the statistics that started it were inherently flawed, there seemed to be a consensus that Factory doesn't have as many packages as it could and that there are many packages in devel projects or home projects that are never submitted to Factory.
I was thinking why shouldn't we create a "Contrib" repo, which has much less bureaucracy, so that we could get more packages into one central repo (because as a user I dont like to have too many extra devel repos enabled - because it makes zypper ref slow and zypper dup unpredictable). The linux kernel has that "staging" area with "crap" drivers for similar reasons. The policies for the repo could be simple. 1. no submits from home repos - this ensures that packages are maintained in devel repos, which makes it easier for more than one person to care for it. 2. package must build for Factory 3. no replacements of Factory packages/files (similar to the openSUSE:Backports repo) and as an additional guideline: if a package is important (who decides?), it should go to Factory instead - this gives it the added benefit of review and openQA testing All requirements can actually be checked by a bot, so that instantaneous updates would be possible. Pros: 1. The Contrib repo could build for multiple openSUSE/SLE versions, making it easy to provide a package for all of them (similar to (some) devel repos). 2. More packages in one place, making it more accessible to the majority of our users. Giving packages more visibility could also lead to more contributions, which could help getting it into Factory. 3. Less conflicts between package versions (if there are different people requiring a certain non-factory component, it would indicate that the component is important and people should work on getting it into Factory) Cons: 1. no openQA testing (same as with non-factory packages now, so it is not worse than that) 2. needs some extra logic for building for older *SUSE releases for requirements that went into Factory later => coding effort Can you think of other Pros and Cons? And should we try it? Ciao Bernhard M. -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On Tuesday 2016-02-09 15:53, Bernhard M. Wiedemann wrote:
On 2016-02-01 23:10, Michal Kubecek wrote:
Factory doesn't have as many packages as it could and that there are many packages in devel projects or home projects that are never submitted to Factory.
I was thinking why shouldn't we create a "Contrib" repo, which has much less bureaucracy
What checks and balances ("bureaucracy") are there in Factory that Contrib is not going to have?
The policies for the repo could be simple.
1. no submits from home repos - this ensures that packages are maintained in devel repos, which makes it easier for more than one person to care for it. 2. package must build for Factory 3. no replacements of Factory packages/files (similar to the openSUSE:Backports repo)
That sounds just like Factory itself. -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On 9 February 2016 at 15:53, Bernhard M. Wiedemann
On 2016-02-01 23:10, Michal Kubecek wrote:
Hello,
you might remember recent discussion in opensuse-factory mailing list on this topic. While the statistics that started it were inherently flawed, there seemed to be a consensus that Factory doesn't have as many packages as it could and that there are many packages in devel projects or home projects that are never submitted to Factory.
I was thinking why shouldn't we create a "Contrib" repo, which has much less bureaucracy, so that we could get more packages into one central repo (because as a user I dont like to have too many extra devel repos enabled - because it makes zypper ref slow and zypper dup unpredictable). The linux kernel has that "staging" area with "crap" drivers for similar reasons.
The policies for the repo could be simple.
1. no submits from home repos - this ensures that packages are maintained in devel repos, which makes it easier for more than one person to care for it. 2. package must build for Factory 3. no replacements of Factory packages/files (similar to the openSUSE:Backports repo)
and as an additional guideline: if a package is important (who decides?), it should go to Factory instead - this gives it the added benefit of review and openQA testing
All requirements can actually be checked by a bot, so that instantaneous updates would be possible.
Pros: 1. The Contrib repo could build for multiple openSUSE/SLE versions, making it easy to provide a package for all of them (similar to (some) devel repos).
2. More packages in one place, making it more accessible to the majority of our users. Giving packages more visibility could also lead to more contributions, which could help getting it into Factory.
3. Less conflicts between package versions (if there are different people requiring a certain non-factory component, it would indicate that the component is important and people should work on getting it into Factory)
Cons: 1. no openQA testing (same as with non-factory packages now, so it is not worse than that)
2. needs some extra logic for building for older *SUSE releases for requirements that went into Factory later => coding effort
Can you think of other Pros and Cons? And should we try it?
Ciao Bernhard M.
Please, no, just no the openSUSE Project builds distributions that work Working requires some standards The Factory standards are not overly strict. Sure there lots of are guidelines which are 'nice to have', but the issues that lead to a package being rejected are few and far between, and totally and utterly sensible when considering the context of a large open source project of hundreds of contributors and thousands of packages Let's not compromise the quality of the openSUSE distributions with a collective dumping ground with low standards - Lets raise the quantity of packages in the openSUSE distributions by adding more packages into them -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
* Bernhard M. Wiedemann
I was thinking why shouldn't we create a "Contrib" repo, which has much less bureaucracy
The bureaucracy is why I stopped contributing packages to Factory. Simple as that. Getting a package building and functioning is enough work. I just don't have the energy/time to pass the Factory 'bar' afterwards. Klaus -- 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 úterý 9. února 2016 16:49:50 CET Richard Brown wrote:
On 9 February 2016 at 15:53, Bernhard M. Wiedemann
wrote: On 2016-02-01 23:10, Michal Kubecek wrote:
Hello,
you might remember recent discussion in opensuse-factory mailing list on this topic. While the statistics that started it were inherently flawed, there seemed to be a consensus that Factory doesn't have as many packages as it could and that there are many packages in devel projects or home projects that are never submitted to Factory.
I was thinking why shouldn't we create a "Contrib" repo, which has much less bureaucracy, so that we could get more packages into one central repo (because as a user I dont like to have too many extra devel repos enabled - because it makes zypper ref slow and zypper dup unpredictable). The linux kernel has that "staging" area with "crap" drivers for similar reasons.
The policies for the repo could be simple.
1. no submits from home repos
- this ensures that packages are maintained in devel repos, which
makes it easier for more than one person to care for it. 2. package must build for Factory 3. no replacements of Factory packages/files (similar to the openSUSE:Backports repo)
and as an additional guideline: if a package is important (who decides?), it should go to Factory instead
- this gives it the added benefit of review and openQA testing
All requirements can actually be checked by a bot, so that instantaneous updates would be possible.
Pros: 1. The Contrib repo could build for multiple openSUSE/SLE versions, making it easy to provide a package for all of them (similar to (some) devel repos).
2. More packages in one place, making it more accessible to the majority of our users. Giving packages more visibility could also lead to more contributions, which could help getting it into Factory.
3. Less conflicts between package versions (if there are different people requiring a certain non-factory component, it would indicate that the component is important and people should work on getting it into Factory)
Cons: 1. no openQA testing (same as with non-factory packages now, so it is not worse than that)
2. needs some extra logic for building for older *SUSE releases for requirements that went into Factory later => coding effort
Can you think of other Pros and Cons? And should we try it?
Ciao Bernhard M.
Please, no, just no
the openSUSE Project builds distributions that work
Working requires some standards
The Factory standards are not overly strict. Sure there lots of are guidelines which are 'nice to have', but the issues that lead to a package being rejected are few and far between, and totally and utterly sensible when considering the context of a large open source project of hundreds of contributors and thousands of packages
Let's not compromise the quality of the openSUSE distributions with a collective dumping ground with low standards - Lets raise the quantity of packages in the openSUSE distributions by adding more packages into them
My understanding of this proposal is that it would just create another Factory, one from the past, one that was often broken. As already said above - please, no, just no Cheers Martin Pluskal
Le mardi 09 février 2016 à 17:16 +0100, Klaus Kaempf a écrit :
* Bernhard M. Wiedemann
[Feb 09. 2016 15:54]: I was thinking why shouldn't we create a "Contrib" repo, which has much less bureaucracy
The bureaucracy is why I stopped contributing packages to Factory.
So, could you explicit what exactly you mean by "bureaucracy", in your case ? -- Frederic Crozat Enterprise Desktop Release Manager SUSE -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On 09/02/2016 16:53, Bernhard M. Wiedemann wrote:
On 2016-02-01 23:10, Michal Kubecek wrote:
Hello,
you might remember recent discussion in opensuse-factory mailing list on this topic. While the statistics that started it were inherently flawed, there seemed to be a consensus that Factory doesn't have as many packages as it could and that there are many packages in devel projects or home projects that are never submitted to Factory. I was thinking why shouldn't we create a "Contrib" repo, which has much less bureaucracy, so that we could get more packages into one central repo (because as a user I dont like to have too many extra devel repos enabled - because it makes zypper ref slow and zypper dup unpredictable). The linux kernel has that "staging" area with "crap" drivers for similar reasons.
The policies for the repo could be simple.
1. no submits from home repos - this ensures that packages are maintained in devel repos, which makes it easier for more than one person to care for it. 2. package must build for Factory 3. no replacements of Factory packages/files (similar to the openSUSE:Backports repo)
and as an additional guideline: if a package is important (who decides?), it should go to Factory instead - this gives it the added benefit of review and openQA testing
All requirements can actually be checked by a bot, so that instantaneous updates would be possible.
Pros: 1. The Contrib repo could build for multiple openSUSE/SLE versions, making it easy to provide a package for all of them (similar to (some) devel repos).
2. More packages in one place, making it more accessible to the majority of our users. Giving packages more visibility could also lead to more contributions, which could help getting it into Factory.
3. Less conflicts between package versions (if there are different people requiring a certain non-factory component, it would indicate that the component is important and people should work on getting it into Factory)
Cons: 1. no openQA testing (same as with non-factory packages now, so it is not worse than that)
2. needs some extra logic for building for older *SUSE releases for requirements that went into Factory later => coding effort
Can you think of other Pros and Cons? And should we try it?
Ciao Bernhard M.
AFAICR there was once a contrib project in the days before I got heavily involved in packaging but it disappeared as quickly as it had appeared. I got involved in packaging because I like my system to be stable, I like all the necessary libraries to be installed to support the applications I use and I like to be able to uninstall those apps without having any unwanted debris left around. With windows you often get debris left around because, unless you want to pay big bucks you install stuff that hijacks your browser and slows your system down and leaves a host of unwanted registry rubbish behind linux doesn't do that, everything you install is clean, no virus's, no bloatware and it's free. I started with SuSE 8.2 (with failing hard drives running reisers fs) and it works so I'm sticking with it. I've submitted a few packages to Factory over the years and attended to subsequent bugs and I'm proud of my packaging work. Yes I had a package rejected by Factory autobuild because my patch explanation was missed at the bottom of the changes file, I simply moved it to the top, I thought the auto provides file was more important but I moved it to the top of the changes file and resubmitted. I don't think Factory is too strict I think it helps to make a good system. As far as contrib is concerned, I've links to a few of my packages in Packman, so users can get up to date versions whenever there's an update. I'm primarily involved in multimedia so the packages fit Packman but I put an ffmpeg enabled blender there too. If the Packman build service wasn't so under resourced it would make a perfect contrib. Just my ten cents Dave Plater -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
The primary issue to which I've hit is legal review. 2 months and still pending.
--
Jimmy
On Tue, Feb 9, 2016 at 12:09 PM, Dave Plater
On 09/02/2016 16:53, Bernhard M. Wiedemann wrote:
On 2016-02-01 23:10, Michal Kubecek wrote:
Hello,
you might remember recent discussion in opensuse-factory mailing list on this topic. While the statistics that started it were inherently flawed, there seemed to be a consensus that Factory doesn't have as many packages as it could and that there are many packages in devel projects or home projects that are never submitted to Factory.
I was thinking why shouldn't we create a "Contrib" repo, which has much less bureaucracy, so that we could get more packages into one central repo (because as a user I dont like to have too many extra devel repos enabled - because it makes zypper ref slow and zypper dup unpredictable). The linux kernel has that "staging" area with "crap" drivers for similar reasons.
The policies for the repo could be simple.
1. no submits from home repos - this ensures that packages are maintained in devel repos, which makes it easier for more than one person to care for it. 2. package must build for Factory 3. no replacements of Factory packages/files (similar to the openSUSE:Backports repo)
and as an additional guideline: if a package is important (who decides?), it should go to Factory instead - this gives it the added benefit of review and openQA testing
All requirements can actually be checked by a bot, so that instantaneous updates would be possible.
Pros: 1. The Contrib repo could build for multiple openSUSE/SLE versions, making it easy to provide a package for all of them (similar to (some) devel repos).
2. More packages in one place, making it more accessible to the majority of our users. Giving packages more visibility could also lead to more contributions, which could help getting it into Factory.
3. Less conflicts between package versions (if there are different people requiring a certain non-factory component, it would indicate that the component is important and people should work on getting it into Factory)
Cons: 1. no openQA testing (same as with non-factory packages now, so it is not worse than that)
2. needs some extra logic for building for older *SUSE releases for requirements that went into Factory later => coding effort
Can you think of other Pros and Cons? And should we try it?
Ciao Bernhard M.
AFAICR there was once a contrib project in the days before I got heavily involved in packaging but it disappeared as quickly as it had appeared. I got involved in packaging because I like my system to be stable, I like all the necessary libraries to be installed to support the applications I use and I like to be able to uninstall those apps without having any unwanted debris left around. With windows you often get debris left around because, unless you want to pay big bucks you install stuff that hijacks your browser and slows your system down and leaves a host of unwanted registry rubbish behind linux doesn't do that, everything you install is clean, no virus's, no bloatware and it's free. I started with SuSE 8.2 (with failing hard drives running reisers fs) and it works so I'm sticking with it. I've submitted a few packages to Factory over the years and attended to subsequent bugs and I'm proud of my packaging work. Yes I had a package rejected by Factory autobuild because my patch explanation was missed at the bottom of the changes file, I simply moved it to the top, I thought the auto provides file was more important but I moved it to the top of the changes file and resubmitted. I don't think Factory is too strict I think it helps to make a good system. As far as contrib is concerned, I've links to a few of my packages in Packman, so users can get up to date versions whenever there's an update. I'm primarily involved in multimedia so the packages fit Packman but I put an ffmpeg enabled blender there too. If the Packman build service wasn't so under resourced it would make a perfect contrib. Just my ten cents Dave Plater
-- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
-- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On Tuesday 2016-02-09 22:59, Jimmy Berry wrote:
The primary issue to which I've hit is legal review. 2 months and still pending.
Are you trying to publish any of the blacklisted sw? Or some huge package? -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On Tue, Feb 9, 2016 at 7:02 PM, Jan Engelhardt
On Tuesday 2016-02-09 22:59, Jimmy Berry wrote:
The primary issue to which I've hit is legal review. 2 months and still pending.
Are you trying to publish any of the blacklisted sw? Or some huge package?
adminer which does not fit either description. -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On 2016-02-09 16:25, Frederic Crozat wrote:
Le mardi 09 février 2016 à 17:16 +0100, Klaus Kaempf a écrit :
* Bernhard M. Wiedemann
[Feb 09. 2016 15:54]: I was thinking why shouldn't we create a "Contrib" repo, which has much less bureaucracy The bureaucracy is why I stopped contributing packages to Factory. So, could you explicit what exactly you mean by "bureaucracy", in your case ?
I remember the story as thus: Klaus packaged something and got it building in OBS for Fedora and openSUSE. The package was accepted in Fedora and rejected in openSUSE, asking him to use openSUSE-only macros in the spec file, which would break Fedora builds, which would increase the overall maintenance effort. Thus one package less for openSUSE. -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On Tue, Feb 09, 2016 at 05:16:12PM +0100, Klaus Kaempf wrote:
* Bernhard M. Wiedemann
[Feb 09. 2016 15:54]: I was thinking why shouldn't we create a "Contrib" repo, which has much less bureaucracy
The bureaucracy is why I stopped contributing packages to Factory.
Simple as that.
Getting a package building and functioning is enough work. I just don't have the energy/time to pass the Factory 'bar' afterwards.
The interesting point here is that both parties are satisfied. We've got good and maintainable distribution with good package quality. Best regards, S_W
Hey, On 09.02.2016 15:53, Bernhard M. Wiedemann wrote:
I was thinking why shouldn't we create a "Contrib" repo
What would be different from the Contrib repo we have started, failed with because people didn't care about their submissions, and closed some years ago? Henne -- Henne Vogelsang http://www.opensuse.org Everybody has a plan, until they get hit. - Mike Tyson -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On Wed, 10 Feb 2016 11:25, Henne Vogelsang wrote:
On 09.02.2016 15:53, Bernhard M. Wiedemann wrote:
I was thinking why shouldn't we create a "Contrib" repo
What would be different from the Contrib repo we have started, failed with because people didn't care about their submissions, and closed some years ago?
Henne
## Proposal: ## (open)SUSE has no direct equivialient to Centos/Redhat EPEL. Call that child "ExtraPackages", "Contrib", or any other (short, but significant) name. ## What is the diff from plain Distro / Factory(Tumbleweed) ? ## * No legal review forced, but welcome. "The Rules" for allowed on openSUSE obs still apply, so the software should be able to pass muster, else it's a candidate for Packman. * Niggles, like: "Wah! Use SUSE special macros only!" do NOT apply. No special SUSE only stuff, valid package means: valid (rpm)build, valid test (build, install, run, uninstall) * Newer Versions than on Distro are welcome. Which lowers the pressure to get things into Distro, gives extra testing, should make getting approval for Distro / Factory easier, if proven good in this repo. ## Why should (open)SUSE enable such a repo? ## * To get to the point where a normal user has four (4) repos max active, or even installed at all: 1. Distro (Frozen Gold) 2. Distro Update 3. Packman (for Multimdia, codecs, stuff not legally possible in Distro) 4. "ExtraPackages Repo" * Reduceing the number of active repos on the user machines reduces interference between these repo, giving way to a smoother experience. * Reducing the pressure on legal team. Times and times again legal review (the time it took between initial review request and review done) has been very contra productive in getting packages ready for Factory. Added to legal came the "Extra SUSE only" stuff by distro rules. Enabling a step-between devel-repo and distro-repo (Factory) gives us packagers the space to breath, the interested users the extra time to use (and test) such a package, and when done with the legal review, and the additional distro testing the package can be moved into Factory repo while still living in "ExtraPackages" for the already released distros. That my oppinion and idea? Do you all have a better one? IMHO "Contrib" is the wrong name (leaden with past faiure), "EPS" (ExtraPackagesSUSE) would be short, pointed, and recognizeable. - Yamaban. -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On Wed, Feb 10, Yamaban wrote:
4. "ExtraPackages Repo"
Project.
* Reduceing the number of active repos on the user machines reduces interference between these repo, giving way to a smoother experience.
What pkg would go into such prj, what would be in its repo list? The question from Henne was not answered yet. Olaf -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
* Bernhard M. Wiedemann
On 2016-02-09 16:25, Frederic Crozat wrote:
So, could you explicit what exactly you mean by "bureaucracy", in your case ?
I remember the story as thus: Klaus packaged something and got it building in OBS for Fedora and openSUSE. The package was accepted in Fedora and rejected in openSUSE, asking him to use openSUSE-only macros in the spec file, which would break Fedora builds, which would increase the overall maintenance effort.
Exactly. That was where I finally gave up. I put a lot of effort into pushing SUSE-specifics into the upstream .spec but the Factory maintainers back then basically said "specs must be pure-SUSE". Klaus -- 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
Hello, On Feb 10 12:17 Yamaban wrote (excerpt):
* No legal review forced, but welcome.
No enforced legal review means the whole stuff must never ever exist on any server where SUSE is responsible for. In short: You would need to do that totally on your own in your own domain on your own server. 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 10.02.2016 12:46, Klaus Kaempf wrote:
* Bernhard M. Wiedemann
[Feb 10. 2016 08:12]: On 2016-02-09 16:25, Frederic Crozat wrote:
So, could you explicit what exactly you mean by "bureaucracy", in your case ?
I remember the story as thus: Klaus packaged something and got it building in OBS for Fedora and openSUSE. The package was accepted in Fedora and rejected in openSUSE, asking him to use openSUSE-only macros in the spec file, which would break Fedora builds, which would increase the overall maintenance effort.
Exactly. That was where I finally gave up. I put a lot of effort into pushing SUSE-specifics into the upstream .spec but the Factory maintainers back then basically said "specs must be pure-SUSE".
I don't remember any such case. What I *do* remember is people submitting debian files next to the spec file not mentioned in the spec file. Greetings, Stephan -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On Wed, 2016-02-10 at 12:17 +0100, Yamaban wrote:
* Niggles, like: "Wah! Use SUSE special macros only!" do NOT apply. No special SUSE only stuff, valid package means: valid (rpm)build, valid test (build, install, run, uninstall)
References please - As an active member of the review team I am pretty sure that having build conditions for other distros in the package are no decline reason. Just as special conditions to build differently on PM for example are no decline reason. For arguments sake: check out libzypp.spec: it is filled with fedora_version. Squid also has checks for fedora_version. Si I dare say: this claim is false.
* Newer Versions than on Distro are welcome. Which lowers the pressure to get things into Distro, gives extra testing, should make getting approval for Distro / Factory easier, if proven good in this repo.
I for one will refuse all bugs coming from replaced libaries that people feel have to go into any such contrib repo - if the bug can't be reproduced without "Contrib" there is no bug for me.
## Why should (open)SUSE enable such a repo? ##
* To get to the point where a normal user has four (4) repos max active, or even installed at all: 1. Distro (Frozen Gold) 2. Distro Update 3. Packman (for Multimdia, codecs, stuff not legally possible in Distro) 4. "ExtraPackages Repo"
Plus the Google Chrome repo, plus Adobes Repo, Plus... A noble goal, but getting the packages ion a decent quality into the distro makes the number by one less. If you anyway 'force' PM on the users: why not use it as contrib (it's scope is way beyond Multimedia anyway) Cheers, Dominique -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On Wednesday 10 February 2016, Olaf Hering wrote:
On Wed, Feb 10, Yamaban wrote:
4. "ExtraPackages Repo"
Project.
* Reduceing the number of active repos on the user machines reduces interference between these repo, giving way to a smoother experience.
What pkg would go into such prj, what would be in its repo list? The question from Henne was not answered yet.
IMO the worst thing about such big contrib repo is that if you only want to update one single package then it might need to update many other updated dependencies too. So this one package update may have many side effects. That's why I think users should maintain their own "contrib" projects like I have my personal "home:rudi_m:musthave". This gets usually bigger and bigger during distro lifetime. After a distro upgrade I can remove most packages again. But it would be nice to make it more easy to simply link certain packages from devel projects to my home project. Spec files in devel projects should be as portable as possible. The enabled repos should be the same for each devel project and they should include even the old but still supported distros (inclusive evergreen). A good example is the "utilities" devel project. Most of it's packages build without problems if you link it to your home project. cu, Rudi -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On Wed, 2016-02-10 at 12:58 +0100, Dominique Leuenberger / DimStar wrote:
On Wed, 2016-02-10 at 12:17 +0100, Yamaban wrote:
* Niggles, like: "Wah! Use SUSE special macros only!" do NOT apply. No special SUSE only stuff, valid package means: valid (rpm)build, valid test (build, install, run, uninstall)
References please - As an active member of the review team I am pretty sure that having build conditions for other distros in the package are no decline reason. Just as special conditions to build differently on PM for example are no decline reason. For arguments sake: check out libzypp.spec: it is filled with fedora_version. Squid also has checks for fedora_version.
As we all like hard facts, I did the following in a openSUSE:Factory checkout (all packages): find -maxdepth 2 -name '*.spec' -exec grep -l "?fedora" {} \; | wc -l Turns out we currently have 117 spec files that contain the string "?fedora" which is most commonly used in %{?fedora_version}. So, there is really no reason why one would not be allowed to submit .spec files with non-openSUSE specific parts in it (but please: try to keep the .spec files readable - the Review team favors readable diffs) Cheers, Dominique -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On Wed, 10 Feb 2016 12:25, Olaf Hering wrote:
On Wed, Feb 10, Yamaban wrote:
4. "ExtraPackages Repo"
Project.
* Reduceing the number of active repos on the user machines reduces interference between these repo, giving way to a smoother experience.
What pkg would go into such prj, what would be in its repo list? The question from Henne was not answered yet.
E.g. {KDE,Gnome,XFCE,...}:Extra build against Distro:Update would be just a few of the candidates, or other apps in newer versions than Distro. A full DE upgrade (like KDE4 to plasma5) should NOT be in this repo. To much change for breaks and frustrations. Most additional apps from the devel repos that are not commited to Distro / Factory are candidates. - Yamaban. -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On Wed, 2016-02-10 at 18:12 +0100, Yamaban wrote:
What pkg would go into such prj, what would be in its repo list? The question from Henne was not answered yet.
E.g. {KDE,Gnome,XFCE,...}:Extra build against Distro:Update would be just a few of the candidates, or other apps in newer versions than Distro.
I think I can speak for the entire GNOME Team here: no one of us will do efforts to get the GNOME Stack into any contrib repo. GNOME historically wants a solid and recent underlying base system. It's not rare that a GNOME Update asked for an updated X-Stack (or at least parts of it) - or more recent system library of anything. Asking for commitment from the GNOME Team (which is somewhat 2 - 3 people) to maintain this on a different level for backports is utopic. This is not to say that you can't add GNOME to any such contrib repo - just that you will need a maintainer team for it that is also willing and capable of handling bugs. The packages alone are 'the easy part' (It's not just an accident that we do not provide GNOME:STABLE:* repos for all kind of combinations) Cheers, Dominique -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On Wed, Feb 10, 2016 at 1:04 AM, Tomáš Čech
On Tue, Feb 09, 2016 at 05:16:12PM +0100, Klaus Kaempf wrote:
The bureaucracy is why I stopped contributing packages to Factory.
Simple as that.
Getting a package building and functioning is enough work. I just don't have the energy/time to pass the Factory 'bar' afterwards.
The interesting point here is that both parties are satisfied.
I don't read Klaus' statement as one of satisfaction. I infer he still wishes he could have found someone who was willing to work with him to get the package into Factory.
We've got good and maintainable distribution with good package quality.
The title of this thread is "how to get more packages into a central repo". It sounds to me Klaus found out how to become discouraged. I think there is a shared responsibility for the lack of the inclusion of whatever package Klaus got built and functioning, but not in Factory between Klaus and whomever made the personal decision(s) not to step forward and offer help or reduce the effort to include a package. -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On středa 10. února 2016 14:41:08 CET PatrickD Garvey wrote:
On Wed, Feb 10, 2016 at 1:04 AM, Tomáš Čech
wrote: On Tue, Feb 09, 2016 at 05:16:12PM +0100, Klaus Kaempf wrote:
The bureaucracy is why I stopped contributing packages to Factory.
Simple as that.
Getting a package building and functioning is enough work. I just don't have the energy/time to pass the Factory 'bar' afterwards.
The interesting point here is that both parties are satisfied.
I don't read Klaus' statement as one of satisfaction. I infer he still wishes he could have found someone who was willing to work with him to get the package into Factory.
We've got good and maintainable distribution with good package quality.
The title of this thread is "how to get more packages into a central repo". It sounds to me Klaus found out how to become discouraged. I think there is a shared responsibility for the lack of the inclusion of whatever package Klaus got built and functioning, but not in Factory between Klaus and whomever made the personal decision(s) not to step forward and offer help or reduce the effort to include a package. Hmmpf "personal decision(s) not to step forward" sounds a bit strange to me :)
Anyway, I sometimes check requests to Factory, especially declined ones, and then try to send sr which would get package acceptable to Factory, in case of tcpreplay, I noticed some issues/room for improvement, thus I send sr, which lead to this whole thread. I kind of feel that we went full circle in this debate. tldr: stepping in lead to discussion about bureaucracy Regards Martin -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On Wed, Feb 10, 2016 at 02:41:08PM -0800, PatrickD Garvey wrote:
On Wed, Feb 10, 2016 at 1:04 AM, Tomáš Čech
wrote: On Tue, Feb 09, 2016 at 05:16:12PM +0100, Klaus Kaempf wrote:
The bureaucracy is why I stopped contributing packages to Factory.
Simple as that.
Getting a package building and functioning is enough work. I just don't have the energy/time to pass the Factory 'bar' afterwards.
The interesting point here is that both parties are satisfied.
I don't read Klaus' statement as one of satisfaction. I infer he still wishes he could have found someone who was willing to work with him to get the package into Factory.
OK, poor wording on my side. I should say - situation is balanced.
We've got good and maintainable distribution with good package quality.
The title of this thread is "how to get more packages into a central repo". It sounds to me Klaus found out how to become discouraged. I think there is a shared responsibility for the lack of the inclusion of whatever package Klaus got built and functioning, but not in Factory between Klaus and whomever made the personal decision(s) not to step forward and offer help or reduce the effort to include a package.
I think that situation has changed over the years. I can only guess but I think that Klaus' experience is not recent. With the OBS which has support for many distributions spec file compatibility is valued feature and I can't imagine that anyone from review team would rant about it these days. You can see that also on preferred behavior in spec-cleaner tool. My experience with review team was always stellar. When the request is denied, I know why or I can ask further. Sometimes I even got SR with the fix but I'd never rant if there is none. They do it in their free time and there is no really no fun in this activity. If it works, it is silently accepted, when there is problem, they are to blame. If you don't belive it, try it. I did. For me they are true silent heroes of our distribution ;) Best regards, S_W
On Thu, Feb 11, 2016 at 7:28 AM, Tomáš Čech
On Wed, Feb 10, 2016 at 02:41:08PM -0800, PatrickD Garvey wrote:
On Wed, Feb 10, 2016 at 1:04 AM, Tomáš Čech
wrote: On Tue, Feb 09, 2016 at 05:16:12PM +0100, Klaus Kaempf wrote:
The bureaucracy is why I stopped contributing packages to Factory.
Simple as that.
Getting a package building and functioning is enough work. I just don't have the energy/time to pass the Factory 'bar' afterwards.
The interesting point here is that both parties are satisfied.
I don't read Klaus' statement as one of satisfaction. I infer he still wishes he could have found someone who was willing to work with him to get the package into Factory.
OK, poor wording on my side. I should say - situation is balanced.
We've got good and maintainable distribution with good package quality.
The sentence above indicates to me that you don't wish the distribution to grow the number of components offered for an installer's choice at installation of openSUSE because that would increase the difficulty in maintaining the package quality. I agree, it would increase the effort required to maintain the quality. The loss inherent in such a balance is an installer of openSUSE would need to repeat Klaus' effort before the said installer could also use the same package. That may be a teaching moment in the life of the installer, but it would be a loss of available time to do the many other things that represent an improvement in the quality of openSUSE.
The title of this thread is "how to get more packages into a central repo". It sounds to me Klaus found out how to become discouraged. I think there is a shared responsibility for the lack of the inclusion of whatever package Klaus got built and functioning, but not in Factory between Klaus and whomever made the personal decision(s) not to step forward and offer help or reduce the effort to include a package.
I think that situation has changed over the years. I can only guess but I think that Klaus' experience is not recent. With the OBS which has support for many distributions spec file compatibility is valued feature and I can't imagine that anyone from review team would rant about it these days. You can see that also on preferred behavior in spec-cleaner tool.
My experience with review team was always stellar. When the request is denied, I know why or I can ask further.
Sometimes I even got SR with the fix but I'd never rant if there is none.
They do it in their free time and there is no really no fun in this activity. If it works, it is silently accepted, when there is problem, they are to blame. If you don't belive it, try it. I did. For me they are true silent heroes of our distribution ;)
I think this is where Richard Brown's suggestion to, "4i. Talk about it!" is relevant. Here, in this posting, you have thanked those "silent heroes". Perhaps there is some way we can learn to give our thanks each time they have benefited openSUSE with their efforts on our individual behalf? -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On Thu, Feb 11, 2016 at 03:55:21PM -0800, PatrickD Garvey wrote:
On Thu, Feb 11, 2016 at 7:28 AM, Tomáš Čech
wrote: On Wed, Feb 10, 2016 at 02:41:08PM -0800, PatrickD Garvey wrote:
On Wed, Feb 10, 2016 at 1:04 AM, Tomáš Čech
wrote: On Tue, Feb 09, 2016 at 05:16:12PM +0100, Klaus Kaempf wrote:
The bureaucracy is why I stopped contributing packages to Factory.
Simple as that.
Getting a package building and functioning is enough work. I just don't have the energy/time to pass the Factory 'bar' afterwards.
The interesting point here is that both parties are satisfied.
I don't read Klaus' statement as one of satisfaction. I infer he still wishes he could have found someone who was willing to work with him to get the package into Factory.
OK, poor wording on my side. I should say - situation is balanced.
We've got good and maintainable distribution with good package quality.
The sentence above indicates to me that you don't wish the distribution to grow the number of components offered for an installer's choice at installation of openSUSE because that would increase the difficulty in maintaining the package quality. I agree, it would increase the effort required to maintain the quality.
My impression is that you shift the meaning of what I write. English is not my mother tongue but I think I wrote that unambiguously. No, I wish to grow number of packages but not at cost of lowering "the quality bar". If it can't meet quality requirements, I'd rather reject the package. People are frustrated about the bureaucracy of the process because they see package submission as their goal. But from the distribution POV it is just beginning and all that rules and quality requirements are set to ease package maintenance - which is something that is important for every other user. It would be nice if people contact either review team, IRC channel or mailing list asking for help before they got frustrated and annoyed. Best regards, S_W
On Fri, Feb 12, 2016 at 1:10 AM, Tomáš Čech
On Thu, Feb 11, 2016 at 03:55:21PM -0800, PatrickD Garvey wrote:
On Thu, Feb 11, 2016 at 7:28 AM, Tomáš Čech
wrote: On Wed, Feb 10, 2016 at 02:41:08PM -0800, PatrickD Garvey wrote:
On Wed, Feb 10, 2016 at 1:04 AM, Tomáš Čech
wrote: On Tue, Feb 09, 2016 at 05:16:12PM +0100, Klaus Kaempf wrote:
The bureaucracy is why I stopped contributing packages to Factory.
Simple as that.
Getting a package building and functioning is enough work. I just don't have the energy/time to pass the Factory 'bar' afterwards.
The interesting point here is that both parties are satisfied.
I don't read Klaus' statement as one of satisfaction. I infer he still wishes he could have found someone who was willing to work with him to get the package into Factory.
OK, poor wording on my side. I should say - situation is balanced.
We've got good and maintainable distribution with good package quality.
The sentence above indicates to me that you don't wish the distribution to grow the number of components offered for an installer's choice at installation of openSUSE because that would increase the difficulty in maintaining the package quality. I agree, it would increase the effort required to maintain the quality.
My impression is that you shift the meaning of what I write. English is not my mother tongue but I think I wrote that unambiguously.
The problem in unambiguous communication in English is that English has so many ways to say the same thing and so many meanings are carried by the same few, carefully chosen words. That is why I fed back my understanding of what you said. You construct well-written English sentences. I just think we are discussing something important and I don't want this to turn into a flame war just from a small misinterpretation on my part.
No, I wish to grow number of packages but not at cost of lowering "the quality bar". If it can't meet quality requirements, I'd rather reject the package.
I stand with you here. One of the things that attracted me to openSUSE was openQA, which I thought was the first attempt I had seen in a Linux distro to apply computer tools to the quality of the distro. I most definitely want what is offered to avoid regressions, which I have come to understand is a strength of openQA. So, Yes, whatever is available as an openSUSE repository or ISO should meet quality requirements.
People are frustrated about the bureaucracy of the process because they see package submission as their goal. But from the distribution POV it is just beginning and all that rules and quality requirements are set to ease package maintenance - which is something that is important for every other user.
Yes, that would be one cause of the frustration, a mismatch between the submitter's expectations and the maintainer's objectives.
It would be nice if people contact either review team, IRC channel or mailing list asking for help before they got frustrated and annoyed.
This is where I wonder if we couldn't find an improvement. Is this not a two-sided problem? If the review process has the same challenge of using the English language, is it not possible for a submitter to perceive a certain arbitrariness to the standards being used by the reviewers? I have worked between two sides of a similar situation. I have had to train Engineers to watch the way they use the software meant to facilitate the design process so that they can describe what led up to a problem that we needed to report to the software shop that built the software. They hated the amount of time and other effort that was required to make the tool produce what they wanted in the manner they wanted to use the tool. I also had to educate the software shop's first-level report taker to not ask for that which can not be provided, namely a keystroke by keystroke recreation of the failure. The first-level, of course, was operating from the perception that the people he was fronting wanted that sort of report. Together we worked on the process so what could be provided would be accepted as part of the information from multiple sources that would lead to an improvement in the software. My perception in the case of submissions to a distro is that the submitter and reviewer need to synchronize their expectations or maybe the process can find a way to accept the work done as a intermediate contribution that still needs some work. Maybe there could be a repository for potential Mentors to review for work with a potential Mentee? It seems to me having a frustrated submitter is a definite loss to the project and it doesn't need to be either adequate quality or no submission. My thanks for having the patience to help me refine my understanding of your viewpoint. -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On pátek 12. února 2016 10:10 Tomáš Čech wrote:
People are frustrated about the bureaucracy of the process because they see package submission as their goal. But from the distribution POV it is just beginning and all that rules and quality requirements are set to ease package maintenance - which is something that is important for every other user.
No. Definitely not in general. Sure, there are people who just want to get a package in Factory and that's it for them. But please don't just presume everyone is like that. When I submit a package or take maintainership of one, I take it as a commitment to take care of the package in the long term (which is also one of the reasons I don't do so too often). And I'm certainly not the only one. What does the frustration come from is the fact that while I took this commitment and take it seriously, I can't have the specfile formated in a way that would make my work easier. I can't have tags ordered in a way I find logical, I can't have two lines between sections etc. because there is some supersmart script whose author thought otherwise. Is that script's author going to submit updates, is he going to fix bugs or build breakages? Most likely not, in most cases it would be me. But for some reason the specfile must be formated the way _he_ prefers (at the given moment), not the way that would make it easier to read and maintain for me. And this is exactly why I started this thread (not for some "bashing" as some chose to believe). The paragraph quoted above sounds like you simply presume submitters and maintainers are irresponsible and careless people who just want to "throw the package over the fence" and are not going to take care of it anymore. (Which would also explain all this general policy of imposing rules on people's packages even when there are no objective reasons so I'm afraid it's not just you and it's not just a momentary lapse.) But did it occur to you that by this policy of assuming the worst, you may get the exact opposite of what you want to achieve, i.e. drive away the other kind? That while a "throw over the fence" submitter would have no problem with spec cleaner completely reshuffling his specfile, someone who intends to maintain that specfile for years may much more likely be frustrated by having it reformatted against his logic and his preferences? If not, you probably should give it some thought. In the end, it's not going to matter if you convince yourself that all these style rules like "no two empty lines between sections" are necessary to keep "high quality standards". In the end, it's always the submitter/maintainer decission who decides if his motivation to get the package in Factory is strong enough to cope with it or if he would rather keep maintaining the package in his home project. Michal Kubeček -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On Mon, Feb 15, 2016 at 08:44:03AM +0100, Michal Kubecek wrote:
On pátek 12. února 2016 10:10 Tomáš Čech wrote:
People are frustrated about the bureaucracy of the process because they see package submission as their goal. But from the distribution POV it is just beginning and all that rules and quality requirements are set to ease package maintenance - which is something that is important for every other user.
No. Definitely not in general.
Yes, sure, it was meant as a one of the reasons I see. Sorry for making it sound too general.
Sure, there are people who just want to get a package in Factory and that's it for them. But please don't just presume everyone is like that. When I submit a package or take maintainership of one, I take it as a commitment to take care of the package in the long term (which is also one of the reasons I don't do so too often). And I'm certainly not the only one.
OK.
What does the frustration come from is the fact that while I took this commitment and take it seriously, I can't have the specfile formated in a way that would make my work easier. I can't have tags ordered in a way I find logical, I can't have two lines between sections etc. because there is some supersmart script whose author thought otherwise. Is that script's author going to submit updates, is he going to fix bugs or build breakages? Most likely not, in most cases it would be me. But for some reason the specfile must be formated the way _he_ prefers (at the given moment), not the way that would make it easier to read and maintain for me. And this is exactly why I started this thread (not for some "bashing" as some chose to believe).
I thought that we all agreed already that the problem was elsewhere - that changes got accepted without your consent. Why do you blame the script again? Blame people accepting requests.
The paragraph quoted above sounds like you simply presume submitters and maintainers are irresponsible and careless people who just want to "throw the package over the fence" and are not going to take care of it anymore. (Which would also explain all this general policy of imposing rules on people's packages even when there are no objective reasons so I'm afraid it's not just you and it's not just a momentary lapse.)
But did it occur to you that by this policy of assuming the worst, you may get the exact opposite of what you want to achieve, i.e. drive away the other kind? That while a "throw over the fence" submitter would have no problem with spec cleaner completely reshuffling his specfile, someone who intends to maintain that specfile for years may much more likely be frustrated by having it reformatted against his logic and his preferences? If not, you probably should give it some thought.
In the end, it's not going to matter if you convince yourself that all these style rules like "no two empty lines between sections" are necessary to keep "high quality standards". In the end, it's always the submitter/maintainer decission who decides if his motivation to get the package in Factory is strong enough to cope with it or if he would rather keep maintaining the package in his home project.
http://38.media.tumblr.com/e8fcca6de5326bf438c4cb0fbaf4abf7/tumblr_inline_o1... First, it may sounded to general and yet it was meant as one of possible reasons. That change shouldn't have been accepted without your consent. If the situation is like you are describing, Base:System/ncurses/ncurses.spec wouldn't look like it does :) I can't say much about obs-service-format_spec_file. It is there, it worked in many cases well. spec-cleaner did a lot of good already when people used that manually. Now it has some 'minimal' mode which is meant as replacement for original obs-service-format_spec_file and that is about it. 1] noone forces you to use spec-cleaner 2] if you find problem with spec-cleaner in its minimal mode, it would be nice to speak up now and report it as a bug Best regards, S_W
participants (34)
-
Axel Braun
-
Axel Braun
-
Bernhard M. Wiedemann
-
Daniel Morris
-
Dave Plater
-
Dominique Leuenberger / DimStar
-
Frederic Crozat
-
Henne Vogelsang
-
İsmail Dönmez
-
Jan Engelhardt
-
Jimmy Berry
-
Johannes Meixner
-
Klaus Kaempf
-
Ludwig Nussel
-
Marcus Meissner
-
Martin Pluskal
-
Martin Pluskal
-
Michael Ströder
-
Michal Kubecek
-
Olaf Hering
-
Ondřej Súkup
-
PatrickD Garvey
-
Per Jessen
-
Petr Červinka
-
Richard Brown
-
Robert Schweikert
-
Ruediger Meier
-
Sergey Kondakov
-
Stefan Seyfried
-
Stephan Kulow
-
Takashi Iwai
-
Tomáš Chvátal
-
Tomáš Čech
-
Yamaban