Rather than
having a large group of people with commit to (nearly) everything for
fixing minor issues, the focus should be on significantly increasing our
levels of co-maintainership. The ideal should be for every package in
the distro to have at least 1 extra co-maintainer, or preferrably 3 or 4.
People with a little domain knowledge for the package who can handle
both the low-hanging fruit the main maintainer misses, with less risk
of making mistakes due to lack of package specific knowledge. Sure it'd
take more people resources than 'provenpackager' solution, and likely
require a big community publicity campaign to kick it off, but long
term it'd be more helpful & safer - particularly for 'infrastruture'
packages (python, perl, etc runtimes & important addon modules) and
security sensitive packages (openssl, gnutls, func, koan, etc).
This makes a lot of theoretical sense but has had mixed results in
practice. I can recall at least two drives to get comaintainers for
packages in the past. This has had some more people sign up for
comaintainership for some packages but it hasn't gotten us near to 100%
coverage. Some of the things it doesn't address:
Trust: If I'm a new contributor who just needed to get X.Y.Z in because
I just started using it on my shiny Fedora Desktop, I may not have any
contact with any other Fedora Contributor. If I don't trust the
provenpackager group with this software, I'm not likely to trust an
unknown packager who asks to be a comaintainer either. In fact, if
there was an over-all group of people who seldom make a mistake and know
packaging and software backward and forward, I'm more likely to entrust
that group with the ability to modify my package than the random packager.
I would hope the process here is to:
(A) email package-owner@xxxxxxxxxxxxxxxxx about the version and/or file
a bugzilla
(B) have a process to handle things if the owner is MIA
Let's take the "I need X.Y.Z" case. If someone can't make a change in
a week --- that in itself may not be a problem -- provenpackager may be
trying to be helpful, but may not have the domain knowledge about the
app -- say version X.Y.Z is not ready for prime time. I would say "I
need version X.Y.Z" now is not a strong enough reason to require an
override by a provenpackager if a maintainer is not immediately
reachable (say, on vacation). If the package maintainer is orphaned by
our definitions, it needs a maintainer. I certaintly would not want
someone updating the package and being suprised by that -- and then
having to revert those changes because they were wrong for the package.
And yes, I'm not likely to trust someone I don't know to co-maintain a
package, but likely are people that we /do/ know in many cases.
provenpackagers seems to imply a whole new need for a level of oversight
-- especially if any provenpackager can make more.
Non-Responsiveness: If the package in question is getting bug reports
from people about the low-hanging packaging bugs but the bug reports are
not being answered even if there are two or more maintainers, there
still needs to be a way for the changes to be applied to the packages.
We also need to have a means of adding comaintainers when the maintainer
does not answer the requests to add a comaintainer.
A non-responsive, forced comaintenance policy would help deal with the
second part of this problem.
Interest in fixing an error that is easily checked for: Contributors
like Michael Schwendt have written and run checks for specific packaging
errors and then opened bugs for them against many packages. When the
bug is not replied to, they have written patches. When those aren't
acknoledged they have applied them where the acls are open. When the
acls are closed the process breaks.
This /seems/ to be why we have the "MIA maintainer" policy. If the
maintainer is unresponsive we have a larger issue and a temporary fix to
the package will still leave the package out of date, and it starts to
be maintained ad-hoc and is likely to grow more out of date.
A non-responsive: forced acl opening policy would work for this.
Interest in a package: If the packager is the only one interested in
doing work on a package, then there won't be a comaintainer. That
doesn't mean that the package won't have common problems so that someone
looking for common problems won't need to get changes applied to it later.
I think it's covered by the above too, isn't it?
Minor issues that don't require an immediate fix /should/ be addressed
with the project (i.e. permissions look wrong in spec file, etc) rather
than being changed in CVS by someone and issuing their own builds. That
seems to be the responsible thing to do.
I assume Fedora release engineering folks already have
something-other-than-provenpackager access for emergency use anyway?
At the moment, the cvsadmin group has the ability to make commits
despite what acls are in place. I don't think we're often called on to
make changes to a package due to non-responsive maintainers, though.
Instead, we have opened the acls and orphaned packages for
non-responsiveness and people who are more interested in the package
have then taken over and done the work.
Yeah, the orphan policy seems to solve most of the problems that I can see.
-Toshio
--
fedora-devel-list mailing list
fedora-devel-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/fedora-devel-list
