Re: F19 Final criteria revamp
On 06/13/2013 12:37 PM, Chris Murphy wrote: My expectation is the installer doesn't crash, the attempt leaves the disk untouched, and I get some coherent message indicating this. This expectation is reasonable, but still constitutes support. I don't know what doesn't support could mean unless it applies uniformly to the entire distribution. If you ask for help with a problem related to resizing, I think you're as likely to get a response on it as anything else in Fedora. I'm not sure who has been responsible for putting all those Official,Recommendation ( like kvm over xen ) ,Support etc. label on various components or group of components within the distribution. We are a community driven distribution and support is nothing more then best effort ( limited to community members individuals free time ) of maintaining to the component we already ship and if we ship it we support it to the that extent. JBG -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Re: F19 Final criteria revamp
On Thu, 2013-06-13 at 12:51 +, Jóhann B. Guðmundsson wrote: On 06/13/2013 12:37 PM, Chris Murphy wrote: My expectation is the installer doesn't crash, the attempt leaves the disk untouched, and I get some coherent message indicating this. This expectation is reasonable, but still constitutes support. I don't know what doesn't support could mean unless it applies uniformly to the entire distribution. If you ask for help with a problem related to resizing, I think you're as likely to get a response on it as anything else in Fedora. I'm not sure who has been responsible for putting all those Official,Recommendation ( like kvm over xen ) ,Support etc. label on various components or group of components within the distribution. We are a community driven distribution and support is nothing more then best effort ( limited to community members individuals free time ) of maintaining to the component we already ship and if we ship it we support it to the that extent. I thought it should be fairly screamingly freaking obvious that in the context of a discussion of the release criteria, 'support' means 'block on'. I didn't think I'd have to explain that. -- 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: F19 Final criteria revamp
On 06/12/2013 02:38 AM, Adam Williamson wrote: On Tue, 2013-06-11 at 19:17 -0700, Samuel Sieb wrote: On 06/11/2013 12:37 AM, Jóhann B. Guðmundsson wrote: Installing to a freespace should be uncontroversial indeed it's the resize I was referring to and as afaik when you buy a set of hardware with windows installed it does not come with freespace available and we should only be supporting dealing with factory defaults but as Samuel points out earlier in the thread The criteria specifically refers to installing to freespace, so other than the single partition reference what is the problem? If the user wants to install alongside a default windows install, they will either have to resize the partitions on their own or risk letting the installer resize it (if it will). I can kinda see Johann's point, which is that - since most dual boot installs will require a resize - if we don't 'support' resize, we're really not 'supporting' dual boot installs. He's not wrong. But overall, I think it's worthwhile having the criterion to ensure that, as cmurf said, we at least make sure we get the bootloader stuff right at release time. Yeah that was my point. If we are going to support dual boot we should do so fully ( freespace/resize/boot loader entries windows/linux linux/windows linux/linux ) If we are not or simply cant ( we should be able to at least support dual booting linux/linux ) we should not have it in the criteria ( but still could perform the tests ) JBG -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Re: F19 Final criteria revamp
On Wed, 2013-06-12 at 18:46 -0400, Chris Murphy wrote: On Jun 12, 2013, at 4:24 PM, Jóhann B. Guðmundsson johan...@gmail.com wrote: On 06/12/2013 02:38 AM, Adam Williamson wrote: I can kinda see Johann's point, which is that - since most dual boot installs will require a resize - if we don't 'support' resize, we're really not 'supporting' dual boot installs. He's not wrong. But overall, I think it's worthwhile having the criterion to ensure that, as cmurf said, we at least make sure we get the bootloader stuff right at release time. Yeah that was my point. If we are going to support dual boot we should do so fully ( freespace/resize/boot loader entries windows/linux linux/windows linux/linux ) If we are not or simply cant ( we should be able to at least support dual booting linux/linux ) we should not have it in the criteria ( but still could perform the tests ) In this increasingly hypothetical file system resizing induced data loss, which as far as I know isn't even happening to anybody, the criterion acts as a do no harm policy to prevent such a distribution from being released to the public. I'm not sure anyone said anything about 'data loss'. What I said is that resizing is inherently unreliable: not 'it sometimes causes data loss', but 'it doesn't always work'. For instance, if you have a heavily fragmented FAT32 or NTFS partition, resizing it is going to fail. If you have an NTFS partition that's marked as not having been cleanly unmounted the last time you booted Windows, resizing it is going to fail. There are various other conditions like this. As I said, one thing we could do is add a carefully worded resize requirement: something like resize operations offered by the installer must trigger the correct action, i.e., if the installer lets you try and resize an NTFS partition to size X, it must pass the correct parameters to ntfsresize, and ntfsresize must be present and ideally not completely broken; beyond that, we offer no guarantees. That seems workable, but I'd want to run it by the anaconda team. It seems rather self evident that a major, respected distribution like Fedora could not possibly entertain the idea of offering NTFS resizing in the installer, with a data loss inducing defect. We already have a catch-all criterion for bugs that are known to cause data loss, so this isn't a problem. -- 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: F19 Final criteria revamp
On 06/11/2013 02:59 AM, Chris Murphy wrote: On Jun 10, 2013, at 1:51 PM, Jóhann B. Guðmundssonjohan...@gmail.com wrote: Resize and refitting another OS along with already installed one on the same hardware ( disks ) is not something I see as we should or could be officially supporting hence we should not be blocking our release for that. Certainly installing to free space should be uncontroversial. I don't care to understand the idea that user choice should only apply to FOSS. You either believe in user choice or you don't, it is a fairly binary position regardless of the software's license. The installer supports it, and considering the damage that could be done is in the category of data loss, yes it needs to have a suitable release blocking criterion. Installing to a freespace should be uncontroversial indeed it's the resize I was referring to and as afaik when you buy a set of hardware with windows installed it does not come with freespace available and we should only be supporting dealing with factory defaults but as Samuel points out earlier in the thread I recently had the fun of installing Fedora beside Windows 7 on more than 10 different laptops. (This was for a class where the students were required to provide their own laptops.) The number of Windows partitions varied from 2 to 4. The 4 partition case required me to delete one of them because they were all primary partitions! Sorry, I don't remember what the contents were on the partitions. My guess of the options was boot, main OS, user data, system (BIOS config?), recovery. There was one Windows 8 laptop which was easier because it used GPT so I didn't have to mess with the partitions other than resizing them. Which means today you are no longer dealing with a single partition ( atleast a rescue partition then 1 -3 windows partitions if you are using laptops ) so the user has to manually resize to fit Fedora along side it and here's what Adam sait about that if ntfsresize fails for some reason, that wouldn't be a blocker. which kinda beats the purpose of the criteria right ( since no factory install of windows comes with available free space so the user always has to resize before or during the installation phaze ) That is indeed the implication, it's intentional, and I wouldn't want to change it without input from the anaconda team. Their position is that resizing is inherently a risky and unpredictable operation that we cannot guarantee the functionality of, but we should be able to guarantee what's written in the criterion. I suppose we could try and come up with a tightly-worded criterion that the resize mechanism in the installer must not be broken - so it should 'do what it's supposed to do', but if ntfsresize fails for some reason, that wouldn't be a blocker. On top of that installer needs to support adding an entry for Fedora to the primary OS ( XP/Vista/Windows7/Windows8 ) already existing bootloader ( if the users chooses not to install grub but chooses using the windows bootloader in this case but the same should be apply to grub if installing alongside another linux distribution as in dualbooting ubuntu and fedora for example ) or adding a entry for the primary OS to grub ( if the user chose to install it ) to grub. And while we cant fully commit to supporting dual or multi booting then we should not have that in our criteria. JBG -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Re: F19 Final criteria revamp
On Jun 10, 2013, at 12:27 PM, Adam Williamson awill...@redhat.com wrote: On Mon, 2013-06-10 at 08:38 -0400, Chris Murphy wrote: b. For BIOS installs, the requirement for the bootloader to boot both Windows and Fedora is reasonable. It's probably not reasonable, still, for UEFI. GRUB2+os-prober really isn't acting as a suitable replacement Boot Manager, so the user either needs to use the firmware boot manager to choose a bootloader (bootmgr.efi for Windows, grubx64.efi for Fedora), or some other boot manager (rEFInd or gummiboot). Well, I see the point, but at the same time, we are finding out that in the Real World, it's a really bad idea to depend on the EFI boot manager because it just isn't being presented to the user in a sane way in enough of the real UEFI implementations. So we might actually want to keep that requirement, and fix up os-prober (which we're currently working on). We'll have to see what pjones' take on that is. The state of affairs with EFI boot managers being is not good, that's true. But GRUB doesn't fix this problem. It's a totally inadequate boot manager replacement on EFI right now. And it's unclear to me if that is even an eventual design goal of a future GRUB. Not only is Windows not added to the GRUB menu, grub-mkconfig is presently unfriendly to prior Fedora and other Linux installations by displaying them differently (and their entries don't even work, Bug 964828). Further, GRUB still depends 100% on a static grub.cfg which can be totally disconnected from the actual boot options for the computer. GRUB doesn't produce menu entries from NVRAM, or from available boot loaders on the available EFI System partitions. Despite highly variable interfaces, the built-in firmware boot managers do better than this. gummiboot does better. And rEFInd better still. So I don't see the point of parity in the criterion for GRUB BIOS and GRUB EFI when it comes to the requirement to show both Fedora and Windows options. I've only recently BIOS installed Windows 7, and it's two partitions to an unpartitioned disk. I think for EFI installing Windows 7, it's three partitions. For Windows 8 EFI, it's four partitions, so I'll guess it's one less for BIOS. What are the partitions? For BIOS Win 7 installs, one is a Microsoft reserved partition. Windows 8 on UEFI, one such system's partition map is in bug 971255 and looks like this: Number Start (sector)End (sector) Size Code Name 12048 616447 300.0 MiB 2700 Basic data partition 2 616448 819199 99.0 MiBEF00 EFI system partition 3 819200 1081343 128.0 MiB 0C01 Microsoft reserved part 4 1081344 12287 58.1 GiB0700 Basic data partition The Windows on a single partition case is pretty rare in any case. Chris Murphy -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Re: F19 Final criteria revamp
Hey folks - so just ahead of the blocker meeting tomorrow, I'm done with the Final criteria rewrite. Thanks a lot, I reviewed them and they seem to be fine. Some comments below. I noticed that the upgrade criterion went missing. But we already have one in Beta, and it seems to be the same. What am I missing? * I wrote an exception for hardware-based services when the hardware isn't present into the 'services' criterion: we waived a couple of 'blockers' for F18 on the basis that it's okay if a service fails if it's for hardware that isn't present, so I thought it made sense to write that into the criterion. (Obviously it's best if we can make the service not fire unless the hardware is present, but I don't think it makes sense to block the release on that kind of thing). The unless they require hardware which is not present phrase could be separated into a comment box, so that the original sentence is cleaner. Just an idea. SELinux and crash notifications There must be no SELinux denial notifications or crash notifications after boot of a release-blocking live image or at first login after a default install of a release-blocking desktop. Should we add during installation as well? Wrt the bug discussed in the last blocker bug meeting. * I watered down the 'desktop' criteria quite a bit. Looking at them afresh I really think we were kind of over-reaching when we wrote them for F13: I remember we were thinking about 'polish criteria', but now we've had this process in place for a while, it really doesn't make sense to block the release on fairly trivial 'polish' issues (especially when we happily ship with much bigger issues in slightly different other areas). So I nuked the 'icons can't be fuzzy' requirement, the requirement for Help and About menus to be present, and the bit about apps not showing up twice in the menus. Those are all nice things to check, but I really don't think we need to be blocking releases on them. I agree. These issues were too trivial to block release on. Still, I'd like to see /someone/ to ensure the polish. It would be great to have both QA team and Polish (UX) team. At present, we need to handle that. But this change is fine. I'm looking forward to simplifying the test cases. * I watered down the artwork criterion yet further: the initial idea was that we were going to be super-keen about having a consistent background graphic from bootloader to desktop, but that's really fallen by the wayside since F14 or so. Given our overall boot process nowadays, it only seems particularly important to make sure we use the right image for the desktop background. It'd be great if the project goes back to that goal, but clearly so far there hasn't been the development commitment to keep it going. All Fedora artwork visible in critical path actions on release-blocking desktops must be consistent with the proposed final theme. Maybe must not be inconsistent? They are hardly consistent now. Plymouth theme is the same for years, GDM background has nothing to do with desktop background. Maybe drop the sentence completely? -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Re: F19 Final criteria revamp
On Jun 11, 2013, at 3:37 AM, Jóhann B. Guðmundsson johan...@gmail.com wrote: here's what Adam sait about that if ntfsresize fails for some reason, that wouldn't be a blocker. which kinda beats the purpose of the criteria right ( since no factory install of windows comes with available free space so the user always has to resize before or during the installation phaze ) Users installing Windows into a discrete space that's less than max available is the minority case, but that doesn't obviate the need for the criterion. Further, historically the part of the criterion that causes hold ups is the boot loader aspect, not resizing problems. If the anaconda team really considers resizing inherently risky and unpredictable, the operation needs to come with a warning to the user. Insofar as I'm aware, there is no such warning, or suggestion of alternatives: boot Windows and use its utility for resizing the file system. Then an install into free space is also possible. Chris Murphy -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Re: F19 Final criteria revamp
On 06/11/2013 12:37 AM, Jóhann B. Guðmundsson wrote: Installing to a freespace should be uncontroversial indeed it's the resize I was referring to and as afaik when you buy a set of hardware with windows installed it does not come with freespace available and we should only be supporting dealing with factory defaults but as Samuel points out earlier in the thread The criteria specifically refers to installing to freespace, so other than the single partition reference what is the problem? If the user wants to install alongside a default windows install, they will either have to resize the partitions on their own or risk letting the installer resize it (if it will). -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Re: F19 Final criteria revamp
On Tue, 2013-06-11 at 08:50 -0400, Kamil Paral wrote: Hey folks - so just ahead of the blocker meeting tomorrow, I'm done with the Final criteria rewrite. Thanks a lot, I reviewed them and they seem to be fine. Some comments below. I noticed that the upgrade criterion went missing. But we already have one in Beta, and it seems to be the same. What am I missing? Sorry, I should have noted that. You're missing that the 'old' criteria were tuned for the pre-F18 situation where we had multiple possible 'recommended' upgrade methods, to whit, preupgrade and 'boot an image and pick upgrade'. The Beta criteria required any single 'recommended' method to work. The Final criteria required all 'recommended' upgrade methods to work. Now we only have one 'recommended' upgrade method, so it seems unnecessary to keep that complexity. We can always add it back if we grow another 'recommended' upgrade method, which I sincerely hope we don't :) * I wrote an exception for hardware-based services when the hardware isn't present into the 'services' criterion: we waived a couple of 'blockers' for F18 on the basis that it's okay if a service fails if it's for hardware that isn't present, so I thought it made sense to write that into the criterion. (Obviously it's best if we can make the service not fire unless the hardware is present, but I don't think it makes sense to block the release on that kind of thing). The unless they require hardware which is not present phrase could be separated into a comment box, so that the original sentence is cleaner. Just an idea. True, it could. I'll try writing it up both ways and see which one looks best... SELinux and crash notifications There must be no SELinux denial notifications or crash notifications after boot of a release-blocking live image or at first login after a default install of a release-blocking desktop. Should we add during installation as well? Wrt the bug discussed in the last blocker bug meeting. Hum, somehow I thought I had, but I must've got confused (I was juggling a few things while I was doing the rewrite). Indeed we should add that. Thanks. The non-live installer does not have the facility to display AVC alerts so we're covered there, but can crop up during live installs. * I watered down the 'desktop' criteria quite a bit. Looking at them afresh I really think we were kind of over-reaching when we wrote them for F13: I remember we were thinking about 'polish criteria', but now we've had this process in place for a while, it really doesn't make sense to block the release on fairly trivial 'polish' issues (especially when we happily ship with much bigger issues in slightly different other areas). So I nuked the 'icons can't be fuzzy' requirement, the requirement for Help and About menus to be present, and the bit about apps not showing up twice in the menus. Those are all nice things to check, but I really don't think we need to be blocking releases on them. I agree. These issues were too trivial to block release on. Still, I'd like to see /someone/ to ensure the polish. It would be great to have both QA team and Polish (UX) team. At present, we need to handle that. But this change is fine. I'm looking forward to simplifying the test cases. Yes, I agree we shouldn't lose the goal of trying to take care of polish entirely. Pity the desktop team isn't going to be at Flock :( * I watered down the artwork criterion yet further: the initial idea was that we were going to be super-keen about having a consistent background graphic from bootloader to desktop, but that's really fallen by the wayside since F14 or so. Given our overall boot process nowadays, it only seems particularly important to make sure we use the right image for the desktop background. It'd be great if the project goes back to that goal, but clearly so far there hasn't been the development commitment to keep it going. All Fedora artwork visible in critical path actions on release-blocking desktops must be consistent with the proposed final theme. Maybe must not be inconsistent? They are hardly consistent now. Plymouth theme is the same for years, GDM background has nothing to do with desktop background. Maybe drop the sentence completely? Probably best to run it by the artwork team. I thought the 'must be consistent' wording was sufficiently weaselly to let us wave through stuff that isn't outrageously incongruent, but maybe it doesn't serve much of a purpose any more. Thanks for your thoughts! I'm planning to go back through and twiddle it based on all the feedback from various people at some point this week, then present a revised draft for review. -- 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:
Re: F19 Final criteria revamp
On Tue, 2013-06-11 at 08:51 -0400, Chris Murphy wrote: On Jun 11, 2013, at 3:37 AM, Jóhann B. Guðmundsson johan...@gmail.com wrote: here's what Adam sait about that if ntfsresize fails for some reason, that wouldn't be a blocker. which kinda beats the purpose of the criteria right ( since no factory install of windows comes with available free space so the user always has to resize before or during the installation phaze ) Users installing Windows into a discrete space that's less than max available is the minority case, but that doesn't obviate the need for the criterion. Further, historically the part of the criterion that causes hold ups is the boot loader aspect, not resizing problems. If the anaconda team really considers resizing inherently risky and unpredictable, the operation needs to come with a warning to the user. Insofar as I'm aware, there is no such warning, or suggestion of alternatives: boot Windows and use its utility for resizing the file system. Then an install into free space is also possible. I think the old anaconda did have a warning about resize operations. If newUI doesn't, then yeah, maybe it should. -- 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: F19 Final criteria revamp
On Tue, 2013-06-11 at 19:17 -0700, Samuel Sieb wrote: On 06/11/2013 12:37 AM, Jóhann B. Guðmundsson wrote: Installing to a freespace should be uncontroversial indeed it's the resize I was referring to and as afaik when you buy a set of hardware with windows installed it does not come with freespace available and we should only be supporting dealing with factory defaults but as Samuel points out earlier in the thread The criteria specifically refers to installing to freespace, so other than the single partition reference what is the problem? If the user wants to install alongside a default windows install, they will either have to resize the partitions on their own or risk letting the installer resize it (if it will). I can kinda see Johann's point, which is that - since most dual boot installs will require a resize - if we don't 'support' resize, we're really not 'supporting' dual boot installs. He's not wrong. But overall, I think it's worthwhile having the criterion to ensure that, as cmurf said, we at least make sure we get the bootloader stuff right at release 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: F19 Final criteria revamp
On Sun, 2013-06-09 at 23:34 -0400, Chris Murphy wrote: On Jun 5, 2013, at 12:55 AM, Adam Williamson awill...@redhat.com wrote: * We were covering bootloaders in a half-assed way in the Windows dual boot criterion, but that seemed kinda dumb, so I figured it would make sense to break out an explicit bootloader criterion: The installer must allow the user to choose which disk the system bootloader will be installed to, and to choose not to install one at all. In practice that's basically what we required to work for F18. I'd like to point out a problem with the existing #9 final criterion, which reads: • 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. It seems the single-partition requirement has been unreasonable for a long time, since Windows 7/8 OEM installations are multi-partition, and if the disk partition is erased and Windows 7/8 is re-installed on an unpartitioned disk, it creates multiple partition installations. Oh, yes - I forgot to mention it in my write-up, but I actually recalled you raising that issue before, and adjusted the text of the rewritten criterion somewhat. Could you take a look and see if it's better now, or still needs improving? Thanks. In particular, what's the default 'multi-partition' layout of Win7/8? I don't think I've seen a stock install of either (I still use an old copy of XP for Windows testing, here.) -- 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: F19 Final criteria revamp
On 06/10/2013 07:51 AM, Adam Williamson wrote: On Sun, 2013-06-09 at 23:34 -0400, Chris Murphy wrote: On Jun 5, 2013, at 12:55 AM, Adam Williamson awill...@redhat.com wrote: * We were covering bootloaders in a half-assed way in the Windows dual boot criterion, but that seemed kinda dumb, so I figured it would make sense to break out an explicit bootloader criterion: The installer must allow the user to choose which disk the system bootloader will be installed to, and to choose not to install one at all. In practice that's basically what we required to work for F18. I'd like to point out a problem with the existing #9 final criterion, which reads: • 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. It seems the single-partition requirement has been unreasonable for a long time, since Windows 7/8 OEM installations are multi-partition, and if the disk partition is erased and Windows 7/8 is re-installed on an unpartitioned disk, it creates multiple partition installations. Oh, yes - I forgot to mention it in my write-up, but I actually recalled you raising that issue before, and adjusted the text of the rewritten criterion somewhat. Could you take a look and see if it's better now, or still needs improving? Thanks. In particular, what's the default 'multi-partition' layout of Win7/8? I don't think I've seen a stock install of either (I still use an old copy of XP for Windows testing, here.) We should just drop that entirely. Our criteria should not depend on windows ( or any other OS for that matter ) nor can we expect all users to own a windows or require it from them to obtain it legally or illegally just so this get's tested. Red Hat can just keep this criteria for RHEL if that's the reason for it to exist there in the first place in since it can supply it's employees with valid Microsoft releases to test against. JBG -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Re: F19 Final criteria revamp
We should just drop that entirely. Our criteria should not depend on windows ( or any other OS for that matter ) They don't depend on Windows, they depend on our tools that detect Windows. nor can we expect all users to own a windows or require it from them to obtain it legally or illegally just so this get's tested. We don't have to have this tested. If there are no bug reports, there's probably nothing to fix. OTOH, sure, it's better when it gets tested. If we have the means. Red Hat can just keep this criteria for RHEL if that's the reason for it The reason is that Windows dual-boot is very important for our users and we are usually capable of making sure it works. If you want to have no user base, sure, dump Windows support. to exist there in the first place in since it can supply it's employees with valid Microsoft releases to test against. Microsoft provides Windows 8 evaluation copies that you can use legally and for free. Of course, IANAL. And we don't seem to lack for community testers that have a Windows installation present. -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Re: F19 Final criteria revamp
On 06/10/2013 10:08 AM, Kamil Paral wrote: We should just drop that entirely. Our criteria should not depend on windows ( or any other OS for that matter ) They don't depend on Windows, they depend on our tools that detect Windows. nor can we expect all users to own a windows or require it from them to obtain it legally or illegally just so this get's tested. We don't have to have this tested. If there are no bug reports, there's probably nothing to fix. OTOH, sure, it's better when it gets tested. If we have the means. Red Hat can just keep this criteria for RHEL if that's the reason for it The reason is that Windows dual-boot is very important for our users and we are usually capable of making sure it works. If you want to have no user base, sure, dump Windows support. Our user base is Fedora users not Windows users or dual booting users and more or less every shipped hardware in the past five years has supported virtualization ( even more so HW requirements for running windows Vista/7/8 not sure if XP is still supported by Microsoft ) which is the area we should be focusing on supporting well as in running Fedora in other OS supported/provided virtualization or running other OS in the virtualization we provide ( there is no such thing as support in Fedora ). Quite frankly dual booting is a thing of the past and it should be dropped from the criteria. JBG -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Re: F19 Final criteria revamp
On 2013-06-10 10:49 (GMT) Jóhann B. Guðmundsson composed: Quite frankly dual booting is a thing of the past and it should be dropped from the criteria. Yet another Fedora way to alienate users. While dual booting is indeed a thing of the '80's, multibooting isn't going away just because virtualization exists. Virtually all my 30+ usable systems are multiboot, regardless whether their hardware supports virtualization. Most of them don't. Virtualization is emulation, faking. Some testing requires using real hardware. Some environments require using real hardware. Some users require real hardware. Even if I personally embraced the concept of virtualization as a replacement for multiboot, I wouldn't want to use a host OS with a mere 18 month support life. -- 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: F19 Final criteria revamp
On 06/10/2013 11:56 AM, Felix Miata wrote: Yet another Fedora way to alienate users. While dual booting is indeed a thing of the '80's, multibooting isn't going away just because virtualization exists. Virtually all my 30+ usable systems are multiboot, regardless whether their hardware supports virtualization. Most of them don't. And in what are you using those 30+ usable system and why aren't you running Fedora only on them? Virtualization is emulation, faking. Some testing requires using real hardware. Some environments require using real hardware. Some users require real hardware. Even if I personally embraced the concept of virtualization as a replacement for multiboot, I wouldn't want to use a host OS with a mere 18 month support life. Then perhaps Fedora is not the distribution for you to use since it has such an short life cycle ( 13 months ) + we are just talking about removing this from the release critera not stop supporting this. JBG -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Re: F19 Final criteria revamp
On Jun 10, 2013, at 4:46 AM, Jóhann B. Guðmundsson johan...@gmail.com wrote: We should just drop that entirely. That's unrealistic. Our criteria should not depend on windows ( or any other OS for that matter ) nor can we expect all users to own a windows or require it from them to obtain it legally or illegally just so this get's tested. Well it's a matter of some recruitment and volunteering of interested parties to do some testing before the product goes final, isn't it? I don't think any of the hard core testers should be required to buy it. Some impetus is on users with a vested interest in it working to do the testing, and presumably they have it. On Jun 10, 2013, at 6:49 AM, Jóhann B. Guðmundsson johan...@gmail.com wrote: Our user base is Fedora users not Windows users or dual booting users and more or less every shipped hardware in the past five years has supported virtualization Quite frankly dual booting is a thing of the past and it should be dropped from the criteria. This is specious. Fedora users depend on dual boot more than RHEL users, not the other way around. Fedora users largely depend on another OS as their primary OS. Of those perhaps most are virtualizing Fedora in a non-KVM environment, and the second is baremetal dual boot. Dual boot capability is important because it creates the condition to improve linux's ability to run on a variety of hardware, video card drivers and so forth. If linux runs well to excellent, then running Windows (or OS X) in qemu/kvm is then realistic. On a whole lot of hardware that's just not the case. Chris Murphy -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Re: F19 Final criteria revamp
On 06/10/2013 12:57 PM, Chris Murphy wrote: On Jun 10, 2013, at 4:46 AM, Jóhann B. Guðmundssonjohan...@gmail.com wrote: We should just drop that entirely. That's unrealistic. There is nothing unrealistic removing it from the criteria but still retain the test case(s) like we do for other things that people want to have tested without having it blocking the release... JBG -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Re: F19 Final criteria revamp
On Mon, 2013-06-10 at 08:38 -0400, Chris Murphy wrote: On Jun 10, 2013, at 3:51 AM, Adam Williamson awill...@redhat.com wrote: Could you take a look and see if it's better now, or still needs improving? Criterion reads: The installer must be able to install into free space alongside an existing clean Windows installation and install a bootloader which can boot into both Windows and Fedora. There was a debate regarding dual boot (here is explained how to install the bootloader into the first sector of the partition) https://lists.fedoraproject.org/pipermail/users/2013-January/429440.html After all, why to get rid of this way of dual boot capability for non UEFI systems, for non encrypted dual boot? What is the big advantage to not have that? Cristian Sava -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Re: F19 Final criteria revamp
On 2013-06-10 12:04 (GMT) Jóhann B. Guðmundsson composed: On 06/10/2013 11:56 AM, Felix Miata wrote: Yet another Fedora way to alienate users. While dual booting is indeed a thing of the '80's, multibooting isn't going away just because virtualization exists. Virtually all my 30+ usable systems are multiboot, regardless whether their hardware supports virtualization. Most of them don't. And in what are you using those 30+ usable system They are all in the same building. and why aren't you running Fedora only on them? This is a test list, so I subscribe because I'm a tester. My role is discovering and reporting reproducible problems in software. Fedora is both testing tool and test subject. None of the testing I do requires a complete PC be constrained to a single operating system. -- 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: F19 Final criteria revamp
On 06/10/2013 02:38 PM, Felix Miata wrote: On 2013-06-10 12:04 (GMT) Jóhann B. Guðmundsson composed: On 06/10/2013 11:56 AM, Felix Miata wrote: Yet another Fedora way to alienate users. While dual booting is indeed a thing of the '80's, multibooting isn't going away just because virtualization exists. Virtually all my 30+ usable systems are multiboot, regardless whether their hardware supports virtualization. Most of them don't. And in what are you using those 30+ usable system They are all in the same building. So being in the same building is why you are multi booting them? and why aren't you running Fedora only on them? This is a test list, so I subscribe because I'm a tester. My role is discovering and reporting reproducible problems in software. Fedora is both testing tool and test subject. None of the testing I do requires a complete PC be constrained to a single operating system. You could just as well wipe those machine clean and perform a fresh OS test on a fresh install ( along with what ever hw driver development you are into ) of what ever OS you have running each time you are performing test. JBG -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Re: F19 Final criteria revamp
It absolutely should block the release as there's no way to fix it after the fact. Dropping the requirement for sane multiboot behavior isn't a good idea. (Sane being, it's possible and does no harm to the existing system.) Chris Murphy -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Re: F19 Final criteria revamp
Cristian Sava wrote: After all, why to get rid of this way of dual boot capability for non UEFI systems, for non encrypted dual boot? What is the big advantage to not have that? Because anaconda devs don't want to support what grub devs recommend against. I think the former is reasonable. Some ext devs think grub devs are being overly cautious. But the reality is, grub does support embedding to a partition without force for filesystems with a large enough boot loader pad, such as Btrfs which has a 64kb pad. Ext's is 1024k, not nearly big enough for grub's core.img. Chris Murphy -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Re: F19 Final criteria revamp
On 2013-06-10 14:57 (GMT) Jóhann B. Guðmundsson composed: And in what are you using those 30+ usable system They are all in the same building. So being in the same building is why you are multi booting them? No. I really don't understand the question or why you are asking it. and why aren't you running Fedora only on them? This is a test list, so I subscribe because I'm a tester. My role is discovering and reporting reproducible problems in software. Fedora is both testing tool and test subject. None of the testing I do requires a complete PC be constrained to a single operating system. You could just as well wipe those machine clean and perform a fresh OS test on a fresh install ( along with what ever hw driver development you are into ) of what ever OS you have running each time you are performing test. I test diverse kinds of software. Operating systems are just one software class among them. OS installation is among the most time consuming and lowest priority tests I perform. I often clone and upgrade the clone in order to avoid the OS installation process. Due to my experience with the pre-release F18 installer, all my F19 installations have been made via partition clone and Yum upgrade. I repeat: Fedora here is both testing tool and test subject. Interference between the two functions needs to be limited. Wiping is antithetical to my limitation methodology and primary goals. -- 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: F19 Final criteria revamp
On 06/10/2013 03:46 PM, Felix Miata wrote: On 2013-06-10 14:57 (GMT) Jóhann B. Guðmundsson composed: And in what are you using those 30+ usable system They are all in the same building. So being in the same building is why you are multi booting them? No. I really don't understand the question or why you are asking it. To see if there is an actual reason for you to be using multiboot in the first place. What exactly are you developing or test being developed? and why aren't you running Fedora only on them? This is a test list, so I subscribe because I'm a tester. My role is discovering and reporting reproducible problems in software. Fedora is both testing tool and test subject. None of the testing I do requires a complete PC be constrained to a single operating system. You could just as well wipe those machine clean and perform a fresh OS test on a fresh install ( along with what ever hw driver development you are into ) of what ever OS you have running each time you are performing test. I test diverse kinds of software. Operating systems are just one software class among them. OS installation is among the most time consuming and lowest priority tests I perform. I often clone and upgrade the clone in order to avoid the OS installation process. Due to my experience with the pre-release F18 installer, all my F19 installations have been made via partition clone and Yum upgrade. So you are using unsupported method of upgrading Fedora to test your application on Fedora and your company supports running application on a upgraded host which is a) upgraded b) via the unofficial method of the distribution? I repeat: Fedora here is both testing tool and test subject. Interference between the two functions needs to be limited. Wiping is antithetical to my limitation methodology and primary goals. And what I'm saying we should not blocking the release for that. We are first and foremost shipping our distribution to be used as primary OS on our users HW just like any other OS does. JBG -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Re: F19 Final criteria revamp
On Mon, 2013-06-10 at 15:58 +, Jóhann B. Guðmundsson wrote: And what I'm saying we should not blocking the release for that. We are first and foremost shipping our distribution to be used as primary OS on our users HW just like any other OS does. NO, you have not valid reasons to avoid the requirement for sane multiboot behavior (sane being, it's possible and does no harm to the existing system) as Chris Murphy stated. Fedora have to just install, work and do not harm. And NO, IT IS NOT A GOOD IDEA. The user have to be able to choose what and how to install on his PC. Cristian Sava -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Re: F19 Final criteria revamp
On Mon, 2013-06-10 at 08:38 -0400, Chris Murphy wrote: On Jun 10, 2013, at 3:51 AM, Adam Williamson awill...@redhat.com wrote: Could you take a look and see if it's better now, or still needs improving? Criterion reads: The installer must be able to install into free space alongside an existing clean Windows installation and install a bootloader which can boot into both Windows and Fedora. a. Since free space is atypical, this phrasing implies the installer doesn't need to be able to resize or resize correctly. Since it's an offered scenario in the installer, I think at this point it should be required to work and thus incorporated into the criterion. That is indeed the implication, it's intentional, and I wouldn't want to change it without input from the anaconda team. Their position is that resizing is inherently a risky and unpredictable operation that we cannot guarantee the functionality of, but we should be able to guarantee what's written in the criterion. I suppose we could try and come up with a tightly-worded criterion that the resize mechanism in the installer must not be broken - so it should 'do what it's supposed to do', but if ntfsresize fails for some reason, that wouldn't be a blocker. b. For BIOS installs, the requirement for the bootloader to boot both Windows and Fedora is reasonable. It's probably not reasonable, still, for UEFI. GRUB2+os-prober really isn't acting as a suitable replacement Boot Manager, so the user either needs to use the firmware boot manager to choose a bootloader (bootmgr.efi for Windows, grubx64.efi for Fedora), or some other boot manager (rEFInd or gummiboot). Well, I see the point, but at the same time, we are finding out that in the Real World, it's a really bad idea to depend on the EFI boot manager because it just isn't being presented to the user in a sane way in enough of the real UEFI implementations. So we might actually want to keep that requirement, and fix up os-prober (which we're currently working on). We'll have to see what pjones' take on that is. Clean Windows installation reveal reads in part: The expected scenario is a cleanly installed or OEM-deployed Windows installation into a single partition. Issues caused by recovery or 'system' partitions may not be considered to violate this criterion, depending on the specific circumstances. I think those two sentences are unworkable. OEM deployed Windows is multi-partition. In particular, what's the default 'multi-partition' layout of Win7/8? I've only recently BIOS installed Windows 7, and it's two partitions to an unpartitioned disk. I think for EFI installing Windows 7, it's three partitions. For Windows 8 EFI, it's four partitions, so I'll guess it's one less for BIOS. What are the partitions? -- 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: F19 Final criteria revamp
On Mon, 2013-06-10 at 08:46 +, Jóhann B. Guðmundsson wrote: We should just drop that entirely. Our criteria should not depend on windows ( or any other OS for that matter ) nor can we expect all users to own a windows or require it from them to obtain it legally or illegally just so this get's tested. Red Hat can just keep this criteria for RHEL if that's the reason for it to exist there in the first place in since it can supply it's employees with valid Microsoft releases to test against. No, the criterion has nothing to do with RHEL. I don't know if multi-boot is even a supported deployment method for RHEL (I suspect not, but I have absolutely no idea). It was created as part of the original criteria effort at F13 because this is something people generally expect Linux distributions to be able to do, and they get angry if they can't. Each time this has been brought up since, it's seemed fairly clear that the majority of people still believe this should be the case, even though you think it's now a 'legacy' thing. -- 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: F19 Final criteria revamp
On 2013-06-10 15:58 (GMT) Jóhann B. Guðmundsson composed: On 06/10/2013 03:46 PM, Felix Miata wrote: On 2013-06-10 14:57 (GMT) Jóhann B. Guðmundsson composed: And in what are you using those 30+ usable system They are all in the same building. So being in the same building is why you are multi booting them? No. I really don't understand the question or why you are asking it. To see if there is an actual reason for you to be using multiboot in the first place. What exactly are you developing or test being developed? Diverse things. Among them, that developers are developing to meet convenience, needs and wishes of users rather than those of developers, and not just users whose eyesight is 50th percentile or better. Developers of all types too often forget not everyone's eyesight is not as good as their own. Another: whether a reported problem is reproducible or not, with or without matching the reporter's environment. Another: whether any particular OS installation can be made without disrupting prior multiboot installations. So you are using unsupported method of upgrading Fedora to test your application on Fedora and your company supports running application on a upgraded host which is a) upgraded b) via the unofficial method of the distribution? I test to see what works or not, and how well, not necessarily whether a particular procedure meets some definition of supported or official. I repeat: Fedora here is both testing tool and test subject. Interference between the two functions needs to be limited. Wiping is antithetical to my limitation methodology and primary goals. And what I'm saying we should not blocking the release for that. We are first and foremost shipping our distribution to be used as primary OS on our users HW just like any other OS does. So what you're saying is whether Fedora is satisfactory as a testing tool or secondary OS needn't be determined prior to release; that it only matters that it works for those who use it as a sole OS. Myopic is thinking few or unimportant those that would want bleeding edge as sole or secondary to something with maximum stability and broadest support, a good way to alienate both common users and community contributors. -- 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: F19 Final criteria revamp
On 06/10/2013 04:33 PM, Adam Williamson wrote: On Mon, 2013-06-10 at 08:46 +, Jóhann B. Guðmundsson wrote: We should just drop that entirely. Our criteria should not depend on windows ( or any other OS for that matter ) nor can we expect all users to own a windows or require it from them to obtain it legally or illegally just so this get's tested. Red Hat can just keep this criteria for RHEL if that's the reason for it to exist there in the first place in since it can supply it's employees with valid Microsoft releases to test against. No, the criterion has nothing to do with RHEL. I don't know if multi-boot is even a supported deployment method for RHEL (I suspect not, but I have absolutely no idea). It was created as part of the original criteria effort at F13 because this is something people generally expect Linux distributions to be able to do, and they get angry if they can't. Each time this has been brought up since, it's seemed fairly clear that the majority of people still believe this should be the case, even though you think it's now a 'legacy' thing. You mean few users here on the test list think it's a must thing afaik there has not been a system wide community survey regarding this ( and usually is not regarding things we deprecate ) JBG -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Re: F19 Final criteria revamp
On 06/10/2013 04:48 PM, Stephen John Smoogen wrote: Johann. DROP IT. Seriously. You are picking a fight just for the sake of a fight. I am sick and tired of you doing this every couple of months. If you can not express yourself in a better less You are an idiot because you disagree with me. point of view, take a break and come back when you can. Seriously stay out of my way and find someone else to pick on in this community I cannot express myself without you butting in. JBG -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Re: F19 Final criteria revamp
On 06/10/2013 04:53 PM, Felix Miata wrote: So what you're saying is whether Fedora is satisfactory as a testing tool or secondary OS needn't be determined prior to release; that it only matters that it works for those who use it as a sole OS. Yes that our primary focus should be the only OS ( which is afaik what other OS like Microsoft Windows or Apple does ) running and as secondary OS as a virtual guest ( or guest container for that matter ). Resize and refitting another OS along with already installed one on the same hardware ( disks ) is not something I see as we should or could be officially supporting hence we should not be blocking our release for that. Windows or Apple or some other OS changes it partition filesystem etc. and we need to delay our release until we have played catchup to those changes. JBG -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Re: F19 Final criteria revamp
On 2013-06-10 17:51 (GMT) Jóhann B. Guðmundsson composed: On 06/10/2013 04:53 PM, Felix Miata wrote: So what you're saying is whether Fedora is satisfactory as a testing tool or secondary OS needn't be determined prior to release; that it only matters that it works for those who use it as a sole OS. Yes that our primary focus should be the only OS Primary focus? Or sole focus? The two are not the same. ( which is afaik what other OS like Microsoft Windows or Apple does ) It's not what other top 10 distros do. running and as secondary OS as a virtual guest ( or guest container for that matter ). Resize and refitting another OS along with already installed one on the same hardware ( disks ) is not something I see as we should or could be officially supporting hence we should not be blocking our release for that. Newbie: Which Linux distro should I try? Puter geek: It makes little difference, as long as you don't pick Fedora. Fedora will screw your system so you can no longer use what you have on it now. -- 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: F19 Final criteria revamp
On 06/10/2013 06:09 PM, Felix Miata wrote: On 2013-06-10 17:51 (GMT) Jóhann B. Guðmundsson composed: On 06/10/2013 04:53 PM, Felix Miata wrote: So what you're saying is whether Fedora is satisfactory as a testing tool or secondary OS needn't be determined prior to release; that it only matters that it works for those who use it as a sole OS. Yes that our primary focus should be the only OS Primary focus? Or sole focus? The two are not the same. Primary as in we should test this but not block the release for it not working ( which is afaik what other OS like Microsoft Windows or Apple does ) It's not what other top 10 distros do. First in our foundation indicates we should be leading not following ;) running and as secondary OS as a virtual guest ( or guest container for that matter ). Resize and refitting another OS along with already installed one on the same hardware ( disks ) is not something I see as we should or could be officially supporting hence we should not be blocking our release for that. Newbie: Which Linux distro should I try? And the opposide part of the coin Fedora just try the live cd/dvd and see if it works out for you if it does you can install it from the live... JBG -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Re: F19 Final criteria revamp
On 06/10/2013 12:51 AM, Adam Williamson wrote: still needs improving? Thanks. In particular, what's the default 'multi-partition' layout of Win7/8? I don't think I've seen a stock install of either (I still use an old copy of XP for Windows testing, here.) I recently had the fun of installing Fedora beside Windows 7 on more than 10 different laptops. (This was for a class where the students were required to provide their own laptops.) The number of Windows partitions varied from 2 to 4. The 4 partition case required me to delete one of them because they were all primary partitions! Sorry, I don't remember what the contents were on the partitions. My guess of the options was boot, main OS, user data, system (BIOS config?), recovery. There was one Windows 8 laptop which was easier because it used GPT so I didn't have to mess with the partitions other than resizing them. -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Re: F19 Final criteria revamp
On Mon, 2013-06-10 at 17:33 +, Jóhann B. Guðmundsson wrote: On 06/10/2013 04:33 PM, Adam Williamson wrote: On Mon, 2013-06-10 at 08:46 +, Jóhann B. Guðmundsson wrote: We should just drop that entirely. Our criteria should not depend on windows ( or any other OS for that matter ) nor can we expect all users to own a windows or require it from them to obtain it legally or illegally just so this get's tested. Red Hat can just keep this criteria for RHEL if that's the reason for it to exist there in the first place in since it can supply it's employees with valid Microsoft releases to test against. No, the criterion has nothing to do with RHEL. I don't know if multi-boot is even a supported deployment method for RHEL (I suspect not, but I have absolutely no idea). It was created as part of the original criteria effort at F13 because this is something people generally expect Linux distributions to be able to do, and they get angry if they can't. Each time this has been brought up since, it's seemed fairly clear that the majority of people still believe this should be the case, even though you think it's now a 'legacy' thing. You mean few users here on the test list think it's a must thing afaik there has not been a system wide community survey regarding this ( and usually is not regarding things we deprecate ) Well, let me put it more baldly: up till now I can't recall a single person agreeing with you that we should stop blocking on basic multiboot-alongside-a-simple-Windows-install. Not a single person. I agree we have a very small sample size on this list, but still, that seems pretty indicative. I can run a forum poll if you like, though... -- 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: F19 Final criteria revamp
On 06/10/2013 07:09 PM, Adam Williamson wrote: Well, let me put it more baldly: up till now I can't recall a single person agreeing with you that we should stop blocking on basic multiboot-alongside-a-simple-Windows-install. Not a single person. I agree we have a very small sample size on this list, but still, that seems pretty indicative. I can run a forum poll if you like, though... More appropriate place then a forum poll or this mailing list would be in the survey the boards working on. JBG -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Re: F19 Final criteria revamp
On 2013-06-10 18:16 (GMT) Jóhann B. Guðmundsson composed: Primary as in we should test this but not block the release for it not working The dangerous not working mode is screwing up the target so what was functional there is no longer. Do you remember as well as I Disk Druid's capacity for destruction? Early on it lead me from RedHat to Mandrake and away from partitioners included on installation media. First do no harm needs testing. First in our foundation indicates we should be leading not following ;) Fine, as long as those ultimately responsible for the choice of path and those implementing it aren't myopic, and the path chosen is one real users are interested to take. It is no success to excel at something none care about. Newbie: Which Linux distro should I try? And the opposide part of the coin Fedora just try the live cd/dvd and see if it works out for you if it does you can install it from the live... Works from live media does not equate to successfully install from live media. -- 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: F19 Final criteria revamp
Date: Mon, 10 Jun 2013 19:10:19 + From: johan...@gmail.com To: test@lists.fedoraproject.org Subject: Re: F19 Final criteria revamp On 06/10/2013 07:09 PM, Adam Williamson wrote: Well, let me put it more baldly: up till now I can't recall a single person agreeing with you that we should stop blocking on basic multiboot-alongside-a-simple-Windows-install. Not a single person. I agree we have a very small sample size on this list, but still, that seems pretty indicative. I can run a forum poll if you like, though... More appropriate place then a forum poll or this mailing list would be in the survey the boards working on. JBG -- Dude, I think it is pretty well known that I think Microsoft could take a flying at a donut. However, I know that there are plenty of people that aren't quite willing to totally commit to Linux. Therefore, this is a totally valid, and even needed criteria. As far as RHEL, I rather doubt that RHEL's target audiance would be dual-booting servers ... John. -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Re: F19 Final criteria revamp
On Jun 10, 2013, at 1:51 PM, Jóhann B. Guðmundsson johan...@gmail.com wrote: Resize and refitting another OS along with already installed one on the same hardware ( disks ) is not something I see as we should or could be officially supporting hence we should not be blocking our release for that. Certainly installing to free space should be uncontroversial. I don't care to understand the idea that user choice should only apply to FOSS. You either believe in user choice or you don't, it is a fairly binary position regardless of the software's license. The installer supports it, and considering the damage that could be done is in the category of data loss, yes it needs to have a suitable release blocking criterion. Windows or Apple or some other OS changes it partition filesystem etc. and we need to delay our release until we have played catchup to those changes. Please, Microsoft and Apple have file systems from the Pleistocene. And it's already the case that HFS+ isn't resized by anaconda (or any linux tools at all insofar as I'm aware). If the file system changes, it'll indicate a version change in a way identifiable to the installer's support utilities, or it won't be an identifiable system at all. In either case the installer should refuse to resize. Chris Murphy -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Re: F19 Final criteria revamp
On Jun 5, 2013, at 12:55 AM, Adam Williamson awill...@redhat.com wrote: * We were covering bootloaders in a half-assed way in the Windows dual boot criterion, but that seemed kinda dumb, so I figured it would make sense to break out an explicit bootloader criterion: The installer must allow the user to choose which disk the system bootloader will be installed to, and to choose not to install one at all. In practice that's basically what we required to work for F18. I'd like to point out a problem with the existing #9 final criterion, which reads: • 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. It seems the single-partition requirement has been unreasonable for a long time, since Windows 7/8 OEM installations are multi-partition, and if the disk partition is erased and Windows 7/8 is re-installed on an unpartitioned disk, it creates multiple partition installations. Chris Murphy -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
F19 Final criteria revamp
Hey folks - so just ahead of the blocker meeting tomorrow, I'm done with the Final criteria rewrite. For now I've put it in a 'sandbox' space because I did make a few changes on-the-fly and they should get reviewed before we replace the old page, but if people think it's a good idea, we can use them for the meeting tomorrow. Here's the new version: https://fedoraproject.org/wiki/User:Adamwill/Draft_final_criteria_sandbox The current one is of course at https://fedoraproject.org/wiki/Fedora_19_Final_Release_Criteria for comparison. Most of the changes I made are fairly minor tweaks to make the meanings more robust and stuff, but here's some more significant things I thought it made sense to change: * I made the 'checksum verification' thing a lot simpler; the existing one was written in two stages which made it read more complicated than it really needed to be. * I re-worded the 'catch-all' partitioning criterion to refer to any file system and/or container format combination offered in a default installer configuration. It doesn't really make a functional difference I don't think, it just reads more clearly and is more 'future-proof'. * We were covering bootloaders in a half-assed way in the Windows dual boot criterion, but that seemed kinda dumb, so I figured it would make sense to break out an explicit bootloader criterion: The installer must allow the user to choose which disk the system bootloader will be installed to, and to choose not to install one at all. In practice that's basically what we required to work for F18. * I 'cloned' the translation criterion for the installer; we were really intending the installer to be covered by the existing criterion, but it really wasn't clear in the wording. This way seemed more clear. * I wrote an exception for hardware-based services when the hardware isn't present into the 'services' criterion: we waived a couple of 'blockers' for F18 on the basis that it's okay if a service fails if it's for hardware that isn't present, so I thought it made sense to write that into the criterion. (Obviously it's best if we can make the service not fire unless the hardware is present, but I don't think it makes sense to block the release on that kind of thing). * I watered down the 'desktop' criteria quite a bit. Looking at them afresh I really think we were kind of over-reaching when we wrote them for F13: I remember we were thinking about 'polish criteria', but now we've had this process in place for a while, it really doesn't make sense to block the release on fairly trivial 'polish' issues (especially when we happily ship with much bigger issues in slightly different other areas). So I nuked the 'icons can't be fuzzy' requirement, the requirement for Help and About menus to be present, and the bit about apps not showing up twice in the menus. Those are all nice things to check, but I really don't think we need to be blocking releases on them. * I watered down the artwork criterion yet further: the initial idea was that we were going to be super-keen about having a consistent background graphic from bootloader to desktop, but that's really fallen by the wayside since F14 or so. Given our overall boot process nowadays, it only seems particularly important to make sure we use the right image for the desktop background. It'd be great if the project goes back to that goal, but clearly so far there hasn't been the development commitment to keep it going. Hope that covers everything! Yell if there's a change you can't see the reason for, and of course, all normal suggestions/improvements/questions/whatever welcome. Thanks folks! -- 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
