What is consensus?

[Andreas Jaeger]

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