half baked idea for further baking: "fedora-ugly" repo

Jens Petersen petersen at redhat.com
Thu Feb 13 08:03:00 UTC 2014

> Matthew Miller (mattdm at fedoraproject.org) said:
> > - depending on the focus between "ugly" vs. "incubation" or "staging" as a
> >   name, the implication would be that these are packages which are
> >   _striving_ to be part of the commons ("Fedora Collection"?) but aren't
> >   ready yet, whereas some other things might live in COPRs forever and
> >   have no intention of ever playing nice.
> So, from a user perspective, what does this buy us? If (for example) the
> only reason it's not in the main repo is that it has bundled libs, what are
> we accomplishing by making the user have an extra checkbox?

Well there are many packages (either with submitted reviews
or not) that take a very long time to get into Fedora
because of the review process.  Good examples might be
javascript (*cough* jquery cough;), but personally there are also
loads of Haskell libraries I would like to put into Fedora but
am not able to also due to the limited review manpower
(Fedora Haskell lags behind Debian and Ubuntu because of this).

> IOW, why not just restrict the super strict guidelines to the core product
> repos of Fedora, and have this repo be for things outside of that, which can
> include things that follow the guidelines, and things like chef that don't.

I am not following the implication/difference, you mean to build out from Core
(koji and current infrastructure) rather than inwards from the outside (copr etc)?
That could also be a reasonable approach - particularly for Commons.
There are certainly good arguments for re-using current infrastructure
where possible while keeping the new repo accessible.

Certainly I have questions about the new repo:
will packages be in git?  tracked by bugzilla?
Can packages be pulled from the repo: either by the maintainer
or because of breakage say?  How to distinguish packages?

Is "Ugly" also a part of Ring 2 btw?

BTW Honza Horak suggested the name Playground in the E&S Meeting,
which I rather like.


More information about the env-and-stacks mailing list