--/04w6evG8XlLl3ft
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable
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 <gjb@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."
> >=20
> > I fully understand forward-compatibility is not feasible.
>=20
> We already build current back to the stable/8 branch. 7.x is no longer fe=
asible, supported or tested. stable/10 is the only one that is required, bu=
t enough people use stable/9 machines it will work. stable/8 has one custom=
er that is keeping it going, so I suspect it will stop working in the comin=
g years, maybe before 11 is branched.
>=20
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.
>=20
> We already do that. It mostly works most of the time, so long as the delt=
a isn=E2=80=99t too great, and we don=E2=80=99t have high compiler/tools/ma=
ke velocity=E2=80=A6 Except we don=E2=80=99t use the kernel version, but ra=
ther the installed tools version as indicated by a .h file. That=E2=80=99s =
more robust.
>=20
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.
>=20
> What should we do we aren=E2=80=99t doing today?
>=20
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.)
>=20
> Yea, if you are using crochet, that=E2=80=99s because crochet uses xdev r=
ather than a ports compiler (which in all fairness didn=E2=80=99t exist whe=
n it started) to build u-boot, which basically requires gcc.
>=20
> The compiler rework in head is still a work in progress. What=E2=80=99s t=
here now is better than before, but still isn=E2=80=99t quite right. I do p=
lan on fixing that before summer is out.
>=20
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, whic=
h is now standard for head. Since 9.2 cannot be changed, and since we=E2=80=
=99ve removed (or nearly) fmake in current, chances are quite good it will =
never build on head again without some special handling.
> >>=20
> >> In summary, good luck! there=E2=80=99s 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=E2=80=A6 I won=E2=80=
=99t stand in your way, but I=E2=80=99m afraid my time available to help is=
limited.
> >>=20
> >=20
> > As Ozzy once sang:
> >=20
> > "I'm just a dreamer
> > I dream my life away
> > I'm just a dreamer
> > Who dreams of better days=E2=80=9D
>=20
> Since I was commenting on the opposite problem of what you were wanting c=
omments on, my harshness is justified.
>=20
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 d=
ue to gcc/clang division being done badly and unsustainable initially and t=
he cleanup taking a bit of time, not specific version issues.
>=20
> Back to your basic point, the issue becomes a testability one: not all co=
mmitters can reasonable be expected to have 8 or 9 systems to test every ch=
ange. 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=E2=80=99t been burned too often by it=E2=80=A6 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=
=E2=80=99t have done given the historical knowledge we have about the ill e=
ffects of certain ways to do conditional compilation).
>=20
To be fair, we do have reference machines in the cluster running head/,
stable/10, and stable/9.
Glen
--/04w6evG8XlLl3ft
Content-Type: application/pgp-signature
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2
iQIcBAEBCAAGBQJTqY6jAAoJELls3eqvi17QZIkP/1ZQ6eF3s6KOFoDXSW6IUKtz
52yhjjWMjPddLacpoquiUdYJBGsoFWe+8TFk/l5Unyh1wHnnBb1ag4ub4R6ht0lF
EhqZ/U9d7hLNDDzFC47nG2ew6P00sczeC+FxaFhL16i/ZrpKGo3pmJF6mIcuOkni
N2WCVrKEAdh9+R4zdA2jEzpCulmJiD/5TUa2FQzhBNm4jAYxPRcXXEUKdHRewmT/
NrzhI0Bdy3QUNNPVBmhd6wkAilQcA0LlPzrpRz0h4LX3nXlS9mthQjodwCXAT7uG
o/H+7N2/26X4vnZYBLJkFz0LeJ03BS95THKOY4ikkeEFT3Rth86QOADSm5NnFBP8
VgDpaPc+BhisKgQ4uIyk3sZN8uopk55uN/AIe3g7wX7U0KSDxOwFy3SqStobQFeU
GiLPWAZaDTe1HHhp+NQoX2NKoZC20pI4YTy/u38ORJrIOUU7PhcP6ydm3BgFTOyb
wWtaFiU4KDeRx6sb6JjVtE/45U6idzd/bn3afUEmUrddfS0PuwBfrJyMuZdQHsfo
UaqIE9s9vhcQqG7dQoOvFdNI8AGEs2So8GyvyBqn3J9911rOXe+0jxar5MdTao4W
KXFXBevSfuIkC8K1tP6biWVY/jU6SpLT4iO5T3o3xGOIpDZe5mHbrSq5vuc/Hstm
956AgTln6ZkS0EXg5bXe
=87kE
-----END PGP SIGNATURE-----
--/04w6evG8XlLl3ft--