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.

There is more than one way to run CI type testing, one of those is
to continuously run long tail types of testing in a loop, not testing
every commit, but testing a fairly small set of commits.  Love how
the excuse is "oh, we cant do that so lets do nothing at all????"

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

My take, many people stop reporting the broken stuff in FreeBSD and 
move to another platform.  Lack of reports != lack of use, or lack
of attemps.

Further IIRC I have seen at least 2 people report they do use this
option, probably not on a daily basis, but it is used.

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

Already implemented, works, just got fixed, why are we even having
the discussion?

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

-- 
Rod Grimes                                                 rgrimes@freebsd.org