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

[Peter Robinson]

On Wed, Apr 22, 2015 at 8:31 PM, Matthew Miller
<mattdm at fedoraproject.org> 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

Which came about again after Atomic tried to push something through
and I had a discussion with you as to why it wasn't appropriate.

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

The major problem your missing here is resources. There is less than
two full time RCM people working on Fedora (I have "Enterprise"
responsibilities too) and the two of us work well over a 40 hour week
with demands across 8 architectures and what is a growing number of
products. Less than 2 years ago in Fedora 20 (not even two releases
ago!!) it was a single product, some spins, a cloud image for AWS and
that was about it.

On the Enterprise side of things if it's not in before "development"
begins its out, in the RCM space you have to even spec it before it
gets signed of and resources assigned and there's an order of
magnitude more people involved.

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

We have processes in place, and since I've come on board I've tried to
educate people and push back and explain why we're pushing back. But
if you look back to F-21 there was a lot of stuff that came in at the
last minute (of course it was the biggest change in out release
process since Fedora 7) and it broke the release and people were
actively blaming rel-eng for slippage where in a lot of cases it
wasn't even us or our process breaking but people pushing for last
minute changes.

We've pushed back in F-22 because FESCo didn't want to slip. Look at
the gcc C++ abi change as an example here and FESCo decided that it
wasn't worth the risk.

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

There's two points here:
1) Docker came around just around the time F-20 was coming out and
we'd decided to throw the spanner in the works and take a year plus to
do it, not the usual 6 month cycle.
2) we're back to the 6 month cycle and October isn't far away!

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

Dennis and I have a good idea about where we need to be but are often
drowning trying to get the current process done to get releases out
while working on the weekends etc to try and implement and improve the
new one.

I'm not 100% up on the vagrant issue but I actually think some of this
is bad planning on the Feature owners behalf. Vagrant isn't a new
technology that's popped it's head up since Jan 31 when we froze.

And this isn't the first time here. There's the Atomic issue where
we've had calls and conversations and they just ignore process (and
complain via there management where they have a team of 63 people and
more RCM resources than all of Fedora) and the App Data thingy where
the requirements have been outlined a number of times and they pop up
blaming us just before release (at least for F-20 / F-21) asking for
it to be implemented.

I was going to answer the "what do we need" with Human Resources but I
think it's education.