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

[drago01]

On Wed, Nov 6, 2013 at 3:38 PM, Phil Knirsch <pknirsch at redhat.com> wrote:
> 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. :)

I doubt that this would scale. It requires manpower for both QA and
backporting stuff that we don't have.
And having the just the long term cycle would be worse for the
workstation as people want there hardware to
work when they buy it not months or even years later.