Automating the NonResponsiveMaintainers policy
vondruch at redhat.com
Fri Mar 2 11:16:35 UTC 2012
Dne 2.3.2012 12:02, Marcela Mašláňová napsal(a):
> On 03/02/2012 11:20 AM, "Jóhann B. Guðmundsson" wrote:
>> I am a feature owner for a feature that involves components in the
>> hundreds and is heavily depended on maintainers responsiveness.
>> For me to start enacting the non responsive maintainers policy is a
>> tremendous work thus I'm wondering if there is something preventing us
>> from automating the non responsive maintainer policy?
>> An bugzilla script that acts something like if maintainer has not
>> responded to a bug report with the status new in a week ( or some other
>> time ) the non responsive maintainers policy automatically starts taking
> Ok, so you'll automatically start non-responsive maintainer process,
> because maintainer didn't work on a one bug. But he might be working on
> different component for whole month. He might be working on a new
> upstream release and not paying attention to low priority bugzillas.
> You should take more parameters than one bug to kick someone from Fedora.
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
>> To get out of that automatic non responsive process the maintainer would
>> have to comment on the bug and set it's status assigned ( or something
>> similar ).
More information about the devel