[Previous Thread]  

[gnu-libc-maintainers] Re: Emacs and glibc malloc API change


  • Subject: Re: Emacs and glibc malloc API change
  • From:    Richard Stallman <rms <at> gnu.org>
  • To:      Paul Eggert <eggert <at> cs.ucla.edu>
  • Cc:      libc-maintainers <at> gnu.org, rms <at> gnu.org, glibc-sc <at> gnu.org
  • Date:    2016-01-22 03:23:51
[[[ To any NSA and FBI agents reading my email: please consider    ]]]
[[[ whether defending the US Constitution against all enemies,     ]]]
[[[ foreign or domestic, requires you to follow Snowden's example. ]]]

  > So far as we know, recent Emacs should work even after the proposed glibc change 
  > is installed. For example, if you build Emacs 24.5 on a system with the new 
  > glibc, it should still work.

How is that?

-- 
Dr Richard Stallman
President, Free Software Foundation (gnu.org, fsf.org)
Internet Hall-of-Famer (internethalloffame.org)
Skype: No way! See stallman.org/skype.html.



(Read the complete message)

[gnu-libc-maintainers] Blocking Yury Norov from libc-alpha


  • Subject: Blocking Yury Norov from libc-alpha
  • From:    Joseph Myers <joseph <at> codesourcery.com>
  • To:      <libc-maintainers <at> gnu.org>
  • Cc:      None
  • Date:    2016-10-20 13:21:41
Yury Norov is persistently wasting glibc developers' time by posting 
low-quality patches that ignore feedback on previous versions and with 
misleading claims of testing that do not actually mean testing with the 
glibc testsuite with no failures caused by the patch.  The most recent 
example was , 
with a claim of testing when as Andreas noted the patch doesn't even 
build, but there have been plenty of previous examples.

I propose that either now, or if there are any future such submissions 
with misleading claims of testing or quietly ignoring previous feedback, 
we ask overseers to block Yury Norov from posting to libc-alpha for a 
month, with increased length of block if the problems continue after that.  
(Also, personally, I don't intend to do any detailed review of any of his 
patches until after glibc 2.26 is out at least.)

-- 
Joseph S. Myers
joseph@codesourcery.com


(Read the complete message)

[gnu-libc-maintainers] Re: Blocking Yury Norov from libc-alpha


  • Subject: Re: Blocking Yury Norov from libc-alpha
  • From:    Paul Eggert <eggert <at> cs.ucla.edu>
  • To:      Joseph Myers <joseph <at> codesourcery.com>, libc-maintainers <at> gnu.org
  • Cc:      None
  • Date:    2016-10-20 16:57:49
I'm in favor of blocking, either now or after any future such submissions.


(Read the complete message)

[gnu-libc-maintainers] Re: Blocking Yury Norov from libc-alpha


  • Subject: Re: Blocking Yury Norov from libc-alpha
  • From:    Carlos O'Donell <carlos <at> redhat.com>
  • To:      Paul Eggert <eggert <at> cs.ucla.edu>, Joseph Myers <joseph <at> codesourcery.com>, libc-maintainers <at> gnu.org
  • Cc:      None
  • Date:    2016-10-20 18:47:38
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
be removed from the ban. When such rules are written and come into effect
should be clear, and transgressions before the public posting of the rules
must be ignored (not count towards the rules).

In the meantime I recommend individual developers should setup filters for
people they do not wish to review posts from and send those emails to the
trash.

I have reached out privately to the person whom I believe is the manager
of this individual at Cavium to discuss the issue.

-- 
Cheers,
Carlos.


(Read the complete message)

[gnu-libc-maintainers] Re: Blocking Yury Norov from libc-alpha


  • Subject: Re: Blocking Yury Norov from libc-alpha
  • From:    Joseph Myers <joseph <at> codesourcery.com>
  • To:      Carlos O'Donell <carlos <at> redhat.com>
  • Cc:      Paul Eggert <eggert <at> cs.ucla.edu>, <libc-maintainers <at> gnu.org>
  • Date:    2016-10-20 20:10:54
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.".)

-- 
Joseph S. Myers
joseph@codesourcery.com


(Read the complete message)

[gnu-libc-maintainers] Re: Blocking Yury Norov from libc-alpha


  • Subject: Re: Blocking Yury Norov from libc-alpha
  • From:    Carlos O'Donell <carlos <at> redhat.com>
  • To:      Joseph Myers <joseph <at> codesourcery.com>
  • Cc:      Paul Eggert <eggert <at> cs.ucla.edu>, libc-maintainers <at> gnu.org
  • Date:    2016-10-21 17:40:34
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.

(Read the complete message)

[gnu-libc-maintainers] Re: Blocking Yury Norov from libc-alpha


  • Subject: Re: Blocking Yury Norov from libc-alpha
  • From:    Joseph Myers <joseph <at> codesourcery.com>
  • To:      Carlos O'Donell <carlos <at> redhat.com>
  • Cc:      Paul Eggert <eggert <at> cs.ucla.edu>, <libc-maintainers <at> gnu.org>
  • Date:    2016-10-21 17:45:25
On Fri, 21 Oct 2016, Carlos O'Donell wrote:

> - Anyone committing patches on behalf of Yury without review could
>   be subject to having their commit privileges revoked for an
>   unspecified period of time.

Right now we must assume that anyone committing his patches must test them 
as well first, since we can't trust any claims he makes about testing.

-- 
Joseph S. Myers
joseph@codesourcery.com


(Read the complete message)

[gnu-libc-maintainers] Re: Blocking Yury Norov from libc-alpha


  • Subject: Re: Blocking Yury Norov from libc-alpha
  • From:    Carlos O'Donell <carlos <at> redhat.com>
  • To:      Joseph Myers <joseph <at> codesourcery.com>
  • Cc:      Paul Eggert <eggert <at> cs.ucla.edu>, libc-maintainers <at> gnu.org
  • Date:    2016-10-21 18:02:25
On 10/21/2016 01:45 PM, Joseph Myers wrote:
> On Fri, 21 Oct 2016, Carlos O'Donell wrote:
> 
>> - Anyone committing patches on behalf of Yury without review could
>>   be subject to having their commit privileges revoked for an
>>   unspecified period of time.
> 
> Right now we must assume that anyone committing his patches must test them 
> as well first, since we can't trust any claims he makes about testing.

Agreed.

I think we need to do two things:

(a) Discuss directly with Yury that his actions are not acceptable.

(b) Discuss with Yury's management at Cavium that his actions are not acceptable.

I have already started (b).

Would you like me to do (a) also?

-- 
Cheers,
Carlos.


(Read the complete message)

[gnu-libc-maintainers] Re: Blocking Yury Norov from libc-alpha


  • Subject: Re: Blocking Yury Norov from libc-alpha
  • From:    Joseph Myers <joseph <at> codesourcery.com>
  • To:      Carlos O'Donell <carlos <at> redhat.com>
  • Cc:      Paul Eggert <eggert <at> cs.ucla.edu>, <libc-maintainers <at> gnu.org>
  • Date:    2016-10-21 18:05:42
On Fri, 21 Oct 2016, Carlos O'Donell wrote:

> I think we need to do two things:
> 
> (a) Discuss directly with Yury that his actions are not acceptable.
> 
> (b) Discuss with Yury's management at Cavium that his actions are not acceptable.
> 
> I have already started (b).
> 
> Would you like me to do (a) also?

Yes, since I've already raised the same issues with him repeatedly in 
response to multiple patches with similar issues, with little apparent 
effect.

-- 
Joseph S. Myers
joseph@codesourcery.com


(Read the complete message)

[gnu-libc-maintainers] Re: Blocking Yury Norov from libc-alpha


  • Subject: Re: Blocking Yury Norov from libc-alpha
  • From:    Carlos O'Donell <carlos <at> redhat.com>
  • To:      Joseph Myers <joseph <at> codesourcery.com>
  • Cc:      Paul Eggert <eggert <at> cs.ucla.edu>, libc-maintainers <at> gnu.org
  • Date:    2016-10-21 18:37:55
On 10/21/2016 02:05 PM, Joseph Myers wrote:
> On Fri, 21 Oct 2016, Carlos O'Donell wrote:
> 
>> I think we need to do two things:
>>
>> (a) Discuss directly with Yury that his actions are not acceptable.
>>
>> (b) Discuss with Yury's management at Cavium that his actions are not acceptable.
>>
>> I have already started (b).
>>
>> Would you like me to do (a) also?
> 
> Yes, since I've already raised the same issues with him repeatedly in 
> response to multiple patches with similar issues, with little apparent 
> effect.
 
Done.

I have sent Yury a rather lengthy and positive email about fixing two
key problem behaviours:
~~~
- Please review all feedback you receive about your patches, and incorporate
  that feedback into your next version, and where you haven't call it out.
- Please make sure you thoroughly test your patches using the glibc regression
  testsuite and as documented in the contribution checklist, explain or fix
  any regressions, explain for which targets the testsuite was run, and
  add any new tests required to cover new features.
~~~

My email was very positive and aimed to coach Yury in the right direction.

I can only hope it has the intended effect.

I will update the list on (a) and (b) as I have information.
(Read the complete message)

[gnu-libc-maintainers] Re: Blocking Yury Norov from libc-alpha


  • Subject: Re: Blocking Yury Norov from libc-alpha
  • From:    Paul Eggert <eggert <at> cs.ucla.edu>
  • To:      Carlos O'Donell <carlos <at> redhat.com>, Joseph Myers <joseph <at> codesourcery.com>
  • Cc:      libc-maintainers <at> gnu.org
  • Date:    2016-10-21 19:08:06
On 10/21/2016 10:40 AM, Carlos O'Donell wrote:
> I am still oppose to blocking public access without clear rules

It is good to have clear rules for blocking. However, it's unrealistic 
to expect blocks to always follow clear rules that are set in advance, 
because misbehavior cannot always be anticipated. So any rules that we 
establish should have an escape clause that says that the rules do not 
constrain us from blocking merely because a particular misbehavior is 
not specifically listed.



(Read the complete message)

[gnu-libc-maintainers] Re: Blocking Yury Norov from libc-alpha


  • Subject: Re: Blocking Yury Norov from libc-alpha
  • From:    Carlos O'Donell <carlos <at> redhat.com>
  • To:      Paul Eggert <eggert <at> cs.ucla.edu>, Joseph Myers <joseph <at> codesourcery.com>
  • Cc:      libc-maintainers <at> gnu.org
  • Date:    2016-10-22 02:08:37
On 10/21/2016 03:08 PM, Paul Eggert wrote:
> On 10/21/2016 10:40 AM, Carlos O'Donell wrote:
>> I am still oppose to blocking public access without clear rules
> 
> It is good to have clear rules for blocking. However, it's
> unrealistic to expect blocks to always follow clear rules that are
> set in advance, because misbehavior cannot always be anticipated. So
> any rules that we establish should have an escape clause that says
> that the rules do not constrain us from blocking merely because a
> particular misbehavior is not specifically listed.
 
I disagree.

New kinds of misbehaviour simply mean we need to adjust the public
set of rules for blocking public access.

The first offender generally gets off with a warning, and if they
offend again you block their access.

This is the only fair and equitable way to treat offenders when the
rules for offending are not clear.

Keep in mind I'm only talking about public access. Access that we
work hard to make sure that everyone in the public can use to 
interact with the community.

I am also of the opinion that you really need to show gross negligence
or abusive behaviour to be banned from public services e.g. harassment,
discrimination, hate speech etc.

I think that simply being "incompetent" means developers will delete
your emails, nobody will review your patches, and you'll never get
commit privileges. Eventually you will just go away, or someone will
coach you and you'll get better.

(Read the complete message)

[gnu-libc-maintainers] Re: Blocking Yury Norov from libc-alpha


  • Subject: Re: Blocking Yury Norov from libc-alpha
  • From:    Paul Eggert <eggert <at> cs.ucla.edu>
  • To:      Carlos O'Donell <carlos <at> redhat.com>, Joseph Myers <joseph <at> codesourcery.com>
  • Cc:      libc-maintainers <at> gnu.org
  • Date:    2016-10-22 06:01:28
Carlos O'Donell wrote:
> New kinds of misbehaviour simply mean we need to adjust the public
> set of rules for blocking public access.

It's not that simple in practice. A determined attacker can easily evade the 
formal rules of a public forum using techniques like sockpuppetry. And glibc has 
security-related responsibilities that go beyond the usual politeness rules for 
text chatting.

Yes there are gray areas, and when in doubt I prefer a more-open forum. But 
serious and novel misbehavior can require immediate action even if the rule 
isn't written down yet.


(Read the complete message)

[gnu-libc-maintainers] Re: Blocking Yury Norov from libc-alpha


  • Subject: Re: Blocking Yury Norov from libc-alpha
  • From:    Carlos O'Donell <carlos <at> redhat.com>
  • To:      Paul Eggert <eggert <at> cs.ucla.edu>, Joseph Myers <joseph <at> codesourcery.com>
  • Cc:      libc-maintainers <at> gnu.org
  • Date:    2016-10-24 00:44:38
On 10/22/2016 02:01 AM, Paul Eggert wrote:
> Carlos O'Donell wrote:
>> New kinds of misbehaviour simply mean we need to adjust the public 
>> set of rules for blocking public access.
> 
> It's not that simple in practice. A determined attacker can easily
> evade the formal rules of a public forum using techniques like
> sockpuppetry. And glibc has security-related responsibilities that go
> beyond the usual politeness rules for text chatting.
> 
> Yes there are gray areas, and when in doubt I prefer a more-open
> forum. But serious and novel misbehavior can require immediate action
> even if the rule isn't written down yet.

You raise a good point.

We could have an escape hatch: "In the interest of project security and
safety the GNU maintainers (project stewards) have the ability to ban
anyone from any part of project infrastructure."

And then the _after_ the incident we could discuss if this was a good
enough use of the escape hatch clause ;-)

-- 
Cheers,
Carlos.


(Read the complete message)
[Previous Thread]