[atomic-devel] Atomic 2 week releases

Jason Brooks jbrooks at redhat.com
Wed Apr 8 15:11:05 UTC 2015

On Tue, Apr 7, 2015 at 6:43 PM, Colin Walters <walters at verbum.org> 
> [ Resurrecting, adding atomic-devel CC ]


> I mentioned this before, but a critical hinge point is whether the 
> tree + images are
> entirely composed of RPMs built in Fedora.  AIUI for example, if we 
> had a COPR
> (or whatever) with a more bleeding edge Docker[0], or carried a 
> patched systemd
> temporarily[1], I believe that would run afoul of:
> https://fedoraproject.org/wiki/Legal:Trademark_guidelines?rd=Legal/TrademarkGuidelines#Virtual_images_or_appliances_with_combinations_of_Fedora_software_with_non-Fedora_or_modified_Fedora_software

A Fedora Remix might be an option: 

> ...at least, I assumed so offhand, but reading it, in that page
> "Fedora software" isn't defined - does COPR count or not?
> Anyways...my bottom line here is that it feels really weird to me to 
> fight all
> the way for F22 and sustain that only to split it out after.  It's a 
> lot simpler
> to say F21 was our first try, we learned some things, but a lot more 
> work
> needs to be done, it'll be faster to iterate outside and then merge 
> back
> when it's ready, which may be F23 or whatever.

This makes sense to me. There's some loss in pulling back from being an 
official Fedora release, but for now, in order to do Atomic well, we 
may need more flexibility than the current policies permit.


> [0] OSTree was born to do continuous delivery, and the fact that it's 
> wedged
>      after the slow, plodding, conservative mainline koji + "daily 
> build" + bodhi
>      IMO weakens its value a lot.  We could also be a lot more 
> aggressive
>      with updates to the RPMs that go into Docker containers - if 
> some http library
>      breaks it may just affect your app and not the host, etc.
> [1] https://bugzilla.redhat.com/show_bug.cgi?id=1197204

More information about the cloud mailing list