Atomic 2 week releases

Paul W. Frields stickster at gmail.com
Fri Mar 13 21:29:26 UTC 2015


On Fri, Mar 13, 2015 at 05:13:29PM -0400, Michael P. McGrath wrote:
> ----- Original Message -----
> > From: "Ian McLeod" <imcleod at fedoraproject.org>
> > To: cloud at lists.fedoraproject.org
> > Sent: Friday, March 13, 2015 4:08:46 PM
> > Subject: Re: Atomic 2 week releases
> > 
> > 
> > On 03/13/2015 02:58 PM, Matthew Miller wrote:
> > > On Fri, Mar 13, 2015 at 02:26:42PM -0400, Joe Brockmeier wrote:
> > >> We are on the hook for an Atomic Host release for F22, but I think I'd
> > >> rather message why we're putting our weight behind a rapid-release host
> > >> based on Fedora than dealing with two competing Fedora-based offerings.
> > > Has the spinner deciding whether the rapid-release host will be based
> > > on Rawhide or on $current come to a definitive rest yet?
> > >
> > > If the focus is on Rawhide, and we don't have interest / resources in
> > > keeping the $current branch up to date, I share Joe's concern — not
> > > just for confusion due to too many options, but also because in that
> > > case $current would almost always be the wrong choice (lagging CentOS
> > > and even RHEL). I think this would weigh heavily towards presenting
> > > that rawhide-based output on its own atomic.fpo home, because if
> > > $current is really going to be $outofdate, new users _will_ inevitably
> > > get the wrong thing.
> > >
> > > If development is done in Rawhide but also released to $current on a
> > > two-week cycle, I might have other worries, but this wouldn't be one of
> > > them. :)
> > >
> > >
> > Apologies for joining in late folks.  I'd like to summarize (I hope) a few
> > points that have been made in this thread and in a handful of
> > side-conversations.
> > 
> > If we want something that is able to be consistently released every two
> > weeks, we will likely struggle with rawhide.  Although we all want rawhide
> > to be usable day to day, it is not guaranteed to be stable and/or able to be
> > built.  We, the Atomic team, are in no position to either A) force it to be
> > stable or B) apply even more effort as part of Atomic beyond the core work
> > to ensure that rawhide stabilizes every two weeks.
> > 
> > So this pushes us in the $current direction.
> > 
> > The primary concern with $current is that Atomic may, for a narrow set of
> > core packages, wish to run slightly ahead of what is in updates-stable for
> > $current.  However, I think this is more of a hypothetical/future concern at
> > the moment.  The core elements (docker, kubernetes, and rpm-ostree/ostree)
> > are being pushed out to updates-testing (and our CentOS CBS builds) pretty
> > rapidly.  If we have a problem, it's that they are not being tested and/or
> > promoted.
> > 
> > So, two concrete options to consider:
> > 
> > * Option 1
> > 
> > We target our 2 week release efforts at $current, which should involve a
> > greater focus on testing and karma-ing the Atomic components as they show up
> > in updates-testing.
> > 
> > This gets us the stable base and gets non-Atomic $current users a nice flow
> > of updates to popular and topical packages.
> > 
> > And, at the risk of stating the obvious, this in no way prevents rawhide
> > Atomic spins.  The road to updates-testing passes through rawhide and the
> > rawhide nightly compose, AIUI, already includes attempts at Atomic tree
> > composes and Atomic images builds.
> > 
> 
> So the Atomic spins would be $current + the updates-testing packages we
> care about (and have tested / have some influence over).  That spin
> would then be copied to the mirrors and we'd be able to link to it.
> 
> There's a nice side benefit there which is if someone who's running non-atomic
> Fedora wants to look at the latest of docker, kubernetes, etcd, ostree,
> whatever, they could just enable updates-testing and have access.
> 
> Sounds like all of the benefits of the original rawhide suggestion with
> none of the pain.
> 
> > * Option 2
> > 
> > If at some point we feel we must carry some Atomic-focused updates that are
> > not appropriate for $current, we maintain a very small side-tag to hold
> > them.  This is essentially what we are already doing for CentOS in the
> > "atomic7-testing" tag on the CBS koji instance here:
> > 
> > http://cbs.centos.org/koji/taginfo?tagID=40
> > 
> > Who exactly manages this tag and how content is promoted into it is TBD.
> > 
> > I personally think we should at least try Option 1 with 2 as a fallback.
> > 
> > Thoughts?
> > 
> 
> +1 to at least trying option 1.

FWIW this makes sense to me, too.

In a chicken-and-egg twist, Atomic may hold part of the key(s) to
making Rawhide more reliably stable and usable in the future.  I think
Atomic stands a better chance for testing and visibility on $current
as already pointed out.  So eventually that will, I hope, yield more
effective iteration on features that allow us to build if not a less
broken Rawhide overall, than at least a more easily recoverable one.

This issue may be somewhat orthogonal to problems with building or
composition of Rawhide.  But still I hope it's a future possibility.

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


More information about the cloud mailing list