As you may know, the technical specification's package list is still
As language support is an important thing, I suggest we should start of
with ALL the fonts currently in the default Desktop install, and not remove
any of them: only add.
Having Fedora Workstation degrade the language support of default Fedora is
a bad idea.
In case you didn't see the announcement, the registration for Flock is
open. Flock is the planned conference that replaced FUDCon in NA and
EU and is being held in Prague this year. You can find information
and registration at the flock website:
I would love to see some talk proposals around Workstation. Anyone
have any ideas for talks?
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.
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.
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?
Now that the basic layout is set aside the customization of partition, it will
be nice to provide a professional look to the installer for fedora.next
I wonder if the layout is responsive depending of the size of the screen.
When starting the installer, it will be nice to display an nice graphical screen
rather than a typical text mode (similar to the way Fedora starts with a
bootloader). Same principle should apply when rebooting after the installation.
Granted the idea is not really important. However, with the increase of Fedora
as workstation, those refinements will only enhance the overall experience of
Fedora Workstation and other part of Fedora.next.
I was inspired by the way iOS is installed and updated on the iMac.
As the subject says, abrt won't analyse evince crashes because the
packages from the COPR repo aren't signed. It won't even do it locally.
Would any one know if there was a way to make abrt skip this check?
> Mar 07 15:19:08 ankur-laptop abrt-server: Deleting problem directory '/var/tmp/abrt/ccpp-2014-03-07-15:19:07-28787'
> Mar 07 15:23:58 ankur-laptop abrt-server: Package 'evince' isn't signed with proper key
> Mar 07 15:23:58 ankur-laptop abrt-server: 'post-create' on '/var/tmp/abrt/ccpp-2014-03-07-15:23:56-30576' exited with 1
> Mar 07 15:23:58 ankur-laptop abrt-server: Deleting problem directory '/var/tmp/abrt/ccpp-2014-03-07-15:23:56-30576'
> Mar 07 15:29:15 ankur-laptop abrt-server: Package 'evince' isn't signed with proper key
> Mar 07 15:29:15 ankur-laptop abrt-server: 'post-create' on '/var/tmp/abrt/ccpp-2014-03-07-15:29:14-1388' exited with 1
> Mar 07 15:29:15 ankur-laptop abrt-server: Deleting problem directory '/var/tmp/abrt/ccpp-2014-03-07-15:29:14-1388'
> Mar 07 15:56:06 ankur-laptop abrt-server: Package 'evince' isn't signed with proper key
> Mar 07 15:56:07 ankur-laptop abrt-server: 'post-create' on '/var/tmp/abrt/ccpp-2014-03-07-15:56:05-17035' exited with 1
> Mar 07 15:56:07 ankur-laptop abrt-server: Deleting problem directory '/var/tmp/abrt/ccpp-2014-03-07-15:56:05-17035'
Of course, I can install the debuginfo packages and generate stack
traces manually, but abrt would make life much easier.
Join Fedora! Come talk to us!
The Workstation WG mission statement states in the opening to the
mission statement that the WG "aims to create a reliable, user-friendly
and powerful operating system for laptops and PC hardware."
In addition to the Technical Specification, would it also be a good idea
to start fleshing out a Definition or Description of the desired User
Experience for the workstation product? This would also most certainly
have to include some user testing / user interviews of some of our
targeted users. Having this description documented and mapped out, (with
some initial user tests and test cases), would also provide a baseline
to test against as initial and future versions are released.
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.
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
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
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net