On Wednesday, April 22, 2015 03:31:35 PM Matthew Miller wrote:
From today's FESCo meeting, on the topic of adding a
non-blocking
Vagrant image that got missed for Alpha and Beta, Dennis noted
"It sets a bad precident if we let it in. People will push the limits
further than they already do." and
"We can physically do it. But we really should not
add new deliverables just for final."
This particular change was, as Kevin said in the meeting, a trainwreck
of bad communication, and we've got a number of corrections in the
works to fix that --
* an official list of deliverables for each release
* change process amended to note need for releng communication
And I've heard a few other good ideas, including FESCo liasons for
Cloud/Server/Workstation working groups helping to track individual
changes more closely throughout the process.
But, in general, I feel sad about the outcome here. This would have
been very useful to Fedora users, and help us in a particular target
area in which we need to grow. Rather than focusing on this particular
thing, though, I want to go with the assumption that in the future, we
_will_ have more new and changing deliverables.
It still will be useful, we will be
enabling it for rawhide and a side effect
will be that it will be enabled for branched as soon as koji is patched for
the rename of the images from .ova to .box we just will not be gathering the
output together for the final release.
I see where Dennis is coming from in frustration with people not
following process. That can causes a lot of extra work for _other_
people, and can result in lower-quality results which we might not be
proud of as a project, and which can erode trust in Fedora overall.
I want innovation, and welcome change, we just have to enable things in the
right place. I also want Fedora to be of a high quality. I think the changes
we will be making to rawhide before F23 branching will help a lot. we plan to
make the nightly compose look just like a TC compose, hopefully we can get to
the point where we no longer do TC's because the nightly composes satisfy the
needs. we then Just do RC composes. maybe even skipping Alpha because we have
great automated testing that we never get to a point where things are horrible
and need major polishing and integration work.
However, there's another side too. Docker was the last big thing,
but
who knows what the next one will be? Increasing communication and
long-term planning is one thing, but often with these emerging
technologies we're _really_ making it up as we go along. When these
things have little negative impact outside of their own space (they are
effectively self-contained changes _except_ for releng needs), and have
significant benefits for the user community and for Fedora's adoption
and growth, I *want* the limits pushed further than they currently can
be.
rawhide is the place to push the limits, let things stablise and make the next
release. The answer here is lets get it in rawhide and get the wrinkles out.
We also have QA, docs, marketing, websites that need to be involved. It is
not limited to just releng.
What would we need in order to have release engineering which can
provide a space for that? And let me be clear — that includes not
making work or life overwhelming with all the work you all already do.
I'm not taking the heroic existing tasks for granted, I'm asking what
_else_ would be needed to make this possible.
We have a space it is called rawhide. We are working to a place where thing
will be more flexible. But we will likely always say no to adding things late
in the release cycle. people should not be scared of running rawhide. now if
we know that something is coming and is just not quite ready we can plan for
it. The main things needed are communication, we have extremely limited
resources., but a lot more than we used to have. Longer term it has to be
easier to add things, but just as the route to RHEL is supposed to be Fedora,
the route to being in a Fedora release is rawhide.
Dennis