Trimmed CC a bit. On Mon, Jun 23, 2014 at 11:42:20PM -0600, Warner Losh wrote: > On Jun 23, 2014, at 8:24 PM, Glen Barber <g...@freebsd.org> wrote: > > I sort of typed what I meant a bit backwards from what I intended to > > write. What I meant (sort of) is, "I would like to discuss our forward > > thinking on backward-compatibility." > > > > I fully understand forward-compatibility is not feasible. > > We already build current back to the stable/8 branch. 7.x is no longer > feasible, supported or tested. stable/10 is the only one that is required, > but enough people use stable/9 machines it will work. stable/8 has one > customer that is keeping it going, so I suspect it will stop working in the > coming years, maybe before 11 is branched. >
To be clear, I am talking about the other direction. Meaning, being able to "reliably" build N-2 from head/, without needing to do silliness like 'make make buildworld', or "not using -jN." > > I hate to even suggest this, but the ports tree (ab)uses the notion of > > using the kern.osreldate for certain things. This, however, requires > > proper bumping of __FreeBSD_version when needed, and maintenance of the > > Makefiles for the kern.osreldate-specific things. > > We already do that. It mostly works most of the time, so long as the delta > isn’t too great, and we don’t have high compiler/tools/make velocity… Except > we don’t use the kernel version, but rather the installed tools version as > indicated by a .h file. That’s more robust. > True. Thank you for the sanity check. > > The benefit to this is that it would help prevent pissing off ports > > developers and make their lives a bit easier when userland / kernel > > things change. It would, however, (expectedly) is that it would force > > src committers to do the right thing. Win-win, IMHO. > > What should we do we aren’t doing today? > There have been a number of times where changes that should deem a __FreeBSD_version bump necessary either 1) do not bump __FreeBSD_version at all, or 2) bump __FreeBSD_version several days (or longer) later. So, we're left with a window of time where something is "different enough", but there is no corresponding version change to reference. This is somewhat tangential to my original annoyance here though. :) > > Personally, and no I won't discuss more on this, I'm in the camp of "I > > don't really see clang as a feature." It caused our ports developers > > and maintainers a mountain of headache to convert to the "invisibly new > > great thing", it increases our overall buildworld by a non-insignificant > > amount of time, and it has personally caused me headaches (still > > ongoing) trying to figure out what the correct incantation of evil to > > wish over the cauldron to get BeagleBone images to build. (They're > > failing because gcc is not being installed on both head/ and stable/10/, > > and despite the game of "musical KNOBS" I've been playing over the past > > few days, I'm running out of hair to pull out of my head.) > > Yea, if you are using crochet, that’s because crochet uses xdev rather than a > ports compiler (which in all fairness didn’t exist when it started) to build > u-boot, which basically requires gcc. > > The compiler rework in head is still a work in progress. What’s there now is > better than before, but still isn’t quite right. I do plan on fixing that > before summer is out. > It isn't just head that is a problem with crochet, though. stable/10 has been a problem since, as far as I can tell, roughly early May. > >> But 9.2 will never build on head because it is broken with bmake, which is > >> now standard for head. Since 9.2 cannot be changed, and since we’ve > >> removed (or nearly) fmake in current, chances are quite good it will never > >> build on head again without some special handling. > >> > >> In summary, good luck! there’s a lot of use cases here, and it will take > >> time and effort of multiple people over the long haul to keep it working. > >> Best effort may be larger than you estimate… I won’t stand in your way, > >> but I’m afraid my time available to help is limited. > >> > > > > As Ozzy once sang: > > > > "I'm just a dreamer > > I dream my life away > > I'm just a dreamer > > Who dreams of better days” > > Since I was commenting on the opposite problem of what you were wanting > comments on, my harshness is justified. > My comment wasn't a comment on your comment. :-) > What you want though, we largely already do, though maybe with a few more > warts than necessary (which we should try to fix). Most of the warts are due > to gcc/clang division being done badly and unsustainable initially and the > cleanup taking a bit of time, not specific version issues. > > Back to your basic point, the issue becomes a testability one: not all > committers can reasonable be expected to have 8 or 9 systems to test every > change. Having a 10.x system to test changes is a bit of a stretch as it is, > but it is the official policy that many folks play fast and loose with the > rules because they haven’t been burned too often by it… VMs, Jails, etc of > various flavors can help, but some info does leak through (mostly the info > leaks are bugs or kludges that well meaning people shouldn’t have done given > the historical knowledge we have about the ill effects of certain ways to do > conditional compilation). > To be fair, we do have reference machines in the cluster running head/, stable/10, and stable/9. Glen
pgpQIkSMZtre7.pgp
Description: PGP signature
