Automating the NonResponsiveMaintainers policy

Vít Ondruch vondruch at redhat.com
Fri Mar 2 12:54:52 UTC 2012


Dne 2.3.2012 13:47, Aleksandar Kurtakov napsal(a):
>
> ----- Original Message -----
>> From: "Vít Ondruch"<vondruch at redhat.com>
>> To: devel at lists.fedoraproject.org
>> Sent: Friday, March 2, 2012 2:37:53 PM
>> Subject: Re: Automating the NonResponsiveMaintainers policy
>>
>> Dne 2.3.2012 13:19, Aleksandar Kurtakov napsal(a):
>>> ----- Original Message -----
>>>> From: "Matthias Runge"<mrunge at matthias-runge.de>
>>>> To: "Development discussions related to
>>>> Fedora"<devel at lists.fedoraproject.org>
>>>> Sent: Friday, March 2, 2012 2:05:07 PM
>>>> Subject: Re: Automating the NonResponsiveMaintainers policy
>>>>
>>>> On 02/03/12 12:53, Marcela Mašláňová wrote:
>>>>> I'm afraid we end up with more bureaucracy than we have now. I'm
>>>>> not
>>>>> against tracking some statistics, so you can look up who is
>>>>> active
>>>>> and
>>>>> probably will answer in few days, but I'd rather not use it for
>>>>> the
>>>>> unresponsive process.
>>>>>
>>>>> Marcela
>>>> I'm thinking about how to support Jóhann with a proven packager
>>>> (or
>>>> two). Since it seems not wanted by Fesco, to give him the
>>>> corresponding
>>>> rights to commit his changes directly? This final target (all
>>>> services
>>>> are supported by systemd) seems to be clear to everyone.
>>> This is a noble goal and I wish this finishes sooner. But attacking
>>> packagers by threatening is not gaining any support for the
>>> efforts.
>>> Most of us gained their commit rights by talking to the respective
>>> maintainers getting them approve us as comaintainers, it's a
>>> lengthy process I agree. But it's not that hard to ask for
>>> co-maintainership so one gets commit rights. I wonder whether
>>> someone refused to give commit rights for someone wanting to add
>>> systemd support in his package?
>>> People should finally understand that by threatening and
>>> over-bureaucracy nothing will improve. When someone wants to see a
>>> feature done he should get his hands dirty in all aspects - do the
>>> changes, find the maintainer, talk to them, get commit rights or
>>> get them to push changes, do builds if needed. We ship a
>>> distribution so if someone do something but doesn't integrate with
>>> the rest we have nothing. And integration is collaboration it's
>>> not something one can enforce with bureacracy.
>> Alex,
>>
>> Don't be so touchy please. The truth is somewhere in between. There
>> are
>> maintainers who do not respond for whatever reason and there are
>> others
>> who are solving reported issue in a minute. I don't believe that it
>> was
>> meant to threaten anybody. You read the "Automating the
>> NonResponsiveMaintainers policy" as "remove the original maintainer"
>> or
>> "punish him" but it might be very well read in opposite way, exactly
>> as
>> you proposed. There is no need for drama.
> This is not the first discussion on the topic I'm involved into. There are such maintainers I agree. But what is the problem with the current NonResponsiveMaintainers policy? How would you automate this? And asking to do it in a week?
> Every packager deserves at least the few steps described into the  current procedure.

The current procedure is a pain ... and it happens that after month of 
waiting, maintainer suddenly appear and (s)he is really angry "how dare 
you can call me unresponsive when I am just busy with other 
projects/live". This is not good from opposite side. And that happened 
to me. So current procedure is at least pretty vague and there is no 
support in kind of some infrastructure. You have to check "hmm, is it 
already week since I last pinged somebody on BZ or ML? Hm, not yet. Ok, 
I'll wait".


Vit




More information about the devel mailing list