On Tue, Apr 7, 2015 at 6:43 PM, Colin Walters <walters verbum org> wrote:
[ Resurrecting, adding atomic-devel CC ]
[snip]
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 systemdtemporarily[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: https://fedoraproject.org/wiki/Remix#Are_Remixes_and_Spins_different.3F
...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 backwhen 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.
Jason
[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 librarybreaks it may just affect your app and not the host, etc. [1] https://bugzilla.redhat.com/show_bug.cgi?id=1197204