[Fedora Base Design WG] Committee FESCO approved, next steps

Phil Knirsch pknirsch at redhat.com
Wed Nov 6 14:38:10 UTC 2013

On 11/06/2013 02:46 PM, Josh Boyer wrote:
> On Wed, Nov 6, 2013 at 8:41 AM, Phil Knirsch <pknirsch at redhat.com> wrote:
>> On 11/06/2013 05:43 AM, Jon wrote:
>>> Another item I'd like to consider for the initial discussion is the
>>> release cycle for the base design. My feeling is that base is small
>>> enough and simple enough to allow a more frequent release, perhaps even
>>> continuously. My guess is the other WGs will have their own ideas for
>>> how frequently they output. So base WG would need to be the lowest
>>> common denominator in that way. Obviouly rel-eng and qa need to
>>> represent for this topic. :-)
>> Right, release cycle will definitely be a hot topic, and i'd like us to
>> investigate different types as well, e.g. not a time based but a major
>> feature based cycle (e.g. new upstream kernel -> new release), continuous,
>> support time for releases, what about feature backports and so forth. Lots
>> revolving around those topics i think.
> Unless you want to do a release every 3 months, the kernel probably
> isn't going to be a good thing to key off of.  I mean, it's a thing we
> could do, but if we did that we'd probably want to treat it in a
> fashion where a new Base release can fit into an older product release
> for some reasonable definition of old.  Similar to how we rebase the
> kernel in existing releases today, with perhaps a bit more lead time
> and QA.

Makes perfect sense, yes. And thanks for giving this great example, and 
why it's so vital to have different people with different backgrounds 
and focuses on each team.

But i do like the idea of well "Overlap" releases? Where most of the 
release would stay stable in a sense of API/ABI and we could still bring 
out a newer release.

As Jaroslav already mentioned, i can see some products that would want 
to have really current Base products while others might want to have 
longer lifecycles and longer release times for Base. This will be a 
tough nut to crack considering the limited resources we have (people and 
time wise):

Just as an example with picking up your 3 month release cycle, imagine 
other teams would want to have 3 year life cycle for Base, that would 
mean in the end we'd have to support and maintain 3 years x 4 releases 
per year = 12 release at once. I'm pretty sure thats not feasible, so 
we'll have to discuss in the WG and with all other WGs a compromise of 
how we can make it work for most of them. Again just throwing out an 
idea here: Doing 1 Long life release per year where long term products 
could base their products on and 3 short life release per year that we'd 
only support for 1 year. That would reduce the number down to 6 already, 
or even sorter if we'd say we only support the short life cycle release 
to 6 months only. And again, this is just food for thought/my $0.02 here 
that comes to my mind. Probably lost of garbage in it. :)

>> One request i also already got was if we in the Base WG could take a look at
>> containers/sandboxes for applications as well. Basically so that the
>> technology could be used by any derived product built on top of Base. And as
>> there are currently multiple competing technologies being worked on
>> (docker.io, systemd containers, libvirt-lxc, openshift cartridges) we'd need
>> to evaluate those and decide which one(s) we'd want to offer as a "standard"
>> from the Base product.
> Yes, the Workstation WG is interested in this as well.

Aye, i've read the PRD and followed to some extent the enormous 
discussions around the Workstation already.

Thanks & regards, Phil

Philipp Knirsch              | Tel.:  +49-711-96437-470
Manager Core Services        | Fax.:  +49-711-96437-111
Red Hat GmbH                 | Email: Phil Knirsch <pknirsch at redhat.com>
Wankelstrasse 5              | Web:   http://www.redhat.com/
D-70563 Stuttgart, Germany

More information about the devel mailing list