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


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