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: What is consensus?


On 04/05/2012 04:54 PM, Carlos O'Donell wrote:
On Thu, Apr 5, 2012 at 7:22 AM, Andreas Jaeger<aj@suse.com> wrote:
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,

Thanks for your input Andreas.


I agree that being too vague is sometimes a bad thing, but in this
case I think *starting* vague has helped kick off the discussion ;-)

Yep ;)


I fully agree that we should change everything and anything as needed
to make the community grow. I don't see that any of these things are
fixed in stone. The purpose of using the word "consensus" is to make
it clear that we aren't going to solve everyones objections, and that
it's a process involving a group.

Understood now.



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.

However, keep in mind that during that day you'v wasted the time of other volunteers working on the same machine or trying to work out a testsuite issue? How do you feel about the frustration that they will face? They will likely locally revert the patch. Is that an OK practice? Is that how most of us work today?

If it's breaking the building, I agree - for the testsuite we could be laxer. As I've said before, I'm not objecting, let's give your suggestion a try.


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.

Agreed. It would certainly seem wrong to penalize you, you did good work, and the machine maintainers had ample opportunity to fix this. I think this is certainly a case where immediate reversion would be wrong.

Could you please add some wording to the Consensus document about this?

I think the process you followed for your large change:
(a) Make a branch.
(b) Ask for input.
(c) Merge branch after input.

Should grant you a "pass" when it comes to getting your patch reverted :-)

I've added a section to the wiki page (called Best Practice) on this but it didn't really fit in. Please move around or change it ;)



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


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