This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: What is consensus?
On 04/05/2012 08:18 AM, Carlos O'Donell wrote:
The wiki MAINTAINERS page says something about achieving consensus
before being allowed to commit a patch.
We are *purposely* vague here because there is no right answer for all cases.
>
You need to think hard about your patch...
* How does this affect our users?
* Who are technical stakeholders in this code?
* Who is experienced with this code and can review the design?
* What are the known risks or problems?
* Have I had enough review?
Then involve the people that you need to answer these questions and
you've reached consensus.
Still people will make errors and I suggest as glibc maintainers we
continue the way of the last weeks and help those that make errors.
Beeing vague can be good but sometimes people need clear goals and might
be too cautious. Let's experiment with this in a friendly and
encouraging manner and change the rules as needed,
Take for example this recent BZ#11787[1] is a case where the thread
stack VM reservation is affected. I don't want to make any change
there until the distributions give some input on the problem. The
final patch will go through a final round of vetting by the
distributions.
Having said that there are some things that we all agree to which I've
started documenting here:
http://sourceware.org/glibc/wiki/Consensus
The more controversial point I make here is that we probably need to
take a hard stand on build/testsuite regressions and simply revert any
patches that break or regress the testsuite.
>
It's easy enough to fixup the patch and put it back in tomorrow when
it's fixed. After some serious introspection and consulting of other
developers on large projects, it was clear that the cost of keeping
trunk broken and regressed is that it ruins development for other
volunteers. That cost is *very* high when you consider that other
developers don't have the time to track down breakage or regressions
just to submit an unrelated bug fix. The more we keep trunk in a
green-light ready-to-go state the better it is for all developers.
My personal preference would be waiting for a day but I'm fine with
trying out this as well.
But there are some exceptions for machine specific changes. Besides the
issue with the libm testsuite that Joseph raised, there're also changes
like the removal of the elf directories. Most architecture maintainers
gave feedback on the change - or I tested it myself - but for some there
was no reaction after several days. I assume my patch works on those
architectures but IMO they had their time of testing/objection and if it
now fails for them, we should not revert it.
But I would not codify the above (besides the libm tests) and assume
we'll be sensible with reverting of code,
Andreas
--
Andreas Jaeger aj@{suse.com,opensuse.org} Twitter/Identica: jaegerandi
SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany
GF: Jeff Hawn,Jennifer Guild,Felix Imendörffer,HRB16746 (AG Nürnberg)
GPG fingerprint = 93A3 365E CE47 B889 DF7F FED1 389A 563C C272 A126