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

[Dennis Gilmore]

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.

Dennis
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: This is a digitally signed message part.
URL: <http://lists.fedoraproject.org/pipermail/rel-eng/attachments/20150428/bf638a8b/attachment.sig>