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

Marcela Mašláňová mmaslano at redhat.com
Mon Feb 10 14:16:45 UTC 2014


On 02/09/2014 01:18 PM, Stanislav Ochotnicky wrote:
> 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
>
>
>
> _______________________________________________
> env-and-stacks mailing list
> env-and-stacks at lists.fedoraproject.org
> https://lists.fedoraproject.org/mailman/listinfo/env-and-stacks
>
I prefer name incubator. So we have topic for tomorrow meeting, yay!

Marcela


More information about the env-and-stacks mailing list