Re: Encrypted volume release criteria

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Fri, Mar 20, 2015 at 12:55 AM, Adam Williamson
<adamwill@xxxxxxxxxxxxxxxxx> wrote:
> On Thu, 2015-03-19 at 23:15 -0600, Chris Murphy wrote:
>> Tackling this one separately:
>>
>> Current Fedora 22 final release criteria of concern and some distain:
>>
>> "The installer must be able to create and install to any workable
>> partition layout using any file system and/or container format
>> combination offered in a default installer configuration."
>>
>> That's a lot of concepts to chew off in a single sentence, I can
>> hardly imagine how long that'd take to translate into another
>> language. Including English!
>>
>> - as Fedora ships on official media, the installer supports XYZ
>> supported storage volume combinations;
>> - only those combinations are in context; not kickstart, not hand
>> editing the Python code, etc;
>> - if the user can compel the installer UI to create a storage volume
>> layout;
>> - the installer should create exactly that, and successfully install
>> Fedora to it.
>>
>> Is that a fair derivative restatement of that criterion?
>>
>> DRAFT: The Fedora supplied installer must successfully complete an
>> installation of Fedora to any layout the user creates in Manual
>> Partitioning.
>>
>> That pretty much says any possible combination of create, remove,
>> assign, with the installer itself as the guardian of what those
>> things can be, that the user can finagle out of the installer, must
>> result in a successful installation. Not unreasonable if there
>> should be trust in the UI. Either the installation must happen and
>> work, or the layout must not be permitted. *shrug*
>>
>> Could redirect the language it by replacing "must" with "should" to
>> make this a matter of honor and pride, rather than some sort of
>> weird edict coming at the last minute for final...
>
> Honestly, I don't think any of the language you're criticizing is as
> bad as you make it out to be.

Umm? Except you wrote that you hated it, thought it was silly, and
badly needing rewriting.


>But as a larger point - the problem with
> that criterion is not the language, the problem is *the criterion*. We
> have never actually lived up to it, and no-one really buys into living
> up to it.

First, never living up to it and not buying into living up to it,
means there's no actual or potential commitment to that criterion.
There's no point in rewriting it, just remove it.

Second, GUIs should be trustable. This isn't possible when
functionality is offered that happens to be functionally broken. The
basic notion of "if it is offered, it should work" is reasonable. But
you appear to be saying it's unrealistic, so I'd just say get rid of
the criterion.


> We need something narrower, but it's very hard to draft
> something specific that genuinely captures *everything* we want to
> block on at Final *but no more than that*.

What you'd like to block on at Final in addition to all criteria,
except the one under discussion, isn't something I'm privy to. So I
can't be specific with what I have available.


> Still, that's the problem
> that really could do with attention. Re-stating 'it's gotta do
> everything' isn't really solving any interesting problems.

False. Completely consistent with both versions of this criterion,
Manual Partitioning could vanish completely, and the installer would
meet it.

Whatever state Manual Partitioning UI is in at the time I click Done,
so long as it accepts Done, it should be able to complete an
installation per that implicit visual contract for an installation.
It's not at all "gotta do everything" unless the UI claims it can do
everything, in which case then yes it'd have to actually be able to do
everything.

This criterion is a UI delimiter, not a functionality mandate.


-- 
Chris Murphy
-- 
test mailing list
test@xxxxxxxxxxxxxxxxxxxxxxx
To unsubscribe:
https://admin.fedoraproject.org/mailman/listinfo/test





[Index of Archives]     [Fedora Desktop]     [Fedora SELinux]     [Photo Sharing]     [Yosemite Forum]     [KDE Users]

  Powered by Linux