Re: [Qemu-devel] Proposal for deprecating unsupported host OSes & architecutures

[Markus Armbruster]

"Daniel P. Berrange" <address@hidden> writes:

> On Thu, Mar 16, 2017 at 03:55:13PM +0000, Peter Maydell wrote:
>> On 16 March 2017 at 15:46, Daniel P. Berrange <address@hidden> wrote:
>> > On Thu, Mar 16, 2017 at 03:23:45PM +0000, Peter Maydell wrote:
>> >> OK, here's a concrete proposal for deprecating/dropping out of
>> >> date host OS and architecture support.
>> >>
>> >> We'll put this in the ChangeLog 'Future incompatible changes'
>> >> section:
>> >> -----
>> >> * Removal of support for untested host OS and architectures:
>> >>
>> >> The QEMU Project intends to drop support in a future release for any
>> >> host OS or architecture which we do not have access to a build and test
>> >> machine for. This affects the following host OSes:
>> >>  * Native CYGWIN building
>> >>  * GNU/kFreeBSD
>> >>  * FreeBSD
>> >>  * DragonFly BSD
>> >>  * NetBSD
>> >>  * OpenBSD
>> >>  * Solaris
>> >>  * AIX
>> >>  * Haiku
>> >> and the following host CPU architectures:
>> >>  * ia64
>> >>  * sparc
>> >>
>> >> Specifically, if we do not have a build and test system available
>> >> to us by the time we release QEMU 2.10, we will remove support in the
>> >> release that follows 2.10.
>> >> -----
>> >>
>> >> I'm not sure here if we want to just have this as a bald list,
>> >> or to have some kind of two tier setup with OSes we expect to
>> >> dump in one tier and OSes where we're really trolling for a build
>> >> machine in the other tier (the "unlikely to dump" category would
>> >> get most of the BSD variants in it). Putting out a changelog
>> >> that says "we're gonna drop all the BSDs" seems like it might
>> >> produce a lot of yelling?
>> >
>> > I think it depends on the level of bit-rot we are aware of, and
>> > whether we expect anyone is likely to fix the bit-rot should it
>> > be discovered.
>> >
>> > Simply not having a build machine for QEMU CI doesn't imply that
>> > it is totally broken, and even if some pieces are broken, it
>> > doesn't imply that QEMU is unusable.
>> 
>> No, but it does imply that our CI is missing a big chunk.
>> Realistically, for the BSDs where I want to get to is "we
>> have BSD coverage in our CI setup". The problem at the moment
>> is that we (presumably) have BSD users but we have basically
>> no BSD developers active upstream, which in my view is not
>> a very long-term satisfactory situation.
>> 
>> > IOW, I think there is a reasonable 3 tier set here
>> >
>> >  1. Stuff we actively test builds & thus guarantee will work for
>> >     any QEMU release going forward.
>> >
>> >  2. Stuff we don't actively test, but generally assume is mostly
>> >     working, and likely to be fixed if & when problems are found
>> >
>> >  3. Stuff we don't actively test,  assume is probably broken
>> >     and unlikely to be fixed if reported
>> >
>> > Stuff in tier 3 should be candidate for deletion. Stuff in tier
>> > 2 shouldn't be removed, but it might drop into tier 3 at some
>> > point if people stop caring about fixing problems when found.
>> > Conversely tier 2 might rise to tier 1 if CI turns up.
>> 
>> I don't really want a tier 2. Either we support it enough
>> to at least be able to run "make && make check" on some
>> representative system, or we don't support it at all.
>> Code which we have but are really reluctant to touch because
>> we don't even test it builds (like bsd-user/) is really bad
>> for preventing cleanups.
>
> IMHO we should not be afraid of cleaning up code in such cases.
> If bsd-user accidentally breaks because we clean up some other
> parts of QEMU, so be it. If someone cares they'll step forward,
> if not, it'll be a sign that it its material for tier 3 & thus
> eventual removal.
>
> I'm just pretty wary of gratuitously deleting stuff that still
> has a reasonable chance of being functional, simply because
> we lack CI testing.

That's pre-git thinking :)

I've done a fair amount of cleanup work.  Having to touch something you
can't test *always* deters.  Working CI is the rock-bottom level of "can
test".

Sure, "if somebody cares, they'll step forward" to fix whatever I break.
Eventually.  But I'd like to turn this argument inside out: if somebody
cares, they can bloody well make CI work, so it doesn't break so easily.
If they discover they care only after we dropped support, they can
bloody well fish its code out of git.

I'm willing to tolerate the odd host-specific configure snippet without
CI.  But no conditional compilation, be it via Make or #if.