On Fri, Mar 13, 2015 at 05:13:29PM -0400, Michael P. McGrath wrote: > ----- Original Message ----- > > From: "Ian McLeod" <imcleod@xxxxxxxxxxxxxxxxx> > > To: cloud@xxxxxxxxxxxxxxxxxxxxxxx > > 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 _______________________________________________ cloud mailing list cloud@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/cloud Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
