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

[Paul W. Frields]

On Thu, Apr 23, 2015 at 01:39:23PM +0100, Peter Robinson wrote:
> 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.

This is a good balance to strike.  At the same time, Dennis himself
said in the FESCo meeting there was not much work to do on rel-eng,
and he was worried more about impact on QA and websites.  Both these
issues were being taken care of already, which was related to him
according to the logs.  He said this was a matter more of principle
and that it would set a bad precedent to let other things in
last-minute.

I can only assume Dennis is right and there isn't a lot of work on
rel-eng.  I would therefore remind folks that Fedora's not a court of
law, and we shouldn't deal in precedent, but in *practicality*.

This is indeed a relatively last-minute change.  But by no means does
making one decision here *require* doing the same for something else
in the future.  If doing so causes substantial last minute pain for
rel-eng or *any* team that we don't have a plan to mitigate, the
answer should be "no."

When we start worrying about precedent, it's easy to sideline the need
for Fedora to be on or near the front lines of innovation and
progress.  That progress should *never* be at the cost of anyone's
sanity!  At the same time, when we hear that making these extra
products available isn't a lot of work, *and* we have a plan to ensure
they're reasonably good quality, precedent or principle doesn't
convince me we're doing the right thing for the community or users
overall.

Paul
[...snip...]
> > 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).

Fully agree that making rel-eng monitor this stuff makes no sense and
doesn't scale.  We need to find a better solution, and I think some
real project management approach makes sense as one alternative.

-- 
Paul W. Frields                                http://paul.frields.org/
  gpg fingerprint: 3DA6 A0AC 6D58 FEC4 0233  5906 ACDB C937 BD11 3717
  http://redhat.com/   -  -  -  -   http://pfrields.fedorapeople.org/
    The open source story continues to grow: http://opensource.com