[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Qemu-devel] Proposal for deprecating unsupported host OSes & archit
From: |
Daniel P. Berrange |
Subject: |
Re: [Qemu-devel] Proposal for deprecating unsupported host OSes & architecutures |
Date: |
Thu, 16 Mar 2017 16:00:12 +0000 |
User-agent: |
Mutt/1.7.1 (2016-10-04) |
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.
Regards,
Daniel
--
|: http://berrange.com -o- http://www.flickr.com/photos/dberrange/ :|
|: http://libvirt.org -o- http://virt-manager.org :|
|: http://entangle-photo.org -o- http://search.cpan.org/~danberr/ :|
- [Qemu-devel] Proposal for deprecating unsupported host OSes & architecutures, Peter Maydell, 2017/03/16
- Re: [Qemu-devel] Proposal for deprecating unsupported host OSes & architecutures, Daniel P. Berrange, 2017/03/16
- Re: [Qemu-devel] Proposal for deprecating unsupported host OSes & architecutures, Paolo Bonzini, 2017/03/16
- Re: [Qemu-devel] Proposal for deprecating unsupported host OSes & architecutures, Thomas Huth, 2017/03/17
- Re: [Qemu-devel] Proposal for deprecating unsupported host OSes & architecutures, Daniel P. Berrange, 2017/03/17
- Re: [Qemu-devel] Proposal for deprecating unsupported host OSes & architecutures, Peter Maydell, 2017/03/17
- Re: [Qemu-devel] Proposal for deprecating unsupported host OSes & architecutures, Thomas Huth, 2017/03/17
- Re: [Qemu-devel] Proposal for deprecating unsupported host OSes & architecutures, Peter Maydell, 2017/03/17
- Re: [Qemu-devel] Proposal for deprecating unsupported host OSes & architecutures, Dr. David Alan Gilbert, 2017/03/16