Fedora.next Product Branding
by Ryan Lerch
*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
8 years, 10 months
Technical Spec, better upgrade/rollback control
by Chris Murphy
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...
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
9 years
default filesystem
by Matthias Clasen
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.
9 years
hw requirements
by Matthias Clasen
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 ?
9 years
Re: default file system, was: Comparison to Workstation Technical Specification
by Adam Williamson
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
9 years
vetting the package list
by Matthias Clasen
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.
9 years
PRDs/Tech Specs to formal Change Proposals and Change submission deadline
by Jaroslav Reznik
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/00...
9 years
Re: default file system, was: Comparison to Workstation Technical Specification
by Josh Boyer
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
9 years
Re: default file system, was: Comparison to Workstation Technical Specification
by Chris Murphy
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
9 years
