On Thu, Nov 12, 2015 at 03:01:49PM -0500, Ray Strode wrote:
> On Tue, Nov 10, 2015 at 1:08 PM, Adam Miller
> <maxamillion(a)fedoraproject.org> wrote:
> > If we were to go with the former rather than the latter, we would need
> > to find a way to "namespace" container images so they can be
> > determined as different. I've thought about this a lot and I worry
> > about defining a namespace by some alphanumberic sequence because I
> > just know that at some point there will end up being a piece of
> > software in the ecosystem that we want to package as a rpm that will
> > share this pattern and result in problematic filtering. We could
> > accept that risk and simply say "this sequence is a reserved word" or
> > use a special character as the leading character in a DistGit
> > repository name to signify that it is a container.
> git repositories normally use '/' to separate namespaces, so i'd propose
> $ fedpkg clone containers/cockpit
> and maybe add support for
> $ fedpkg clone srpms/cockpit
> at the same time.
> This has the added benefit that cgit will automatically filter docker
> reposistories when you visit, e.g,
I like this too. Here are three thoughts:
Perhaps, we use 'dockerfiles' for the prefix instead of 'containers',
because presumably there will be some whole new way to build
containers in 2017, and we'll need to keep our dockerfiles/ repos
separate from our awesomefiles/ repos.
We could also use this opportunity to move the kickstarts (another
input to koji builds) away from https://fedorahosted.org/spin-kickstarts
and over to dist-git as well, with a namespace like 'kickstarts/kde'
The existing rpm content could be moved to a 'specfiles/' namespace
(or maybe 'srpms/'?) but we could further add some apache httpd rules that
respond with a redirect to the 'srpms/' namespace if the requests to
the base namespaceless-namespace level are met with a 404. -- "when in
doubt, default to srpms/". That might help keep some of our existing
tools working as-is without too much catastrophe.
I'm a big fan of where this is going.
Maybe we should draft a proposal around this (maybe some notes in
gobby?) and then start a new thread under a new name to generate more
general discussion around this in the context of being able to deliver
many different kinds of artifact for Fedora.Next. My only fear of
continuing this topic thread is that folks who aren't interested in
containers or docker might not be tuned in because of the subject