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

[Tadej Janež]

Hi!

On Sun, 2014-02-09 at 01:25 -0500, Matthew Miller wrote: 
> COPRs are cool, but very much the uncharted wilderness. The Fedora
> distribution proper is a stockade fort with high walls -- it's very nice
> iside (with some rough parts of town... I can take this analogy all the
> way...) but the barrier to get in is giantic and topped with spikes. 
> 
> And it's not just that there's a lack of guidelines. Different COPRs repos
> don't need to work together, and it's imposible to tell which will or to
> have any epectation that two which work together today will work together
> tomorrow. And, packages aren't signed at all.
> 
> So, the proposal: a new repository in the Fedora Project which I am
> tentatively calling "Fedora Ugly". It could be "Fedora Staging", but I think
> that promises a bit much (some things may remain here for a really, really
> long time). This repo would provide an integration space where packages from
> diverse COPRs repos could come together, and also be more discoverable by
> other Fedora developers and users (just add one repo).

Generally, a big +1 from me for the idea.

I really don't like the name "Fedora ugly". While it may make sense to
us, it would quite possible send the wrong message to those who we
target with this repo.
I'm also not so in favour of naming it "Fedora Staging" or "Fedora
Incubator", since it would send the message that packages would
eventually come out of this repo. Well, they might be just fine sitting
in the repo forever.

Of the top of my head, I would say we need to send the right message to
two audiences:
1) Upstream application authors/Wanna be Fedora packagers: we need to
tell them that we want them to "play" with us, create packages for
Fedora and that it is not so difficult and strict as it is now (i.e.
they don't need to follow the current Packaging guidelines).
2) Fedora users: we want to tell them: "Hey, we have this cool new repo,
which provides so much more packages than just Fedora's main repo, but
you should know that:
- these packages might have security issues which won't be fixed as
quickly as they are right now in Fedora's main repo,
- these packages might not have gone through the same QA scrutiny as
packages in Fedora's main repo,
- these packages might disappear or become unmaintained quickly, if
their author is not interested in them anymore
- etc."
Basically, I advocate to set the right expectations for users and tell
them it's a *best effort* thing.

So, in-line with that, I'm suggesting that we name it:
- "Fedora Easy(TM)", since it will be easier for upstream application
authors to get their apps in Fedora (the same for Wanna be Fedora
packagers) and we need to tell the users to "ease up" their expectations
for packages in this repo,
- or "Fedora Mantle", since it would mean upstream application authors
can stay in the "mantle" zone and not "dig" to the "core" if they don't
want to, and the users will know that the packages would not be the
"core" focus of Fedora (like Fedora's main repo).

>  - it could feed from COPRs -- add your packages by checking a box

+1. I think it would be a very natural workflow to first make your own
(scratch) packages, improve them, build them and then, if you see
interest/demand, propose them to inclusion in the "ugly" repo.

>  - packages would only go in if they meet minimal automatic gating --
>    can't conflict with other packages

I think we should define a small core policy (e.g. non-conflicting with
packages in Fedora's main repo, no over-riding of packages in Fedora's
main repo, licenses compatible with Fedora) and have an automated way to
check and enforce it. Having a manual review process would unnecessarily
slow the process of populating this repository.

>  - possibly some sort of automatic flagging of crazy %pre or %post package
>    scripts?

Yes, definitely, since these are going to be executed as root, right?
We could have automated testing that would warn if the package's %pre or
%post scripts tamper with other parts of the system. Another idea would
be to only allow "macroized" %pre and %post scripts and the macros would
be provided and controlled by main Fedora?

>  - if they don't meet the gating, package owner would get an email
>    explaining the problem

+1 (or some other notification).

>  - Fedora packaging guidelines don't apply fully, but maybe some subset
>    is appropriate?

Yes, it would make sense to not reinvent the wheel.
But to reach a consensus on the subset might be challenging.
I'm in favour of the subset being as small as possible.

>  - repo would be off by default, but easily enabled in yum or in Gnome
>    Software

+1. We could set users' expectations in the spirit of what I wrote in
the beginning by presenting this in Gnome Software (or as a comment in
yum/dnf's repo file).

>  - packages would be signed, possibly by a different key from the main
>    Fedora one. 

+1

>  - signing could be automatic rather than manual

+1

>  - ugly-testing or ugly-updates repo, and rolling release vs versioning? to
>    be figured out!

I agree that, in principle, the repo should follow the current lifecycle
of Fedora's main repo.
We don't know yet how the products might change that in the future, so
this will need to be figured out.

Tadej