----- 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. -Mike > -Ian > > _______________________________________________ > cloud mailing list > cloud@xxxxxxxxxxxxxxxxxxxxxxx > https://admin.fedoraproject.org/mailman/listinfo/cloud > Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct > _______________________________________________ cloud mailing list cloud@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/cloud Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
