How *could* we make it more easy to deliver late-breaking deliverables?

[Dennis Gilmore]

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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: This is a digitally signed message part.
URL: <http://lists.fedoraproject.org/pipermail/rel-eng/attachments/20150422/9b197d8d/attachment.sig>