[Proposal] Ring-based Packaging Policies
ibmalone at gmail.com
Fri Feb 13 14:00:07 UTC 2015
On 13 February 2015 at 13:06, Michael Schwendt <mschwendt at gmail.com> wrote:
> 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 at lists.fedoraproject.org)
>> > >
>> > > 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
> 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.
Actually, a question I have about this is how it will impact people
trying to become maintainers. When I last checked (it may have
changed) the only way to do that was to create a new package.
Typically that will be a package you're interested in getting into
Fedora which may be non-trivial and benefit from someone more
experienced doing it, or it might be somewhat arbitrarily chosen if
you want to help maintain an existing package.
So, is that implicit test (can you package according to the
guidelines?) going to become easier? Is it necessary to then have a
second level of approval before you can work on core packages if you
started on a non-core package? Should becoming a maintainer become a
bit more decoupled from the process of actually preparing a package?
This doesn't really affect the proposal at hand, but it would be useful to know.
More information about the devel