On 03/13/2015 04:13 PM, 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. Actually, the idea is that Atomic spins would be $current + updates (not testing), coupled with "updates" being more actively and aggressively managed by those involved with Atomic. > > 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
