Automating the NonResponsiveMaintainers policy

Aleksandar Kurtakov akurtako at
Fri Mar 2 15:53:56 UTC 2012

----- Original Message -----
> From: "Reindl Harald" <h.reindl at>
> To: "Development discussions related to Fedora" <devel at>
> Sent: Friday, March 2, 2012 2:09:00 PM
> Subject: Re: Automating the NonResponsiveMaintainers policy
> Am 02.03.2012 13:00, schrieb Matthias Runge:
> > On 02/03/12 12:52, Aleksandar Kurtakov wrote:
> >>
> >> If a maintainer doesn't respond to a bug repord with the status
> >> new in a week - give commit rights to the reporter in pkgdb
> >> so he/she can fix it himself.
> > I kind a' like this proposal. You're speaking of current package
> > maintainers getting commit rights automatically after a timespan,
> > right?
> > 
> > What about bug reporter being unable to fix the mentioned bug?
> > And does the bug-reporter get his right revoked after a time
> > (automatically?)
> you are missing the differences between "ignored", "assigend" and
> "fixed"
> where did you see a line that a bug must be fixed in whatever time?
> you did not because it is not there
> the point is that if a reporter takes time to file a bugreport
> he can expect any response - this response may be change status
> from "new" to "assigend" even without any comment
> if you now saying that a maintainer has not the time to do this
> simple step realize that the reporter in the future has no time
> to report any bugs for nothing and that if the "assigned" is
> tto much work the maintainer has really other problems and
> appearently no time to maintain the package any longer

So are you saying that every one that finds a bug will obey and report that bug?
Once someone manages to enforce this he/she can try to give orders to others about their workflow.
Let's agree on that - there are different people with different workflows and etc.
If the packager has no rights to say how/when/what will be tested and used I don't see a reason why the reported should be able to give this orders to the packager.
It's evolutionary - this way the good packages with good maintainers will survive by people either moving to such packages or becoming maintainers.


> --
> devel mailing list
> devel at

More information about the devel mailing list