Re: GCC withdraw

On 31 Aug 2013, at 08:33, John-Mark Gurney <jmg_at_funkthat.com> wrote:

> Why didn't this come up when John added XSAVE (a year ago) or Pedro
> Giffuni added amdfam10 support (3 months ago)?
> 
> Plus, I've sent other patches earlier this year to -toolchain and made
> clear why I was adding them...  Had I known that the policy was gcc was
> dead for HEAD (which btw, I was told multiple times that we were keeping
> gcc for 10 for i386/amd64), I would have just committed my kernel changes
> by now, but didn't want to break a (what I thought was) supported
> configuration...

gcc is not dead for 10.0, we're simply wanting to not ship it in binary form by default.  There is a BIG difference between saying 'if you want gcc then you must explicitly opt in and build it yourself and it may not be there for the entire 10.x series' and saying 'gcc is gone now, don't expect any of FreeBSD to build with it'.  We are absolutely not proposing the latter for 10.0.  

We still expect the 10.0 kernel and most of the userland (libc++ excepted) to build with gcc.  We expect this to be true for 10.1, and probably 10.2, possibly even 10.3.  I'd probably expect that at least the kernel will build with gcc 4.2.1 for the entire timeframe.  Some modules may not, although for ease of debugging compiler bugs I'd recommend that if they don't build with gcc 4.2.1 then at least they build with upstream gcc.

However, we want to be able to make it unsupported at some point in the 10.x series when there is a polished alternative for every supported architecture (either when they've moved to clang or when the XCC stuff is fully documented in the handbook and tested in a large variety of configurations and once our forked binutils and is available as a package and we have cross-gcc that uses it).  If this doesn't happen by the time 10.x is EOL'd then I'll be sad, but we still have the fall-back position of gcc in base for the entire 10.x.  If it does happen, then we can start more aggressively phasing out gcc in the base system.  


> We need to communicate better on issues like these, since this isn't the
> first time one group of people made a decision w/o telling the rest
> of the community...  For major items like this, we need to make sure
> the road map is published, either on www.freebsd.org or on the wiki and
> gets kept up to date...

I agree.  This is why I made sure that at the BSDCam DevSummit all of the sessions had someone who was taking notes for their sessions on the wiki:

https://wiki.freebsd.org/201308DevSummit#Schedule-1

(Well, except, somewhat ironically, the docs team, who still haven't put their notes on the wiki)
It's also why I've taken charge of putting out special status reports for each DevSummit for wider public consumption, like this one:

http://www.freebsd.org/news/status/report-2013-05-devsummit.html

I'd be interested in hearing any more suggestions about how we can improve this.

> For example, the release schedule for 10 wasn't posted till over a week
> after the code slush was announced (which caught people, like myself, by
> surprise)...  That's kinda the wrong order to do it in, the schedule
> should be posted well in advance so people know what to expect...

This one you'll have to discuss with re_at_.  I think that after 10.0 there will be some more discussion about our release policy.  

David