On Thu, 12 Feb 2015 16:49:13 -0500, Stephen Gallagher wrote: > On Thu, 2015-02-12 at 20:18 +0100, Alec Leamas wrote: > > On 12/02/15 19:32, Stephen Gallagher wrote: > > > (Logistical note: please keep all replies to this thread on > > > devel@xxxxxxxxxxxxxxxxxxxxxxx) > > > > > > tl;dr Shall we consider requiring a lesser package review for packages > > > that are not present on Product or Spin install media? > > > > > > Thanks for bringing this up. We really need to do something about this, > > and the proposal is likely to get things rolling. > > > > This is really about two things, right? A "lighter review" and a general > > bundling exception for packages not in the core (?) > > > > Ultimately, it's about one thing: Help get more software into Fedora > without scaring people away. What is the background for this? Who has been scared away? Is this about a few vocal people, who boycott everything related to packaging guidelines and update guidelines? We've had a few incidents like that *many* years ago when somebody wanted to put pressure on the Fedora Project because things are not done in the same way as preferred by such people. IMO: What scares away people primarly is the actual maintenance period during the life-cycle of a Fedora. Somebody, who is afraid of making mistakes, whether small or large, will likely not join at all. Somebody, who takes the requirements too lightly, will run into trouble sooner than later. A good example is the first lib upgrade that bumps the soname and has been pushed to stable without even testing installation, because of treating the repo like a dumping ground. The sudden requirements to learn about what needs to be done to prevent this (ABI checks, buildroot overrides, rebuilds) make some people think twice whether they want to maintain the packages at Fedora. Plus, in order to rebuild dependencies, they would need to co-maintain the dependencies (for commit access) or actively communicate with the maintainers of the deps. For some this is too much effort to be worthwhile. The review process is only a minor hurdle. Especially, if there are two people with real interest in a package. It's too easy to approve a package without even adhering to all guidelines. It's even easier to reintroduce packaging mistakes _after_ approval. Mind you, we don't re-review packages regularly unless the maintainers do their update/upgrade jobs painstakingly. But what to do if package bugs are found in a released package? Then the fun starts. Especially for those who shall "maintain" the package. The quality of some submitted new packages during review is lousy. Some don't build (not even with plain rpmbuild). Some don't even work. Some introduce the most basic and harmful mistakes, just because the submitter does not even show interest in skimming over the review guidelines or giving the fedora-review tool a try. Some spec files are full of dist-independent conditionals, which are out-of-date and don't add any value. => For such packagers, there will be a lot to learn, and eventually they will give up, if packages cause problems when they are exposed to more users than when offering a source tarball to download somewhere. We've all started somewhere with packaging. We do need to start *somewhere* during times when the packaging related Wiki pages seem to be crammed with guidelines. The review queue is the first place where you get a chance to find a helping hand that offers a bit of guidance. It could even be a co-worker to team up for the reviewing. The second pair of eyes that may make the difference! But if there's nobody else than a single submitter, a bit of activity from that submitter is needed. The same amount of activity that will be needed also later during the actual life-cycle of the package in the Fedora dist. Simply waiting in the review queue for magic to happen won't work. Those, who wait months without even trying to follow the "How to get sponsored ..." guides, bear a huge risk of turning AWOL suddenly. And once a potential sponsor shows up in the review ticket, not even then the process is speed up with a bit of activity to jump over this small initial hurdle. There are enough review tickets where a simple response from a submitters takes many weeks or months. > The ultimate goal being that Fedora becomes > (remains!) a leader in the distribution of open source software. To reach that goal, something else would need to change instead: Declare official project-wide goals for the Fedora Packaging project with regard to what maintenance level the package users can expect, especially for the "Core Packages" you refer to. Or else you run into the dangers of the "Quantity vs. Quality" pitfall, and problems when propagating a package from the dumping ground "ring" into the core. -- devel mailing list devel@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
