On 11/06/2013 02:46 PM, Josh Boyer wrote:
On Wed, Nov 6, 2013 at 8:41 AM, Phil Knirsch <pknirsch@xxxxxxxxxx> 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@xxxxxxxxxx>
Wankelstrasse 5 | Web: http://www.redhat.com/
D-70563 Stuttgart, Germany
--
devel mailing list
devel@xxxxxxxxxxxxxxxxxxxxxxx
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
