How to become a packager (was: Re: [Proposal] Ring-based Packaging Policies)
mschwendt at gmail.com
Fri Feb 13 15:35:59 UTC 2015
On Fri, 13 Feb 2015 14:00:07 +0000, Ian Malone wrote:
> 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.
That isn't the only way to become a packager. And it hasn't changed
for a very long time:
Submitting a new package is just _one_ of multiple ways to find a sponsor,
since it is an opportunity to demonstrate that you know packaging.
> 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.
Again: we all need to start somewhere. There are enough people, who build
software from source tarballs or who create private updates of existing
src.rpms and who open bugzilla tickets requesting version upgrades.
*That* could lead to becoming a co-maintainer. A bit of interest provided.
Nowadays it is so much easier to contribute. You could still submit patch
files via bugzilla, but it is to much more convenient to get direct commit
access to the package and co-maintain it with other people. Provided that
you are not pissed off by Fedora's guidelines or anything else related to
> So, is that implicit test (can you package according to the
> guidelines?) going to become easier?
Not every packager in the packager group can package "according to the
guidelines" either. Don't think that all of them are 100% perfect
packagers, who know all of the guidelines and who never do packaging
> 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 interesting would be whether packagers in an "outer ring" would
be willing to improve their packages once mistakes are found? Even if
that made it necessary to think about solutions and spend more time on
Random fire'n'forget builds in a public Fedora repo would be something
that would scare me.
More information about the devel