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

Peter Robinson pbrobinson at gmail.com
Wed Apr 22 22:36:25 UTC 2015


On Wed, Apr 22, 2015 at 9:28 PM, Joe Brockmeier <jzb at redhat.com> wrote:
> On 04/22/2015 03:31 PM, Matthew Miller wrote:
>> 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.
>
> Sign me up.
>
>> 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.
>
> This is discouraging and disappointing. Yes, I totally get that we need
> to have processes and procedures that protect our already hard-working
> folks from being overrun with last-minute requests, changing
> deliverables, and all that. I do. I get it.
>
> But this ... we did spell this out in the request. Maybe we didn't do it
> properly, but it was in the change request. We had someone rush the
> work. IT WORKS. There's no reason not to ship this other than to stand
> on a principle of enforcing procedures.

What works? The creation of it in a kickstart? Any one can throw
together a kickstart and "make IT WORK" but just some of the other
things rel-eng needs to deal with for each of the features we need to
deal with are:
* How do we build it in a repeatable way
* How do we ensure we're complying with publishing of all the source
and process to recreate the product as an open source project
* How do we sign it and ensure it's verifiable that it's from us
* How do we update it with security updates. This now isn't just a
"yum update" but new cloud images, or atomic tree updates
* How do we distribute it. Does it get pushed it out to mirrors, AWS,
docker registry, cloud providers. Do we need accounts, security keys,
etc to do so, do we need to pay for that.

I mean it's very easy to say "here's the kickstart, it works" but I
would say 90% of the time need to spend a non insignificant amount of
time dealing with the above. It then can also have an impact on the
rest of the process and the time it takes us to get a release out
(about 8 hours I think for a RC/TC at the moment, if it breaks 7.5
hours in we have to fix and do it again. Good bye sleep!

> This is a loss for the project and our users.

I don't disagree but I really don't think you've fully taken into
account the amount of work it is for us to get a feature even one
"THAT WORKS" from a users perspective out to a high quality on
numerous levels that in a lot of cases people don't even consider
because when it churns through rel-eng and the infrastructure teams it
also "just works" but there's a lot of cogs grinding away to ensure as
smooth and consistent experience for users and for us we have to plan
ahead for it's whole lifecycle not just the one that ends for the
developers when it goes GA.

I mean if this process was so easy to deal with the tools to do this
where is Bodhi2? Last I heard it was due to go live in Jan post F-21
GA, I have no idea on the latest timeframe. I still don't see it and
it's been talked about for 5 years or so if my memory serves me
correctly I think I remember it being discussed at FUDCon Toronto ( I
apologise if my timing is a little out here, it's a long time).

>> 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.
>>
>> 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.
>
> Not only is the project making it up as we go along, so are participants
> and volunteers. I know I get it wrong occasionally, but I do *try* to
> follow procedures. The thing is, we need to make it easier for people to
> contribute, not raise barriers. How would someone who isn't paid to work
> on open source feel about this? Would they come back to do this again?

It's not about putting up barriers. I mean if a Change isn't in place
in time it's pushed back to the next release. There were a number
pushed back this cycle. We don't have these discussions internally
because there's RCM processes in place and there's schedules and
timings for these schedules and if they don't meet it they go to the
next cycle. Why are you beating us up here because we're public?

There are other teams in Fedora that have deadlines (web team is one
I'm aware of, not sure exactly as I don't have the time to deal with
them as much as I would like.

Peter


More information about the rel-eng mailing list