Automating the NonResponsiveMaintainers policy

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

On 03/02/2012 11:16 AM, Vít Ondruch wrote:
>>
>
> Actually I support such initiative. We have also filled a few bugs 
> against Ruby components which needs some love due to Ruby update and 
> it happens that we have no response. If there would be tool that 
> reports "yes, the maintainer was active in some Fedora project 3 days 
> ago", then it would be meaningful to nag him again, because the BZ was 
> probably somewhere lost/forgotten, but if you see that the maintainer 
> have been non-active for last 6 months, you know that you should 
> probably start "NonResponsiveMaintainer" process. 

Yeah I suspected that I was not alone in this regard since I am just 
dealing with ca 5% of packages in the distribution.

This could be beneficial in various project processes although I'm not 
familiar with how FPC ensures that FPG is being followed and is updated 
each time changes are made to the guidelines but let's assume they are 
using this workflow.

FPC makes changes to FPG -->

They then generate a list of packages affected by the change to FPG -->

They then file a report against all the component on the list were they 
state that the relevant package is affected by the change made by FPG 
and the spec file should be updated accordingly and maintainers should 
comment if they would they require the assistant of proven packager do 
to those changes for them and those changes should preferable be 
completed by this $DATE -->

A week ( or some other time ) later the component gets hit by the 
automatic non responsive policy which would allow proven packager only 
have to walk through components that have not been flagged non 
responsive and check if maintainers have asked for their assistant thus 
focusing their available time and energy only on responsive and actively 
maintainer.

JBG