Re: Retiring WITHOUT_CXX

On Fri, Nov 26, 2021 at 10:11 AM Rodney W. Grimes <
freebsd-rwg@gndrsh.dnsmgr.net> wrote:

> [ Charset UTF-8 unsupported, converting... ]
> > On Fri, 26 Nov 2021 at 04:09, Rodney W. Grimes
> > <freebsd-rwg@gndrsh.dnsmgr.net> wrote:
> > >
> > > So is the feature model of FreeBSD becoming, oh it gets broken
> > > cause it is not regularly tested, so lets remove that feature.
> >
> > I don't agree with that. We have a large and growing CI infrastructure
> > to regularly test functionality and are continually adding to it over
> > time. But it's important to test and maintain what is actually used
> > and is useful. Disabling C++ support made sense when obrien@ added the
> > original knob in 2000, but it makes less sense today when parts of
> > FreeBSD are written in C++.
> >
>
> You can disagree with my assertion, but I shall continue to assert
> that it *seems* as if rather than adding B O S to the CI such that
> it is not only regularly tested, but continuously tested is the
> correct path forward here.


Testing all possible options takes on the order days. Testing all
possible combinations takes much longer. It's not practical to test
them all on every commit. It's computationally difficult.


> Removing an option that seems to
> break due to not beeing tested (your original assertion) is not
> only false (I pointed out, and do know for a fact that Michael
> Dexter runs BOS on a very regulary basis, infact near continously.)
> and the wrong path forward.
>

I think you're missing the data here. While it's great that Dexter's BOS run
finds things (don't get me wrong here), the fact that he's finding it with
a BOS run w/o user reports of it being broken suggests that it's not
very popular.


> Fix the broken stuff, stop letting stuff rot because you don't care
> to work on it, or because it is not being "tested".
>

We do have to stop and consider the bigger picture: is it an option
that's useful enough to have it be one of the subset of things we test
on a regular basis, and enforce some sort of pre-commit requirements
for. Or is it an option we're content to test after the fact and have some
sane plan for remediation? Or is it an option that we've slavishly
carried forward from a time where it made a lot of sense to a time where
the situation on the ground is such that it no longer makes sense?

That's the discussion we're having here. Is it important enough to require
everybody to pay attention to it or not...

Warner