FAD Goals and deliverables

[Luke Macken]

On Wed, May 13, 2015 at 09:02:08AM -0500, Dennis Gilmore wrote:
> On Wednesday, May 13, 2015 09:17:23 AM Colin Walters wrote:
> > On Sun, May 10, 2015, at 02:28 PM, Dennis Gilmore wrote:
> > > 2) integrated ability to make atomic installer and pxe to live in pungi
> > 
> > Downstream Atomic operates on an asynchronous schedule, so there
> > are going to be few times when we actually want to generate two installers
> > and trees/etc simultaneously.
> > 
> > The CentOS Atomic SIG is also planning to do regular 4 week releases,
> > again asynchronously of the CentOS Core rebuild.
> > 
> > We would also like the ability to do faster and more regular releases
> > of Fedora Atomic Host - a 2 week interval has been discussed.
> This is a big part of why we need it integrated into the tooling. we can 
> define a pungi config that has a subset of the full compose, i.e. the atomic, 
> and possibly cloud and/or livecd bits.
> we can then make them as part of the 
> updates push process and  promote them to stable at any time.

So you're saying bodhi should run pungi as a part of the push process
and handle creating installers, trees, and pxe images? Do you want
people to have to submit these things to go through the testing->stable
karma cycle through the bodhi interface?

Bodhi has already seen a tremendous amount of feature-creep, so I want
to make sure the expectations are set appropriately. My primary focus
with it at the moment is to have bodhi2 get the existing bits out to the
mirrors for testing as fast as possible. It is not designed to create
the bits, it's designed to take what's already built/composed and
facilitate community testing. It is designed for updates, not releases,
which it sounds like the 2-week model is about.

Instead of making bodhi an arbitrary task-runner for various releng
tasks, I think that effort should be focused on Koji plugins + The
ComposeDB. The goal has always been to outsource the mashing of the
updates repos to our build farm, and I think these various
trees/images/containers/installers are in the same boat. I'm fine with
bodhi potentially kicking off these various tasks, but it is not
designed to be a compose farm.

> > That doesn't mean that the code can't be shared - but it does make
> > the "release mainline and Atomic together as one big blob" is an
> > unusual case.
> not at all. 
[...]
> > So there may be a more fundamental decision to make about whether
> > Atomic should simply be part of that "big set" release at all.
> not at all.

With regard to updates, I am in favor of getting bits out asynchronously
as fast as possible. This means repos would hit first, then the various
installers/trees/images trickle out shortly after as soon as they
complete.

luke
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: not available
URL: <http://lists.fedoraproject.org/pipermail/rel-eng/attachments/20150514/eeb54653/attachment.sig>