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

[Paul Frields]

On Fri, Apr 24, 2015 at 1:16 PM, Colin Walters <walters at verbum.org> wrote:
> On Fri, Apr 24, 2015, at 12:22 PM, Paul W. Frields wrote:
>>
>> 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.
>
> I keep circling back to the concept of a staging rel-eng space.
>
> Certainly before any deliverable is being proposed, some functional
> prototype of how it's built in a reliable fashion is feature complete.  Then
> after that the Change is "promoting" it to be a defined reliable
> updated bit.
>
> Let's take the Vagrant box as a concrete example.  Someone
> who was joining from outside could very reasonably propose
> using Packer:
> https://www.packer.io/intro/getting-started/vagrant.html
> to make a Fedora vagrant box.
>
> They say "Hey Vagrant is popular enough to be official, let's get
> this in rel-eng staging".  So some resources are provisioned to
> do this, they get a little bit of space to manage the release.
>
> Then later, a Change is made for this to be official.  At that
> point someone from rel-eng looks and would say things like
> "Hey this Packer thing completely duplicates the ImageFactory
>  work that's already in Koji, can you rework to use that?  And
>  kickstart files, etc."

I think this may actually be the direction we've been discussing since
Adam joined -- modulo waiting until we're that far along to get input.
;-) I don't think we want to wait for some formal Change to get the
rel-eng community to look at the approach. But we want a safe (from
production interference) place to prototype stuff. Right now the
"staging" we have is broken. So the critical path is to fix it up, and
see how we need to extend it to accommodate more experimentation.

-- 
Paul