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

[Phil Knirsch]

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