Atomic 2 week releases

[Ian McLeod]

On 03/13/2015 04:13 PM, Michael P. McGrath wrote:
> ----- Original Message -----
>> From: "Ian McLeod" <imcleod at fedoraproject.org>
>> To: cloud at 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.

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 at lists.fedoraproject.org
>> https://admin.fedoraproject.org/mailman/listinfo/cloud
>> Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
>>