On Jun 23, 2014, at 7:12 PM, Glen Barber <g...@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 <rodr...@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.

> 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.

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 

> 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.

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.


Attachment: signature.asc
Description: Message signed with OpenPGP using GPGMail

Reply via email to