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

[Stanislav Ochotnicky]

Matthew Miller <mattdm at fedoraproject.org> writes:

> This idea has come up several times at DevConf, and I thought I'd throw it
> out here so it can maybe get further development and discussion.
>
> 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).
>
> Some specifics:
>
>  - it could feed from COPRs -- add your packages by checking a box
>  - packages would only go in if they meet minimal automatic gating --
>    can't conflict with other packages

How about updates for packages in given Fedora release? I'd say no
because that easily breaks integration/other parts. That's what copr is for.

>  - possibly some sort of automatic flagging of crazy %pre or %post package
>    scripts?
>  - if they don't meet the gating, package owner would get an email
>    explaining the problem
>  - Fedora packaging guidelines don't apply fully, but maybe some subset
>    is appropriate?

Basic licensing should apply, but most likely I'd ignore bundling stuff
because that's often going to be main reason for being in this repo.

>  - degree to which packages would be allowed here forever vs. encouraged
>    to improve so they can eventually be in the main repo is an open
>    question

I'd say people would be expected to work on integration but there's no
guarantee.

I mentioned this during the talk, but basically I think adopting
"Incubator" name and generic process from Apache project and
Eclipse[2]. It's well know terminology in OSS world IMO.

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

Sounds good

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

Sensible as well I'd say

>  - signing could be automatic rather than manual

Not sure about this one...probably not.

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

They'll have to match the releases. It should basically follow the same
workflow/lifecycle as normal packages

>
> What do people think of this idea overall? Anyone interested in polishing
> this up into a Real Thing?

As said up top I'd prefer Fedora Incubator naming but otherwise +1!


[1] http://incubator.apache.org/
[2] http://wiki.eclipse.org/Development_Resources/Process_Guidelines/What_is_Incubation

--
Stanislav Ochotnicky <sochotnicky at redhat.com>
Software Engineer - Developer Experience

PGP: 7B087241
Red Hat Inc.                               http://cz.redhat.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 835 bytes
Desc: not available
URL: <http://lists.fedoraproject.org/pipermail/env-and-stacks/attachments/20140209/4a3a6aad/attachment.sig>