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

[Matthew Miller]

On Wed, Apr 22, 2015 at 06:44:51PM -0500, Dennis Gilmore wrote:
> 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.

This I really don't understand. If we're making the output, and Cloud
SIG is testing it and it's good, why *not* gather it for final release?
As I've said, this isn't just a random feature — it's a valuable PR
point for Fedora, and this seems like the proverbial cutting off our
nose to teach our face a lesson. I don't dispute the lesson — I don't
think anyone does — but, I don't think this approach really delivers it
effectively.

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

That sounds awesome. Elimination of manual TC composes will reduce
the manual workload significantly, right?

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

I can basically agree with this, but I think we need a way to cut some
things over from rawhide in a shorter time. As I said in the FESCo
meeting, there's a dichotomy with image-based deliverables and those
which can be delivered as RPMs, where something like this — effectively
a stand-alone change except for the rel-eng needs. If this were a new
package which were delayed in getting through review or something, it
would still very easily land after the beta freeze without much remark.


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

I think one of the main things is that people expect the accepted,
official Fedora Changes to _themselves_ serve as communication to
release engineering. I think in an ideal world, that would be very
nice, and not just release engineering. Once the changes are accepted
by FESCo, everyone would look at them and say "okay, I see this needs
to be done, and that's in my area, so I'll make sure that goes on my
worklist".

But, a) that doesn't really work in the parts of the project that are
largely volunteer, and b) for areas like release engineering where
you're stretched very thin, it's a lot to expect.

Thinking as I'm typing here: I think the answer can't just be more
procedures for the change owners — it's already heavyweight enough that
people have trouble following. And it also clearly can't be "Rel-Eng,
you need to read every change more carefully and do all the things" —
that's not reasonable either. But, I think this does answer part of my
question to Peter in the other message I just sent, about exactly where
more people would help (beyond just more bodies to shovel): it seems
like a project manager role would be very helpful in release
engineering... someone whose job _is_ to look through those changes and
translate into deliverables and tasks early on.

That's not trying to absolve change owners of the need for better
communication — that's important too. But it seems like filling that
gap in the middle would be a big step forward.

-- 
Matthew Miller
<mattdm at fedoraproject.org>
Fedora Project Leader