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

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.

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

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

> But I would not codify the above (besides the libm tests) and assume we'll
> be sensible with reverting of code,

OK.

Cheers,
Carlos.


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