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-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org