Sponsor shortage

Nick Coghlan ncoghlan at gmail.com
Wed Jul 15 08:43:31 UTC 2015

On 13 July 2015 at 03:54, Stephen John Smoogen <smooge at gmail.com> wrote:
> On 11 July 2015 at 16:09, Michael Schwendt <mschwendt at gmail.com> wrote:
>> On Sat, 11 Jul 2015 11:45:13 -0600, Stephen John Smoogen wrote:
>>> and I will probably also find that those
>>> packages have 'accepted' differentiation because no one wants to get
>>> into a political fight over XYZ package ever again.
>> And how would you like to fix that? By making packaging guidelines
>> more lax? By removing the review process, so _every_ packager may
>> decide whether not to adhere to the guidelines?
> Wow do you have any more words you want to stuff in my mouth that I
> supposedly want? Thank you for reminding me why I don't want anything
> to do with packaging anymore.

Hopefully I can change your mind on that front, as the package review
process is something I'm deeply interested in helping to improve. I
consider enabling more effective collaboration between upstream
communities and the Fedora community to be an essential part of the
role of the Environments & Stacks Working Group, and the package
review process is a core element of that.

This *doesn't* mean relaxing any of the core packaging policy
requirements - those exist for a reason. Rather, it means providing a
smoother onramp for the packaging process, where potential packagers
are able to make incremental progress, largely facilitated by
automated systems, such that by the time potential packagers are
seeking sponsors for inclusion in the main Fedora repositories,
they'll already have a much clearer idea of what a "good" package
looks like, and how the packaging guidelines serve to protect the
interests of Fedora's end users by imposing additional requirements on
Fedora's contributors.

A few of the key barriers to entry that currently exist:

1. The package review process is currently a manual mixture of command
line tools, wiki pages, Bugzilla issues, and more. It's incredibly
hard for newcomers to figure out where to get started, how to move
things along to the next stage, how to run automated scans on their
own packages, etc. Google doesn't help unless you already know which
documentation is authoritative and which is a historical relic.

2. Humans don't like other humans being pedantic, but we expect it
from computers. We'll instinctively argue with other people to try to
get out of doing work if we think their requirements are unreasonable,
but we know computers can't be reasoned with. As a result, if an
automated scan is complaining, we're more likely to just fix the
problem to make it be quiet than we are if another person were to
point out the same problem (especially if making the automated scan
happy is a prerequisite for getting attention from a human).

3. Package review is currently an all or nothing process. Even with
COPR, a "staging package" that is in principle acceptable for
inclusion in the main Fedora process but doesn't yet meet package
policy guidelines isn't any easier to discover or install than a
project that hasn't been packaged at all. This last problem then makes
it difficult for groups of people to effectively *collaborate* on
getting a package to a point where it's not only acceptable for
inclusion in the main distribution, but also has multiple potential
maintainers rather than relying specifically on the one package
maintainer who pushed it through the review process.

I think the Fresque developers have the right idea in wanting to
create a dedicated Fedora Review Server. Moving package reviews out of
Bugzilla provides an opportunity to create a more integrated review
experience that can potentially bring in automated server side
execution of tools like rpmlint and rpmgrill against COPR repos before
human reviewers even need to get involved at all.

That way potential packagers wouldn't be left in limbo waiting for
potential sponsors to provide feedback, and potential sponsors would
be able to focus their attention on potential packagers that have
already demonstrated their willingness to meet at least the essential
standards set by the automated scans.


Nick Coghlan   |   ncoghlan at gmail.com   |   Brisbane, Australia

More information about the devel mailing list