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
effect.
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.
Marcela
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.
Vit
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 ).
JBG
--
devel mailing list
devel@xxxxxxxxxxxxxxxxxxxxxxx
https://admin.fedoraproject.org/mailman/listinfo/devel
