desktop February 2014

desktop@lists.fedoraproject.org

60 participants
46 discussions

Fedora.next Product Branding
by Ryan Lerch 23 May '14

23 May '14

*This is sent with my Fedora Design Team hat on* With the creation of 3 products for Fedora, the Fedora Design Team anticipates manynewquestions aroundFedora'sbrand. As the main caretakers of the Fedora brand, weare going to have to figure these things out within the next few months. For example, the Design Team is starting to think about how to answer these types of questions: • Should each product have its own logo? or • Can you add our product to the Fedora website? or • Can you make our product its own website? (How should we represent these products on the website? Should we allow products to have their own separate websites?) To start off the rebranding discussion, the Fedora Design Teamhas4 basic questions for each of the 3 product-focused working groups to answer: (1) What problem does your product solve, in one sentence? (2) Who is the target audience for your product, in one sentence? (3) List at least 5 products that successfully target the same target audience you are after. (4) List at least 5 products that try to solve the same problem. We are reaching out to each group individually to ask that you discuss these questions and come back to us with answers by Wednesday, December 4th2013. cheers, ryanlerch

5 8

technical spec for the workstation up for review
by Matthias Clasen 23 Apr '14

23 Apr '14

I've spent quite a bit of time last week on this document: https://fedoraproject.org/wiki/Workstation/Technical_Specification It is not 100% complete, but I haven't found the time to get back to it since Friday, so I should probably open it up for a first round of review to the other WG member. Let me know what you think, Matthias

19 65

Technical Spec, better upgrade/rollback control
by Chris Murphy 17 Mar '14

17 Mar '14

The Workstation PRD includes "better upgrade/rollback control" under plans & policies. "• Better upgrade/rollback control If there are any problems with an upgrade or an upgrade breaks a configuration script we want to offer an easy way for users to roll-back such upgrades and changes." The Technical Specification doesn't address this requirement. And I'm also not finding anything in the list archives about it. I'm aware of three possible candidates for implementing snapshots and rollbacks: a.) Roller Derby Project: It lists a dependency on LVM Thin Provisioning, which is a new option in Fedora 20. I'm uncertain if it's considered stable for production use or not. Also uncertain is if the project is adaptable for Btrfs, although it seems likely. https://fedorahosted.org/roller-derby/ http://fedoraproject.org/wiki/Changes/Rollback https://lists.fedoraproject.org/pipermail/devel-announce/2013-July/001204.h… b.) Snapper: Lists a dependency on either LVM Thin Provisioning, or Btrfs. Snapper+Btrfs is the most mature and actively maintained option at this time. It's presently used in openSUSE, by default when the file system is Btrfs, for at least a couple of years. https://github.com/openSUSE/snapper/blob/master/README http://snapper.io/ http://snapper.io/faq.html c. ) Gnome: Richard Hughes has expressed interest in making this happen within Gnome. As far as I know it doesn't yet exist, but is expected to depend on either Btrfs or LVM Thin Provisioning snapshots. Am I missing any others? It seems to me the PRD requirement necessitates some assessment of file systems, the various snapshotting/rollback strategies and software, before the spec can detail an implementation. Should the facts as they're presently known be included in the spec in the meantime, with a TDB status? Chris Murphy

11 20

default filesystem
by Matthias Clasen 03 Mar '14

03 Mar '14

I've updated the spec to say The default file system type for workstation installs should be btrfs. Until btrfs is considered ready for this role, we will stay with the current setup of the desktop spin. Lets move on to more important topics.

14 32

hw requirements
by Matthias Clasen 03 Mar '14

03 Mar '14

I've added a section about hw requirements to the spec. It is a bit vague atm. Can we (and should we) make it more precise ?

15 18

Re: default file system, was: Comparison to Workstation Technical Specification
by Adam Williamson 01 Mar '14

01 Mar '14

On Thu, 2014-02-27 at 23:16 -0700, Chris Murphy wrote: > On Feb 27, 2014, at 11:07 PM, James Wilson Harshaw IV <jwharshaw(a)gmail.com> wrote: > > > I apologize, I guess I did not get the whole background out of it. > > > > What filesystems are we considering? > > It's XFS vs ext4 and Server WG has agreed on XFS on LVM. As a server WG member I voted +1 on XFS as I have no particular objection to XFS as a filesystem, but I do think it seems a bit sub-optimal for us to wind up with server and desktop having defaults that are very similar but slightly different, for no apparently great reason. ext4 and xfs are basically what I refer to as 'plain' filesystems (i.e. not all souped-up btrfs/zfs stuff), they're stable, mature, and generally good-enough for just about all cases. Is xfs really so much better for servers, and ext4 so much better for desktops, that it's worth the extra development/maintenance to allow Desktop to use ext4 and Server to use xfs? Basically, what I'm saying is that if Desktop would be OK with using xfs-on-LVM as default with all choices demoted to custom partitioning (no dropdown), as Server has currently agreed on, that'd be great. Or if we could otherwise achieve agreement on something. Right now we seem to be sleepwalking into a situation where server and desktop diverge but no-one particularly *wants* that, which seems a bit off. -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net http://www.happyassassin.net

4 6

vetting the package list
by Matthias Clasen 28 Feb '14

28 Feb '14

I've compared the package list from the workstation spec with a recent rawhide desktop spin image. I'm attaching the results (+ = on desktop spin, not in workstation spec, - = not on desktop spin, but in workstation spec). No further analysis yet.

2 2

PRDs/Tech Specs to formal Change Proposals and Change submission deadline
by Jaroslav Reznik 28 Feb '14

28 Feb '14

Hi, at yesterday's FESCo meeting, it was agreed on setting deadlines for Change submission for Fedora 21 [1] and to process PRDs into Change proposals. "AGREED: Fedora Changes Process submission deadline for system-wide changes is April 7th. Deadline for true standalone changes will be sometime later than that. Changes to how fedora is produced for fedora.next are still due on March 3rd. (+7,0,0) (nirik, 18:29:42)" Current deadlines: * March 3rd: Technical Specifications for products & and changes needed for products and deliverables --- very soon! * April 7th: System Wide Changes submission deadline Working Groups teams, please, try to "transform" required changes for your products from PRDs/Technical Specifications into standalone Change proposals (between March 3rd and April 7th). It will help us to scope the release. Also all changes would be trackable the standard way we do it and it's going to help transparency (as Change announcements are being to be part of the process). Self Contained Changes submission deadline will be set later, after the System Wide deadline. If you expect your proposed Self Contained Change will be on the edge and could be escalated to the System Wide, please try to submit it as early as possible too. As some Fedora.next details will be clarified later in the process, System Wide Changes submitted after the deadline will be approved case by case, even after submission deadline. For the details about the Change process, see my previous email to the devel announce list [2]. Thank you for your help with Change process and let me know in case of any questions. Jaroslav [1] https://fedorahosted.org/fesco/ticket/1178 [2] https://lists.fedoraproject.org/pipermail/devel-announce/2014-February/0013…

7 7

Re: default file system, was: Comparison to Workstation Technical Specification
by Josh Boyer 27 Feb '14

27 Feb '14

On Thu, Feb 27, 2014 at 3:59 PM, Dennis Gilmore <dennis(a)ausil.us> wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > On Thu, 27 Feb 2014 15:01:47 -0500 > Matthew Miller <mattdm(a)fedoraproject.org> wrote: > >> On Thu, Feb 27, 2014 at 07:43:53AM -0500, Stephen Gallagher wrote: >> > I realize that XFS is a difficult pill to swallow for /boot, due to >> > your use of syslinux instead of GRUB2. If the Server and Workstation >> > groups decide to settle on both using XFS-on-LVM for the main >> > partitions, we could *probably* also compromise on using ext4 for >> > just /boot. >> >> Right now, the cloud images are unpartitioned. In some cloud providers >> (e.g., the 800lb gorilla of Amazon EC2) we in fact use the kernel that >> assumes the image is just one partition, not a disk image. We could >> change that (and I kind of want to anyway, for consistency), but it >> would be... change. Having a separate /boot is also problematic >> (read: wasteful) for ultra-small images, and adds complexity a lot of >> users are going to frown at. So..... if by "/boot" you mean "the >> partition that /boot happens to be on, even if it is /", then I think >> we're good. Otherwise we will have to figure something else out. > > u-boot has zero support for xfs so arm systems will have to use ext4 > for /boot at least as well. which would mean / if users chose to not > use a separate /boot partition Or, as an alternative, XFS support could be added to u-boot and/or syslinux. Never eliminate the possibility of actually writing code to fix problems. All it takes is someone willing to do work ;). josh

2 1

Re: default file system, was: Comparison to Workstation Technical Specification
by Chris Murphy 27 Feb '14

27 Feb '14

On Feb 26, 2014, at 5:33 PM, Josef Bacik <josef(a)toxicpanda.com> wrote: > > Just popping in here to say that btrfs is not ready to be default in Fedora yet. Optional is fine but not default. > > OK good, that's definitive. Thanks Josef. So my thought is Workstation WG choices: parity with Server WG, whatever they choose; or plain ext4; or keep things the same with LVM + ext4. And on the question of an alternate choice (what currently appears in the Automatic/Guided path's Partition Scheme pop-up menu) the WG's might consider this too, even whether an alternate is desired. Because from a my personal QA perspective, I'd like to see the two products agree on either the default or an alternate so we don't have four total possible paths combined, which today means 100 testable outcomes. One or two paths is ideal; three might be OK. Four is like… chickens with no heads, running. Chris Murphy

4 3

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

desktop February 2014