Second draft of revised final criteria, proposed criterion for partition resizing

[Adam Williamson]

On 2013-07-04 2:23, Kamil Paral wrote:
>> Hi folks! Taking into account the feedback on the first draft of the
>> revised criteria, I've updated the draft page with a few changes:
> 
> Here's the diff:
> https://fedoraproject.org/w/index.php?title=User%3AAdamwill%2FDraft_final_criteria_sandbox&diff=343808&oldid=340486
> 
> Looks good to me.
> 
>> I'd also like to consider adding a criterion that covers resizing, as
>> discussed in the long thread about dual-booting. I think we can add a
>> minimal criterion that's realistically enforceable if we word it 
>> right.
>> Let's make that a proposal here on the list, rather than part of the
>> 'revision' draft, though. So, here's my proposal:
>> 
>> ++++++++++++++++++++
>> 
>> Any installer mechanism for resizing storage volumes must correctly
>> attempt the requested operation.
>> 
>> Sub-section "What does that cover?":
>> 
>> 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 - then fails. We
>> only want to cover the case that the installer's resize code itself is
>> badly broken.
>> 
>> ++++++++++++++++++++
> 
> Hmm, shouldn't we at least hold our ground for Linux-native
> filesystems? If there's a bug in e2resize that wipes the partition
> clean during resize, on every attempt regardless of circumstances, it
> wouldn't be covered by our criteria. Shouldn't that be?

Whoops, sorry: I actually thought down that avenue and concluded that 
any such bug is covered by the 'bugs that cause data loss must be fixed 
or documented' criterion. So we don't need to explicitly include it in 
the resize criterion. Perhaps it would be good to explain this in a 
sub-paragraph, though, it's exactly the kind of non-obvious reasoning we 
need to make explicit. I'll add one.

> As for ntfsresize, if we (Fedora) don't want to guarantee it working
> (and we never might, since it's a closed thing), Anaconda should at
> least warn the user that the operation is not safe and something might
> go wrong (therefore you should back up first, et cetera et cetera). If
> the user is aware of this, then we don't need to ensure proper
> functionality of ntfsresize, just of anaconda code, as you propose. Or
> if we go without a warning, we should make sure ntfsresize is
> generally working OK (sure, doesn't have to be in all circumstances,
> but mostly so).

That's probably a good idea. I thought for some reason I came across an 
existing bug report for it yesterday, but now I can't find it...
-- 
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | identi.ca: adamwfedora
http://www.happyassassin.net