This is the mail archive of the libc-alpha@sourceware.org mailing list for the glibc project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Concensus-based community-driven development.


On Wed, Apr 4, 2012 at 1:56 PM, Andreas Jaeger <aj@suse.com> wrote:
> On 04/04/2012 08:42 PM, Carlos O'Donell wrote:
>>
>> I've adjusted the wiki to indicate that
>> prime mover is consensus. Patches should
>> be posted to libc-alpha, reviewed, discussed,
>> and then committed.
>>
>> The machine maintainers are people who have
>> assumed a role of leadership when it comes
>> to the code for the machine they are maintaining.
>>
>>
>> http://sourceware.org/glibc/wiki/MAINTAINERS#Maintainers_for_libc_and_ports_add-on
>>
>> Comments?
>
>
> Thanks a lot for starting this discussion. I have - like Pasky in his email
> - a couple of questions:
> * What patch will be committed without review? E.g. should a machine
> maintainer commit directly? Should we have - like gcc has - a role that
> states that obvious patches are fine?

As the Power arch maintainer I still prefer to have someone else
review patches as well.

> * What does consensus mean? If somebody sends a patch, I review it and ack
> it and nobody complains in say 24 hours - did we reach consensus? Or can it
> get committed directly? Whose positive review counts?

The way it seems to be working is that after a review a committer
proposes that they will commit in 24 number of hours if there are no
further comments.  I believe Roland had expressed some concerns about
having these time-limits fall on the weekends.  Also, I think that
committers should withhold committing if they're lacking the ack of an
obviously interested party.

> * There are several patches on the mailing list where people ask for review
> and nothing happens - including the x86-64 memcpy patch that I send. What
> happens if nobody reviews a patch?

In the case of memcpy (and any other platform specific string routine)
I believe that the people that should be reviewing are arch
maintainers as well as the people who've previously submitted
fixes/improvements.  I know that for Power we keep a pretty close eye
on performance in the string routines and we don't want that to
regress.

We also have less developers playing in the code, so I imagine it can
be hard to gather consensus for x86[_64].

On the other hand, as Dave Miller pointed out to me a few months ago,
correction issues should be fixed immediately and performance can be
corrected afterward even if the correction causes a performance
regression.

I think for other patches the problem may be that there isn't an
expert in all areas.

> I agree that every patch (with the exception of regeneration of e.g.
> configure files) should be send to the list before committing it.

Likewise, I agree.

> I also agree with Pasky that we should be liberal in some places (note: We
> should not be too liberal in adding new functions ;) to avoid bottlenecks.
> There are very few active people and thus we should not overload them,

Adding new functions (as in the case of the platform specific headers)
should have some consensus about the utility of the changes and the
proper way to proceed.

Ryan


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]