libc-maintainers
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Blocking Yury Norov from libc-alpha


From: Carlos O'Donell
Subject: Re: Blocking Yury Norov from libc-alpha
Date: Fri, 21 Oct 2016 13:40:34 -0400
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.2.0

On 10/20/2016 04:10 PM, Joseph Myers wrote:
> On Thu, 20 Oct 2016, Carlos O'Donell wrote:
> 
>> On 10/20/2016 12:57 PM, Paul Eggert wrote:
>>> I'm in favor of blocking, either now or after any future such submissions.
>>  
>> I am against blocking anyone from the developer mailing list, bugzilla,
>> patchwork, or any other form of infrastructure that we use to communicate
>> with the public.
>>
>> The only way you might convince me would be to detail the exact rules under
>> which such a person would be banned, followed by the exact rules required to
> 
> Blocking would be for being persistently disruptive to the development and 
> review process - for example, by misleading the community about the 
> testing done on patches, or seeking review and then just ignoring it, or 
> committing patches lacking consensus - the key thing being that it is 
> persistent and goes far beyond the occasional mistake.  (HJ Lu had commit 
> access to GCC suspended to two weeks last year because of repeatedly 
> committing unapproved patches, with a warning that "Future unapproved 
> commits will lead to longer suspensions.".)

I am still oppose to blocking public access without clear rules e.g.
bugzilla, mailing lists, wiki, etc. These public services should always
remain available for everyone to use, unless such people show a history
of abuse (spammers). Here it is not clear if the person is simply incompetent,
which is not something we should punish, nor is it something we are required
to correct either. Perhaps with enough guidance they might be capable of
working on something else. We should not cut them out of our public services.
I think it would send a bad public message if were to cut people out of the
services they use to report bugs or otherwise interact with the community.

I am _not_ opposed to revoking privileges like those granted by the GNU
maintainers to developers e.g. commit rights.

Thus I do not disagree with revoking commit access, like was done in the case
of H.J. Lu and the gcc project. In fact revoking commit access could be done
with much less well defined rules. I think any GNU maintainer for glibc should
have the authority to revoke commit privileges and to reinstate them.

Yury Norov doesn't have a sourceware.org account (AFAICT) so he doesn't
have commit privileges, and therefore he has no privileges to revoke.

In summary:
- Yury Norov does not current deserve commit privileges.
- Anyone committing patches on behalf of Yury without review could
  be subject to having their commit privileges revoked for an
  unspecified period of time.
- Individual developers can ignore Yury's patches as they wish.

-- 
Cheers,
Carlos.



reply via email to

[Prev in Thread] Current Thread [Next in Thread]