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