Re: CVS commit: pkgsrc/cross/mingw-binutils

[David Holland <dholland-pkgchanges%netbsd.org@localhost>]

On Thu, Oct 11, 2012 at 08:16:40PM +0200, John Marino wrote:
 > >Not long ago there were no regular bulk build reports of any kind
 > >except for the stable-branch NetBSD package builds.
 > >
 > >Anyhow, the last FreeBSD bulk report I see was posted in April. Yes,
 > >that's six months ago, but that's hardly a long time.
 > 
 > I still didn't see it.  However, my point is still valid: without
 > regular bulk runs, there's no way to know the current state.

Yes, sure.

That's why it's a good thing there are a lot of bulk build reports
coming through on a regular basis lately.

It's still only a tiny fraction of the platforms we intend to
support, but it's what we've got available to work with.

 > That leads to another tangent: No build farms.  In an ideal
 > (fantasy) world, somebody would throw their proposed changed in a
 > build farm and ensure that no regressions (build failures) were
 > suffered on any platform.  Pkgsrc BADLY needs something like this.
 > I know it costs money, I'm sure we could scrape together funds for
 > a dedicated machine but it still has to be hosted and controlled
 > with other machines.  I don't see any talk about a facility like
 > this, but I think it's essential to keep QA levels up.

It is entirely unrealistic. This suggestion comes up regularly,
usually for commits to NetBSD base, and always fails; it introduces a
huge amount of administrative complication and produces little or no
benefit.

For pkgsrc it's completely impossible. To be sure your change doesn't
break anything, even on one platform, you need to do a full bulk
build. To be sure it doesn't break anything on *any* platform you need
a build farm containing at least one copy of *every* platform.

I think you vastly underestimate how many platforms there are. There
are 19 platforms listed in the 2012Q3 announcement. Many of those have
ports for multiple architectures. There's probably at least forty
targets all told, and some of them (e.g. NetBSD on macppc) are things
some people do actually care about supporting but are not fast.

You're probably talking about a build farm of 500+ heterogeneous
machines. Just finding a place to put them all is a nonstarter, let
alone the sysadminning and hardware maintenance costs. And even then
you'd have a month or more latency between proposing a commit and
having it be approved and appear.

It isn't going to happen, and there's no point thinking about it even
as an ideal.

The purposes of QA are best served by running what builds we can and
paying attention to the results. When people put the time in on a
particular platform, it's reasonably possible to get it down to only a
couple hundred failures and keep it there. (At least for non-broken
platforms; I doubt any amount of effort would bring HPUX to this
state.)

For the rest, we take bug reports.

That's about all we can do. It only works at all because we make a
point of committing portable changes.

 > >  >  Also missing the point: Nobody pointed at GCC 4.2 as the problem.
 > >
 > >That would require knowing offhand which gcc version the warning flag
 > >was added to (not likely) or having a stable of already-built gcc
 > >versions to test (also not likely) -- like many people here the only
 > >gcc versions I have readily available are the 4.1 from netbsd-5 and
 > >the 4.5 from netbsd-6 and -current.
 > >
 > >(Actually I can also get to a 4.1 shipped by Red Hat, and I might have
 > >a 4.2 somewhere on a machine that's powered down.)
 > 
 > The current release of DragonFly, 3.0, also has 4.1.  If I wasn't
 > already running 3.3, I could have checked with it.
 > 
 > But I think you're missing the "problem".
 > mingw-binutils didn't build on gcc47.  I originally added a cflag
 > "-Wno-unused-but-set-variable".  GCC 4.4 sees the flag, doesn't
 > know it, but lets it pass.  Some unknown GCC older than that sees
 > the flag, doesn't not it, and chokes.  The question is really:
 > Which is the first GCC that lets unrecognized warning flags pass?

I don't know. The point is, I don't have a pile of gcc versions to
test. One might be able to find out by wading through Google or
changelogs, but it's hardly worthwhile.

(Also, it's only unknown negative warning options.)

 > >  >  I think the project should define what platforms and compilers are
 > >  >  protected (supported) leaving the rest as "maybe it will work,
 > >  >  maybe not".  These seem like very basic parameters to me.  If this
 > >  >  already exists, how about a link?
 > >
 > >This list already exists (there's a list of OSes, the compiler list
 > >follows from it) but this suggestion is missing the basic point, which
 > >is that there is no time when it's appropriate to tell someone whose
 > >world you've broken to suck it.
 > 
 > This is a consequence of not actually defining what pkgsrc pledges
 > to support.

No, it's a conscious decision to not gratuitously unsupport anything.

 > >Since gcc 3.x still appears in the field, we need to continue to
 > >support it.
 > 
 > You'll be able to find gcc 3.x in the field in 2020.  I'm not so
 > certain "field" is the discerning factor here.

It is. Or are you proposing that the story should be "You cannot use
pkgsrc on a machine that only has gcc 3.x because I think your
platform is laughably old"?

We did eventually decide to explicitly drop support for certain very
old MacOS versions, because they're badly broken, not widely used, and
have/had a readily accessible upgrade path.

 > >This whole thread is also missing another point, which is: new gcc
 > >versions routinely break builds, particularly of low-quality software.
 > >As long as gcc remains the predominant compiler, affected packages
 > >will get fixed upstream, so these problems are transient, and
 > >disabling -Werror in the meantime is a perfectly fine approach.
 > >Or one can do the fixes and send them upstream.
 > 
 > It is good to know that disabling -Werror is fine.

It is not "fine". It is a reasonable response to floods of minor
warnings, in some cases.

I have argued before that all packages should be expected to pass gcc
-Wall -Werror; failing to do almost always eventually hides critical
problems.

 > In fact, I think you can make a case for not having it on any
 > packages for the reason above.  GCC 4.8 is sure to break something
 > that passes GCC 4.7.

Yes, except sometimes you'd rather see and inspect the failures than
disable it preemptively.

-- 
David A. Holland
dholland%netbsd.org@localhost