Automating the NonResponsiveMaintainers policy
al.dunsmuir at sympatico.ca
Fri Mar 2 17:56:15 UTC 2012
On Friday, March 2, 2012, 12:23:51 PM, Jóhann wrote:
> On 03/02/2012 05:10 PM, Rahul Sundaram wrote:
>> Again, what access do you need and who have you asked for it?
> It's pretty obvious that this is a proposal I made today thus I have
> asked no one for it nor can I since infrastructure has made it clear to
> me when I asked them to fix my user accounting mess that I found myself
> into that they do not handle bugzilla that is Red Hat only territory.
> Secondly first we need to reach conscious about the proposal in general
> then if reached settle on a time frame for the automatic process to
> start taking place as Aleksandar and other have pointed out.
> I'm not sure how you do things in your part of the world but usually
> here on top of the world we dont start building houses without knowing
> first how they should look like...
Perhaps one factor is that what you are trying to build may not be
right for the problem at hand, and a new solution is required for a
different sort of problem? Or perhaps the issue is that we only have
one sort of tool/process, and you are attempting to solve your problem
with that tool when a better solution would be to propose a new tool.
The NonResponsiveMaintainer process is designed to remove all packages
from a maintainer who has gone missing, and is no longer able to take
care of their duties as a Fedora package owner.
It seems to me that many who object to using this large hammer to
solve what some view (correctly or incorrectly) as one minor packaging
issue of many.
Perhaps it would be better to view this as something more akin to the
FTBFS (fails to build from source) process, where regular attempts are
made to build packages from source, and those failures tracked. That
and the follow-up process are more of an "action required by
maintainer" type of process than a "fix it now or else" process.
I would suggest that you might be better to propose a generalized
"FTFPG" (fails to follow packaging guidelines) process, of which one
of the first regular automated checks would be to discover and track
packages that are not enabled for systemd. This would expand over time
to check for other packages which violate other guidelines for which
automated checks can be created. Automation would include creating
bugs, tracking reports, and should have exception lists to support
By the way, that automation would need to be in a package... which
might well be suitable to be your one/only Fedora package. 8^)
More information about the devel