Hi folks! So as promised on IRC here's a mail to discuss this issue. https://bugzilla.redhat.com/show_bug.cgi?id=1033778 is proposed as a release blocker. As I understand it, dlehman is strongly of the opinion that it shouldn't be accepted, on technical grounds. However, it does constitute a fairly clear violation of the release criteria. The bug - as I understand it - is that a particular type of partition ("Apple Core Storage" volumes, whatever those are) appears as "Unknown" in anaconda, and the guided install workflow (the "Reclaim Space" screen) allows you to try and resize it. If you do this, it fails to work at all and causes complete loss of all data on the partition. The Final release criteria state: "Any installer mechanism for resizing storage volumes must correctly attempt the requested operation." with a footnote: "This means that if the installer offers mechanisms for resizing storage volumes, then it must run the appropriate resizing tool with the appropriate parameters for the resize the user chooses. The reason it's worded this way is we specifically don't want to cover cases where the requested resize operation then fails for some reason - dirtily unmounted or over-fragmented partition, for instance. We only want to cover the case that the installer's resize code itself is badly broken." It seems pretty inarguable that as the criteria currently stand, this bug violates them, and thus it should be a Final release blocker. However, we delayed the decision at this week's blocker review meeting since we were aware you folks might want this not to be a blocker. For clarity, if it were to be accepted as a blocker, this would not mean that anaconda would be required to resize such partitions successfully, nor does it necessarily imply that anaconda must be able to *recognize* such partitions. So far as the blocker process is concerned it would be a sufficient resolution if *either* anaconda attempted to resize such partitions 'appropriately' (I'm not sure if that is even possible) *or* refused to attempt to resize them. The criteria do not, I think, place any effective restrictions on exactly *how* the latter resolution could be effected. So, I guess the question is: do we think the criteria should stand as written but this bug be rejected, and if so on what grounds? Do we think the criteria should be adjusted to reflect some kind of technical restriction? Or do we in fact think the bug should be accepted (and presumably the 'fix' should be to disallow resizing of this kind of partition somehow)? I asked on IRC whether it would be possible to disallow resizing of 'unknown' partitions. As I understand it the problem with this is it's difficult or impossible to distinguish between an empty partition and one that contains an unknown filesystem (and, presumably, one that is not empty, but contains garbage). I wonder, though, is that actually a problem? Do we need to allow 'resizing' of such partitions, or can we simply say that you should delete and recreate such partitions, and we will only allow the operation we call 'resizing' for partitions we definitely know the filesystem of and that we can safely resize that filesystem? Thanks! -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net http://www.happyassassin.net _______________________________________________ Anaconda-devel-list mailing list Anaconda-devel-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/anaconda-devel-list
