Upstream first? [Was: Re: The future of how to debug pages]

[Richard Ryniker]

On 09/26/2012 10:37 AM, Kamil Paral wrote:
> I personally split maintainers in the distribution into three
> categories.
>
> 1. Packager
>
> 2, Maintainer
>
> 3. Upstream maintainer

Is this an argument for an additional Fedora package class?  At present,
it seems there are two well-defined types: "critical path" and
"everything else".  If gcc is broken, it is a larger issue (it affects a
much greater number of users) than when something is wrong with
gnome-games.  A person who principally uses Fedora to run "Mines" or
"Sudoku" may feel differently.

Some distributions have a "user-contributed" category (often a separate
repository) that formally recognizes packages that are not maintained and
tested, or handled in a more casual way than packages with a defined
support structure.

This looks something like your distinction of "Packager" (one-off effort,
person now interested in something else: user contribution category) and
"Maintainer" (responds to error reports, communicates upstream where
appropriate: distribution category, subject to QA).

This is somewhat like the rpmfusion effort, which separates packages
that do not meet Fedora license requirements into a separate repository.
An rpmuser effort could collect packages that do not meet Fedora QA,
test, or maintenance requirements into a separate repository.

The best (or maybe the worst) of both worlds.  I expect there are many
who agree with:

On Wed, 26 Sep 2012 10:55:40 +0000, Jóhann B. Guðmundsson wrote:
>I prefer few but well maintained packages over many unmaintained
>packages.

and at least as many who agree with:

On Wed, 26 Sep 2012 06:37:35 -0400 (EDT), Kamil Paral wrote:
>Having the package for a year or two is better than not having it at
>all.

I am no stranger to building applications from source.  I have the
training and experience to think I know what I am doing.  When I am
lucky, the application author has made it very clear what resources are
needed, but most often an iterative process is necessary, where I
identify pieces (*-devel packages, libraries) that are needed.  This is
work that can be factored out by a packager, performed once instead of
many times over by users who must start from source, or resolve a series
of "shared library not found" issues when an executable file is copied.

I can imagine other solutions to make it easy to import into Fedora
applications not packaged in rpm files, but nothing that can be
established quickly, and likely not as convenient as a yum repository.  I
want it to be easy for a person to package an application and share his
work with the community of Fedora users.  A moderated yum repository,
which is what Fedora now uses, is a good answer.  Additional repositories
that identify packages by support characteristics might be useful,
especially if they "lower the bar" for casual contributors, but maintain
high standards for most-used and critical pieces.

As usual, the difficult question is not technical (we know how to create
and maintain yum repositories), it is whether more repositories will add
enough value to justify the confusion and work that their establishment
entails.  It has some problems, but the present scheme works (I think
suprisingly) well.  A lot of people share their talent to make it so.