What is consensus?

[Andreas Jaeger]

On 04/05/2012 04:42 PM, Carlos O'Donell wrote:
> On Thu, Apr 5, 2012 at 6:04 AM, Joseph S. Myers<joseph@codesourcery.com>  wrote:
>> On Thu, 5 Apr 2012, Carlos O'Donell wrote:
>>
>>> 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.
>>
>> The way the libm tests work it's unavoidable that a newly added test will
>> typically fail on each architecture until the ulps baselines are updated,
>> since they are architecture-specific.  I don't think we should expect
>> people to test on all architectures; we should state in such cases that
>> ulps updates that do not add unduly large ulps entries (any ulps at all
>> for functions that should be exact) are considered obvious.  We should
>> also be liberal about conditioning out tests for particular floating-point
>> formats etc. if they show up bugs (always with a comment added pointing to
>> the bug in Bugzilla), for those cases where they show up an
>> architecture-specific problem that isn't being immediately fixed.
>
> (a) libm.
>
> I agree that libm is going to be problematic. Could you please add
> some wording to Consensus regarding libm and feel free to include
> vague wording about unduly large ulps?

I'll do now.

> (b) Testing on all architectures.
>
> What might you propose for situations where a patch breaks the
> testsuite for an architecture?
>
> There are some architectures which are very importantly IMO, namely
> x86 and x86_64 (and probably x32 soon). I think everyone should be
> able to test on those, and any build breakage there or testsuite
> regression should be grounds for immediate reverting to keep the tree
> "green."
>
> Comments? Should the wording be ammended to say "If you break x86 or
> x86_64 be prepared for your commit to be reverted?"

Let's pick an architecture where I have no access at all to for my 
example: If I would break Sparc somehow, I think I would need David's 
help in testing any patches. Depending on the problem, my work should be 
reverted since there's no easy patch - or we continue while fixing the 
breakage.

What I want to avoid is that some architecture maintainer comes back 
from 2 weeks of vacation and asks for the reversion of all patches of 
the last two weeks. ;)

Let's go with common sense for now - and leave the text as is and once 
it leads to problems, discuss again. So, I would amend a general 
reversion policy with something like:

  "We still need to work out some of the finer points on when to revert 
and will refine this this on a case by case basis - for now common sense 
applies."

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