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.
* 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?
-Ian