Automating the NonResponsiveMaintainers policy

["Jóhann B. Guðmundsson"]

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?

JBG