adding desktop@ since they are also looking at file system options
On Feb 25, 2014, at 1:42 PM, Stephen Gallagher <sgallagh(a)redhat.com> wrote:
>> === File system ===
>> The default file system type for workstation installs should be
> The default file system is definitely up for some debate, but I'd make
> an argument for using XFS atop LVM for the default filesystem in
> the Fedora Server, at least in part because Red Hat's storage experts
> have done the research for us already and determined that XFS is the
> recommended fit for Red Hat Enterprise Linux 7.
XFS is a really good idea for Server.
- Can Server and Workstation WG's choose different defaults for their product's installers?
- Other than lack of shrink support in XFS, I'd say XFS is suitable for Workstation as well. Would the Workstation WG have concerns about the lack of fs shrink support in the default file system? 
> Btrfs still makes me somewhat nervous, given that its upstream doesn't
> consider it stable.
That wiki entry appears old. The stable aspect was about disk format, which is now stable. And also the experimental description was removed in kernel 3.13. 
My main two concerns with Btrfs:
1. With even minor problems users sometimes go straight to the big hammer approach with "btrfsck/btrfs check --repair" rather than the recommended approaches. Remounting with -o recovery, and even using a newer kernel are recommended on linux-btrfs@ significantly more often than btrfs check --repair.
It's a fair question how fail safe the offline repair utility currently is, and should be. In my monitoring of linux-btrfs@, even if btrfs check --repair made things worse, the offline btrfs restore utility enabled files to be extracted.
2. Supporting multiple device volumes in Anaconda. Although multiple device Btrfs volumes work very well when devices are working, there's no device failure notification yet. When a device fails, the volume becomes read-only; and the volume isn't mountable (or bootable) without the use of "degraded" mount option. While this can be done as a boot parameter, it's sort of a non-obvious thing for the typical user. I think it's valid for either WG to consider reducing exposure by dropping Anaconda support for it, or placarding the feature somehow.
 LVM Thin Provisioning, if ready for production prime time as a default, is a work around. It's actually better than fs resize anyway.
The Board has reviewed the PRDs for the Cloud, Server, and Workstation
products and approves. While there are some reservations in certain
areas, the overall goals of each product seem to be well thought out
and an benefit to Fedora going forward. Thank you for taking the time
to work through these issues.
As a next step, the Board would like to see FESCo and the Working
Groups discuss marketing of these products, both individually for each
product and collectively as the Fedora project deliverables. The
Board, FESCo, WGs, Marketing, Ambassadors and web sites team should
come up with a broader marketing/branding plan to make the transition
to a three main product deliverable world as clear and effective as
possible. We look forward to working with these groups in the near
On Wed, 2014-02-26 at 11:17 +0100, Karel Zak wrote:
> Don't try to be smart to everyone, it does not work. IMHO all you
> need is to support one or a very few scenarios (complete scenarios
> without customization) and a way how to switch from installer
> to manual partitioning by parted/fdisk/mdadm/mkfs/etc.
> The anaconda partitioning UI will never be smart enough for
> advanced users and it also does not make sense to duplicate effort,
> we *already have* tools to create all the unusual crazy disk layouts.
We don't, really. Well, we do, but it really is "tools" plural, and some
of them don't have GUIs at all. blivet and its anaconda GUI really is
one of the most advanced partitioning tools in existence. There's no
one-stop graphical tool that does everything blivet/anaconda does,
AFAIK. gparted can't do anywhere near the LVM, RAID and btrfs stuff that
blivet does: it really only does *partitions*.
We've kind of boxed ourselves into a corner of unreasonably high
expectations here now, though - we either commit to continuing to
support all the functionality custom part currently supports, or we say
"reduce it and screw the complainers", but there *will* be complainers.
There already are quite vociferous complainers for the very small amount
of simplification that was done between oldUI custom part and newUI
Possibly the most viable long-term option, and I think one the devs are
gradually working towards, is to make the blivet GUI an independent
component. That would mean it wouldn't kill your whole anaconda run if
it crashed (you could just start over and try again), and you could use
it from outside of anaconda (say, to pre-partition). And it'd maybe
encourage other projects to adopt and contribute to it, which would
definitely help take the load off - I've said it before but I'll say it
again, it is kinda absurd that we have, what, about the equivalent of
1.5 full-time developers trying to maintain this extremely capable and
complex partitioning backend *and* frontend.
It would certainly make life much easier on us if we said 'screw it,
disks are hard, let's go shopping' and just outsourced all the
partitioning to gparted (like ubiquity does), but it'd definitely be a
substantial drop in capability compared to what we have now. (And I
doubt it'd be acceptable for RHEL, so in the end the same people would
have to work on it anyway even if Fedora wasn't using it.)
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net
On Tue, Feb 25, 2014 at 18:11:35 -0500,
David Cantrell <dcantrell(a)redhat.com> wrote:
>I say the default Fedora filesystem should be up for vote, much like FESCo
>members or the code name for a release.
I don't think that is a good idea. I'd rather see a small group of subject
experts make the decision for the default, than have a large group of
Fedora contributors vote, who may not be in a good position to judge the
relative merits of file systems.
On Wed, 2014-02-26 at 10:24 -0500, David Cantrell wrote:
> > Yep, a lot of fun - three different file systems for free different products.
> > And we are back to the question how much these products could differ - with
> > limited resources we have right now - at least short term. Who can answer it
> > - filesystem/kernel guys, if they are able and willing to support all
> > potential filesystem, as David stated, it's possible in Anaconda but again
> > the same question if the team would be able to maintain more filesystems
> > support with high bar in terms of quality (even for example brtfs limited
> > to bare minimum), QA... And it could be pretty confusing for users but that's
> > up to us/marketing to explain that products aim specific goal and it's for
> > good (if we would be able to support it - then it's for good, if not...).
> I think filesystem variance across different Fedoras really impacts QA more
> than us. We already support a lot of filesystems, but the real hit is the
> QA test matrix.
Well, there is an indirect impact on devel.
As I said, it's about what we decide is 'release blocking'. The historic
approach there, and the one that's really simplest and makes most sense,
is 'guided path is release blocking, custom is not'. The more choice
there is on the guided path, the more release blocking codepaths we
have, and the more release blocker bugs you folks get to treadmill.
If, for instance, we ditched LVM thinp and btrfs from the guided path
dropdown, we cut the number of potentially release blocking paths by 50%
immediately. It won't necessarily cut the number of release blocking
bugs by precisely 50%, but it's pretty hard to believe it wouldn't cut
the number at *all*. And I know you folks get tired of the release
Remember, what QA release validation testing ultimately *results in* is
blocker bugs :)
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net
sorry for bringing up something that has probably been discussed here
several times already.
I went across the Software Updates section:
It's not very descriptive, but I guess by using PackageKit we will also
be using offline updates.
I've told been told theoretical issues of online updates many times, I
don't need anyone to repeat that.
The fact is that the offline updates have been received mostly
negatively by users from what I read on the Internet or hear from people
at events. But what really worries me is a much higher number of users
with broken package databases or even whole systems asking for help on
forums. When we got down to the problem we found out the user
interrupted offline updates (they took too long, or they even got stuck
and they didn't even know the system was being updated).
The offline updates as they are done now seem to be confusing to them.
I see more and more often advices from experienced users such as "if you
want reliable updates, use yum update" which is probably not the kind of
solution we want for workstation users.
I know we're not switching back to online updates, but we might want to
reassess how they're done now. Maybe making more obvious that the system
is being updated and the process is not yet over, or excluding packages
that really don't need offline update so that the update time is much
I must admit that I also have started using "yum update" although I
always used the gui tool on my laptop as the most convenient way to
Trying with a new thread: One of the edits I did yesterday was to add a
section for 'Installation methods and media'. So far, it is empty.
Are there any ideas for doing something other than live USB sticks
Continuing the discussion from here
https://plus.google.com/+RichardHughes/posts/LmPUMRJVFP6 (because G+ is a
horrible platform for discussion).
Also see this thread:
I don't think anything have changed since the last thread (besides Matthew
voicing his perfectly valid objections to push it as an update).
What I want to know is if there are people who are willing to invest their
time in making 3.12 in F20 a reality, be it via COPR or a regular update.
For a regular update, we'll need FESCO's approval, so someone will need to
submit a ticket with our proposal.
If we are going to do this in COPR, we will face some critical issues:
How can we preform sufficient QA in COPR? The lack of a -testing stage is a
huge disadvantage. Moving packages between COPR repos is impossible, so if
we make a -testing repo separately a rebuild will be needed every time we
move packages between -testing and -stable COPRs, this will take quite a
lot of time, seeing how COPR is much slower than koji.
Another issue that might arise with COPR is the lack of "team" support.
This means that if we do it in COPR, only one person will have access to
updating any package of the stack. This is quite a dealbreaker, because the
entire workload will fall on that person. Also, if said person is
unavailable, updating the repo will be impossible.
Those issues are quite major if we are going to maintain an entire GNOME
release in COPR, and the reason why I believe we should use COPR as a
testing stage and then move it all to the real repo.
So, anyone volunteering to this effort? I think convincing FESCO to grant
a policy exception is the only sensible way right now, unless the features
we need (QA stages, bodhi-style karma system, and team repositories) will
be implemented by COPR soon.
----- Original Message -----
> On Sat, Feb 22, 2014 at 03:37:40PM -0700, Chris Murphy wrote:
> > On Feb 22, 2014, at 9:39 AM, Bruno Wolff III <bruno(a)wolff.to> wrote:
> > > On Fri, Feb 21, 2014 at 19:08:15 -0700,
> > > Chris Murphy <lists(a)colorremedies.com> wrote:
> > >>
> > >> The idea of what Anaconda can do to create powerful storage stacks with
> > >> open source software has significant merit. But it's in the wrong
> > >> place. It's an anchor on the installer, and can only be leveraged
> > >> during an install of RHEL, CentOS or Fedora.
> > >
> > > What would you have people do instead? For example run a live image to do
> > > the partitioning, raid, lvm, dmcrypt, and file system setup before doing
> > > the install? Even then, you need some way to tell the installer which
> > > directories go on which file systems for the install.
> > I'm mainly suggesting a decoupling of all of this effort from an
> > installation only context, so that it can be used to create and modify
> > storage stacks without installing an OS. I don't particularly care how it
> > manifests - separate app, or a spoke within the current app. Communicating
> > the layout can be done with a fstab-like metadata file. If there's no
> > inclination to do this for a much broader use case, then why wedge so much
> > capability and effort into a narrow installer-only use case? Bootable
> > raid6 and raid4??
> Decoupling can't happen given the hard requirement we have on supporting a
> wide range of storage configurations. Linux in general has far too many
> options in this area and everyone's corner case or configuration is most
Well, as Fedora.next aims pretty much on productization and we'd like to
set higher bar for these products, I think we can limit these everyone's
corner case configuration and focus on what's really needed for our main
products. And I understand, this is really more politics than technical
issue and we're right in this politics time of Fedora.next - a good time
to rethink what we do now.
Of course the last but not least question is manpower of your team. There's
possibility that if we would be able to simplify blocking paths in installer,
we could get to the point there would be more time and will to touch proposed