Re: How to interpret F18 Blocker criterion
On Tue, Nov 13, 2012 at 10:02 PM, Adam Williamson awill...@redhat.com wrote: On Mon, 2012-11-12 at 09:36 -0500, Kamil Paral wrote: No, I don't see any reason why VMs are any different from any other hardware plattform. So for VMs everything that applies to hardware applies. If you are using out of tree or closed source drivers you are on your own etc. pp. It is a tempting thought, to address virtualization issues similarly to hardware issues. The only difference that comes to my mind is that hardware tends to be pretty stable (except for firmware updates), but virtualization software might change pretty quickly. If we take it into account, we could really consider virt platforms same as hw platforms - it would be a conditional blocker, and we would decide by using our best judgment according to issue severity, our estimate of the number of users affected and our ability to fix that. We could create a new paragraph in Blocker Bug FAQ [1] that would describe virt issues. We could specify which technologies we consider most important for Fedora (like KVM, VirtualBox, etc), and that would affect the final decision. In return, we wouldn't have to have criteria about concrete technologies, and we would be able to avoid tricky criteria definitions, like the VirtualBox one. Thoughts? This seems an interesting way to go, so long as we can keep the strong support for KVM we currently have. Given how widely used it is ... I wouldn't worry about that. -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Re: How to interpret F18 Blocker criterion
On Mon, 2012-11-12 at 09:36 -0500, Kamil Paral wrote: No, I don't see any reason why VMs are any different from any other hardware plattform. So for VMs everything that applies to hardware applies. If you are using out of tree or closed source drivers you are on your own etc. pp. It is a tempting thought, to address virtualization issues similarly to hardware issues. The only difference that comes to my mind is that hardware tends to be pretty stable (except for firmware updates), but virtualization software might change pretty quickly. If we take it into account, we could really consider virt platforms same as hw platforms - it would be a conditional blocker, and we would decide by using our best judgment according to issue severity, our estimate of the number of users affected and our ability to fix that. We could create a new paragraph in Blocker Bug FAQ [1] that would describe virt issues. We could specify which technologies we consider most important for Fedora (like KVM, VirtualBox, etc), and that would affect the final decision. In return, we wouldn't have to have criteria about concrete technologies, and we would be able to avoid tricky criteria definitions, like the VirtualBox one. Thoughts? This seems an interesting way to go, so long as we can keep the strong support for KVM we currently have. -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | identi.ca: adamwfedora http://www.happyassassin.net -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Re: How to interpret F18 Blocker criterion
No, I don't see any reason why VMs are any different from any other hardware plattform. So for VMs everything that applies to hardware applies. If you are using out of tree or closed source drivers you are on your own etc. pp. It is a tempting thought, to address virtualization issues similarly to hardware issues. The only difference that comes to my mind is that hardware tends to be pretty stable (except for firmware updates), but virtualization software might change pretty quickly. If we take it into account, we could really consider virt platforms same as hw platforms - it would be a conditional blocker, and we would decide by using our best judgment according to issue severity, our estimate of the number of users affected and our ability to fix that. We could create a new paragraph in Blocker Bug FAQ [1] that would describe virt issues. We could specify which technologies we consider most important for Fedora (like KVM, VirtualBox, etc), and that would affect the final decision. In return, we wouldn't have to have criteria about concrete technologies, and we would be able to avoid tricky criteria definitions, like the VirtualBox one. Thoughts? [1] https://fedoraproject.org/wiki/Blocker_Bug_FAQ -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Re: How to interpret F18 Blocker criterion
On 11/11/2012 04:31 AM, Adam Williamson wrote:
We do, and that's a plausible outcome. But I think those pushing for a
stronger approach than this are making a decent case. It's at least
worth considering if our 'we don't care about VBox' stance may be
hurting more than we had thought, and considering making more of a
distinction between 'we don't care about using Fedora as a VBox host'
and 'we rather do care about making sure Fedora works as a VBox guest,
as best we can'.
I think we need something like in the final criteria
Fedora must successfully install,boot and establish a network
connection running as a guest in hyperv/kvm/vbox/vmware/xen for each one
of the release-blocking package sets ('minimal', and the package sets
for each one of the release-blocking desktops)
( this means #810040 will block the release )
maybe we should say with the virtualzation host default settings in the
above?
And I think we need rewrite and or adjust this one which I simply fail
to parse
The release must boot successfully as Xen DomU with releases providing
a functional, supported Xen Dom0 and widely used cloud providers
utilizing Xen. This does not include any issues limited to the release
functioning as Xen Dom0
To something that covers both kvm and xen without referring to cloud
specifically and be more generic which should cover that just fine.
Fedora must successfully run as an kvm/xen virtualzation host
Followed by test cases on how to setup and run Fedora as a one.
JBG
--
test mailing list
test@lists.fedoraproject.org
To unsubscribe:
https://admin.fedoraproject.org/mailman/listinfo/test
Re: How to interpret F18 Blocker criterion
On Sun, Nov 11, 2012 at 9:15 AM, Jóhann B. Guðmundsson johan...@gmail.com wrote: On 11/11/2012 04:31 AM, Adam Williamson wrote: We do, and that's a plausible outcome. But I think those pushing for a stronger approach than this are making a decent case. It's at least worth considering if our 'we don't care about VBox' stance may be hurting more than we had thought, and considering making more of a distinction between 'we don't care about using Fedora as a VBox host' and 'we rather do care about making sure Fedora works as a VBox guest, as best we can'. I think we need something like in the final criteria No, I don't see any reason why VMs are any different from any other hardware plattform. So for VMs everything that applies to hardware applies. If you are using out of tree or closed source drivers you are on your own etc. pp. -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Re: How to interpret F18 Blocker criterion
On 11/11/2012 08:33 AM, drago01 wrote: No, I don't see any reason why VMs are any different from any other hardware plattform. So for VMs everything that applies to hardware applies. If you are using out of tree or closed source drivers you are on your own etc. pp. I dont think none of the solution actually do use or require anykind of closed source drivers ( as has been claimed here but been proven otherwise atleast with VMware )when running as an guest and since we explicitly mention running fedora as an virtualzation host we should do so as well as an guest and arguably more so because to me fedora as an virtualzation host equals to us saying we must be able to run fedora as an samba host,fedora as an nfs host etc... JBG -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Re: How to interpret F18 Blocker criterion
On Sat, Nov 10, 2012 at 11:31 PM, Adam Williamson awill...@redhat.com wrote: On 2012-11-10 9:36, Josh Boyer wrote: 1) It's making something Fedora does not build, provide, or have any influence on part of our release process. Doubly so if you're going down the test it using Windows or OS X as a host route. I'm personally not thrilled at all about adding such dependencies as criteria at the moment. I also think if you're running it using a Linux host, then there are other options we already support that do just fine... As others have pointed out, this is really rather a matter of perception. Yes, I'm aware of that. The problem space here is what is Fedora's perception, fitting in within the confines of our rules, community, and abilities. I suggest that your use of the plural 'options' there is somewhat optimistic. As things stand we nominally support two 'options' - KVM and The definiton of plural is more than one. That is a fact and usage of plural nouns does not connotate anything other than the existance of more than one option. Now, if you want to debate the usefulness of those options, fine. Xen sucks. I wasn't thrilled with _it_ being made a criteria either, but hey it's there now and the cloud people love it out of necessity. Xen. Both of these have significant limitations. Xen in itself is, let's face it, not popular. Especially not popular for desktop virt. To a rough approximation, no-one uses it for that. KVM does not work on Windows hosts, Why are you talking about Windows hosts in a reply to a fragment where I clearly said Linux host? The KVM stack works well on Fedora / RHEL and (so I've heard) reasonably well on Ubuntu. I don't know if it's widely used or supported on other distributions, or even necessarily packaged for them. It definitely is not an option on Windows or OS X. Again. I said Linux host. Maybe we already have testcases that are run but are not criteria. I honestly have no idea. If we do, I think that would be a better fit than trying to put some kind of weight behind Fedora as a guest in these cases. We do, and that's a plausible outcome. But I think those pushing for a stronger approach than this are making a decent case. It's at least worth I can make strong cases for many things we cannot scale to. I'd love to see those pushing for this to actually step up and do it. Get testcases written, form groups of triagers, just run the damn tests regardless of criteria status, present results. And KEEP doing that until we can see that this isn't a flash in the pan and it's sustainable. josh -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Re: How to interpret F18 Blocker criterion
On 2012-11-11 5:00, Josh Boyer wrote: Yes, I'm aware of that. The problem space here is what is Fedora's perception, fitting in within the confines of our rules, community, and abilities. As far as I'm aware, there is nothing in our rules or our communities that makes hard requirements about the freeness of the platforms on which we run. The KVM stack works well on Fedora / RHEL and (so I've heard) reasonably well on Ubuntu. I don't know if it's widely used or supported on other distributions, or even necessarily packaged for them. It definitely is not an option on Windows or OS X. Again. I said Linux host. Sorry for not making this part clearer, but in the wider context it doesn't matter what you said, because the wider context is whether we should support other virt platforms or not. If you would like me to put it in context, fine, add the following text to my previous post: You say 'Linux host', but why should we only worry about Linux hosts? It's clearly the case that people want to run Linux distributions on Windows virtualization hosts, and this seems like a valuable case that we should consider. I can make strong cases for many things we cannot scale to. I'd love to see those pushing for this to actually step up and do it. Get testcases written, form groups of triagers, just run the damn tests regardless of criteria status, present results. And KEEP doing that until we can see that this isn't a flash in the pan and it's sustainable. Sure, that would be nice, of course. But often such efforts grow out of discussions like this. The Xen case did. I'm certainly hoping the same people who pushed for the Xen support and wrote the Xen criterion and test cases will be testing it this time around as they did last time around, for instance. -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | identi.ca: adamwfedora http://www.happyassassin.net -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Re: How to interpret F18 Blocker criterion
On Sun, Nov 11, 2012 at 11:26 AM, Adam Williamson awill...@redhat.com wrote: I can make strong cases for many things we cannot scale to. I'd love to see those pushing for this to actually step up and do it. Get testcases written, form groups of triagers, just run the damn tests regardless of criteria status, present results. And KEEP doing that until we can see that this isn't a flash in the pan and it's sustainable. Sure, that would be nice, of course. But often such efforts grow out of discussions like this. The Xen case did. I'm certainly hoping the same people who pushed for the Xen support and wrote the Xen criterion and test cases will be testing it this time around as they did last time around, for instance. Since what I say doesn't seem to matter, and we can sort of agree on this point I think we'll end here. If some show up to do the work, great. Until then, it's an idea. josh -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Re: How to interpret F18 Blocker criterion
On Sat, Nov 10, 2012 at 5:14 AM, Jóhann B. Guðmundsson johan...@gmail.com wrote: On 11/10/2012 12:39 AM, Adam Williamson wrote: I think there's still some host/guest confusion going on, possibly. I was refereeing to Fedora as an guest in vmware,vbox,hyperv not as an host which is in context with the criteria discussion about Fedora being installed along with other OS. I considered it important that Fedora works out of the box when deployed as an guest in available virtual solutions but other people seem to praise stallman and what not fixating on open being the only way and failing to understand that people will use what works for *them* and accept other alternatives... It's kinda obvious that we cover our ground to the best of our ability with Fedora as an host where applicable ( kvm/xen ) We should not differentiate between hardware platforms and virtual machine environments i.e treat running on a guest the same as running on laptop foo baz. It is just a different platform. When we find bugs that hit any other criteria that are specific to some environment we should do the same as we do with hardware ... i.e ask ourselves is this a common platform worth blocking for? and decide based on that (like we do now for hardware specific bugs). -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Re: How to interpret F18 Blocker criterion
On Sat, Nov 10, 2012 at 3:29 PM, drago01 drag...@gmail.com wrote: On Sat, Nov 10, 2012 at 5:14 AM, Jóhann B. Guðmundsson johan...@gmail.com wrote: On 11/10/2012 12:39 AM, Adam Williamson wrote: I think there's still some host/guest confusion going on, possibly. I was refereeing to Fedora as an guest in vmware,vbox,hyperv not as an host which is in context with the criteria discussion about Fedora being installed along with other OS. I considered it important that Fedora works out of the box when deployed as an guest in available virtual solutions but other people seem to praise stallman and what not fixating on open being the only way and failing to understand that people will use what works for *them* and accept other alternatives... It's kinda obvious that we cover our ground to the best of our ability with Fedora as an host where applicable ( kvm/xen ) We should not differentiate between hardware platforms and virtual machine environments i.e treat running on a guest the same as should ready running as a guest -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Re: How to interpret F18 Blocker criterion
On 11/09/2012 08:17 PM, Jóhann B. Guðmundsson wrote: Well those numbers show clear dominance in vbox and vmware on the virtualzation field amongs those users that reported their smolt data so I dont think we can ignore those numbers just like that. Really? If you're installing a virtual machine, e.g via aeolus or so, imho that doesn't get counted. In most cases, these are machines run on kvm/xen hosts. -- Matthias Runge mru...@matthias-runge.de mru...@fedoraproject.org -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Re: How to interpret F18 Blocker criterion
On Fri, Nov 9, 2012 at 7:17 PM, Adam Williamson awill...@redhat.com wrote: On Fri, 2012-11-09 at 16:14 -0500, Josh Boyer wrote: On Fri, Nov 9, 2012 at 3:49 PM, Jóhann B. Guðmundsson johan...@gmail.com wrote: On 11/09/2012 08:34 PM, Josh Boyer wrote: Maybe you're talking about running Fedora as a vbox or vmware guest on some other OS? Yup those are the use cases I'm concern about as in users running other OS and installing Fedora as an virtualzation guest in that OS. ( like Robyn pointed out with Vbox as in people who do dev-type work on macs ) Eh. There's certainly bugs in those cases too, because people install the 'guest' drivers to share the host FS and such, or because the implementation of the hypervisor is just broken. So like I said, I'm not really thrilled about that case either. However, I will admit it is a more difficult case to call because at least they're trying to use Linux in some form. I just don't think, from a criteria perspective, that it's fair to compare it to dual boot. You might want to read back in the thread to a post from Kamil in response to me. I think we have a plausible way to go here, where we write a criterion which says something like 'There must be no issues in the installed system which prevent it from running as a guest on a VirtualBox host' (roughly - just the idea, not final wording). The point would be to only require that _we don't screw anything up_, not to say definitively that 'the release must work as a VBox guest', as we do for KVM. That gives us a get-out clause in the case where VBox itself is busted upstream, which we don't want to block for; so long as everything on the Fedora side was in order we'd be okay. Figuring out if it's vbox (or vmware or whatever) can take quite a bit of time. If this were to happen, someone would really need to step up to drive it and own it. That way we could have a test case for running Fedora as a VBox guest, and we could run it as part as validation, and if we ran into problems we'd figure out whether they were Fedora-side or VBox-side, and if they were Fedora-side they'd be blockers, but if they were VBox-side they wouldn't. Sensible? I'm not sold on it at all, but it's not completely insane. I'd rather see it more as a testcase we run but don't block on. If it works, excellent. If it doesn't, we don't spend any time on it until all of the other actual criteria are fixed. My concern on making it an official criteria is three-fold. 1) It's making something Fedora does not build, provide, or have any influence on part of our release process. Doubly so if you're going down the test it using Windows or OS X as a host route. I'm personally not thrilled at all about adding such dependencies as criteria at the moment. I also think if you're running it using a Linux host, then there are other options we already support that do just fine... 2) The testing and validation takes time and people. We seem to have problems coming up with both of those already. Debugging issues takes both of those, plus knowledge about both the HV in question and the area in Fedora that is having problems (which is often kernel). 3) The more criteria we add, the longer checks take. Maybe we already have testcases that are run but are not criteria. I honestly have no idea. If we do, I think that would be a better fit than trying to put some kind of weight behind Fedora as a guest in these cases. josh -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Re: How to interpret F18 Blocker criterion
On 2012-11-10 9:36, Josh Boyer wrote: 1) It's making something Fedora does not build, provide, or have any influence on part of our release process. Doubly so if you're going down the test it using Windows or OS X as a host route. I'm personally not thrilled at all about adding such dependencies as criteria at the moment. I also think if you're running it using a Linux host, then there are other options we already support that do just fine... As others have pointed out, this is really rather a matter of perception. It's perfectly reasonable to consider a given virtualization system as a hardware platform on which Fedora ought to be able to run - just like any random box from Dell or HP, except that we know for a fact that millions of each of these boxes has been 'sold'. We don't build or provide laptops, either, after all. :) I suggest that your use of the plural 'options' there is somewhat optimistic. As things stand we nominally support two 'options' - KVM and Xen. Both of these have significant limitations. Xen in itself is, let's face it, not popular. Especially not popular for desktop virt. To a rough approximation, no-one uses it for that. KVM does not work on Windows hosts, which obviously shuts out a large chunk of our potential user base. And again, to be blunt, it is not very popular for casual desktop virt (by which I mean just enthusiast end users running single-system virt to try out multiple OSes). By a weird coincidence, a rather handy reference for this happened to appear just yesterday: http://ask.slashdot.org/story/12/11/09/2226249/ask-slashdot-which-virtual-machine-software-for-a-beginner There are several replies that are positive about KVM, which is great, but the general consensus is that it's a 'second step' to be used for big grown up purposes, once you've grasped the basics using VMware or VBox. Whether we agree with that or not, that's the perception that's out there: KVM's a great technology, but it's for expert server virtualization use, not casual desktop virt use. Still, it is nice to see how positive people generally are about it as a technology. The KVM stack works well on Fedora / RHEL and (so I've heard) reasonably well on Ubuntu. I don't know if it's widely used or supported on other distributions, or even necessarily packaged for them. It definitely is not an option on Windows or OS X. 2) The testing and validation takes time and people. We seem to have problems coming up with both of those already. Debugging issues takes both of those, plus knowledge about both the HV in question and the area in Fedora that is having problems (which is often kernel). 3) The more criteria we add, the longer checks take. These are all true, of course, but equally, true of any proposal. It's a balance we always must keep in mind. Maybe we already have testcases that are run but are not criteria. I honestly have no idea. If we do, I think that would be a better fit than trying to put some kind of weight behind Fedora as a guest in these cases. We do, and that's a plausible outcome. But I think those pushing for a stronger approach than this are making a decent case. It's at least worth considering if our 'we don't care about VBox' stance may be hurting more than we had thought, and considering making more of a distinction between 'we don't care about using Fedora as a VBox host' and 'we rather do care about making sure Fedora works as a VBox guest, as best we can'. -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | identi.ca: adamwfedora http://www.happyassassin.net -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Re: How to interpret F18 Blocker criterion
This is starting to get off topic but: All of the critical accelerated drivers for Linux guests hosted by newer versions of VMware are in the main Linux and X.org distributions. The past few Fedora releases have included them. While Fedora may not officially support it, I have every Fedora version back to 14 on my VMware server. My Fedora 18 VM is using VMXNET3, Paravirtualized SCSI, VMware graphics/mouse support, etc. with nothing custom installed. For those who want full integration, it should be possible to build open-vm-tools without modules and in a manner which does not recompile things already in Fedora. But if such a trimmed version would be accepted is a discussion for another mailing list. In terms of criteria, it's a question of how important we consider the VMware components; one could argue that Fedora is always dependent on the host UEFI system or BIOS. --- SJG On Fri, Nov 9, 2012 at 11:14 PM, Jóhann B. Guðmundsson johan...@gmail.com wrote: On 11/10/2012 12:39 AM, Adam Williamson wrote: I think there's still some host/guest confusion going on, possibly. I was refereeing to Fedora as an guest in vmware,vbox,hyperv not as an host which is in context with the criteria discussion about Fedora being installed along with other OS. I considered it important that Fedora works out of the box when deployed as an guest in available virtual solutions but other people seem to praise stallman and what not fixating on open being the only way and failing to understand that people will use what works for *them* and accept other alternatives... It's kinda obvious that we cover our ground to the best of our ability with Fedora as an host where applicable ( kvm/xen ) JBG -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.**org/mailman/listinfo/testhttps://admin.fedoraproject.org/mailman/listinfo/test -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Re: How to interpret F18 Blocker criterion
On 11/09/2012 07:49 AM, Matthias Runge wrote: On 11/09/2012 01:01 AM, Jóhann B. Guðmundsson wrote: In today's age it's become more common to just run GNU/Linux in a vm since more or less all hw you buy this day has a virtual capable cpu instead of jumping through the partitioning hoops and loose the warranty and support while you are at it and yeah one of the fundamental things users like and have to do is to upgrade their computers and devices firmware and even now in the 21 century it cant be done in GNU/Linux with an ease... Do I understand you right, that you're suggesting to run Linux in a vm instead of real hardware? Because it's the 21st century and we would loose warranty? N!, right? If I was asked I would actual respond that way if it voids people warranty or OS support. If those have expired then it's an whole different ball game... We definitely need to ensure, Fedora runs quite well as dual boot installation. I was saying today it's more common that people use vm ( In both direction linux in vm on windows and windows in vm on linux ) instead of dualbooting. But as has been pointed out why aren't we testing and ensuring that Fedora runs well in vmware,hyperv and virtualbox since we ensure it works well being dualbooted alongside windows? JBG -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Re: How to interpret F18 Blocker criterion
On 11/09/2012 09:49 AM, Jóhann B. Guðmundsson wrote: But as has been pointed out why aren't we testing and ensuring that Fedora runs well in vmware,hyperv and virtualbox since we ensure it works well being dualbooted alongside windows? JBG OK, agreed. It seems common, to run Fedora also in any kind of virtualization environment. So, we're also interested in a good user experience there (whatever this may include). But: Which environments do we take into account? Carry this to extremes: We also need to look at cloud infrastructure envs, which are a special case of virtualization -- Matthias Runge mru...@matthias-runge.de mru...@fedoraproject.org -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Re: How to interpret F18 Blocker criterion
On 11/09/2012 09:01 AM, Matthias Runge wrote: On 11/09/2012 09:49 AM, Jóhann B. Guðmundsson wrote: But as has been pointed out why aren't we testing and ensuring that Fedora runs well in vmware,hyperv and virtualbox since we ensure it works well being dualbooted alongside windows? JBG OK, agreed. It seems common, to run Fedora also in any kind of virtualization environment. So, we're also interested in a good user experience there (whatever this may include). But: Which environments do we take into account? Carry this to extremes: We also need to look at cloud infrastructure envs, which are a special case of virtualization The cloud community seems to be taking care of ensuring that Fedora works in various cloud environments ( which is good ) so I dont think that's something we have to worry about. What worries me more is the *mixed* signal we keep sending both in criteria and on blocker bug meetings and that's something I feel we need to fix. JBG -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Re: How to interpret F18 Blocker criterion
On Fri, Nov 09, 2012 at 09:31:47AM +, Jóhann B. Guðmundsson wrote: But: Which environments do we take into account? Carry this to extremes: We also need to look at cloud infrastructure envs, which are a special case of virtualization The cloud community seems to be taking care of ensuring that Fedora works in various cloud environments ( which is good ) so I dont think that's something we have to worry about. I hope the QA team keeps a _little_ bit of worry about it! -- Matthew Miller ☁☁☁ Fedora Cloud Architect ☁☁☁ mat...@fedoraproject.org -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Re: How to interpret F18 Blocker criterion
On 11/09/2012 01:36 PM, Matthew Miller wrote: On Fri, Nov 09, 2012 at 09:31:47AM +, Jóhann B. Guðmundsson wrote: But: Which environments do we take into account? Carry this to extremes: We also need to look at cloud infrastructure envs, which are a special case of virtualization The cloud community seems to be taking care of ensuring that Fedora works in various cloud environments ( which is good ) so I dont think that's something we have to worry about. I hope the QA team keeps a _little_ bit of worry about it! afaik we dont have any criteria that specifically deals with cloud bits JBG -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Re: How to interpret F18 Blocker criterion
On Fri, Nov 09, 2012 at 03:04:48PM +, Jóhann B. Guðmundsson wrote: afaik we dont have any criteria that specifically deals with cloud bits Final criterion #13. -- Matthew Miller ☁☁☁ Fedora Cloud Architect ☁☁☁ mat...@fedoraproject.org -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Re: How to interpret F18 Blocker criterion
On 11/09/2012 03:08 PM, Matthew Miller wrote: On Fri, Nov 09, 2012 at 03:04:48PM +, Jóhann B. Guðmundsson wrote: afaik we dont have any criteria that specifically deals with cloud bits Final criterion #13. Interesting which cloud access does QA have to actually test this stuff? Btw last time I check the cloud solution being deployed rank this... 1.VMware 2 Xen 3.KVM 4.HyperV So that criteria only cover Xen but not the most used and deployed cloud solution JBG -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Re: How to interpret F18 Blocker criterion
On Fri, Nov 09, 2012 at 03:31:23PM +, Jóhann B. Guðmundsson wrote: Btw last time I check the cloud solution being deployed rank this... Where were you checking? 1.VMware 2 Xen 3.KVM 4.HyperV These are virtualization technologies, which are fundamental to cloud but not in themselves cloud solutions. So that criteria only cover Xen but not the most used and deployed cloud solution Amazon EC2 is Xen-based. Rackspace uses KVM. (OpenStack.) -- Matthew Miller ☁☁☁ Fedora Cloud Architect ☁☁☁ mat...@fedoraproject.org -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Re: How to interpret F18 Blocker criterion
On 11/09/2012 03:52 PM, Matthew Miller wrote: On Fri, Nov 09, 2012 at 03:31:23PM +, Jóhann B. Guðmundsson wrote: Btw last time I check the cloud solution being deployed rank this... Where were you checking? Inhouse Gartner document which seems to be inline with the recent cloud survey from zenoss 1.VMware 2 Xen 3.KVM 4.HyperV These are virtualization technologies, which are fundamental to cloud but not in themselves cloud solutions. We are talking about testing the virtualzation technologies not cloud solution or their providers So that criteria only cover Xen but not the most used and deployed cloud solution Amazon EC2 is Xen-based. Rackspace uses KVM. (OpenStack.) These are cloud providers using cloud solution on top of the virtualization technologies and our criteria should only cover running fedora as an guests and hosts ( server ) where applicable ( guest in vmware,xen,kvm,hyperv and server for kvm,xen ). JBG -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Re: How to interpret F18 Blocker criterion
On Fri, Nov 09, 2012 at 08:49:19AM +, Jóhann B. Guðmundsson wrote: I was saying today it's more common that people use vm ( In both direction linux in vm on windows and windows in vm on linux ) instead of dualbooting. Just out of curiosity. Do you have some real data to back up this claim or this is one of those made-up statistical statements based on an negligible sample and wishful thinking? From what a limited examples I have seen I would say that vm use is nearly non-existent in a general population of Linux users but I am not trying to affirm in public that this is typical. Michal -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Re: How to interpret F18 Blocker criterion
On 11/09/2012 05:30 PM, Michal Jaegermann wrote: On Fri, Nov 09, 2012 at 08:49:19AM +, Jóhann B. Guðmundsson wrote: I was saying today it's more common that people use vm ( In both direction linux in vm on windows and windows in vm on linux ) instead of dualbooting. Just out of curiosity. Do you have some real data to back up this claim or this is one of those made-up statistical statements based on an negligible sample and wishful thinking? From what a limited examples I have seen I would say that vm use is nearly non-existent in a general population of Linux users but I am not trying to affirm in public that this is typical. Look at the top model section of [1] Virtual vs HW Virtual box 12723 + VMware 9990 + Parallels Virtual Platform, Bochs ( KVM ) 773 and ( xen I believe ) 546 = 24032 vm ( of what I can identify as virtual solution out of it dont know the output from dmidecode on hyperv ) With VB and WMware only ( which can be considered running on Windows ) = 22713 vm which are clearly dominating there on the top 1. http://smolt.fedoraproject.org/static/stats/stats.html -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Re: How to interpret F18 Blocker criterion
On Fri, Nov 09, 2012 at 06:16:24PM +, Jóhann B. Guðmundsson wrote: On 11/09/2012 05:30 PM, Michal Jaegermann wrote: On Fri, Nov 09, 2012 at 08:49:19AM +, Jóhann B. Guðmundsson wrote: I was saying today it's more common that people use vm ( In both direction linux in vm on windows and windows in vm on linux ) instead of dualbooting. Just out of curiosity. Do you have some real data to back up this claim Look at the top model section of [1] Virtual vs HW ... 1. http://smolt.fedoraproject.org/static/stats/stats.html You think that smolt data are representative? I have serious doubts due to a self-selection nature of these submissions; but at least these are some numbers. Michal -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Re: How to interpret F18 Blocker criterion
On 11/09/2012 06:40 PM, Michal Jaegermann wrote: On Fri, Nov 09, 2012 at 06:16:24PM +, Jóhann B. Guðmundsson wrote: On 11/09/2012 05:30 PM, Michal Jaegermann wrote: On Fri, Nov 09, 2012 at 08:49:19AM +, Jóhann B. Guðmundsson wrote: I was saying today it's more common that people use vm ( In both direction linux in vm on windows and windows in vm on linux ) instead of dualbooting. Just out of curiosity. Do you have some real data to back up this claim Look at the top model section of [1] Virtual vs HW ... 1. http://smolt.fedoraproject.org/static/stats/stats.html You think that smolt data are representative? I have serious doubts due to a self-selection nature of these submissions; but at least these are some numbers. It's the only numbers we have and the accuracy of them is debatable for instance you cant see how many % of total hw install are dualboot installs or how many virtualbox are running on windows etc... But there is certainly one thing we can say with these numbers that we should most definitely add a criteria surrounding vbox and vmware usage... JBG -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Re: How to interpret F18 Blocker criterion
Smolt is also being retired: https://fedoraproject.org/wiki/Smolt_retirement The stats also have not been updated in quite a while. I'd take any data from smolt with a block of salt. kevin signature.asc Description: PGP signature -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Re: How to interpret F18 Blocker criterion
On 11/09/2012 07:14 PM, Kevin Fenzi wrote: Smolt is also being retired: https://fedoraproject.org/wiki/Smolt_retirement The stats also have not been updated in quite a while. I'd take any data from smolt with a block of salt. Well those numbers show clear dominance in vbox and vmware on the virtualzation field amongs those users that reported their smolt data so I dont think we can ignore those numbers just like that. -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Re: How to interpret F18 Blocker criterion
On Fri, Nov 9, 2012 at 2:17 PM, Jóhann B. Guðmundsson johan...@gmail.com wrote: On 11/09/2012 07:14 PM, Kevin Fenzi wrote: Smolt is also being retired: https://fedoraproject.org/wiki/Smolt_retirement The stats also have not been updated in quite a while. I'd take any data from smolt with a block of salt. Well those numbers show clear dominance in vbox and vmware on the virtualzation field amongs those users that reported their smolt data so I dont think we can ignore those numbers just like that. Yes we can. We don't support VMWare or VBox. We can ignore anything we don't support as much as we want. josh -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Re: How to interpret F18 Blocker criterion
On 11/09/2012 07:24 PM, Josh Boyer wrote: On Fri, Nov 9, 2012 at 2:17 PM, Jóhann B. Guðmundsson johan...@gmail.com wrote: On 11/09/2012 07:14 PM, Kevin Fenzi wrote: Smolt is also being retired: https://fedoraproject.org/wiki/Smolt_retirement The stats also have not been updated in quite a while. I'd take any data from smolt with a block of salt. Well those numbers show clear dominance in vbox and vmware on the virtualzation field amongs those users that reported their smolt data so I dont think we can ignore those numbers just like that. Yes we can. We don't support VMWare or VBox. We can ignore anything we don't support as much as we want. Yet we have criteria is specifically tailored at dual booting along proprietary operating system on proprietary filesystem ( thus arguably support it ) which can block our own release if not fulfilled. What's your take on that since you are so opposed to us adding a criteria that cover vbox,vmware which atleast arguably is equally being used among our userbase? JBG -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Re: How to interpret F18 Blocker criterion
On Fri, Nov 9, 2012 at 2:37 PM, Jóhann B. Guðmundsson johan...@gmail.com wrote: On 11/09/2012 07:24 PM, Josh Boyer wrote: On Fri, Nov 9, 2012 at 2:17 PM, Jóhann B. Guðmundsson johan...@gmail.com wrote: On 11/09/2012 07:14 PM, Kevin Fenzi wrote: Smolt is also being retired: https://fedoraproject.org/wiki/Smolt_retirement The stats also have not been updated in quite a while. I'd take any data from smolt with a block of salt. Well those numbers show clear dominance in vbox and vmware on the virtualzation field amongs those users that reported their smolt data so I dont think we can ignore those numbers just like that. Yes we can. We don't support VMWare or VBox. We can ignore anything we don't support as much as we want. Yet we have criteria is specifically tailored at dual booting along proprietary operating system on proprietary filesystem ( thus arguably support it ) which can block our own release if not fulfilled. What's your take on that since you are so opposed to us adding a criteria that cover vbox,vmware which atleast arguably is equally being used among our userbase? My personal take is that Windows doesn't try and load things into the Linux kernel, or otherwise disrupt the installed Fedora OS so I don't personally care. As for being popular, I have no doubt they are. So are the nvidia and flgrx drivers, and mp3 support, and a bunch of other things we don't support as well. All of that may be the best stuff since sliced bread and awesome for our users, but it all runs within the Fedora OS and comparing it to something completely outside of it seems odd. Again, this is all my personal opinion which doesn't matter at all. josh -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Re: How to interpret F18 Blocker criterion
On 11/09/2012 12:37 PM, Jóhann B. Guðmundsson wrote: On 11/09/2012 07:24 PM, Josh Boyer wrote: On Fri, Nov 9, 2012 at 2:17 PM, Jóhann B. Guðmundsson johan...@gmail.com wrote: On 11/09/2012 07:14 PM, Kevin Fenzi wrote: Smolt is also being retired: https://fedoraproject.org/wiki/Smolt_retirement The stats also have not been updated in quite a while. I'd take any data from smolt with a block of salt. Well those numbers show clear dominance in vbox and vmware on the virtualzation field amongs those users that reported their smolt data so I dont think we can ignore those numbers just like that. Yes we can. We don't support VMWare or VBox. We can ignore anything we don't support as much as we want. Yet we have criteria is specifically tailored at dual booting along proprietary operating system on proprietary filesystem ( thus arguably support it ) which can block our own release if not fulfilled. What's your take on that since you are so opposed to us adding a criteria that cover vbox,vmware which atleast arguably is equally being used among our userbase? Sticking strictly to the statistics point - I tend to agree at least on Vbox - esp. for all the people who do dev-type work on macs, etc. VMware is a bit harder to see - obviously they're the huge elephant in the virt space but I would tend to think that people using KVM or Xen would be more likely to use Fedora/care about open source and that we'd get more value out of testing for that scenario than VMWare. But if the (albeit old) stats reflect otherwise it might be worth considering, though the ability to actually test that way isn't cheap and i fear that we'd have pretty low participation in it. JBG -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Re: How to interpret F18 Blocker criterion
On 11/09/2012 07:56 PM, Josh Boyer wrote: My personal take is that Windows doesn't try and load things into the Linux kernel, or otherwise disrupt the installed Fedora OS so I don't personally care. And vbox vmware and hyperv do? What about ( citrix ) xen in that regard as well? Actually network out of the box in F17 guest in hyperv does not work out of the box ( but work on the triple U distro ) hence I dont think we need to worry to much that users are using/deploying fedora in hyperv... JB. -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Re: How to interpret F18 Blocker criterion
On Fri, Nov 9, 2012 at 3:16 PM, Jóhann B. Guðmundsson johan...@gmail.com wrote: On 11/09/2012 07:56 PM, Josh Boyer wrote: My personal take is that Windows doesn't try and load things into the Linux kernel, or otherwise disrupt the installed Fedora OS so I don't personally care. And vbox vmware and hyperv do? Yes. vbox and vmware load out-of-tree kernel modules. We get many, many reports in the kernel about things being broken when they're loaded. Hyperv modules are already provided as part of the Fedora kernel because their development team worked diligently on getting them into the upstream kernel. Maybe you're talking about running Fedora as a vbox or vmware guest on some other OS? E.g. Windows as the host OS running Fedora within vbox. We've seen reports where vbox has screwed up it's machine emulation and caused Fedora kernels to crash in the guest too. I'm really not thrilled at all about that case either, but I don't really have a formed opinion about it. What about ( citrix ) xen in that regard as well? What about them? Xen is already a supported target and has release criteria against it working. And as someone already noted somewhere else, Amazon EC2 is all Xen and the cloud people are all about taht. (I'm using the word supported here very loosely. We are lucky to have upstream Xen people looking at most of the issues that pop up around it.) josh -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Re: How to interpret F18 Blocker criterion
On 11/09/2012 08:34 PM, Josh Boyer wrote: Maybe you're talking about running Fedora as a vbox or vmware guest on some other OS? Yup those are the use cases I'm concern about as in users running other OS and installing Fedora as an virtualzation guest in that OS. ( like Robyn pointed out with Vbox as in people who do dev-type work on macs ) JBG -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Re: How to interpret F18 Blocker criterion
On Fri, Nov 9, 2012 at 3:49 PM, Jóhann B. Guðmundsson johan...@gmail.com wrote: On 11/09/2012 08:34 PM, Josh Boyer wrote: Maybe you're talking about running Fedora as a vbox or vmware guest on some other OS? Yup those are the use cases I'm concern about as in users running other OS and installing Fedora as an virtualzation guest in that OS. ( like Robyn pointed out with Vbox as in people who do dev-type work on macs ) Eh. There's certainly bugs in those cases too, because people install the 'guest' drivers to share the host FS and such, or because the implementation of the hypervisor is just broken. So like I said, I'm not really thrilled about that case either. However, I will admit it is a more difficult case to call because at least they're trying to use Linux in some form. I just don't think, from a criteria perspective, that it's fair to compare it to dual boot. josh -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Re: How to interpret F18 Blocker criterion
On 11/09/2012 01:49 PM, Jóhann B. Guðmundsson wrote: On 11/09/2012 08:34 PM, Josh Boyer wrote: Maybe you're talking about running Fedora as a vbox or vmware guest on some other OS? Yup those are the use cases I'm concern about as in users running other OS and installing Fedora as an virtualzation guest in that OS. ( like Robyn pointed out with Vbox as in people who do dev-type work on macs ) Indeed, those are the use cases I was speaking of as well. :) JBG -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Re: How to interpret F18 Blocker criterion
On Fri, Nov 09, 2012 at 06:58:07PM +, Jóhann B. Guðmundsson wrote: On 11/09/2012 06:40 PM, Michal Jaegermann wrote: On Fri, Nov 09, 2012 at 06:16:24PM +, Jóhann B. Guðmundsson wrote: On 11/09/2012 05:30 PM, Michal Jaegermann wrote: On Fri, Nov 09, 2012 at 08:49:19AM +, Jóhann B. Guðmundsson wrote: I was saying today it's more common that people use vm ( In both direction linux in vm on windows and windows in vm on linux ) instead of dualbooting. Just out of curiosity. Do you have some real data to back up this claim Look at the top model section of [1] Virtual vs HW ... 1. http://smolt.fedoraproject.org/static/stats/stats.html You think that smolt data are representative? I have serious doubts due to a self-selection nature of these submissions; but at least these are some numbers. It's the only numbers we have and the accuracy of them is debatable ... But there is certainly one thing we can say with these numbers that we should most definitely add a criteria surrounding vbox and vmware usage... Vbox and vmware require external kernel modules. This detail alone immediately limits an audience for these solutions to a rather narrow circle. Yes, I appreciate that you do not have other numbers but I would refrain from ascribing too much significance to these. Michal -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Re: How to interpret F18 Blocker criterion
On 11/09/2012 10:56 PM, Michal Jaegermann wrote: Vbox and vmware require external kernel modules. This detail alone immediately limits an audience for these solutions to a rather narrow circle How so? JBG -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Re: How to interpret F18 Blocker criterion
On 11/09/2012 10:56 PM, Michal Jaegermann wrote: Vbox and vmware require external kernel modules. Can you please provide a link to where it says you need to install external kernel modules because there is no mention of a such things here [1] JBG 1.http://kb.vmware.com/selfservice/microsites/search.do?language=en_UScmd=displayKCexternalId=2030588http://kb.vmware.com/selfservice/microsites/search.do?language=en_UScmd=displayKCexternalId=2030588 -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Re: How to interpret F18 Blocker criterion
On Fri, 2012-11-09 at 10:01 +0100, Matthias Runge wrote: On 11/09/2012 09:49 AM, Jóhann B. Guðmundsson wrote: But as has been pointed out why aren't we testing and ensuring that Fedora runs well in vmware,hyperv and virtualbox since we ensure it works well being dualbooted alongside windows? JBG OK, agreed. It seems common, to run Fedora also in any kind of virtualization environment. So, we're also interested in a good user experience there (whatever this may include). But: Which environments do we take into account? Carry this to extremes: We also need to look at cloud infrastructure envs, which are a special case of virtualization The fact that EC2 runs on Xen is actually one of the main reasons we added a criterion for Xen a couple of cycles back. I think Johann and Kamil make a decent point that we might want to continue expanding our support/testing in the direction of more diverse virt environments than just Fedora's 'native' virt stack. -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | identi.ca: adamwfedora http://www.happyassassin.net -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Re: How to interpret F18 Blocker criterion
On Fri, 2012-11-09 at 13:06 -0700, Robyn Bergeron wrote: On 11/09/2012 12:37 PM, Jóhann B. Guðmundsson wrote: On 11/09/2012 07:24 PM, Josh Boyer wrote: On Fri, Nov 9, 2012 at 2:17 PM, Jóhann B. Guðmundsson johan...@gmail.com wrote: On 11/09/2012 07:14 PM, Kevin Fenzi wrote: Smolt is also being retired: https://fedoraproject.org/wiki/Smolt_retirement The stats also have not been updated in quite a while. I'd take any data from smolt with a block of salt. Well those numbers show clear dominance in vbox and vmware on the virtualzation field amongs those users that reported their smolt data so I dont think we can ignore those numbers just like that. Yes we can. We don't support VMWare or VBox. We can ignore anything we don't support as much as we want. Yet we have criteria is specifically tailored at dual booting along proprietary operating system on proprietary filesystem ( thus arguably support it ) which can block our own release if not fulfilled. What's your take on that since you are so opposed to us adding a criteria that cover vbox,vmware which atleast arguably is equally being used among our userbase? Sticking strictly to the statistics point - I tend to agree at least on Vbox - esp. for all the people who do dev-type work on macs, etc. VMware is a bit harder to see - obviously they're the huge elephant in the virt space but I would tend to think that people using KVM or Xen would be more likely to use Fedora/care about open source and that we'd get more value out of testing for that scenario than VMWare. But if the (albeit old) stats reflect otherwise it might be worth considering, though the ability to actually test that way isn't cheap and i fear that we'd have pretty low participation in it. I think the 'old' thing is pretty significant here; for quite a while VMware was about the _only_ viable virt option. I certainly used VMware-player for quite a long time just because there wasn't anything else. I think it's certainly plausible that the smolt stats have a heavy skew to VMware based on the time ranges they cover and don't cover. It would be nice if we had better numbers, but lots of things would be nice :/ -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | identi.ca: adamwfedora http://www.happyassassin.net -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Re: How to interpret F18 Blocker criterion
On Fri, 2012-11-09 at 16:14 -0500, Josh Boyer wrote: On Fri, Nov 9, 2012 at 3:49 PM, Jóhann B. Guðmundsson johan...@gmail.com wrote: On 11/09/2012 08:34 PM, Josh Boyer wrote: Maybe you're talking about running Fedora as a vbox or vmware guest on some other OS? Yup those are the use cases I'm concern about as in users running other OS and installing Fedora as an virtualzation guest in that OS. ( like Robyn pointed out with Vbox as in people who do dev-type work on macs ) Eh. There's certainly bugs in those cases too, because people install the 'guest' drivers to share the host FS and such, or because the implementation of the hypervisor is just broken. So like I said, I'm not really thrilled about that case either. However, I will admit it is a more difficult case to call because at least they're trying to use Linux in some form. I just don't think, from a criteria perspective, that it's fair to compare it to dual boot. You might want to read back in the thread to a post from Kamil in response to me. I think we have a plausible way to go here, where we write a criterion which says something like 'There must be no issues in the installed system which prevent it from running as a guest on a VirtualBox host' (roughly - just the idea, not final wording). The point would be to only require that _we don't screw anything up_, not to say definitively that 'the release must work as a VBox guest', as we do for KVM. That gives us a get-out clause in the case where VBox itself is busted upstream, which we don't want to block for; so long as everything on the Fedora side was in order we'd be okay. That way we could have a test case for running Fedora as a VBox guest, and we could run it as part as validation, and if we ran into problems we'd figure out whether they were Fedora-side or VBox-side, and if they were Fedora-side they'd be blockers, but if they were VBox-side they wouldn't. Sensible? -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | identi.ca: adamwfedora http://www.happyassassin.net -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Re: How to interpret F18 Blocker criterion
On Fri, Nov 09, 2012 at 11:17:16PM +, Jóhann B. Guðmundsson wrote: On 11/09/2012 10:56 PM, Michal Jaegermann wrote: Vbox and vmware require external kernel modules. This detail alone immediately limits an audience for these solutions to a rather narrow circle How so? Is this is a serious question? If yes then we definitely live in different realities. Michal -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Re: How to interpret F18 Blocker criterion
On Fri, Nov 09, 2012 at 11:24:54PM +, Jóhann B. Guðmundsson wrote: On 11/09/2012 10:56 PM, Michal Jaegermann wrote: Vbox and vmware require external kernel modules. Can you please provide a link to where it says you need to install external kernel modules Somebody said so earlier in this thread and I took it for a face value. Maybe I misunderstood something? Michal -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Re: How to interpret F18 Blocker criterion
On Fri, 2012-11-09 at 17:21 -0700, Michal Jaegermann wrote: On Fri, Nov 09, 2012 at 11:24:54PM +, Jóhann B. Guðmundsson wrote: On 11/09/2012 10:56 PM, Michal Jaegermann wrote: Vbox and vmware require external kernel modules. Can you please provide a link to where it says you need to install external kernel modules Somebody said so earlier in this thread and I took it for a face value. Maybe I misunderstood something? I think there's still some host/guest confusion going on, possibly. VBox does need out-of-tree kernel modules when run as a host on Linux. Some Linux distros package these via kmods or dkms or whatever. I'm not sure if RPMFusion packages them for Fedora. If your distro does not have a packaged version of RPMFusion with the kernel modules included, you have to use a little installer script that comes along with VBox to install them. When running as a guest in VBox, I don't believe Linux _needs_ any out of tree kernel modules to function, though I think there may be optional 'guest drivers' like most virt systems have, to improve the efficiency of graphics and networking and provide for file transfer and clipboarding between host and guest and so on. I think you are a bit off-base when you say This detail alone immediately limits an audience for these solutions to a rather narrow circle, though, even considering the host case. It's not very difficult to install the modules to use VBox as a host even on Fedora, and on Windows, Mac or many other distros, you can install VBox with the usual installer system, you don't have to manually fiddle about with the kernel modules. I know from experience on these lists and on the forums that many users do it. I'd say VBox is probably the most popular virtualization environment for the 'desktop enthusiast' user group, who use a simple single-system virt system to test out OSes and distributions - a completely different use case from the 'enterprise virt' user who is running multiple machines on a dedicated host. As I mentioned up-thread, many users cite VBox's ease of use and features like 3D passthrough as a reason to use it over virt-manager/libvirt/kvm. Just go to the Fedora or Ubuntu forums and look how many people ask for help with, or mention in passing that they are using, VBox. It's quite a lot. And rather a lot more than mention virt-manager. -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | identi.ca: adamwfedora http://www.happyassassin.net -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Re: How to interpret F18 Blocker criterion
On Fri, Nov 09, 2012 at 04:39:53PM -0800, Adam Williamson wrote: VBox does need out-of-tree kernel modules when run as a host on Linux. Some Linux distros package these via kmods or dkms or whatever. I'm not sure if RPMFusion packages them for Fedora. If your distro does not have a packaged version of RPMFusion with the kernel modules included, you have to use a little installer script that comes along with VBox to install them. I dunno about VMware, but if you run a Linux distribution without vmware-tools installed, your VMware administrator *will* yell at you. -- Matthew Miller ☁☁☁ Fedora Cloud Architect ☁☁☁ mat...@fedoraproject.org -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Re: How to interpret F18 Blocker criterion
On 11/10/2012 12:39 AM, Adam Williamson wrote: I think there's still some host/guest confusion going on, possibly. I was refereeing to Fedora as an guest in vmware,vbox,hyperv not as an host which is in context with the criteria discussion about Fedora being installed along with other OS. I considered it important that Fedora works out of the box when deployed as an guest in available virtual solutions but other people seem to praise stallman and what not fixating on open being the only way and failing to understand that people will use what works for *them* and accept other alternatives... It's kinda obvious that we cover our ground to the best of our ability with Fedora as an host where applicable ( kvm/xen ) JBG -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Re: How to interpret F18 Blocker criterion
On Sat, 2012-11-10 at 04:14 +, Jóhann B. Guðmundsson wrote: On 11/10/2012 12:39 AM, Adam Williamson wrote: I think there's still some host/guest confusion going on, possibly. I was refereeing to Fedora as an guest in vmware,vbox,hyperv not as an host which is in context with the criteria discussion about Fedora being installed along with other OS. Right - that was the confusion I referred to. I think you were talking about guest, while others might still have been thinking about host. -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | identi.ca: adamwfedora http://www.happyassassin.net -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Re: How to interpret F18 Blocker criterion
I actually agree that your argument for supporting install as a VBox *guest* makes a lot of sense, really, it's a pretty common use case. It's probably true that we've applied the 'we don't support VBox' mantra too easily to the VBox guest case, where it doesn't entirely apply. It's more about using Fedora as a VBox *host*. I wouldn't be opposed to proposals to test or even block on the VBox guest case, as it is a common case. Though we'd need to consider the problem where it breaks because of something in upstream VBox, which we can't control; that might be a deal-breaker for making it a blocker. I'm very glad that you see it this way. I'd like to codify it somehow, and attach a link to this conversation, so we don't have to remember it. But I understand this is a problematic criterion, it would have to be very carefully worded. Basically, it makes sense to block the release only for VirtualBox issues that 1) are showstoppers, they prevent VB usage in a very serious way 2) are bugs in our components (e.g. graphics drivers), we can fix them and we also want to fix them (it wouldn't be a VB-specific hack). I'm not sure we want to have a criterion like that. I'd rather have it written down in a best-effort goals document. Issues related to that document would be considered blockers only when they are extremely serious, otherwise they would be just NTH. We would use common sense and developer feedback when judging it. But that goes against our current policy if it's not in the criteria, it's not a blocker. Any preferences how to deal with that? What I can do immediately is to create a new test case for VirtualBox. I'd mark it as optional for the time being. WDYT? -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Re: How to interpret F18 Blocker criterion
On Wed, 2012-11-07 at 07:51 +, Jóhann B. Guðmundsson wrote: We can still test this and installing Fedora, and arguably we should be doing that along other OS other than just Microsoft as well. We would just not have the Fedora release dependent upon the result from those tests... Really. So if it were known that Anaconda WOULD hose an existing Windows install you would be ok with releasing? Or if Anaconda simply puked and failed to install a working, booting Fedora in the presence of a Windows partition? That is what a release grade product does? And not just Windows, if Anaconda failed to do it's job and install a working Fedora without destroying any other OS install it is a serious problem. If the newly installed Fedora doesn't work it is a fail. If it causes damage beyond itself it is a disaster. Testing for and preventing such a PR disaster SHOULD be a release criteria. Failing to even test means that not only would a broken Fedora be released upon a unsuspecting world, there wouldn't even be a warning in the release notes to point to. Is it even possible to test every corner case out there in the complex world we live in? Probably not. Doesn't mean that making a respectable attempt is a bad idea. We have suffered since day one with Microsoft's refusal to admit other products exist and merrily destroy other boot loaders without so much as an I see something else in the MBR, should I overwrite it? prompt. We are supposed to be the White Hats and care about users and all that, lets live up to our own book of rules. signature.asc Description: This is a digitally signed message part -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Re: How to interpret F18 Blocker criterion
On Wed, 2012-11-07 at 11:55 +0100, Chris Murphy wrote: I actually don't understand the RHEL angle on this missing piece either. What is the use case of installing RHEL along side Windows? Really, enterprise users do this? They share a single disk with one bootloader/manager taking over another? Seems risky to me. I'd think best practices would be, at best, separate OS's on separate drives, in the case of BIOS-MBR. For UEFI-GPT it's… different. One word: laptops. Few laptops can fit a second hard drive. And you quickly learn that in the real word you had better leave Windows installed so can get tech support, download new firmware, etc. So you resize it down to minimal and put your work OS on. And if you can't do it in a couple of tries then you will probably pick a distro that can pull it off. signature.asc Description: This is a digitally signed message part -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Re: How to interpret F18 Blocker criterion
On 2012-11-08 16:28 (GMT-0600) John Morris composed: We have suffered since day one with Microsoft's refusal to admit other products exist and merrily destroy other boot loaders without so much as an I see something else in the MBR, should I overwrite it? prompt. pot -black- kettle Installing Grub to MBR never destroys another boot loader? Not! For more installations than not, Linux can be installed and booted without changing a single byte of MBR code. -- The wise are known for their understanding, and pleasant words are persuasive. Proverbs 16:21 (New Living Translation) Team OS/2 ** Reg. Linux User #211409 ** a11y rocks! Felix Miata *** http://fm.no-ip.com/ -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Re: How to interpret F18 Blocker criterion
On 11/08/2012 10:34 PM, John Morris wrote: Few laptops can fit a second hard drive. And you quickly learn that in the real word you had better leave Windows installed so can get tech support, download new firmware, etc. So you resize it down to minimal and put your work OS on. And if you can't do it in a couple of tries then you will probably pick a distro that can pull it off. In today's age it's become more common to just run GNU/Linux in a vm since more or less all hw you buy this day has a virtual capable cpu instead of jumping through the partitioning hoops and loose the warranty and support while you are at it and yeah one of the fundamental things users like and have to do is to upgrade their computers and devices firmware and even now in the 21 century it cant be done in GNU/Linux with an ease... JBG -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Re: How to interpret F18 Blocker criterion
On 11/09/2012 01:01 AM, Jóhann B. Guðmundsson wrote: In today's age it's become more common to just run GNU/Linux in a vm since more or less all hw you buy this day has a virtual capable cpu instead of jumping through the partitioning hoops and loose the warranty and support while you are at it and yeah one of the fundamental things users like and have to do is to upgrade their computers and devices firmware and even now in the 21 century it cant be done in GNU/Linux with an ease... Do I understand you right, that you're suggesting to run Linux in a vm instead of real hardware? Because it's the 21st century and we would loose warranty? N!, right? We definitely need to ensure, Fedora runs quite well as dual boot installation. -- Matthias Runge mru...@matthias-runge.de mru...@fedoraproject.org -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Re: How to interpret F18 Blocker criterion
On 11/07/2012 07:59 AM, Adam Williamson wrote: We can still test this and installing Fedora, and arguably we should be doing that along other OS other than just Microsoft as well. There's a ticket for writing some other dual boot test cases, I think. No-one's ever got around to picking it up. Feel free... We would just not have the Fedora release dependent upon the result from those tests... In practice what usually happens is I fire up the VM I keep around specifically for this purpose and do the test on the last few Final builds. Takes me about ten minutes a shot. Ah so you dont even test this on real HW as the user would be expected to do to try Fedora which was the argument you made for the criteria that's a nice one. Do you at least test all the GA supported releases of Microsoft Windows which might reside on the users machine when doing that test in a VM since HD partitioning differs between release as got mentioned earlier in this thread? In any case those in favor of continuing to do have this block the release criteria should update the test cases to cover all microsoft windows release and OEM/Vendors installs along with their rescue and or system rescue partition you know to prevent those that install Fedora along side their Microsoft Windows installs dont accidentally find themselves unable to boot their hw and are going to use the system/rescue partition to recover from it it, Then discovering our installer accidentally wiped it... Dont we have to test and add to that criteria as well the revert process encase the user does not want to use Fedora and decides to uninstall to revert his machine to it's former state before he decided to try Fedora? What happens to users support once they install Fedora along side Microsoft Windows, Do the support contracts usually cover that scenario ( as in dualbooting Microsoft with other OS'es )? JBG -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Re: How to interpret F18 Blocker criterion
On Tue, Nov 06, 2012 at 11:59:31PM -0800, Adam Williamson wrote: We would just not have the Fedora release dependent upon the result from those tests... In practice what usually happens is I fire up the VM I keep around specifically for this purpose and do the test on the last few Final builds. Takes me about ten minutes a shot. Can you test with UEFI in a VM? I ran into the problem that I couldn't dualboot with Windows 8 under UEFI (because it appears 'os-prober' can't speak EFI yet!) This was a 'bare metal' install obviously. (Bugzilla: 873207) So I think Johann does have a slight point, though he expresses most of his opinions rather bluntly :) I however would vote for keeping some minimal QA attention fixed to dual booting as I occasionaly have a use for Windows. (And running Windows in a VM is merde on these stupid 16:9 laptop screens). OT 1: Apart from the 'pain in the anaconda' bit and some slight hiccups (are there dracut changes for example?) F18 runs smoothly and beautifully. OT 2: The default install of Windows 8 is clean and smart. Much simpler and faster than fancy pants anaconda-new (but then of course Windows does not aim for all these diverse situations). Alexander -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Re: How to interpret F18 Blocker criterion
I'm most certainly for _keeping_ the criterion, and I'm not necessarily against expanding it also to MacOS, but that's about it (IMHO). J. - Original Message - From: Adam Williamson awill...@redhat.com To: For testing and quality assurance of Fedora releases test@lists.fedoraproject.org Sent: Wednesday, November 7, 2012 3:09:39 AM Subject: Re: How to interpret F18 Blocker criterion On Wed, 2012-11-07 at 00:42 +, Jóhann B. Guðmundsson wrote: On 11/07/2012 12:04 AM, drago01 wrote: That's not absurd ... that's reality. I'm perfectly well aware how absurd and real that criteria is Does anyone else agree with Johann that we should change or remove the criterion? If there's significant support for that idea I'll throw it on the meeting agenda for next week, but if no-one else thinks we should stop testing and supporting install-alongside-Windows, maybe we should just leave it there. I think the arguments on both sides have been made clearly by now. -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | identi.ca: adamwfedora http://www.happyassassin.net -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Re: How to interpret F18 Blocker criterion
I don't think there's a conflict at all. All distros work hard to dual boot with Windows successfully because that's how you get people to try Linux: i.e., it's actually a key thing to have *in order to driver our philosophy*. The current approach is that we don't care about problems with VirtualBox, with nvidia drivers, with just about _anything_ that is not included in Fedora. This test case doesn't really resonate with it. I disagree, because there's a vital difference. The dual boot case is about having Fedora - fully 'philosophy compliant' Fedora - working _alongside_ a different proprietary operating system; a configuration that's important to support for 'ideological' reasons as much as any others (see above). What we don't support is proprietary components *inside our own operating system*. I also believe that the dual-boot support with Windows is important, should be thoroughly tested, and should be in our criteria. What annoys me is your reasoning being inconsistent with our past arguments about VirtualBox. According to your explanation, VirtualBox support should be in a completely same position as dual-boot support with Windows. It does not change the Fedora platform, it just allows the project to run as a whole inside a virtualized environment. I believe it's even more important than dual-boot, because most of the newcomers don't install Fedora into dual-boot, they are scared and unsure about what might happen. They try it first in a VM, and #1 is usually VirtualBox. I come across that in all my Fedora presentations, I even _recommend_ people to use VirtualBox prior to installing Fedora into dual-boot! Yet, we don't give a damn about VirtualBox support. It's not in our criteria. We don't care much about its issues. We care a bit, but not much. Even though it's even open-source. (And it's very hard to find reasons why it's not included in Fedora, except for a single sentence here [1]). I understand there are issues that we can't fix, because VirtualBox itself would have to be modified, and it's not under our direct control. But there are many issues that we can fix, like bugs in cirrus driver etc. And still we keep telling people we don't support VirtualBox, this is not a blocker, even when it's a showstopper and we could fix it if we wanted. So if the philosophy should really be interpreted as you say, I still find inconsistencies in our approach. Not with Windows support being superfluous, but with other components being missing. [1] https://fedoraproject.org/wiki/Archive:Features/VirtualBox -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Re: How to interpret F18 Blocker criterion
On Nov 7, 2012, at 11:33 AM, Kamil Paral kpa...@redhat.com wrote: Yet, we don't give a damn about VirtualBox support. It's not in our criteria. We don't care much about its issues. We care a bit, but not much. Even though it's even open-source. I think it's a big missing piece of the puzzle for overall reducing barrier to entry problems for trying out Fedora. I actually don't understand the RHEL angle on this missing piece either. What is the use case of installing RHEL along side Windows? Really, enterprise users do this? They share a single disk with one bootloader/manager taking over another? Seems risky to me. I'd think best practices would be, at best, separate OS's on separate drives, in the case of BIOS-MBR. For UEFI-GPT it's… different. The lack of explicit VirtualBox support not only reduces the test footprint when there are problems, but I think anaconda is made a lot more complicated than it needs to be in order to support the dual-boot case JUST for Fedora? So yeah, again, what's the dual-boot use case in enterprise? So if the philosophy should really be interpreted as you say, I still find inconsistencies in our approach. Not with Windows support being superfluous, but with other components being missing. I agree. I don't think Windows support can be considered superfluous to the point that a reasonable conversation can be had to dump it as a release criteria, prior to the decision to support VirtualBox explicitly. And even then dual-boot is probably part of Fedora's demand because the developers depend on natively booting both, even if there's little enterprise use case. But there is a developer *and* enterprise use case for supporting VirtualBox. Chris Murphy -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Re: How to interpret F18 Blocker criterion
On Tue, 06 Nov 2012 12:00:09 -0800, Adam Williamson wrote: Fact is, a _lot_ of people still dual boot with Windows, because they're not sure they want to switch 100% to Linux, or they still need to run some apps on Windows, or they want to play games, or whatever. Is anyone seriously doubting it's a common and important use case? I DO NOT object to this statement, but I am just curious, whether you have any recent data supporting it. Could smolt register and collect information about this (it should be able to read grub2 configuration, shouldn't it)? Matěj -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Re: How to interpret F18 Blocker criterion
On Wed, 7 Nov 2012 11:59:49 + (UTC) Matěj Cepl mc...@redhat.com wrote: On Tue, 06 Nov 2012 12:00:09 -0800, Adam Williamson wrote: Fact is, a _lot_ of people still dual boot with Windows, because they're not sure they want to switch 100% to Linux, or they still need to run some apps on Windows, or they want to play games, or whatever. Is anyone seriously doubting it's a common and important use case? I DO NOT object to this statement, but I am just curious, whether you have any recent data supporting it. Check the I need dual-boot... posts on the user list. https://lists.fedoraproject.org/pipermail/users/2012-October/425447.html Could smolt register and collect information about this (it should be able to read grub2 configuration, shouldn't it)? Matěj Has not smolt been retired: https://fedoraproject.org/wiki/Smolt_retirement -- Regards, Frank -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Re: How to interpret F18 Blocker criterion
On Tue, 06 Nov 2012 12:00:09 -0800, Adam Williamson wrote: Fact is, a _lot_ of people still dual boot with Windows, because they're not sure they want to switch 100% to Linux, or they still need to run some apps on Windows, or they want to play games, or whatever. Is anyone seriously doubting it's a common and important use case? I DO NOT object to this statement, but I am just curious, whether you have any recent data supporting it. Could smolt register and collect information about this (it should be able to read grub2 configuration, shouldn't it)? Matěj Hey, Matěj, do we really need to discuss such obvious issues? Just ask around, in Red Hat, some students, look at some support forums, and you'll have no doubt. Loads of people dual-boot every day. The statistics could be interesting wrt to other minor OSes, like MacOS etc, but wrt Windows the answer is masses. -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Re: How to interpret F18 Blocker criterion
On 11/07/2012 01:54 PM, Kamil Paral wrote: Hey, Matěj, do we really need to discuss such obvious issues? Just ask around, in Red Hat, some students, look at some support forums, and you'll have no doubt. Loads of people dual-boot every day. The statistics could be interesting wrt to other minor OSes, like MacOS etc, but wrt Windows the answer is masses. That's not sufficient reply like Adam's gut feeling that certain graphics drivers aren't widely enough used just because he does not know anyone that's using it... The statistic is interesting compared live usb with persistant storage or vm setups for example JBG -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Re: How to interpret F18 Blocker criterion
On Wed, 2012-11-07 at 11:08 +0100, Alexander Volovics wrote: On Tue, Nov 06, 2012 at 11:59:31PM -0800, Adam Williamson wrote: We would just not have the Fedora release dependent upon the result from those tests... In practice what usually happens is I fire up the VM I keep around specifically for this purpose and do the test on the last few Final builds. Takes me about ten minutes a shot. Can you test with UEFI in a VM? I could, but I never have. I'm not sure we'd block on dualboot-alongside-UEFI-native-Windows, at least not up until now. But different now W8 is out. I ran into the problem that I couldn't dualboot with Windows 8 under UEFI (because it appears 'os-prober' can't speak EFI yet!) This was a 'bare metal' install obviously. (Bugzilla: 873207) So I think Johann does have a slight point, though he expresses most of his opinions rather bluntly :) Well, 'more testing is always better' is always a valid point, but practically not of much use. I'm happier for us to be testing dualboot with Windows a bit than to be testing it not at all. Testing it a lot would obviously be better. I however would vote for keeping some minimal QA attention fixed to dual booting as I occasionaly have a use for Windows. (And running Windows in a VM is merde on these stupid 16:9 laptop screens). OT 1: Apart from the 'pain in the anaconda' bit and some slight hiccups (are there dracut changes for example?) F18 runs smoothly and beautifully. OT 2: The default install of Windows 8 is clean and smart. Much simpler and faster than fancy pants anaconda-new (but then of course Windows does not aim for all these diverse situations). Yes, it's very easy to be clean and smart if you offer no options for partitioning, install source, or package set :) -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | identi.ca: adamwfedora http://www.happyassassin.net -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Re: How to interpret F18 Blocker criterion
On 2012-11-07 09:13 (GMT-0800) Adam Williamson composed: it's very easy to be clean and smart if you offer no options for partitioning, install source, or package set :) My only exposure to W8 was last May when I installed the beta to a system with 8 filesystems it supports, and last partition sda23. I don't remember any material difference between it and XP in having to select which partition it should install to on a text screen not unlike what the default Debian installer still used last I installed Debian. IOW, Windows' partition options are nonzero. The W8 install did leave me unable to figure out how to boot XP, so it wasn't long before I restored all the first partition's content, leaving me with no access to booting W8, which I most definitely didn't and don't miss. What a stupid UI for a PC desktop environment! -- The wise are known for their understanding, and pleasant words are persuasive. Proverbs 16:21 (New Living Translation) Team OS/2 ** Reg. Linux User #211409 ** a11y rocks! Felix Miata *** http://fm.no-ip.com/ -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Re: How to interpret F18 Blocker criterion
On Wed, 2012-11-07 at 05:33 -0500, Kamil Paral wrote: I don't think there's a conflict at all. All distros work hard to dual boot with Windows successfully because that's how you get people to try Linux: i.e., it's actually a key thing to have *in order to driver our philosophy*. The current approach is that we don't care about problems with VirtualBox, with nvidia drivers, with just about _anything_ that is not included in Fedora. This test case doesn't really resonate with it. I disagree, because there's a vital difference. The dual boot case is about having Fedora - fully 'philosophy compliant' Fedora - working _alongside_ a different proprietary operating system; a configuration that's important to support for 'ideological' reasons as much as any others (see above). What we don't support is proprietary components *inside our own operating system*. I also believe that the dual-boot support with Windows is important, should be thoroughly tested, and should be in our criteria. What annoys me is your reasoning being inconsistent with our past arguments about VirtualBox. According to your explanation, VirtualBox support should be in a completely same position as dual-boot support with Windows. It does not change the Fedora platform, it just allows the project to run as a whole inside a virtualized environment. I believe it's even more important than dual-boot, because most of the newcomers don't install Fedora into dual-boot, they are scared and unsure about what might happen. They try it first in a VM, and #1 is usually VirtualBox. I come across that in all my Fedora presentations, I even _recommend_ people to use VirtualBox prior to installing Fedora into dual-boot! Yet, we don't give a damn about VirtualBox support. It's not in our criteria. We don't care much about its issues. We care a bit, but not much. Even though it's even open-source. (And it's very hard to find reasons why it's not included in Fedora, except for a single sentence here [1]). I understand there are issues that we can't fix, because VirtualBox itself would have to be modified, and it's not under our direct control. But there are many issues that we can fix, like bugs in cirrus driver etc. And still we keep telling people we don't support VirtualBox, this is not a blocker, even when it's a showstopper and we could fix it if we wanted. So if the philosophy should really be interpreted as you say, I still find inconsistencies in our approach. Not with Windows support being superfluous, but with other components being missing. VBox isn't unsupported for philosophy reasons exactly, but more for technical reasons. The main reason it's not packaged for Fedora is that it requires out-of-tree kernel modules. There appears to be little interest on either side for getting these upstreamed. Fedora does not accept out-of-tree kernel modules. I actually agree that your argument for supporting install as a VBox *guest* makes a lot of sense, really, it's a pretty common use case. It's probably true that we've applied the 'we don't support VBox' mantra too easily to the VBox guest case, where it doesn't entirely apply. It's more about using Fedora as a VBox *host*. I wouldn't be opposed to proposals to test or even block on the VBox guest case, as it is a common case. Though we'd need to consider the problem where it breaks because of something in upstream VBox, which we can't control; that might be a deal-breaker for making it a blocker. The other side of the 'VBox isn't supported' argument, btw, is a very pragmatic one: all the virtualization and kernel coders I've ever happened to discuss it with seem to be in agreement that, technically speaking, VBox is a pile of shit. There are reasons small-scale virt users - i.e. desktop users who use virt on a single box for testing and playing with new OSes - like it; it has a good UI for that use, and it has some features the Fedora stack doesn't yet, notably 3D passthrough. But looking at it in design and code quality terms, there appears to be a strong consensus among Fedora devs that it's terrible code which has fundamental problems that make them unwilling to commit too strongly to 'supporting' it. I don't know the details of this argument, though. Maybe someone following this thread does. -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | identi.ca: adamwfedora http://www.happyassassin.net -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Re: How to interpret F18 Blocker criterion
On Wed, 2012-11-07 at 12:07 -0800, Adam Williamson wrote: Though we'd need to consider the problem where it breaks because of something in upstream VBox, which we can't control; that might be a deal-breaker for making it a blocker. Before anyone says 'but that applies to Windows too!', VBox is *way* more of a moving target than Windows. VBox releases rapidly and breaks stuff often. There's a new Windows release, what, every three or four years? For practical purposes we can consider Windows a static target that we accommodate, it's not practical to do that with VBox. -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | identi.ca: adamwfedora http://www.happyassassin.net -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
How to interpret F18 Blocker criterion
The F18 Blocker criteria contain: The installer must be able to install into free space alongside an existing clean single-partition Windows installation and either install a bootloader which can boot into the Windows installation, or leave the Windows bootloader untouched and working What must be understood under single-partition? Alexander -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Re: How to interpret F18 Blocker criterion
The F18 Blocker criteria contain: The installer must be able to install into free space alongside an existing clean single-partition Windows installation and either install a bootloader which can boot into the Windows installation, or leave the Windows bootloader untouched and working What must be understood under single-partition? Alexander The intended purpose is to say this should be a default Windows installation, which usually consist of a single NTFS partition. But we should probably improve the description, because recent Windows (at least Win 7) create two partitions - 100MB System Reserved and then the rest of the space for disk C. -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Re: How to interpret F18 Blocker criterion
On Tue, Nov 6, 2012 at 8:03 PM, Frank Murphy frankl...@gmail.com wrote: On Tue, 6 Nov 2012 09:30:41 -0500 (EST) Kamil Paral kpa...@redhat.com wrote: The F18 Blocker criteria contain: The installer must be able to install into free space alongside an existing clean single-partition Windows installation and either install a bootloader which can boot into the Windows installation, or leave the Windows bootloader untouched and working What must be understood under single-partition? Alexander The intended purpose is to say this should be a default Windows installation, which usually consist of a single NTFS partition. But we should probably improve the description, because recent Windows (at least Win 7) create two partitions - 100MB System Reserved and then the rest of the space for disk C. If OEM, it will also have that restore partition, to reset to factory default so maybe 3 partitions. What if we make it Like .. The installer must be able to install into free space alongside an existing Windows partition(s) and either install a bootloader which can boot into the Windows installation, or leave the Windows bootloader untouched and working -- Regards, Frank -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test -- Akshay vyas (http://www.gofedora.in) -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Re: How to interpret F18 Blocker criterion
On 11/06/2012 02:30 PM, Kamil Paral wrote: The F18 Blocker criteria contain: The installer must be able to install into free space alongside an existing clean single-partition Windows installation and either install a bootloader which can boot into the Windows installation, or leave the Windows bootloader untouched and working What must be understood under single-partition? Alexander The intended purpose is to say this should be a default Windows installation, which usually consist of a single NTFS partition. But we should probably improve the description, because recent Windows (at least Win 7) create two partitions - 100MB System Reserved and then the rest of the space for disk C. What's the reason for this criteria and why is it only limited to windows as opposed to OS-X and other OS in general? JBG -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Re: How to interpret F18 Blocker criterion
On 11/06/2012 02:30 PM, Kamil Paral wrote: The F18 Blocker criteria contain: The installer must be able to install into free space alongside an existing clean single-partition Windows installation and either install a bootloader which can boot into the Windows installation, or leave the Windows bootloader untouched and working What must be understood under single-partition? Alexander The intended purpose is to say this should be a default Windows installation, which usually consist of a single NTFS partition. But we should probably improve the description, because recent Windows (at least Win 7) create two partitions - 100MB System Reserved and then the rest of the space for disk C. What's the reason for this criteria and why is it only limited to windows as opposed to OS-X and other OS in general? Good question. I guess the answer is practicality, dual boot with Windows is the most common use case. We can't really extend this criterion to _any_ operating system, we don't really want to block Fedora because it can't properly dual-boot with Haiku or whatever, do we? OTOH I find somewhat inconsistent that our release criterion is related to a closed-source proprietary product, while Fedora philosophy, as currently interpreted/written, refuses these links [1]. The current approach is that we don't care about problems with VirtualBox, with nvidia drivers, with just about _anything_ that is not included in Fedora. This test case doesn't really resonate with it. Personally I find the philosophy in a direct clash with practicality and too extreme. [1] The Fedora Project is not interested in having its distribution be a platform for proprietary or patent encumbered components. While we do not purposely make installation of such components more difficult, we also do not allow our schedule or processes to be driven by theirs. http://fedoraproject.org/wiki/Objectives -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Re: How to interpret F18 Blocker criterion
On Tue, 2012-11-06 at 14:33 +, Frank Murphy wrote: On Tue, 6 Nov 2012 09:30:41 -0500 (EST) Kamil Paral kpa...@redhat.com wrote: The F18 Blocker criteria contain: The installer must be able to install into free space alongside an existing clean single-partition Windows installation and either install a bootloader which can boot into the Windows installation, or leave the Windows bootloader untouched and working What must be understood under single-partition? Alexander The intended purpose is to say this should be a default Windows installation, which usually consist of a single NTFS partition. But we should probably improve the description, because recent Windows (at least Win 7) create two partitions - 100MB System Reserved and then the rest of the space for disk C. If OEM, it will also have that restore partition, to reset to factory default so maybe 3 partitions. Restore partitions have been around forever. I don't count them as part of the Windows install, because they're really not, they're lower-level than that. It's what you use when the Windows install falls over. :) -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | identi.ca: adamwfedora http://www.happyassassin.net -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Re: How to interpret F18 Blocker criterion
On Tue, 2012-11-06 at 11:06 -0500, Kamil Paral wrote: On 11/06/2012 02:30 PM, Kamil Paral wrote: The F18 Blocker criteria contain: The installer must be able to install into free space alongside an existing clean single-partition Windows installation and either install a bootloader which can boot into the Windows installation, or leave the Windows bootloader untouched and working What must be understood under single-partition? Alexander The intended purpose is to say this should be a default Windows installation, which usually consist of a single NTFS partition. But we should probably improve the description, because recent Windows (at least Win 7) create two partitions - 100MB System Reserved and then the rest of the space for disk C. What's the reason for this criteria and why is it only limited to windows as opposed to OS-X and other OS in general? Good question. I guess the answer is practicality, dual boot with Windows is the most common use case. We can't really extend this criterion to _any_ operating system, we don't really want to block Fedora because it can't properly dual-boot with Haiku or whatever, do we? Right. It's a pragmatic consideration. We can't support all dual boot cases, and dual booting alongside Windows is the most common and important to support (as it's what you need to do to attract new converts). OTOH I find somewhat inconsistent that our release criterion is related to a closed-source proprietary product, while Fedora philosophy, as currently interpreted/written, refuses these links [1]. I don't think there's a conflict at all. All distros work hard to dual boot with Windows successfully because that's how you get people to try Linux: i.e., it's actually a key thing to have *in order to driver our philosophy*. The current approach is that we don't care about problems with VirtualBox, with nvidia drivers, with just about _anything_ that is not included in Fedora. This test case doesn't really resonate with it. I disagree, because there's a vital difference. The dual boot case is about having Fedora - fully 'philosophy compliant' Fedora - working _alongside_ a different proprietary operating system; a configuration that's important to support for 'ideological' reasons as much as any others (see above). What we don't support is proprietary components *inside our own operating system*. Personally I find the philosophy in a direct clash with practicality and too extreme. [1] The Fedora Project is not interested in having its distribution be a platform for proprietary or patent encumbered components. While we do not purposely make installation of such components more difficult, we also do not allow our schedule or processes to be driven by theirs. http://fedoraproject.org/wiki/Objectives See? Perfectly compatible. In a dual boot scenario, Fedora is not being 'a platform for proprietary components'. The proprietary 'component' in question is entirely independent from Fedora and works fine without it. We are not 'enabling' proprietary software by booting alongside it. -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | identi.ca: adamwfedora http://www.happyassassin.net -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Re: How to interpret F18 Blocker criterion
On 11/06/2012 05:42 PM, Adam Williamson wrote: Good question. I guess the answer is practicality, dual boot with Windows is the most common use case. We can't really extend this criterion to_any_ operating system, we don't really want to block Fedora because it can't properly dual-boot with Haiku or whatever, do we? Right. It's a pragmatic consideration. We can't support all dual boot cases, and dual booting alongside Windows is the most common and important to support (as it's what you need to do to attract new converts). OTOH I find somewhat inconsistent that our release criterion is related to a closed-source proprietary product, while Fedora philosophy, as currently interpreted/written, refuses these links [1]. I don't think there's a conflict at all. All distros work hard to dual boot with Windows successfully because that's how you get people to try Linux: i.e., it's actually a key thing to have *in order to driver our philosophy*. That argument does not hold water and has not for sometime now... Remind me again what the purpose of live cd/dvd/usb is ;) JBG -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Re: How to interpret F18 Blocker criterion
On Tue, 2012-11-06 at 17:57 +, Jóhann B. Guðmundsson wrote: On 11/06/2012 05:42 PM, Adam Williamson wrote: Good question. I guess the answer is practicality, dual boot with Windows is the most common use case. We can't really extend this criterion to_any_ operating system, we don't really want to block Fedora because it can't properly dual-boot with Haiku or whatever, do we? Right. It's a pragmatic consideration. We can't support all dual boot cases, and dual booting alongside Windows is the most common and important to support (as it's what you need to do to attract new converts). OTOH I find somewhat inconsistent that our release criterion is related to a closed-source proprietary product, while Fedora philosophy, as currently interpreted/written, refuses these links [1]. I don't think there's a conflict at all. All distros work hard to dual boot with Windows successfully because that's how you get people to try Linux: i.e., it's actually a key thing to have *in order to driver our philosophy*. That argument does not hold water and has not for sometime now... Remind me again what the purpose of live cd/dvd/usb is ;) That's not really the same thing at all. You can try out this funny Linux thing for an hour or two using a live image. You can't use it seriously. Fact is, a _lot_ of people still dual boot with Windows, because they're not sure they want to switch 100% to Linux, or they still need to run some apps on Windows, or they want to play games, or whatever. Is anyone seriously doubting it's a common and important use case? -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | identi.ca: adamwfedora http://www.happyassassin.net -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Re: How to interpret F18 Blocker criterion
On 11/06/2012 08:00 PM, Adam Williamson wrote: Fact is, a_lot_ of people still dual boot with Windows, because they're not sure they want to switch 100% to Linux, or they still need to run some apps on Windows, or they want to play games, or whatever. Is anyone seriously doubting it's a common and important use case? Arent users on OS-X and Apple hw doing the exact same thing? JBG -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Re: How to interpret F18 Blocker criterion
On Tue, 2012-11-06 at 20:34 +, Jóhann B. Guðmundsson wrote: On 11/06/2012 08:00 PM, Adam Williamson wrote: Fact is, a_lot_ of people still dual boot with Windows, because they're not sure they want to switch 100% to Linux, or they still need to run some apps on Windows, or they want to play games, or whatever. Is anyone seriously doubting it's a common and important use case? Arent users on OS-X and Apple hw doing the exact same thing? Sure, but there are far fewer OS X users than Windows users. It's just a numbers game. There is another factor at play there, though, to be fair. When we wrote the criterion, our support for Intel Macs was still pretty much non-existent. That was the time when we explicitly wrote into the criteria that we didn't support Intel Macs. So obviously we weren't going to block on OS X dual boot. That consideration probably doesn't apply any more, though the numbers game still does. -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | identi.ca: adamwfedora http://www.happyassassin.net -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Re: How to interpret F18 Blocker criterion
On 11/06/2012 09:02 PM, Adam Williamson wrote: On Tue, 2012-11-06 at 20:34 +, Jóhann B. Guðmundsson wrote: On 11/06/2012 08:00 PM, Adam Williamson wrote: Fact is, a_lot_ of people still dual boot with Windows, because they're not sure they want to switch 100% to Linux, or they still need to run some apps on Windows, or they want to play games, or whatever. Is anyone seriously doubting it's a common and important use case? Arent users on OS-X and Apple hw doing the exact same thing? Sure, but there are far fewer OS X users than Windows users. It's just a numbers game. There is another factor at play there, though, to be fair. When we wrote the criterion, our support for Intel Macs was still pretty much non-existent. That was the time when we explicitly wrote into the criteria that we didn't support Intel Macs. So obviously we weren't going to block on OS X dual boot. That consideration probably doesn't apply any more, though the numbers game still does. -- Well the fundamental question to ask ourselves is if windows or os-x do honor other operating system installed then we should if not we should not regardless of any numbers game you like to play trying to justify this criteria... JBG -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Re: How to interpret F18 Blocker criterion
On Tue, 2012-11-06 at 21:19 +, Jóhann B. Guðmundsson wrote: On 11/06/2012 09:02 PM, Adam Williamson wrote: On Tue, 2012-11-06 at 20:34 +, Jóhann B. Guðmundsson wrote: On 11/06/2012 08:00 PM, Adam Williamson wrote: Fact is, a_lot_ of people still dual boot with Windows, because they're not sure they want to switch 100% to Linux, or they still need to run some apps on Windows, or they want to play games, or whatever. Is anyone seriously doubting it's a common and important use case? Arent users on OS-X and Apple hw doing the exact same thing? Sure, but there are far fewer OS X users than Windows users. It's just a numbers game. There is another factor at play there, though, to be fair. When we wrote the criterion, our support for Intel Macs was still pretty much non-existent. That was the time when we explicitly wrote into the criteria that we didn't support Intel Macs. So obviously we weren't going to block on OS X dual boot. That consideration probably doesn't apply any more, though the numbers game still does. -- Well the fundamental question to ask ourselves is if windows or os-x do honor other operating system installed then we should if not we should not regardless of any numbers game you like to play trying to justify this criteria... Well, I mean, there's no simple answer to that question. The only time OSes really interact with each other, aside from by user intervention, is at install time. Neither Windows nor OS X makes any real attempt to try and 'behave' alongside installs of other operating systems, if you install them after your install other OSes. That is known and has been the case for years. It's why the standing advice is to install Linux after Windows or OS X. But then, trying to do so is fraught with difficulties. We certainly don't behave as perfectly as possible in all possible multiboot scenarios. Multiboot is inherently a hack in the PC BIOS / MBR system, really. It's all duct tape and gum, and impossible for any OS or utility to really support all possible cases perfectly. Once you have two OSes installed and multibooting correctly, it's usually the case that they'll continue to do so indefinitely unless you do anything that pokes the MBR, or you start manually mounting partitions from other OSes and poking them, or you do a major version upgrade of one and it pokes the MBR in the process of that upgrade. The OSes themselves will leave each other alone, in general. I don't think Windows ever, say, just squelches the MBR on update, or anything like that. Ultimately the intent of the criterion is that a simple 'do a default install of Windows, then do a default install of Fedora next to it' case is fairly commonly seen in the real world, reasonably stable in behaviour (Windows has not changed in how it behaves in this scenario over the years), and possible to support. Since it's often done in the real world, it's something our releases ought to work with. It's pretty much that simple. The corresponding test case does specify the order of installing the OSes; we don't support the 'install Fedora then install Windows' case, and never have (no OS can, really, as Windows will always just squelch the MBR at install time). -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | identi.ca: adamwfedora http://www.happyassassin.net -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Re: How to interpret F18 Blocker criterion
On Nov 6, 2012, at 10:19 PM, Jóhann B. Guðmundsson johan...@gmail.com wrote: Well the fundamental question to ask ourselves is if windows or os-x do honor other operating system installed then we should if not we should not regardless of any numbers game you like to play trying to justify this criteria… I'm sorry, that's neither fundamental nor a question. It's quite well known for a very long time: Microsoft: What other operating systems? Oh you mean the last version of Windows? Umm, yeah OK if you really want to do that you can, I guess. Apple: Apple does not acknowledge past or future releases of OS X, there is only the current version of OS X. Other operating systems? Why would you want to do that? Seriously, not a joke, the instant 10.8 came out, you could not legally obtain 10.7; and Apple notoriously does not comment on unreleased products. Windows? Really you want it on your Mac? And what's Linux again? Acknowledging doesn't even happen, let alone honoring. Chris Murphy -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Re: How to interpret F18 Blocker criterion
On Nov 6, 2012, at 9:34 PM, Jóhann B. Guðmundsson johan...@gmail.com wrote: On 11/06/2012 08:00 PM, Adam Williamson wrote: Fact is, a_lot_ of people still dual boot with Windows, because they're not sure they want to switch 100% to Linux, or they still need to run some apps on Windows, or they want to play games, or whatever. Is anyone seriously doubting it's a common and important use case? Arent users on OS-X and Apple hw doing the exact same thing? It's not quite the same thing in that non-Apple hardware comes in many flavors approaching (or perhaps flirting) with standards or expected behaviors when it comes to firmware in particular. Whereas Apple hardware is weird. So for practical purposes it's an OS X dominant purchase where buyers are buying access to OS X every bit as much as the hardware design aesthetic. Fedora's mactel-boot support actually is the first thing to make Linux-only viable on Apple hardware. Before this (or without it), excessive compromises end up being made that makes Linux a non-advantage compared to just running it in a VM on OS X (or buying non-Apple hardware that can directly run Linux without jumping through hoops). Chris Murphy -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Re: How to interpret F18 Blocker criterion
On 11/06/2012 09:42 PM, Adam Williamson wrote: Ultimately the intent of the criterion is that a simple 'do a default install of Windows, then do a default install of Fedora next to it' case is fairly commonly seen in the real world, reasonably stable in behaviour (Windows has not changed in how it behaves in this scenario over the years), and possible to support. Since it's often done in the real world, it's something our releases ought to work with. It's pretty much that simple. What's simple is that this criteria should not exist and block the release from my pov of view... People that want to try Fedora can do so via live cd/dvd/usb or in a vm and those that dont need to reformat/repartition and reinstall windows and then install Fedora assuming that they have legal copy of Microsoft Windows in the first place ( which I seriously doubt is the case today since I dont even think they ship a copy on cd with windows with laptops/desktops today atleast I did not get any copy with the last laptop I bought )... JBG -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Re: How to interpret F18 Blocker criterion
On Tue, 2012-11-06 at 21:55 +, Jóhann B. Guðmundsson wrote: People that want to try Fedora can do so via live cd/dvd/usb or in a vm and those that dont need to reformat/repartition and reinstall windows and then install Fedora assuming that they have legal copy of Microsoft Windows in the first place ( which I seriously doubt is the case today since I dont even think they ship a copy on cd with windows with laptops/desktops today atleast I did not get any copy with the last laptop I bought )... What? you don't have to reinstall Windows to install Fedora alongside it. Almost all OEM preloads of Windows are simple installs, just what we list in the criteria and what we test: they just have a single big partition with Windows on it (and maybe some system restore partition as we discussed earlier in the thread). I'm not sure if you're being obtuse or just misunderstanding, but it is generally the case that you can take a perfectly normal OEM Windows box, maybe resize the Windows partition (or just add another disk), and install Linux alongside it, and it'll work fine. -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | identi.ca: adamwfedora http://www.happyassassin.net -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Re: How to interpret F18 Blocker criterion
On 11/06/2012 10:23 PM, Adam Williamson wrote: What? you don't have to reinstall Windows to install Fedora alongside it. Almost all OEM preloads of Windows are simple installs, just what we list in the criteria and what we test: they just have a single big partition with Windows on it (and maybe some system restore partition as we discussed earlier in the thread). I'm not sure if you're being obtuse or just misunderstanding, but it is generally the case that you can take a perfectly normal OEM Windows box, maybe resize the Windows partition (or just add another disk), and install Linux alongside it, and it'll work fine. You do realize by having this criteria you are tying the release to users having existing windows installs be it oem installs or not and that's just absurd... JBG -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Re: How to interpret F18 Blocker criterion
On Nov 6, 2012, at 10:55 PM, Jóhann B. Guðmundsson johan...@gmail.com wrote: People that want to try Fedora can do so via live cd/dvd/usb or in a vm and those that dont need to reformat/repartition and reinstall windows and then install Fedora assuming that they have legal copy of Microsoft Windows in the first place ( which I seriously doubt is the case today since I dont even think they ship a copy on cd with windows with laptops/desktops today atleast I did not get any copy with the last laptop I bought )… This makes zero sense. Why do they need to reinstall Windows? What's the point in that effort? Have you ever done this? It's extremely time consuming. You turn a 15-30 minute Fedora install into 2 days of flinging poo in a pig pen. If that's what I'd be signing up for in advance I'd say, umm thanks but no thanks. Chris Murphy -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Re: How to interpret F18 Blocker criterion
On Nov 6, 2012, at 11:43 PM, Jóhann B. Guðmundsson johan...@gmail.com wrote: You do realize by having this criteria you are tying the release to users having existing windows installs be it oem installs or not and that's just absurd… Why is OEM vs retail install relevant? It's NTFS in any case. You have some justified concern as to whether the NTFS volume is healthy prior to being resized in advance of Fedora's installation - I haven't tried this so I don't know what happens but it's seems highly risky to resize a file system that hasn't had a recent file system check that goes beyond checking the journal. Chris Murphy -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Re: How to interpret F18 Blocker criterion
On 11/06/2012 11:23 PM, Chris Murphy wrote: On Nov 6, 2012, at 11:43 PM, Jóhann B. Guðmundsson johan...@gmail.com wrote: You do realize by having this criteria you are tying the release to users having existing windows installs be it oem installs or not and that's just absurd… Why is OEM vs retail install relevant? It's NTFS in any case. You have some justified concern as to whether the NTFS volume is healthy prior to being resized in advance of Fedora's installation - I haven't tried this so I don't know what happens but it's seems highly risky to resize a file system that hasn't had a recent file system check that goes beyond checking the journal. Sorry not following to me it does not matter if it's whole Microsoft Windows or just Microsoft's propriety file system it's still absurd to me having our QA community members having to set it up and use it and have our release be dependent upon it... JBG -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Re: How to interpret F18 Blocker criterion
That's not absurd ... that's reality. On Wed, Nov 7, 2012 at 12:36 AM, Jóhann B. Guðmundsson johan...@gmail.com wrote: On 11/06/2012 11:23 PM, Chris Murphy wrote: On Nov 6, 2012, at 11:43 PM, Jóhann B. Guðmundsson johan...@gmail.com wrote: You do realize by having this criteria you are tying the release to users having existing windows installs be it oem installs or not and that's just absurd… Why is OEM vs retail install relevant? It's NTFS in any case. You have some justified concern as to whether the NTFS volume is healthy prior to being resized in advance of Fedora's installation - I haven't tried this so I don't know what happens but it's seems highly risky to resize a file system that hasn't had a recent file system check that goes beyond checking the journal. Sorry not following to me it does not matter if it's whole Microsoft Windows or just Microsoft's propriety file system it's still absurd to me having our QA community members having to set it up and use it and have our release be dependent upon it... JBG -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.**org/mailman/listinfo/testhttps://admin.fedoraproject.org/mailman/listinfo/test -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Re: How to interpret F18 Blocker criterion
Sorry for top posting ... gmail's new compose thing is just stupid. -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Re: How to interpret F18 Blocker criterion
On 11/07/2012 12:04 AM, drago01 wrote: That's not absurd ... that's reality. I'm perfectly well aware how absurd and real that criteria is JBG -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Re: How to interpret F18 Blocker criterion
On Wed, 2012-11-07 at 00:23 +0100, Chris Murphy wrote: On Nov 6, 2012, at 11:43 PM, Jóhann B. Guðmundsson johan...@gmail.com wrote: You do realize by having this criteria you are tying the release to users having existing windows installs be it oem installs or not and that's just absurd… Why is OEM vs retail install relevant? It's NTFS in any case. You have some justified concern as to whether the NTFS volume is healthy prior to being resized in advance of Fedora's installation - I haven't tried this so I don't know what happens but it's seems highly risky to resize a file system that hasn't had a recent file system check that goes beyond checking the journal. We don't actually cover resizing in the criteria. It's a bit of a fudge, but anaconda team considers resizing fundamentally too fragile to guarantee, it's too easy for it to go wrong. The criteria really require that anaconda be able to deploy Fedora alongside Windows and correctly set up a bootloader that boots both, with the availability of empty space for the Fedora install assumed. -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | identi.ca: adamwfedora http://www.happyassassin.net -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Re: How to interpret F18 Blocker criterion
On Wed, 2012-11-07 at 00:42 +, Jóhann B. Guðmundsson wrote: On 11/07/2012 12:04 AM, drago01 wrote: That's not absurd ... that's reality. I'm perfectly well aware how absurd and real that criteria is Does anyone else agree with Johann that we should change or remove the criterion? If there's significant support for that idea I'll throw it on the meeting agenda for next week, but if no-one else thinks we should stop testing and supporting install-alongside-Windows, maybe we should just leave it there. I think the arguments on both sides have been made clearly by now. -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | identi.ca: adamwfedora http://www.happyassassin.net -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Re: How to interpret F18 Blocker criterion
On 11/07/2012 02:09 AM, Adam Williamson wrote: On Wed, 2012-11-07 at 00:42 +, Jóhann B. Guðmundsson wrote: On 11/07/2012 12:04 AM, drago01 wrote: That's not absurd ... that's reality. I'm perfectly well aware how absurd and real that criteria is Does anyone else agree with Johann that we should change or remove the criterion? If there's significant support for that idea I'll throw it on the meeting agenda for next week, but if no-one else thinks we should stop testing and supporting install-alongside-Windows, maybe we should just leave it there. I think the arguments on both sides have been made clearly by now. FWIW I always test installing alongside Windows. -- Regards, OldFart -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Re: How to interpret F18 Blocker criterion
On 11/07/2012 02:09 AM, Adam Williamson wrote: On Wed, 2012-11-07 at 00:42 +, Jóhann B. Guðmundsson wrote: On 11/07/2012 12:04 AM, drago01 wrote: That's not absurd ... that's reality. I'm perfectly well aware how absurd and real that criteria is Does anyone else agree with Johann that we should change or remove the criterion? If there's significant support for that idea I'll throw it on the meeting agenda for next week, but if no-one else thinks we should stop testing and supporting install-alongside-Windows, maybe we should just leave it there. I think the arguments on both sides have been made clearly by now. -- We can still test this and installing Fedora, and arguably we should be doing that along other OS other than just Microsoft as well. We would just not have the Fedora release dependent upon the result from those tests... JBG -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
