On Tue, Apr 7, 2015 at 6:43 PM, Colin Walters <walters@xxxxxxxxxx>
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 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:
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
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.
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 library
breaks it may just affect your app and not the host, etc.
[1] https://bugzilla.redhat.com/show_bug.cgi?id=1197204
_______________________________________________
cloud mailing list
cloud@xxxxxxxxxxxxxxxxxxxxxxx
https://admin.fedoraproject.org/mailman/listinfo/cloud
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
