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

[Peter Robinson]

On Thu, Apr 23, 2015 at 1:07 PM, Matthew Miller
<mattdm at fedoraproject.org> wrote:
> 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

Because the rawhide compose process is nothing like the official
compose process. It doesn't deal with
updates/signing/distribution(mirrors etc) etc. It's just run in koji
and you get the results, it might pass some days not the others and
there's no distribution of the output in a official
supported/signed/updatable means. The F-23/rawhide process Dennis
described below will be significantly different to the current F-22
one.

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

It's not a cut of our nose to despite our face effort. As much as
people would like to spin it as rel-eng being evil and non cooperative
every I believe we do everything in our effort to be as flexible as
possible while maintaining stability and not have the potential of
delaying the release at this late stage and attempting to keep some of
our own sanity and not work every hour of the day.

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

Yes, and that's why we've been pushing to get the code used internally
open sourced, it's the beginning, there's still a lot of work to add
all the missing Fedora bits in that the Enterprise product doesn't
care about.

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

Yes, but the only part of the process that needs anything from rel-eng
in a new package is the signing of it as it goes out the gate. It's
not an Apples and Oranges comparison.

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

Everyone look at them every time they change? There are days I barely
get time to read my email! Sorry I don't believe that to be scalable.

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

Maybe a series of tracker bugs where the Change Wrangler when creating
the tracking bugs links them to Web/rel-eng/whatever and flags (or
what ever they are) to track approval etc? So rel-eng can track a
single f23-change-releng tracker bug to see what people are
requesting? (thinking as I type)

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

Yes, having read this post typing the above it sort of aligns with the
tracker bug by the the Change Wrangler who has to read them all
anyway.

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

Ultimately the change owner should bare the majority of the
responsibility. It's an issue we've had for a long time but going back
to pre .next the rel-eng involvement was less but with images/atomic
etc that have come since we're trying to scale the process within
resource constraints and not breaking everything (one).