Automating the NonResponsiveMaintainers policy

[Toshio Kuratomi]

On Fri, Mar 02, 2012 at 03:27:24PM +0000, "Jóhann B. Guðmundsson" wrote:
> On 03/02/2012 03:21 PM, Toshio Kuratomi wrote:
> >Process looks like this:
> >
> >* Guidelines updated
> >* Someone notices that the package does not follow the guidelines (Note that
> >   this step does not require that the Guidelines were updated... the
> >   packaging bug could have been missed during review or been introduced
> >   later).
> >* That person files a bug.
> >* If the maintainer chooses to ignore the bug or refuse to fix it then the
> >   matter is escalated.
> >   - In an ideal world, it would probably go to FPC as a "can we change the
> >     guidelines?  I have this special case which I don't think you intended."
> >   - In a less ideal world, or in  the case where the FPC has already made
> >     clear that they did intend it to apply in that case, it would fall on
> >     FESCo to enforce the decision.
> >
> >How would fesco enforce the decision?  That would depend on the arguments
> >being made and the maintainer attitude.  For instance, if the maintainer
> >said, I simply don't have time to fix this, "enforcement" would probably
> >that someone would fix it for them and apply the patch to the spec file.
> >
> >OTOH, if the maintainer decided that they were going to revert any change
> >made to the package to fix the issue, FESCo would have to remove the
> >maintainer from the package and tell them they could not be a committer on
> >that package for a period of time.  They might even remove the packager from
> >the packager group if the maintainer was uncooperative enough.enough.
> 
> Does FPC have any process to measure how many packages are affected
> by a single change made to guidelines?
> 
> If so is it hard to implement the process I mentioned which hopefully
> should keep packages according to guidelines and up to date?
> 
There is no one method for the FPC.  When we pass guidelines we usually
do think about how many packages are affected but there's no general method
that we follow.

However, for most (not all but most) guideline changes, we don't tell people
that there's a hurry to fix things.  They can be fixed as people file bugs
and propose patches.  There are a few changes that are fixes that we feel
are necessary enough that we want to be proactive about fixing when the
guidelines change.  For those we are more strict about figuring out how much
work is involved.

-Toshio
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 198 bytes
Desc: not available
URL: <http://lists.fedoraproject.org/pipermail/devel/attachments/20120302/ed03c53c/attachment.sig>