Re: It's not Rust, it's FreeBSD (and LLVM)

>> - A system that is easy to build and tweak in practice (for developers at the very least).
> But what are the boundaries of this "system" of which you talk ?

In the quote to which you responded, "system" simply designates FreeBSD, or the "base system" to be even more explicit.

I have not accurately described what this "system" should include, simply because I don't believe it can be delimited precisely ex abrupto in all generality, as this depends on a lot of factors (amount of people; what they are willing and able to work on; which upstreams project exist, can be used, and are cooperative; technology evolutions; our collective project direction; etc.).

That's why I gave some high-level view of what I think the project is and should remain, and without which its nature would be considerably altered (I'd really like to hear other's points of view).  And I contend that this view is more important than the precise detail of whether we have this or that as "base".

However, according to that view, I'm more or less coming to the conclusion that FreeBSD should include the compiler.  Which doesn't mean its code has to *live* in the 'src' git repository, nor does it mean we cannot rebuild FreeBSD without using pre-packaged binary or an earlier build from source.

Before elaborating further, I'd like to expand a bit on my earlier list of what FreeBSD is/should be.  I had written this, in particular:
> - A system that is self-sufficient, in the sense that, once installed on a machine, one can set it up to do whatever one would like without having to boot something else (e.g., further software installations must be possible over the network or from some USB key; so it must include some tools to support the network, etc.).
> - A system that is easy to build and tweak in practice (for developers at the very least).
I would add that "self-sufficient" also means that it can be easily built entirely from source from itself and other commonly available systems.  And also, as developed at the end of my previous mail, that it is easy to obtain a workable view of all the source.
 
> I am more or less responsible for nearly two hundred computers
> running FreeBSD right now.  Only two of those have zero ports/packages
> installed, one monitors my floor heating system, the other firewalls
> some old crap.
> 
> To me "src+kernel" is just the foundations.
> 
> "A system" is what people build on top of the foundations.

That's one possible view of a system, which is consumer-oriented rather than developer or software-project-oriented.  And I could return the question to you: What's the limit of your "system"? One computer? Your network? A group of machines owned by someone? Or accomplishing some special task? Does it include the network (routers, cables, etc.)? Does it include your ISP?  These different groupings can always be seen as foundations of other, bigger ones.  Without more context, I don't see how this foundation/system distinction is going to be fruitful.

By "system", or FreeBSD base, I mean code written, overseen and/or managed by the people comprising the FreeBSD project, with the goals listed in my previous mail.  I think that's the fundamental difference with ports: Ports are... ports of software developed externally (which doesn't prevent some porters to contribute to upstream), not necessarily tied to FreeBSD's code, not having the same quality insurance, nor the same coding policies or release schedules, and not collectively maintained by members of the project (at least, we do not promise that; of course, members are individually free to participate to whatever upstream project they like).

There is no denying that for lots of (most?) tasks, being able to run these ports is a pre-requisite, it's just that we are not responsible for their development.  What porters are responsible for is ensuring that we can build and run these softwares on top of FreeBSD, with varying degrees of quality (depending on the size of upstream, the number of porters for each project, their level of engagement, etc.).  This sometimes entails participating to upstream development, but does not require setting, e.g., the full architecture or roadmap of these projects.

So, while we as a group are not living in an isolated island for sure, and, e.g., should strive to maintain good working relationship with other projects, we are not (and cannot) be the developers or maintainers of all useful software.  But we have to be so for software that we consider part of FreeBSD.

Of course, code that is our own (provided, again, that it is needed to fulfill the high-level principles), i.e., for which there's no upstream and no changes happen that aren't done or fully reviewed by project members (well, this may be slightly idealistic, but hey...), belongs to 'src'.

Finally, we have the kind of middle-ground comprising upstream projects, such as LLVM, which AFAICT are growing in number.  As long as we consider them to be needed in FreeBSD ("base") according to the high-level principles, we are responsible for them functioning correctly and consistently with the rest of the system, even if we are not the primary developers.  So, we also "own" this code, albeit differently to code entirely in our hands.  And it should be maintained collectively.  From commits and internal discussions, I can identify more or less correctly the (small) group of FreeBSD people working on LLVM in FreeBSD.  If, for some reason, these people would stop working on it, we would have a problem, to which I expect the project as a whole would respond with actively trying to find a solution (some would invest more time to work on it, and/or we would try to find external people who can, or we would switch to another toolchain, etc.).  If, for some reason, let's say, Firefox would lose enough of its developers to have its viability threatened, I don't expect us (as a project) to react to that as Firefox is not part of base.  This doesn't exclude having a project response to the difficulty of *porting* some software that we deem very important for the ecosystem, occasionally or in a longer term fashion.

This is only my view, but I have the feeling it is implicitly shared by many.  I'm very interested in hearing whether it is more or less conform to reality and what people think about it as of now and for FreeBSD's future.

That said, I also think this debate is mostly independent from the possibility of building FreeBSD without having to rebuild a full compiler every time.  It is however relevant to the proposal of removing LLVM's code from 'src', as this has bad consequences (according to the principles I listed) that we probably can, and should, remedy with tooling, although, as the saying goes, the daemon is in the details.

Thanks and regards.

-- 
Olivier Certner