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

[Phil Knirsch]

Hi everyone.

A quick update from my side regarding the Base Design WG:

  - My proposed committee was approved by FESCO last Wednesday. One 
negative vote came from Stephen Gallagher that he would have very much 
preferred to have Lennart instead of Harald or Josh on the committee.

  - IRC meeting time. I've set up a http://whenisgood.net/fimbxij/ event 
where every committee member has now responded. The current best time 
slots would be Monday 19:00 UTC or Friday 15:00 UTC. At both times only 
Jon Disnard wouldn't be able to join, so i'll follow up with him 
personally to see if he could make it to one of them somehow. The 2nd 
best options would be Friday 14:00 UTC or Friday 17:00 UTC. For the 
former Bill Nottingham and Jon Disnard wouldn't be able to join, for the 
later Jaroslav Reznik and Bill Nottingham.
    For this week to get things underway i'll propose to use the Friday 
15:00 UTC timeslot as an initial meeting time where we can discuss the 
first important topics and tasks the committee needs to work on
   And to reiterate one point: EVERYONE is invited to join these 
meetings and participate in the discussions there. Just because you are 
not a committee member doesn't mean you can voice your ideas, comments, 
questions, concerns or thoughts during the meetings. This will make a 
difference and can only make a difference if you do so.

  - The main topics for the meeting agenda from my side will be:
    o Governance discussion & draft (Proposal: Review other WGs 
governance drafts & create our own based on those)
    o Regular meeting times (stay with Friday 15:00 PM or move somewhere 
else?)
    o Base mailing list discussion (yes/no, pros/cons)
    o QE representation discussion (who, how, status, etc)
    o Role of Base Design group discussion ->
    o Start of collecting ideas for Base Design. Proposal: Use wiki
        https://fedoraproject.org/wiki/Base
      Maybe something like a mission statement first that relates to the 
idea that the Base Design is the platform for all other direct Fedora 
products (there can potentially be other separate products based on our 
original products or others consuming Base in the future).

Thats it for now.

Thanks everyone!

Regards, Phil

-- 
Philipp Knirsch              | Tel.:  [phone]
Manager Core Services        | Fax.:  [phone]
Red Hat GmbH                 | Email: Phil Knirsch <pknirsch(a)redhat.com&gt;
Wankelstrasse 5              | Web:   http://www.redhat.com/
D-70563 Stuttgart, Germany

[Stephen Gallagher]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 11/04/2013 11:07 AM, Phil Knirsch wrote:
>  Hi everyone.
>  
>  A quick update from my side regarding the Base Design WG:
>  
>  - My proposed committee was approved by FESCO last Wednesday. One 
>  negative vote came from Stephen Gallagher that he would have very
>  much preferred to have Lennart instead of Harald or Josh on the
>  committee.
>   
To be completely clear, I said I would have preferred having Lennart
on the WG. I did not state that I thought Harald or Josh should not be
members. That's an important distinction, I think :)

I felt strongly enough that Lennart belonged on this group that I
chose to cast a token vote, knowing that it would not affect the outcome.
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.15 (GNU/Linux)
> Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
>
> iEYEARECAAYFAlJ34PkACgkQeiVVYja6o6MrUwCgpYhhbnQ2eFX/c4Eb8bSAbBVs
> fB4AoIKJyckoVozKnZyh03E0MfMzmpxy
> =L79V
> -----END PGP SIGNATURE-----

[Jon]

On Nov 4, 2013 12:01 PM, "Stephen Gallagher" <sgallagh(a)redhat.com&gt; wrote:
>  -----BEGIN PGP SIGNED MESSAGE-----
>  Hash: SHA1
>
>  On 11/04/2013 11:07 AM, Phil Knirsch wrote:
>  > Hi everyone.
>  >
>  > A quick update from my side regarding the Base Design WG:
>  >
>  > - My proposed committee was approved by FESCO last Wednesday. One
>  > negative vote came from Stephen Gallagher that he would have very
>  > much preferred to have Lennart instead of Harald or Josh on the
>  > committee.
>  >
>
>  To be completely clear, I said I would have preferred having Lennart
>  on the WG. I did not state that I thought Harald or Josh should not be
>  members. That's an important distinction, I think :)
>
>  I felt strongly enough that Lennart belonged on this group that I
>  chose to cast a token vote, knowing that it would not affect the outcome.
> >  -----BEGIN PGP SIGNATURE-----
> >  Version: GnuPG v1.4.15 (GNU/Linux)
> >  Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
> >
> >  iEYEARECAAYFAlJ34PkACgkQeiVVYja6o6MrUwCgpYhhbnQ2eFX/c4Eb8bSAbBVs
> >  fB4AoIKJyckoVozKnZyh03E0MfMzmpxy
> >  =L79V
> >  -----END PGP SIGNATURE----- 
>  --
>  devel mailing list
>  devel(a)lists.fedoraproject.org
>  https://admin.fedoraproject.org/mailman/listinfo/devel
>  Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct 
Howdy folks.

Looking forward to getting to work on base design. Regarding the voting
members I feel we have a great group. Everyone intersted (voting or not)
should participate in our discussions. My vote will certainly be influenced
by anyone in the community willing to participate.  :-)

One thing I would like to talk about is embedded Fedora, mostly as that is
my personal area of involvement with the project.  There is not an embedded
working group, and it's my agenda to hopefully have the base design double
as embedded.  It makes sense to me in the sense that base ring-zero is sort
of the embedded core into cloud, server, or workstation. By itself base
would be suitable for the smallest deployment.

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. :-)

Thanks,
-Jon Disnard

[Jaroslav Reznik]

----- Original Message -----
>  Howdy folks.
>  
>  Looking forward to getting to work on base design. Regarding the voting
>  members I feel we have a great group. Everyone intersted (voting or not)
>  should participate in our discussions. My vote will certainly be influenced
>  by anyone in the community willing to participate. :-)
>  
>  One thing I would like to talk about is embedded Fedora, mostly as that is my
>  personal area of involvement with the project. There is not an embedded
>  working group, and it's my agenda to hopefully have the base design double
>  as embedded. It makes sense to me in the sense that base ring-zero is sort
>  of the embedded core into cloud, server, or workstation. By itself base
>  would be suitable for the smallest deployment. 
Btw. for embedded as I understand WGs - these four were setup as an initial
seed to begin with something. Embedded WG in the (near) future is of course
possible.

>  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. :-) 
For release cycle, yes, Base will be that lowest common denominator. That's
why I'm on board (and why I signed up for Base ;-). The biggest limitation
here are "resources", from qa, releng tooling. Currently it's pretty
difficult
to produce and release one well defined collection in one time. Let's hope
tooling (QA and relengs are planning now) will help (and I know it will ;-).
And one thing I'd like to work as member of WG and FPGM is to share as many
resources, as many processes between products as possible, not to break 
apart completely but still allow flexibility and governance of upper level
WGs ;-).

Jaroslav

>  Thanks,
>  -Jon Disnard
>  
>  --
>  devel mailing list
>  devel(a)lists.fedoraproject.org
>  https://admin.fedoraproject.org/mailman/listinfo/devel
>  Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

[Phil Knirsch]

On 11/06/2013 05:43 AM, Jon wrote:
>  On Nov 4, 2013 12:01 PM, "Stephen Gallagher"
> <sgallagh(a)redhat.com
>  <mailto:[e-mail]>> wrote:
>   >
>   > -----BEGIN PGP SIGNED MESSAGE-----
>   > Hash: SHA1
>   >
>   > On 11/04/2013 11:07 AM, Phil Knirsch wrote:
>   > > Hi everyone.
>   > >
>   > > A quick update from my side regarding the Base Design WG:
>   > >
>   > > - My proposed committee was approved by FESCO last Wednesday. One
>   > > negative vote came from Stephen Gallagher that he would have very
>   > > much preferred to have Lennart instead of Harald or Josh on the
>   > > committee.
>   > >
>   >
>   > To be completely clear, I said I would have preferred having Lennart
>   > on the WG. I did not state that I thought Harald or Josh should not be
>   > members. That's an important distinction, I think :)
>   >
>   > I felt strongly enough that Lennart belonged on this group that I
>   > chose to cast a token vote, knowing that it would not affect the outcome.
> >   > -----BEGIN PGP SIGNATURE-----
> >   > Version: GnuPG v1.4.15 (GNU/Linux)
> >   > Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
> >   >
> >   > iEYEARECAAYFAlJ34PkACgkQeiVVYja6o6MrUwCgpYhhbnQ2eFX/c4Eb8bSAbBVs
> >   > fB4AoIKJyckoVozKnZyh03E0MfMzmpxy
> >   > =L79V
> >   > -----END PGP SIGNATURE----- 
>   > --
>   > devel mailing list
>   > devel(a)lists.fedoraproject.org <mailto:[e-mail]>
>   > https://admin.fedoraproject.org/mailman/listinfo/devel
>   > Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
>
>  Howdy folks.
>
>  Looking forward to getting to work on base design. Regarding the voting
>  members I feel we have a great group. Everyone intersted (voting or not)
>  should participate in our discussions. My vote will certainly be
>  influenced by anyone in the community willing to participate.  :-) 
100% :)

>  One thing I would like to talk about is embedded Fedora, mostly as
> that
>  is my personal area of involvement with the project.  There is not an
>  embedded working group, and it's my agenda to hopefully have the base
>  design double as embedded.  It makes sense to me in the sense that base
>  ring-zero is sort of the embedded core into cloud, server, or
>  workstation. By itself base would be suitable for the smallest deployment. 
Thats a really good point, and one i do share as well: The Base needs to 
be able to serve as a starting point for every current and any potential 
future Fedora products. And to do so means we need to find the smallest 
common denominator. Of course this is just my personal opinion, and 
we'll discuss this among many other topics during our meetings. And last 
but not least in collaboration with the other WGs, as they rely on us to 
deliver something they can use as a, well, "Base". ;)

>  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.

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.

Thanks & regards, Phil

-- 
Philipp Knirsch              | Tel.:  [phone]
Manager Core Services        | Fax.:  [phone]
Red Hat GmbH                 | Email: Phil Knirsch <pknirsch(a)redhat.com&gt;
Wankelstrasse 5              | Web:   http://www.redhat.com/
D-70563 Stuttgart, Germany

[Josh Boyer]

On Wed, Nov 6, 2013 at 8:41 AM, Phil Knirsch <pknirsch(a)redhat.com&gt; 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.

>  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.

josh

[Jaroslav Reznik]

----- Original Message -----
>  > 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. 
And it's also the place where Base overlaps with Env/Stacks group.

Jaroslav

>  josh
>  --
>  devel mailing list
>  devel(a)lists.fedoraproject.org
>  https://admin.fedoraproject.org/mailman/listinfo/devel
>  Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

[Phil Knirsch]

On 11/06/2013 02:46 PM, Josh Boyer wrote:
>  On Wed, Nov 6, 2013 at 8:41 AM, Phil Knirsch
> <pknirsch(a)redhat.com&gt; 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.:  [phone]
Manager Core Services        | Fax.:  [phone]
Red Hat GmbH                 | Email: Phil Knirsch <pknirsch(a)redhat.com&gt;
Wankelstrasse 5              | Web:   http://www.redhat.com/
D-70563 Stuttgart, Germany

[drago01]

On Wed, Nov 6, 2013 at 3:38 PM, Phil Knirsch <pknirsch(a)redhat.com&gt; wrote:
>  On 11/06/2013 02:46 PM, Josh Boyer wrote:
> >
> > On Wed, Nov 6, 2013 at 8:41 AM, Phil Knirsch <pknirsch(a)redhat.com&gt; 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.

[Bruno Wolff III]

On Wed, Nov 06, 2013 at 15:38:10 +0100,
   Phil Knirsch <pknirsch(a)redhat.com&gt; wrote:
> 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. 
Since we have a system where multiple kernel types can be installed, maybe 
we could use that to have a latest stable kernel package and a latest 
long term support kernel package. This will take more kernel team resources 
and may have some issues if the graphics drivers devs want to take 
advantage of a new feature that isn't going to be back ported to stable.

[Stephen Gallagher]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 11/06/2013 09:57 AM, Bruno Wolff III wrote:
>  On Wed, Nov 06, 2013 at 15:38:10 +0100, Phil Knirsch
>  <pknirsch(a)redhat.com&gt; wrote:
> > 
> > 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.
>  
>  Since we have a system where multiple kernel types can be
>  installed, maybe we could use that to have a latest stable kernel
>  package and a latest long term support kernel package. This will
>  take more kernel team resources and may have some issues if the
>  graphics drivers devs want to take advantage of a new feature that
>  isn't going to be back ported to stable. 
Alternately, maybe this is one of the cases where we leave it to
RHEL/CentOS to cover. For really long-term kernel support, those
groups are much better equipped to resource it than the Fedora kernel
team.
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.15 (GNU/Linux)
> Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
>
> iEYEARECAAYFAlJ6ZD4ACgkQeiVVYja6o6MveACfbAcNcioMfV4R1cJfu9yu8kXD
> lHsAn3WH1RfEfSvFzVEKOjjegYybVxrZ
> =JnZM
> -----END PGP SIGNATURE-----

[Phil Knirsch]

On 11/06/2013 04:46 PM, Stephen Gallagher wrote:
>  -----BEGIN PGP SIGNED MESSAGE-----
>  Hash: SHA1
>
>  On 11/06/2013 09:57 AM, Bruno Wolff III wrote:
> > On Wed, Nov 06, 2013 at 15:38:10 +0100, Phil Knirsch
> > <pknirsch(a)redhat.com&gt; wrote:
> >>
> >> 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.
> >
> > Since we have a system where multiple kernel types can be
> > installed, maybe we could use that to have a latest stable kernel
> > package and a latest long term support kernel package. This will
> > take more kernel team resources and may have some issues if the
> > graphics drivers devs want to take advantage of a new feature that
> > isn't going to be back ported to stable.
>
>  Alternately, maybe this is one of the cases where we leave it to
>  RHEL/CentOS to cover. For really long-term kernel support, those
>  groups are much better equipped to resource it than the Fedora kernel
>  team. 
Hm, so would the Fedora Server products base their releases then on 
CentOS instead? Otherwise, if due to resource constraints the Base 
products can't have a longer life cycle then say, 1 year or so, how 
would the Server products from Fedora be able to provide longer 
lifecycles on top of that? Would they support the Base they are using 
themselves? Who would do that?

As at the end of the day, as Bruno already mentioned in his answer, # of 
releases per year and lifetime of one product don't scale well. They 
actually scale quadratic, which is even worse. So we'll have to find 
some common ground and ideas on how we can manage to support both fast 
moving products e.g. like Cloud or potentially Workstation vs. slower 
moving and longer living ones like i expect Server.

And don't take this as an attack please, i just want to ensure everyone 
is on the same page regarding our finite resources and how we can most 
efficiently use them and find a solution that will work for all involved 
WGs and products.

Thanks & regards, Phil

-- 
Philipp Knirsch              | Tel.:  [phone]
Manager Core Services        | Fax.:  [phone]
Red Hat GmbH                 | Email: Phil Knirsch <pknirsch(a)redhat.com&gt;
Wankelstrasse 5              | Web:   http://www.redhat.com/
D-70563 Stuttgart, Germany

[Stephen Gallagher]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 11/06/2013 11:09 AM, Phil Knirsch wrote:
>  On 11/06/2013 04:46 PM, Stephen Gallagher wrote:
> > -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
> > 
> > On 11/06/2013 09:57 AM, Bruno Wolff III wrote:
> >> On Wed, Nov 06, 2013 at 15:38:10 +0100, Phil Knirsch 
> >> <pknirsch(a)redhat.com&gt; wrote:
> >>> 
> >>> 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.
> >> 
> >> Since we have a system where multiple kernel types can be 
> >> installed, maybe we could use that to have a latest stable
> >> kernel package and a latest long term support kernel package.
> >> This will take more kernel team resources and may have some
> >> issues if the graphics drivers devs want to take advantage of a
> >> new feature that isn't going to be back ported to stable.
> > 
> > Alternately, maybe this is one of the cases where we leave it to 
> > RHEL/CentOS to cover. For really long-term kernel support, those 
> > groups are much better equipped to resource it than the Fedora
> > kernel team.
>  
>  Hm, so would the Fedora Server products base their releases then
>  on CentOS instead? Otherwise, if due to resource constraints the
>  Base 
No, please don't take that from what I said. I actually mean pretty
much the opposite. In my vision, the Fedora Server should be CLEARLY
the feeder channel for RHEL and CentOS server offerings (in that
order; Fedora Server is the feeder for RHEL server which is the feeder
for CentOS server).

I merely meant that if a user absolutely needs a stabilized and
*supported* (in the commercial or near-commercial sense) kernel, that
they should be looking at products intended for that purpose. The
Fedora Server should certainly be useful, but not on the same ten-year
cycle. In general, if we settled on eighteen to twenty-four months of
updates, I think that would strike a usable balance.


>  products can't have a longer life cycle then say, 1 year or so,
>  how would the Server products from Fedora be able to provide
>  longer lifecycles on top of that? Would they support the Base they
>  are using themselves? Who would do that? 
This is still being discussed. Please see the thread "Thoughts on
Fedora Server lifecycle"[1]

My plan would be for the server to have a stabilized release every
eighteen months and after that an updates roll-up every six months
thereafter. These updates should be more tightly controlled than the
classic Fedora firehose (possibly limited to security and data-loss
issues). Kernel will probably get a pass to just rebase though. If you
want to discuss this, please do so on the thread I mentioned above.
I'd prefer not to split the discussion.


>  
>  As at the end of the day, as Bruno already mentioned in his answer,
>  # of releases per year and lifetime of one product don't scale
>  well. They actually scale quadratic, which is even worse. So we'll
>  have to find some common ground and ideas on how we can manage to
>  support both fast moving products e.g. like Cloud or potentially
>  Workstation vs. slower moving and longer living ones like i expect
>  Server.
>   
That's why in my lifecycle discussions I'm aiming to time update
releases and preview releases alongside the Base releases. That way
they should stay closely aligned.


>  And don't take this as an attack please, i just want to ensure
>  everyone is on the same page regarding our finite resources and how
>  we can most efficiently use them and find a solution that will work
>  for all involved WGs and products.
>   
No attack


>  Thanks & regards, Phil
>   

[1]
https://lists.fedoraproject.org/pipermail/server/2013-November/000369.html
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.15 (GNU/Linux)
> Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
>
> iEYEARECAAYFAlJ6escACgkQeiVVYja6o6Mn3wCgn9JiY51rv1eX0RHKMusWbCGS
> dBAAniKXnndc08CKlPS+5rBPof5VRqSc
> =7ZSc
> -----END PGP SIGNATURE-----

[Jaroslav Reznik]

----- Original Message -----
>  -----BEGIN PGP SIGNED MESSAGE-----
>  Hash: SHA1
>  
>  On 11/06/2013 11:09 AM, Phil Knirsch wrote:
>  > On 11/06/2013 04:46 PM, Stephen Gallagher wrote:
>  >> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
>  >> 
>  >> On 11/06/2013 09:57 AM, Bruno Wolff III wrote:
>  >>> On Wed, Nov 06, 2013 at 15:38:10 +0100, Phil Knirsch
>  >>> <pknirsch(a)redhat.com&gt; wrote:
>  >>>> 
>  >>>> 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.
>  >>> 
>  >>> Since we have a system where multiple kernel types can be
>  >>> installed, maybe we could use that to have a latest stable
>  >>> kernel package and a latest long term support kernel package.
>  >>> This will take more kernel team resources and may have some
>  >>> issues if the graphics drivers devs want to take advantage of a
>  >>> new feature that isn't going to be back ported to stable.
>  >> 
>  >> Alternately, maybe this is one of the cases where we leave it to
>  >> RHEL/CentOS to cover. For really long-term kernel support, those
>  >> groups are much better equipped to resource it than the Fedora
>  >> kernel team.
>  > 
>  > Hm, so would the Fedora Server products base their releases then
>  > on CentOS instead? Otherwise, if due to resource constraints the
>  > Base
>  
>  No, please don't take that from what I said. I actually mean pretty
>  much the opposite. In my vision, the Fedora Server should be CLEARLY
>  the feeder channel for RHEL and CentOS server offerings (in that
>  order; Fedora Server is the feeder for RHEL server which is the feeder
>  for CentOS server).
>  
>  I merely meant that if a user absolutely needs a stabilized and
>  *supported* (in the commercial or near-commercial sense) kernel, that
>  they should be looking at products intended for that purpose. The
>  Fedora Server should certainly be useful, but not on the same ten-year
>  cycle. In general, if we settled on eighteen to twenty-four months of
>  updates, I think that would strike a usable balance. 
Well, even for 18-24 months of updates you first need buy-in from 
packagers (and probably our sponsor too as it was rejected several times).
And with that conflict - resources to backport stuff or do updates (that's
the reason why we have so many updates - no resources to backport fixes,
more hope that upstream fixed it and it's regression free :D).

So we need some balance - time, quality, rebases vs backports. And we
can't have all of them :).

Jaroslav

[Stephen Gallagher]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 11/06/2013 12:31 PM, Jaroslav Reznik wrote:
>  ----- Original Message -----
> > -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
> > 
> > On 11/06/2013 11:09 AM, Phil Knirsch wrote:
> >> On 11/06/2013 04:46 PM, Stephen Gallagher wrote:
> >>> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
> >>> 
> >>> On 11/06/2013 09:57 AM, Bruno Wolff III wrote:
> >>>> On Wed, Nov 06, 2013 at 15:38:10 +0100, Phil Knirsch 
> >>>> <pknirsch(a)redhat.com&gt; wrote:
> >>>>> 
> >>>>> 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.
> >>>> 
> >>>> Since we have a system where multiple kernel types can be 
> >>>> installed, maybe we could use that to have a latest stable 
> >>>> kernel package and a latest long term support kernel
> >>>> package. This will take more kernel team resources and may
> >>>> have some issues if the graphics drivers devs want to take
> >>>> advantage of a new feature that isn't going to be back
> >>>> ported to stable.
> >>> 
> >>> Alternately, maybe this is one of the cases where we leave it
> >>> to RHEL/CentOS to cover. For really long-term kernel support,
> >>> those groups are much better equipped to resource it than the
> >>> Fedora kernel team.
> >> 
> >> Hm, so would the Fedora Server products base their releases
> >> then on CentOS instead? Otherwise, if due to resource
> >> constraints the Base
> > 
> > No, please don't take that from what I said. I actually mean
> > pretty much the opposite. In my vision, the Fedora Server should
> > be CLEARLY the feeder channel for RHEL and CentOS server
> > offerings (in that order; Fedora Server is the feeder for RHEL
> > server which is the feeder for CentOS server).
> > 
> > I merely meant that if a user absolutely needs a stabilized and 
> > *supported* (in the commercial or near-commercial sense) kernel,
> > that they should be looking at products intended for that
> > purpose. The Fedora Server should certainly be useful, but not on
> > the same ten-year cycle. In general, if we settled on eighteen to
> > twenty-four months of updates, I think that would strike a usable
> > balance.
>  
>  Well, even for 18-24 months of updates you first need buy-in from 
>  packagers (and probably our sponsor too as it was rejected several
>  times). And with that conflict - resources to backport stuff or do
>  updates (that's the reason why we have so many updates - no
>  resources to backport fixes, more hope that upstream fixed it and
>  it's regression free :D).
>  
>  So we need some balance - time, quality, rebases vs backports. And
>  we can't have all of them :). 
Well, the difference from previous approaches is that I'm not talking
about supporting additional branches too. For the "preview" branch,
every six month release until the stable one is immediately obsoleted
upon the release of the new one. So you can either be on the 6-month
front-lines or you can stay on the 18-24-month LTM version. This keeps
our contributors only concerned with two release branches at a time,
just as they do now.

> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.15 (GNU/Linux)
> Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
>
> iEYEARECAAYFAlJ6gwIACgkQeiVVYja6o6NT4QCdFlfBwe3yx4pby2YkrzfO7Ggv
> 3CwAn1Jh5FrQT/OF1pooLhbT6cmPrzpl
> =faEw
> -----END PGP SIGNATURE-----

[Miloslav Trmač]

On Wed, Nov 6, 2013 at 6:31 PM, Jaroslav Reznik <jreznik(a)redhat.com&gt; wrote:
>  And with that conflict - resources to backport stuff or do updates
> (that's
>  the reason why we have so many updates - no resources to backport fixes,
>  more hope that upstream fixed it and it's regression free :D). 
Note that it's not strictly necessary for all groups to have the same,
or even a compatible, release cadence, as long as their stability
promises are compatible.

It might be possible for Base to release every 3 months, and to apply
the Base update to all Server installations, even with an 18-month
Server lifetime; in the same way as we currently are rebasing the
kernel during the lifetime of a single Fedora release.

Of course this is only possible when the shorter-lifetime project is
explicitly tasked with keeping $somehow_defined stability (and the
kernel is one of the cases where they've been fairly public about this
being the goal; I have my doubts about the larger Base deliverable).
    Mirek

[Karel Zak]

On Wed, Nov 06, 2013 at 02:41:25PM +0100, Phil Knirsch wrote:
>  On 11/06/2013 05:43 AM, Jon wrote:
>  Right, release cycle will definitely be a hot topic, and i'd like us to 
 Maybe too early, it's probably better to answer "what do you want to
 release" before you choice the right release cycle :-)
 
 It means -- what is QA role, how important is upstream role, do you want to
 backport often, how stable code is expected, how important are a new features,
 do you have man-power for all your dreams?

>  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, 
 +1
 
 I can imagine that we will synchronize (for example) kernel + util-linux +
 udev + systemd upgrades for the Fedora Base upgrade, NACK feature backports
 and fix only "really important bugs" in already released Base packages.

>  support time for releases, what about feature backports and so forth.
> Lots
>  revolving around those topics i think.
>  
>  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. 
> From long term point of view I'm almost sure that we will see
> tendency to  
add more and more packages to the Base ;-)

    Karel

-- 
 Karel Zak  <kzak(a)redhat.com&gt;
 http://karelzak.blogspot.com

[Phil Knirsch]

On 11/04/2013 07:01 PM, Stephen Gallagher wrote:
>  -----BEGIN PGP SIGNED MESSAGE-----
>  Hash: SHA1
>
>  On 11/04/2013 11:07 AM, Phil Knirsch wrote:
> > Hi everyone.
> >
> > A quick update from my side regarding the Base Design WG:
> >
> > - My proposed committee was approved by FESCO last Wednesday. One
> > negative vote came from Stephen Gallagher that he would have very
> > much preferred to have Lennart instead of Harald or Josh on the
> > committee.
> >
>
>  To be completely clear, I said I would have preferred having Lennart
>  on the WG. I did not state that I thought Harald or Josh should not be
>  members. That's an important distinction, I think :)
>
>  I felt strongly enough that Lennart belonged on this group that I
>  chose to cast a token vote, knowing that it would not affect the outcome. 
Apologies if i phrased that a badly. I didn't intend to either play down 
your opinion or the importance and contributions of Lennart. I 
definitely hope he will participate and contribute to the Base WG even 
if he isn't a voting member of the committee.

After all, in my personal opinion the committee's decision should 
strongly be influenced exactly by that kind of participation and input 
from interested parties. And taking in all aspects and weighing them 
based on feasibility, resources, importance and other criteria everyone 
will have and then, as a group, come to a final decision that everyone 
can and will support.

Thanks & regards, Phil

-- 
Philipp Knirsch              | Tel.:  [phone]
Manager Core Services        | Fax.:  [phone]
Red Hat GmbH                 | Email: Phil Knirsch <pknirsch(a)redhat.com&gt;
Wankelstrasse 5              | Web:   http://www.redhat.com/
D-70563 Stuttgart, Germany