11:49 p.m.
Hey, folks. So I'm sorry this is a bit late, but I've been working on
the proposed partitioning criteria for F18, and here's what I've got:
For Alpha, I think the proposal from the earlier 'untitled' thread still
stands up pretty well:
* The installer must be able to complete an installation using automatic
partitioning to any sufficiently large target disk, whether unformatted,
empty, or containing any kind of existing data
I'd also like to add this:
* The installer must allow the user to select which of the disks
connected to the system will be affected by the installation process.
Disks not selected as installation targets must not be affected by the
installation process in any way
Seems self-explanatory.
For Final, I think our current rather catch-all criterion probably
stands up OK:
* The installer must be able to create and install to any workable
partition layout using any file system offered in a default installer
configuration, LVM, software, hardware or BIOS RAID, or combination of
the above
So that leaves Beta. Here's what I've come up with for Beta so far:
* The installer must be able to complete an installation using automatic
partitioning to a disk with sufficient empty space, using the empty
space and leaving the existing partition table and data untouched
* The installer's custom partitioning mode must be capable of the
following:
** Creating and assigning mount points to partitions of any specified
size using most commonly-used filesystem types
** Creating encrypted partitions
** Rejecting obviously invalid operations without crashing
I tried to cover the non-custom case we need to work at Beta that we
don't need at Alpha - non-destructively using existing free space. Note
I _intentionally_ didn't require resizing to work, we've always
considered resizing to be a 'best effort' thing, not guaranteed. The
second thing is just a laundry list of 'things that probably ought to
work in custom partitioning at Beta' drawn from experience. It also
happens to reflect the Beta test cases in the matrix quite well, now I
look at it, though I didn't refer to them when drawing it up.
There's probably stuff I haven't thought of here, I'm sure people can
think of improvements. I'll throw an item on the agenda for Monday for
this, but please do post any improvements you can think of. thanks!
--
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | identi.ca: adamwfedora
http://www.happyassassin.net
12:09 a.m.
the proposed partitioning criteria for F18
So that leaves Beta. Here's what I've come up with for Beta
so far:
* The installer must be able to complete an installation using automatic
partitioning to a disk with sufficient empty space, using the empty
space and leaving the existing partition table and data untouched
* The installer's custom partitioning mode must be capable of the
following:
** Creating and assigning mount points to partitions of any specified
size using most commonly-used filesystem types
** Creating encrypted partitions
** Rejecting obviously invalid operations without crashing
In addition to creating new partitions from free space,
I'd like to be able to re-use existing partitions
(keep the space allocation, but optionally [re-]format,
or change the filesystem type and label)
without having first to delete them (thus turning them
into free space.)
--
1:38 a.m.
On Sep 30, 2012, at 10:49 PM, Adam Williamson wrote:
The installer must be able to create and install to any workable
partition layout using any file system offered in a default installer
configuration, LVM, software, hardware or BIOS RAID, or combination of
the above.
I think BIOS RAID (i.e. fakeraid, or IMSM RAID) should be dropped. It's fragile. It
implies dual-boot with who knows what version of Windows driver and metadata on-disk that
the md driver is going to be expected to support without imploding the user's data?
I'm really skeptical. I see many IMSM problems with Linux, and even more confused
users even if their data is OK but nothing is booting correctly. Beyond a very early point
it's totally non-obvious or easy to back out of this arrangement. Baring a total drop,
I'd say make it explicitly RAID 1 only.
I think we should agree that "partition layout" refers to MBR or GPT and LVM
means LVM; and not construed for anything related to btrfs subvolumes. Because I've
thought of some complex (and cool) subvolume arrangements that are totally workable and
GRUB2 bootable, but probably not wise to commit the installer to "must be able to
create and install to." I don't think a change in wording is needed, just make it
a tacit agreement.
On Sep 30, 2012, at 11:09 PM, John Reiser wrote:
In addition to creating new partitions from free space,
I'd like to be able to re-use existing partitions
(keep the space allocation, but optionally [re-]format,
or change the filesystem type and label)
without having first to delete them (thus turning them
into free space.)
The reformatting mandate of oldui is one of my biggest, most annoying pet peeves. It
actually makes me furious. I would like to be able to create lunatic asylum btrfs layouts
and have the installer just be pointed to each, without either deleting them or
reformatting them. [1] But for F18 I don't know how realistic this is. I'm very
hopeful about the condition of newui for beta, but I have a feeling a lot more work is
going to be needed. I'm very hesitant to expand release requirements related to
anaconda for F18.
So even if F18 ends up being a regression in this respect, I'm willing to bite that
bullet for another 6 months. *shrug*
Chris Murphy
[1] For the record, since this is a court of law, I point out that neither Windows nor Mac
OS installers format a target volume. They just start installing stuff to the volume you
pointed the installer to.
4:35 a.m.
On 10/01/2012 02:04 AM, "Jóhann B. Guðmundsson" wrote:
On 10/01/2012 06:38 AM, Chris Murphy wrote:
> I'm very hesitant to expand release requirements related to anaconda
> for F18.
Should it not be sufficient for us to have our release criteria be on
par what other os installers ( Like Windows or OS-X ) are capable of
doing?
JBG
I would suggest partitioning as easy and straightforward as in recent
OpenSuse and Ubuntu
as a reasonable goal.
--
Chuck Forsberg WA7KGX N2469R caf(a)omen.com www.omen.com
Developer of Industrial ZMODEM(Tm) for Embedded Applications
Omen Technology Inc "The High Reliability Software"
10255 NW Old Cornelius Pass Portland OR 97231 503-614-0430
4:57 a.m.
On 10/01/2012 09:35 AM, Chuck Forsberg WA7KGX N2469R wrote:
>
I would suggest partitioning as easy and straightforward as in recent
OpenSuse and Ubuntu
as a reasonable goal.
End user UI experience is not something we want our criteria to be based
upon on since it's subjective to the eye of the beholder.
If we would, we would be blocking the release for the "Back Button" in
the spokes which is the number one thing novice en users are struggling
with base on my findings ( second being the wealth of keyboard layout
options presented to them ).
They
a) have a hard time finding it
b) think it will cancel what they have selected
If Anaconda detects only a single harddrive and pre-selects it for the
novice end user then they will never have to touch partitioning which
they should not be doing anyway since they dont have any understanding
what partitioning is nor what it means.
From my pov of view it's irrelevant how horrid the custom partitioning
UI experience is for advanced/experience user as long as it works it's
the only thing that matters.
JBG
1:52 p.m.
On Oct 1, 2012, at 3:04 AM, Jóhann B. Guðmundsson wrote:
On 10/01/2012 06:38 AM, Chris Murphy wrote:
> I'm very hesitant to expand release requirements related to anaconda for F18.
Should it not be sufficient for us to have our release criteria be on par what other os
installers ( Like Windows or OS-X ) are capable of doing?
Not necessarily.
I don't know what's involved in getting anaconda to do a "point and
shoot" installation to a destination of my choice (a partition, a volume, or a mount
point). Until I do, I would not expand the release requirements until I know the
consequences.
Windows and Mac OS X installers are very rudimentary when it comes to partitioning; the OS
X installer doesn't even provide a UI for partitioning or volume formatting. It's
purely point and shoot, to a single partition. Would it be nice to have that in
Fedora's installer? I think it might be nice, but not a requirement, because there
probably are quite a few users who will designate a disk or partition for Fedora, and
should be able to simply point at that and have the Fedora installer slice it up into
whatever additional partitions are needed. I don't think, by default, disclosure is
needed either textually or visually, what is about to be done with that partition.
Chris Murphy
3:48 a.m.
On 10/01/2012 04:49 AM, Adam Williamson wrote:
There's probably stuff I haven't thought of here, I'm
sure people can
think of improvements. I'll throw an item on the agenda for Monday for
this, but please do post any improvements you can think of. thanks!
I would like us add a criteria about the storage spoke to autoselect the
storage device for user if he only has a single instance of it ( one
hard drive ) not sure which criteria we would like to have thou.
JBG
10:09 a.m.
On Mon, 2012-10-01 at 08:48 +0000, "Jóhann B. Guðmundsson" wrote:
On 10/01/2012 04:49 AM, Adam Williamson wrote:
> There's probably stuff I haven't thought of here, I'm sure people can
> think of improvements. I'll throw an item on the agenda for Monday for
> this, but please do post any improvements you can think of. thanks!
I would like us add a criteria about the storage spoke to autoselect the
storage device for user if he only has a single instance of it ( one
hard drive ) not sure which criteria we would like to have thou.
That seems kind of excessively specific for a release criterion, maybe?
I agree that newUI should probably do it, though - have you filed an
RFE?
--
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | identi.ca: adamwfedora
http://www.happyassassin.net
10:19 a.m.
On 10/01/2012 03:09 PM, Adam Williamson wrote:
On Mon, 2012-10-01 at 08:48 +0000, "Jóhann B. Guðmundsson"
wrote:
> On 10/01/2012 04:49 AM, Adam Williamson wrote:
>> There's probably stuff I haven't thought of here, I'm sure people
can
>> think of improvements. I'll throw an item on the agenda for Monday for
>> this, but please do post any improvements you can think of. thanks!
> I would like us add a criteria about the storage spoke to autoselect the
> storage device for user if he only has a single instance of it ( one
> hard drive ) not sure which criteria we would like to have thou.
That seems kind of excessively specific for a release criterion, maybe?
I agree that newUI should probably do it, though - have you filed an
RFE?
I filed a genuine bug I think but with regards to storage I think we
should have some kind of criteria involving the storage spoke + single
and multiple disks + custom partitioning
JBG
1:53 p.m.
On Oct 1, 2012, at 9:09 AM, Adam Williamson wrote:
On Mon, 2012-10-01 at 08:48 +0000, "Jóhann B. Guðmundsson"
wrote:
> On 10/01/2012 04:49 AM, Adam Williamson wrote:
>> There's probably stuff I haven't thought of here, I'm sure people
can
>> think of improvements. I'll throw an item on the agenda for Monday for
>> this, but please do post any improvements you can think of. thanks!
>
> I would like us add a criteria about the storage spoke to autoselect the
> storage device for user if he only has a single instance of it ( one
> hard drive ) not sure which criteria we would like to have thou.
That seems kind of excessively specific for a release criterion, maybe?
I agree that newUI should probably do it, though - have you filed an
RFE?
I think it's a good design goal to get to, eventually, but I don't think it should
be a release requirement for F18.
Chris Murphy
4:58 p.m.
On 10/01/2012 11:53 AM, Chris Murphy wrote:
I think it's a good design goal to get to, eventually, but I
don't think it should be a release requirement for F18.
Disk partitioning
resembles open heart surgery. The patient suffers
when not done well.
Some software problems do not appear until Linux is used on a
"production" system.
My server has a large number of existing partitions. It also has a few
unused partitions
so I can fall back to a working system if installation of a new release
fails to yield a
satisfactory result. This came in very handy when I wasn't able to get
F17 to do the
things I needed.
I don't need much in the way of custom partitioning. Make fdisk and
parted available
from Anaconda's Ctrl-Alt-F2 shell, then tell Anaconda where to install
Linux. Not
elegant but workable and reasonably safe.
If Fedora doesn't have good support for custom partitioning people like
me will want to
jump to a distribution that does have good support for custom
partitioning. And
we will be debugging Ubuntu, Suse, etc. and not Fedora.
--
Chuck Forsberg WA7KGX N2469R caf(a)omen.com www.omen.com
Developer of Industrial ZMODEM(Tm) for Embedded Applications
Omen Technology Inc "The High Reliability Software"
10255 NW Old Cornelius Pass Portland OR 97231 503-614-0430
5:51 p.m.
On Oct 1, 2012, at 3:58 PM, Chuck Forsberg WA7KGX N2469R wrote:
On 10/01/2012 11:53 AM, Chris Murphy wrote:
> I think it's a good design goal to get to, eventually, but I don't think it
should be a release requirement for F18.
Disk partitioning resembles open heart surgery. The patient suffers when not done well.
Bad analogy. I therefore refuse the premise.
If Fedora doesn't have good support for custom partitioning
people like me will want to
jump to a distribution that does have good support for custom partitioning. And
we will be debugging Ubuntu, Suse, etc. and not Fedora.
You haven't had a point and shoot [1] installer to date with Fedora. a.) parted always
wipes the partition map and replaces it, even if you're not changing anything (which
causes hybrid MBRs to be nuked, BTW); and b.) it will not let you install to a volume that
it's also not set to format. I don't know if these two behaviors will persist in
newui.
Chris Murphy
[1]I mean the user points the installer to an existing valid formatted partition(s) and
the installer does not write out a new partition table, does not format the partition, it
just starts installing.
7:38 p.m.
On 10/01/2012 03:51 PM, Chris Murphy wrote:
On Oct 1, 2012, at 3:58 PM, Chuck Forsberg WA7KGX N2469R wrote:
> On 10/01/2012 11:53 AM, Chris Murphy wrote:
>> I think it's a good design goal to get to, eventually, but I don't think
it should be a release requirement for F18.
> Disk partitioning resembles open heart surgery. The patient suffers when not done
well.
Bad analogy. I therefore refuse the premise.
> If Fedora doesn't have good support for custom partitioning people like me will
want to
> jump to a distribution that does have good support for custom partitioning. And
> we will be debugging Ubuntu, Suse, etc. and not Fedora.
You haven't had a point and shoot [1] installer to date with Fedora. a.) parted
always wipes the partition map and replaces it, even if you're not changing anything
(which causes hybrid MBRs to be nuked, BTW); and b.) it will not let you install to a
volume that it's also not set to format. I don't know if these two behaviors will
persist in newui.
Chris Murphy
[1]I mean the user points the installer to an existing valid formatted partition(s) and
the installer does not write out a new partition table, does not format the partition, it
just starts installing.
Have I just been told to see Figure.1 ?
--
Chuck Forsberg WA7KGX N2469R caf(a)omen.com www.omen.com
Developer of Industrial ZMODEM(Tm) for Embedded Applications
Omen Technology Inc "The High Reliability Software"
10255 NW Old Cornelius Pass Portland OR 97231 503-614-0430
8:18 p.m.
On Oct 1, 2012, at 6:38 PM, Chuck Forsberg WA7KGX N2469R wrote:
Have I just been told to see Figure.1 ?
I guess. More to the point you've been told that the thing you say Fedora should have
to keep you from using another distro, you haven't had with oldui, so it's
actually a feature request.
Chris Murphy
8:32 p.m.
On Mon, 2012-10-01 at 19:18 -0600, Chris Murphy wrote:
On Oct 1, 2012, at 6:38 PM, Chuck Forsberg WA7KGX N2469R wrote:
> Have I just been told to see Figure.1 ?
I guess. More to the point you've been told that the thing you say
Fedora should have to keep you from using another distro, you haven't
had with oldui, so it's actually a feature request.
Right. In general, several of the proposals in this thread seem to be
more feature requests than criteria proposals. This thread isn't
intended to be a comprehensive list of every feature we think the newUI
partitioning code ought to have, but what we think absolutely must be in
place and working _as a minimum_ for Alpha and Beta releases. If you're
thinking more along the lines of 'I'd like for the new anaconda to do
X', then that's an RFE bug against anaconda or a thread for the anaconda
mailing list.
--
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | identi.ca: adamwfedora
http://www.happyassassin.net
8:30 p.m.
On Sun, 2012-09-30 at 21:49 -0700, Adam Williamson wrote:
Hey, folks. So I'm sorry this is a bit late, but I've been
working on
the proposed partitioning criteria for F18, and here's what I've got:
So an update here: there's various additional proposals in the thread,
but no objections to the proposals I made for Alpha and Beta. These
proposals were additionally discussed and agreed with minor changes at
the QA meeting this morning. So I've gone ahead and edited the Alpha and
Beta criteria pages in line with the proposals as revised and accepted
at the QA meeting:
https://fedoraproject.org/w/index.php?title=Fedora_18_Alpha_Release_Crite...
https://fedoraproject.org/w/index.php?title=Fedora_18_Beta_Release_Criter...
(I know Alpha is done already, but we apply Alpha criteria at Beta and
Final release time too, so we need those to be correct; it's not
pointless to edit the Alpha criteria).
Of course, this doesn't close the partitioning topic finally or
anything, we can continue to discuss the further proposals people have
come up with on the list or at the meeting and add them to the criteria.
But there was broad agreement on _at least_ the requirements I've added,
AFAICT no-one seems to feel they over-reached in any way, and we need
something in place to evaluate proposed blockers and the freezeability
of 18 for Beta release, so it seemed good to get these baseline criteria
in place ASAP.
Please do continue to propose any extensions or improvements you can
think of to these criteria, thanks!
--
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | identi.ca: adamwfedora
http://www.happyassassin.net
4223
days inactive
4224
days old
16 comments
5 participants
participants (5)
-
Adam Williamson -
Chris Murphy -
Chuck Forsberg WA7KGX -
John Reiser -
Jóhann B. Guðmundsson