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