--Apple-Mail=_DD61DB34-0FD3-4459-9BDB-32F5E9522E2B
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
charset=windows-1252
On Jun 23, 2014, at 7:12 PM, Glen Barber <gjb@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@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.
>>=20
>> You=92ll have to back port the patch then. We don=92t guarantee =
forward
>> compatibility like this since 9.2 is frozen in time now.
>>=20
>=20
> I'd really like to discuss rethinking our forward-compatibility
> policies, since we have (now) 3 active stable/ branches, plus head/.=20=
Generally, in the past, the rule has been =93head will build from the =
last stable branch tip.=94 This was extended, for a while, to =93last =
stable branch point=94 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=92s tools changing in ways that are allowed for head, but that =
break prior branches.
> 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=92t always work. Things break in this area a lot. More than you =
might think, especially with the huge amount of churn we=92ve 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=85 With -current starting to support building multiple =
versions of clang (and gcc), there=92s hope for the future, but =
back-porting this code is beyond what I have the time to do. That=92s =
going to make things increasingly difficult as we march forward.
This isn=92t even getting into cross build scenarios=85.
Or building releases, which is a whole different set of lightly tested =
code that is mostly host independent, but sometimes isn=92t as much as =
you=92d 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=92s a race, that needs to be fixed in =
stable/9. That=92s quasi supported because people do it. The =93best =
effort=94 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 =93best effort=94 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=92s 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.
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=92ve =
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=92s 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=85 I won=92t stand =
in your way, but I=92m afraid my time available to help is limited.
Warner
--Apple-Mail=_DD61DB34-0FD3-4459-9BDB-32F5E9522E2B
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment;
filename=signature.asc
Content-Type: application/pgp-signature;
name=signature.asc
Content-Description: Message signed with OpenPGP using GPGMail
-----BEGIN PGP SIGNATURE-----
Comment: GPGTools - https://gpgtools.org
iQIcBAEBCgAGBQJTqNeDAAoJEGwc0Sh9sBEAW34P/j6piRRxQNGqYDyrCIb3eiKT
py5v64urwDGP18QkFbzjXE1QfkqgbkPpRM40+xgWRRNsfgn/zmFUiFvTeBy66wB3
CnnRpcrppS2mSFv1V7xbDN8Dgtu7ibNRkK0zTrlHLqRmfoZp6pcSaFo9OripIP04
pCNfIp0vpDTj8PKYIBOeh/WuzFO2YGOA0XidjEjnxN1iWlhZbjjCeBvlV2drD3V1
qeiTALTLEWSOEuxl0LYernfTRSAR5d8KKd8LvDLvqFkRqWTgMY8Pn/ik+HdAg0wx
dk/O13DUumgKmp62AtUSOIJ+XrEJ+xXQwfDNmAGw2Tsa6sd9LxlGY69am1z/r5k6
orhdh783koeP5aCT4iNGLxV2qPuAxpDySICh6hX58n4h5qfZfj5u32iWfPzqT9dB
u644GCuKz/HOkdg9DGjPctKKiphobzoNprBgKot51LtNkh/OLBpWvpmE4DHh+88I
laXeqzbwAn/HLaPDgrWj6an5aOaHXgW0IMLvwLmP85FyJ34VZt8w74tvpZltIQ+A
bs5cYfcobJzs/oYwGpDEJzYlbJhub/IprBUcDNMTAN5iAoHrDZ84Pg7RKjrxWKoa
jW5zR/w35DKRIy0dEaOsPGQ86JLy2zBXEkhE6ts+Ft2HUVid3KT0RXk3TskkC2pE
LYl7lu2Vhyj6B487dvpg
=s6Lq
-----END PGP SIGNATURE-----
--Apple-Mail=_DD61DB34-0FD3-4459-9BDB-32F5E9522E2B--