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

[Paul W. Frields]

On Tue, Apr 28, 2015 at 10:30:53PM -0500, Dennis Gilmore wrote:
> On Tuesday, April 28, 2015 09:12:08 PM Paul Frields wrote:
> > 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.
> 
> https://fedoraproject.org/wiki/ReleaseEngineering/Philosophy lays out why we 
> do thing the way we do. People proposing to add new types of deliverables have 
> to talk to us to work on making sure that we can satisfy all 
> requirements.having a place to test things while valuable and needed  It is 
> not the most important thing,  which I think is engagement with releng when 
> you have something that delivers something new.  while adding a new LiveCD 
> spin is trivial, we add a new kickstart and edit some scripts and it is done. 
> adding something that needs new tooling and integration takes a lot more work 
> and effort.  FESCo now requires that people talk to releng when preparing a  
> change that requires releng to do anything.  So hopefully going forward that 
> will help.

I think we're violently in agreement here.  IOW, the testing area is
not a place to skunkworks things without rel-eng visibility.  It's to
encourage early prototyping and review directly by rel-eng, *prior* to
any formal change process, so we don't start off in an ineffective
direction.

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