On Jun 23, 2014, at 8:24 PM, Glen Barber <gjb_at_freebsd.org> wrote: > On Mon, Jun 23, 2014 at 07:42:27PM -0600, Warner Losh wrote: >> >> On Jun 23, 2014, at 7:12 PM, Glen Barber <gjb_at_FreeBSD.org> wrote: >> >>> On Mon, Jun 23, 2014 at 06:57:15PM -0600, Warner Losh wrote: >>>> On Jun 23, 2014, at 6:15 PM, Craig Rodrigues <rodrigc_at_FreeBSD.org> wrote: >>>>> So, I guess that stable/9 can build properly on a stable/10 box. >>>>> For FreeBSD 9.2, there is no easy way out. >>>> >>>> You’ll have to back port the patch then. We don’t guarantee forward >>>> compatibility like this since 9.2 is frozen in time now. >>>> >>> >>> I'd really like to discuss rethinking our forward-compatibility >>> policies, since we have (now) 3 active stable/ branches, plus head/. >> >> Generally, in the past, the rule has been “head will build from the last stable branch tip.” This was extended, for a while, to “last stable branch point” when Ruslan made sure that worked. While -stable has generally built on -head, this was never part of the contract. It usually did, but is very very hard to guarantee given the nature of head’s tools changing in ways that are allowed for head, but that break prior branches. >> > > 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. >>> What I would like to see, with my RE hat on, is a "best effort" >>> backwards compatibility to being able to build the lowest-numbered >>> supported stable/ branch on head/. >> >> I think, that as in the past, this will generally work. However, it won’t always work. Things break in this area a lot. More than you might think, especially with the huge amount of churn we’ve had wrt compilers, make, etc. I suspect that new imports of clang will break this every time, since every import of clang has required changes to the tree to either disable warnings, or to fix newly flagged things. I suspect there will be a lot of churn here, and releases will go stale the fastest… With -current starting to support building multiple versions of clang (and gcc), there’s hope for the future, but back-porting this code is beyond what I have the time to do. That’s going to make things increasingly difficult as we march forward. >> > > 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. > 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? >> This isn’t even getting into cross build scenarios…. >> >> Or building releases, which is a whole different set of lightly tested code that is mostly host independent, but sometimes isn’t as much as you’d had hoped... >> >>> Sure, this won't always work, but "best effort" is better than "no >>> effort", which the latter is why we do not have stable/8 snapshot >>> builds, to be honest. I won't spend the time on the stable/8/release/ >>> code nor the snapshot build scripts to waste the time. Building >>> stable/9 on head/ is annoying alone. >> >> stable/9 builds on head. If there’s a race, that needs to be fixed in stable/9. That’s quasi supported because people do it. The “best effort” involves people that are interested in the bugs being fixed fixing them, or convincing others to fix them. For me, this scenario is outside the area I care about, have the ability to test, or have time for. >> >> So “best effort” involves more than me making an effort. I may or I may not. It all depends on my time and inclination. If it is going to work, bugs need to be fixed in stable/9 that prevents it from building on head, while not breaking the ability to build on 9. So there’s a lot of heavy lifting that will be needed in short order to keep this working once the clang folks can figure out how to get past the angst of the upgrade path and push forward to 3.5. Some architectures will break when that happens, no doubt. >> > > 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. >> 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. 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). Warner
This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:40:50 UTC