Re: glibc development and conflicts of interest

[Torvald Riegel <triegel at redhat dot com>]

On Thu, 2015-07-23 at 20:40 -0400, Carlos O'Donell wrote:
> On 07/22/2015 05:56 PM, Joseph Myers wrote:
> > I have seen some comments in some recent glibc discussions that could be 
> > interpreted as people giving preference to their colleagues rather than to 
> > the public, collaborative discussion in the glibc community as a whole.
> > 
> > I think it's important to avoid that appearance in glibc development.  (I 
> > am not asserting that in fact such preference has been given, simply that 
> > the appearance of it should also be avoided.)  Where there could be 
> > conflicts of interest, I think the following should be considered good 
> > practice:
> > 
> > Err on the side of being *more* critical of your co-workers because they 
> > are your co-workers, not less - hold them up to higher standards in public 
> > patch review than unconnected patch contributors.  Err on the side of 
> > deferring *more* to the community on patches where such a conflict of 
> > interest could arise, not less - when you have good arguments, they will 
> > still reach consensus in the community.  If other contributors to the 
> > discussion are making irrelevant comments (e.g. suggestions that are not 
> > application on your architecture), stick to objective facts in response, 
> > and maybe let other people read the consensus to see that your comments 
> > are relevant where the other ones are not.
> > 
> > If you have been involved in internal discussion or design of a patch, 
> > take extra care to ensure that review is based only on what is public and 
> > that sufficient rationale for the patch is included in the submission, 
> > including answers to any questions raised internally that might also be of 
> > relevance to the public discussion; avoid citing internal discussion, or a 
> > contributor's connection to you, as justification for a patch.  Take extra 
> > care to ensure that your patch review in such cases is in accord with 
> > community consensus.
> 
> I agree completely. I would also suggest that if you see such behaviour that
> you call it out immediately.

Agreed.

> It serves the community to have such behaviour
> pointed out immediately such that we can discuss specific examples of it
> rather than abstract principles. In many cases I expect the authors of such
> conflicts of interest had not considered how it appeared to the public.

Agreed.  And I suppose that often, pointing it out will also allow the
involved people to show that it's not an actual conflict of interest but
is harmless and more due to limited time etc.

For example, assume one would consider it as a bias if I'm saying that
I've talked with Siddhesh about the synchronization in his TLS patch and
therefore think it's sound.  I do see why it could be interpreted as a
conflict of interest.  However, in current practice, we're getting very
little review for concurrency bits -- often we're even get very little
discussion about it.  Also, we don't yet have a *shared* way to talk
about concurrency.  At the same time, the patch is considered a blocker
for the release, IIRC (and we have consensus for that, I believe).
Thus, given limited resources and time, it's best if I talk it through
with Siddhesh.  Publishing the chat log of that won't be helpful.
In contrast, we're trying to change this situation for the community as
a whole.  Siddhesh and I have been working on the documentation of why
we think the concurrency bits in his patch are sound, and I think the
most recent text he produces is good.  I will give a tutorial and a talk
about concurrency (in general and in glibc, respectively) at Cauldron.