On Fri, Mar 13, 2015 at 05:13:29PM -0400, Michael P. McGrath wrote:
----- Original Message -----
> From: "Ian McLeod" <imcleod(a)fedoraproject.org>
> To: cloud(a)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