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 2:56 PM, Andreas Jaeger <aj@suse.com> wrote:
>> 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?

(1) Trivial bug-fix changes.

Obvious patches can be committed without review.

I've written up a page on "Consensus" here to try clarify some of the
current community attitude:

http://sourceware.org/glibc/wiki/Consensus

(2) Changes to code where *you* are the expert.

If you are a machine maintainer then you are assuming a role of
leadership in the community. You must still post your patches to the
list, but after that you can commit them immediately.

(3) Obvious patches.

Yes, obvious patches are always fine.

> * 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?

I chose to be *purposely* vague.

Why?

By being vague I have forced you to *think* about your patch:

* What are the risks?

* How many people should I get review from before I feel the feature,
bug fix, or enhancement is ready to go into trunk?

* Should I do more testing?

These are all the questions you need to ask yourself.

These questions vary depending on the complexity of the patch.

In general I think you should seek out two other people to review any
non-trivial patches.

Ping the list, make a BZ entry, mark it with a milestone for the
upcoming release etc.

> * 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?

Ping the patch.

File a BZ.

Ask a specific person for review (choose someone randomly!)

Go find someone new to the community, but who knows x86 assembly to have a look.

> 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,

Does the above answer some of your questions?

Do you still have some questions?

Cheers,
Carlos.


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