I am in favor of removing the Xen blocking criteria as it has not received the testing it needs and has been a source of conflict for several releases in the past.
Geoff Marr IRC: coremodule On Mon, Jul 8, 2019 at 10:12 AM Adam Williamson <adamw...@fedoraproject.org> wrote: > On Tue, 2019-05-21 at 11:14 -0700, Adam Williamson wrote: > > > > > > "The release must boot successfully as Xen DomU with releases > providing > > > > > > a functional, supported Xen Dom0 and widely used cloud providers > > > > > > utilizing Xen." > > > > > > > > > > > > and change the 'milestone' for the test case - > > > > > > > https://fedoraproject.org/wiki/QA:Testcase_Boot_Methods_Xen_Para_Virt - > > > > > > from Final to Optional. > > > > > > > > > > > > Thoughts? Comments? Thanks! > > > > > > > > > > I would prefer for it to remain as it is. > > > > > > > > This is only practical if it's going to be tested, and tested > regularly > > > > - not *only* on the final release candidate, right before we sign off > > > > on the release. It needs to be tested regularly throughout the > release > > > > cycle, on the composes that are "nominated for testing". > > > > > > Would the proposal above work for you? I think it satisfies what you > are > > > looking for. We would also have someone who monitors these test results > > > pro-actively. > > > > In theory, yeah, but given the history here I'm somewhat sceptical. I'd > > also say we still haven't really got a convincing case for why we > > should continue to block the release (at least in theory) on Fedora > > working in Xen when we don't block on any other virt stack apart from > > our 'official' one, and we don't block on all sorts of other stuff we'd > > "like to have working" either. Regardless of the testing issues, I'd > > like to see that too if we're going to keep blocking on Xen... > > So, this died here. As things stand: I proposed removing the Xen > criterion, Lars opposed, we discussed the testing situation a bit, and > I said overall I'm still inclined to remove the criterion because > there's no clear justification for it for Fedora any more. Xen working > (or rather, Fedora working on Xen) is just not a key requirement for > Fedora at present, AFAICS. > > It's worth noting that at least part of the justification for the > criterion in the first place was that Amazon was using Xen for EC2, but > that is no longer the case, most if not all EC2 instance types no > longer use Xen. Another consideration is that there was a time when KVM > was still pretty new stuff and VirtualBox was not as popular as it is > now, and Xen was still widely used for general hobbyist virtualization > purposes; I don't believe that's really the case any more. > > So...with thanks to Lars / Xen Project for their input, I'm afraid I'm > still in favor of this proposal, and still think we should drop the Xen > criterion for F31. This wouldn't mean Xen is out of Fedora and we don't > care about it any more, or anything like that; it would still be a part > of Fedora and we still would like Xen to work on Fedora and Fedora to > work on Xen, just like any other non-release-blocking package. It just > means we would no longer block releases if it does not work. > > Anyone have further thoughts on this? Xen folks, do you object to this > really strenuously? If so I guess we could take this to a higher/wider > level for more input. > -- > Adam Williamson > Fedora QA Community Monkey > IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net > http://www.happyassassin.net > _______________________________________________ > test mailing list -- t...@lists.fedoraproject.org > To unsubscribe send an email to test-le...@lists.fedoraproject.org > Fedora Code of Conduct: > https://docs.fedoraproject.org/en-US/project/code-of-conduct/ > List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines > List Archives: > https://lists.fedoraproject.org/archives/list/t...@lists.fedoraproject.org >
_______________________________________________ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
