Automating the NonResponsiveMaintainers policy

[Al Dunsmuir]

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
known/approved exceptions.

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^)