--Apple-Mail=_3AEF3E78-6AA3-4C5E-83D3-7055130C549E
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
charset=windows-1252
On Jun 23, 2014, at 8:24 PM, Glen Barber <gjb@freebsd.org> wrote:
> On Mon, Jun 23, 2014 at 07:42:27PM -0600, Warner Losh wrote:
>>=20
>> On Jun 23, 2014, at 7:12 PM, Glen Barber <gjb@FreeBSD.org> wrote:
>>=20
>>> 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=
>>=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.
>>=20
>=20
> 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.
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/.
>>=20
>> 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.
>>=20
>=20
> 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=92t too great, and we don=92t have high compiler/tools/make =
velocity=85 Except we don=92t use the kernel version, but rather the =
installed tools version as indicated by a .h file. That=92s 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=92t doing today?
>> This isn=92t even getting into cross build scenarios=85.
>>=20
>> 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...
>>=20
>>> 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.
>>=20
>> 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.
>>=20
>> 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.
>>=20
>=20
> 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=92s because crochet uses xdev rather =
than a ports compiler (which in all fairness didn=92t exist when it =
started) to build u-boot, which basically requires gcc.
The compiler rework in head is still a work in progress. What=92s there =
now is better than before, but still isn=92t 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=92ve 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=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.
>>=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=94
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=92t been burned too often by it=85=
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=92t have done given the historical knowledge we have =
about the ill effects of certain ways to do conditional compilation).
Warner
--Apple-Mail=_3AEF3E78-6AA3-4C5E-83D3-7055130C549E
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
iQIcBAEBCgAGBQJTqQ+8AAoJEGwc0Sh9sBEANF8P/j5uxOgG4T3jdXvTUDdJ2UYC
b/4XXg9Wueh/kvSM1J/qkZqYj98XXUhJdg/VOLS9Zd2dOkYB3CLTudqSF8vktUWx
JejMqoVvuhDIUG2PtOBEcmHJsxkx1eKmK7AcIvXV1ljKplhsBXcbNLv4ojt5hDRK
h5nAWCDLDrjnQgfy0ugf1O8PKtj8ChIsoV87hMZ4giv08HoIQTmNqCHjo7NoLjT/
mL0J8seb/8r2LFrP69VBj8i6h0Bte0XxVE1/rlmtd2rpYbXJbGxTHuztXu0WiUm9
XFQ8Uuaqp1LNxCYYWCWQx3fePcLXGETkFbkq2vOCi8GfV3IXIYrfJA0R+yieoB1x
JjO05bZr5KdjAIHH2W2HH0OqgVjmdL2e8pVcNlgzXGZN2veTPde10b+d7aciODrI
JsAEFr4SzXuJqDmw3dJ5VCU4RJKZQduenxRQY3m1V/TAbG7kko+b9Dk0aS7o48ns
la8gkAziTyf3F/mNjltkCT3VXd1fI/2T2ITHxCJYoQgrLC8NrPo12DUsv5PHsNAS
7sXEpDI2d5UadKGykus7PI9JMLtyG6TCfZ6oTbXl2B1bIRGKRHXp9bAJn3D7NgHf
MuyubeRN/3xerD9VUi0mWvvYYe0xkqLPmL4ox1E1KLIAe7m93zk4zWIBnKiAvDo6
nwUzzUhhslHy7oto+U8v
=V6b4
-----END PGP SIGNATURE-----
--Apple-Mail=_3AEF3E78-6AA3-4C5E-83D3-7055130C549E--