http://fedoraproject.org/wiki/Fedora_22_Beta_Release_Criteria
The only final release criteria pertaining to disk encryption has to do with keyboard support, so skipping that. For beta there is only one criteria applying to encrypted disks, and it reads:
When using the custom partitioning flow, the installer must be able to:
Correctly interpret, and modify as described below, any disk with a valid ms-dos or gpt disk label and partition table containing ext4 partitions, LVM and/or btrfs volumes, and/or software RAID arrays at RAID levels 0, 1 and 5 containing ext4 partitions [...snip...] Encrypt newly-created storage volumes
What about existing LUKS, which is a PV->VG containing LVs one of which is /home that the user wishes to preserve? The way this currently reads, it suggests only new LUKS volumes are supported?
Example bug I think is a beta blocker candidate: https://bugzilla.redhat.com/show_bug.cgi?id=1200749 I think this could be solved with a rewrite, moving the 1st bullet up and incorporating it with the lead text because the current 1st bullet states with "as described below" that subsequent bullets are further qualifiers of this main statement.
DRAFT rewrite of the thesis statement:
When using the custom partitioning flow, the installer must be able to correctly interpret, create, and modify any disk with valid ms-dos or gpt disk label; LVM volumes; LUKS volumes; software RAID sets levels 0, 1 and 5; ext4, XFS, or Btrfs file systems to:
## all of those storage types must be interpretable, createable, and modifiable; and if they already exist they must each be valid as a prerequisite for said interpreting, creating, and modifying. And this includes LUKS volumes.That alone pretty much fixes it, but then I think the bullets could be simplified as follows:
- Create, assign, or delete mount points to/from new and existing storage volumes - Assign sizes to newly-created storage volumes and containers - Remove existing or planned storage volumes (from the planned layout) ## sure the parenthetical part is necessary or adds clarity somehow) - Reject or disallow invalid disk and volume configurations without crashing
On Fri, Mar 13, 2015 at 1:36 PM, Chris Murphy lists@colorremedies.com wrote:
- Remove existing or planned storage volumes (from the planned layout)
## sure the parenthetical part is necessary or adds clarity somehow
## ^not sure
DRAFT 2:
When using the custom partitioning flow, the installer must be able to correctly interpret, create, and modify any disk containing storage volumes made from valid ms-dos or gpt disk label partitions; LVM; LUKS; software RAID sets levels 0, 1 and 5; ext4, XFS, or Btrfs file systems to:
## clearly define "storage volume" as any of MBR/GPT partitions, LVM, LUKS, and RAID sets.
- Create, assign, or delete mount points to/from new and existing storage volumes - Assign sizes to newly-created storage volumes - Remove existing or planned storage volumes - Reject or disallow invalid disk and volume configurations without crashing
## only change was to remove "and containers" from the 'Remove existing' bullet, since it's kinda superfluous when "storage volumes" is already defined. I'd also be OK with "storage containers" vs "storage volumes", it's sortof a minor distinction.
Chris Murphy
On Fri, 2015-03-13 at 13:36 -0600, Chris Murphy wrote:
http://fedoraproject.org/wiki/Fedora_22_Beta_Release_Criteria
The only final release criteria pertaining to disk encryption has to do with keyboard support, so skipping that. For beta there is only one criteria applying to encrypted disks, and it reads:
<snip>
First point: note that for Final we still have the catch-all criterion I hate more and more as time goes on:
"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."
which more or less means 'everything must work', which is clearly kind of silly, and badly needs rewriting. If we were to interpret it literally, it would already cover any kind of encryption support the installer offers.
If we pretend we don't have that criterion...
I kinda like the direction you're going in here, but I find the wording awkward. How about something along these lines?
== Guided partitioning ==
When using the guided partitioning flow, the installer must be able to: ... * Correctly display the locations and sizes of existing storage volumes and remove them to free up space, at the user's direction ...
== Custom partitioning ==
When using the custom partitioning flow, the installer must be able to:
* Correctly display, remove, and assign mount points to existing storage volumes of the supported types (requiring entry of the encryption passphrase, for encrypted volumes) * Correctly display the locations and sizes of, and remove, existing partitions of other types * Create and assign mount points to new storage volumes of the supported types * Remove a planned storage volume from the planned layout * Reject or disallow invalid disk and volume configurations without crashing.
footnote: Supported storage volume types
Supported storage volume types are btrfs, xfs and ext4 filesystems - including LUKS-encrypted filesystems - residing on: * Plain partitions * LVM logical volumes (including thinly-provisioned LVs) * btrfs volumes and sub-volumes * Linux software RAID-0, RAID-1, and RAID-5 sets * Reasonable combinations of the above (e.g. LVM-on-RAID)
If we're going to touch this stuff, though, maybe we should try to kill the horrible Final criterion, decide what (if anything) beyond the above we want to support by Final, and maybe split the requirements a bit between Beta and Final or allow some workarounds / exceptions at Beta and stuff.
On Fri, Mar 13, 2015 at 4:27 PM, Adam Williamson adamwill@fedoraproject.org wrote:
When using the custom partitioning flow, the installer must be able to:
- Correctly display, remove, and assign mount points to existing
storage volumes of the supported types (requiring entry of the encryption passphrase, for encrypted volumes)
- Correctly display the locations and sizes of, and remove, existing
partitions of other types
- Create and assign mount points to new storage volumes of the
supported types
"assign" appears in 2 out of 3, "remove" appears in 2 out of 3. I'd like to think "correctness" is implicit, and can go without explicitly saying it, and if not then add correctness to the initial statement. I definitely think encryption caveat is a given, it's unworkable if the user doesn't enter the passphrase). This reads more consistently to me:
When using the custom partitioning flow, the installer must be able to (correctly):
- create mount points with new storage volumes of the supported types.
- assign mount points to existing storage volumes of the supported types.
- display (including location and size), and remove any storage volume.
- Remove a planned storage volume from the planned layout
How does this differ from "remove any storage volume"? Seems wordy.
- Reject or disallow invalid disk and volume configurations without
crashing.
Good as is.
footnote: Supported storage volume types
Supported storage volume types are btrfs, xfs and ext4 filesystems - including LUKS-encrypted filesystems - residing on:
- Plain partitions
- LVM logical volumes (including thinly-provisioned LVs)
- btrfs volumes and sub-volumes
- Linux software RAID-0, RAID-1, and RAID-5 sets
- Reasonable combinations of the above (e.g. LVM-on-RAID)
Supported storage volume types are Btrfs, XFS, an ext4 filesystems, including if LUKS encrypted, when residing on: - plain partitions - LVM Logical Volumes (including thin Volumes) - Linux software RAID 0, RAID 1, and RAID 5 sets. - Reasonable combinations of the above (e.g. LVM-on-RAID)
## omitted separate item for btrfs volumes and subvolumes because a.) it's implicit, thus redundant; b.) making it explicit is confusing+silly because of this 2.5 year old bug with a submitted, tested patch yet no forward progress getting it into grubby stable, and now Anaconda has reverted support for /boot on Btrfs subvolumes again for the umpteenth time. Haha, yes it is like sand stuck in the wrong place for me...GRR!
## It's not a hill I'm going to die on, but I personally don't like the idea of blocking on raid0 or raid5. For one, raid0 is "I hate my data" anyway. And raid10 is conservative, scalable, better performing, and more general purpose than raid5, so I'd sooner promote it to working by beta rather than raid 5. I think it's a good idea for raid1 installs to be possible by Beta, beyond that is icing.
OK maybe block on raid0/raid5 if a problem is found? But if the test in the matrix hasn't been done then a missing test itself isn't blocking (it's an optional test)?
If we're going to touch this stuff, though, maybe we should try to kill the horrible Final criterion, decide what (if anything) beyond the above we want to support by Final, and maybe split the requirements a bit between Beta and Final or allow some workarounds / exceptions at Beta and stuff.
There's still quite a lengthy list for the additional installer items for Final. The only thing really being added is LUKS as existing rather than newly created. And that makes sense because more people use it these days. And there seems to be some tentative agreement on doing the work necessary to make it a default on day, since unlike marginally longer login passwords, it'll protect your data at rest should the computer go MIA.
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...
Chris Murphy
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. 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. 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*. 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.
Thanks!
On Fri, Mar 20, 2015 at 12:55 AM, Adam Williamson adamwill@fedoraproject.org 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.
On Fri, 2015-03-20 at 10:49 -0600, Chris Murphy wrote:
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.
Yes - *the meaning of the criterion*, not the way it expresses what it means.
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.
You say potato. Rewriting it to mean something else is the same as removing it and adding a new one, no? It's just two ways to say the same thing.
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.
It amounts to the same thing, because we can't practically just rip out all the functionality. Fundamentally, we're painted into a corner where the installer has to contain more functionality than we can absolutely guarantee will work in all circumstances. Is that ideal? No. But we can't pretend it isn't true.
There are going to be cases where we get to go/no-go, find there's an obscure bug in custom part, and want to ship anyway. As long as that's the case, this criterion as written is just not the right thing and instead of assisting us in deciding if releases are done (the actual point of the criteria), it's getting in our way.
On Fri, Mar 20, 2015 at 10:52 AM, Adam Williamson adamwill@fedoraproject.org wrote:
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.
It amounts to the same thing, because we can't practically just rip out all the functionality.
I wasn't recommending ripping out all functionality. I was only using that as example that neither criterion versions would be violated in such a case, therefore obviously the criterion aren't mandating any specific functionality other than what the installer visually promises.
This really should be uncontroversial. Plumber says he can install a faucet into a granite counter top. Great! They should be able to do exactly that, not f up the faucet or the granite counter top or cause a flood, right? Pretty straightforward. If they can't do it, they shouldn't claim they can.
Fundamentally, we're painted into a corner where the installer has to contain more functionality than we can absolutely guarantee will work in all circumstances. Is that ideal? No. But we can't pretend it isn't true.
If there's no accountability for its own promises, then I'm not imagining any available criterion.
There are going to be cases where we get to go/no-go, find there's an obscure bug in custom part, and want to ship anyway. As long as that's the case, this criterion as written is just not the right thing and instead of assisting us in deciding if releases are done (the actual point of the criteria), it's getting in our way.
Right, fine, so just delete it. I have no alternative wordsmithing to offer on this, because it's not about that. This isn't a creative writing assignment.