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" <johannbg@xxxxxxxxx> 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@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
