'policy' for multiple versions of same software in EPEL

[Michael Stahnke]

On Wed, Oct 24, 2012 at 9:30 AM, Greg Swift <gregswift at gmail.com> wrote:
> On Tue, Oct 23, 2012 at 10:43 AM, Kevin Fenzi <kevin at scrye.com> wrote:
>> ...snip...
>>> NEW ---> PENDING --> TESTING --> STABLE --> OBSOLETE
>>>                                             \--UNSTABLE--/------------/
>>>
>>> With an UNSTABLE package also being able to push into STABLE if the
>>> STABLE package is no longer considered safe to run (that unsupported,
>>> or no available patch for security issue, or whatever.. would define a
>>> list)
>>>
>>> Or the UNSTABLE package would just live in UNSTABLE unless it gets
>>> sent to OBSOLETE.
>>
>> Right. If you allow crossing the unstable/stable streams here it
>> becomes very complicated.
>>
>> This is where the start of all the work is... make git repos understand
>> an unstable, make bodhi and mash and other compose tools understand it,
>> have some way to report bugs about it (how do you set it in bugzilla?).
>>
>> Lots of complicated questions and then lots of actual work. ;)
>>
>> Even if you don't allow them to cross (ie, it's a completely seperate
>> branch), it has still a bunch of work around the tools to get them
>> working with it. Also, there will be problems where 'stable' stuff gets
>> ignored or shoved down because people are more interested in the
>> unstable part, etc.
>
> Between thinking about it more, reading the RHEL/EPEL conflict post
> again, and this post I'm inclined to go with the separate branch path.
>
>> Personally, I don't have the time or desire to do all this work. If a
>> group of folks wanted to write up a complete plan here and offer to do
>> the work, I would be happy to provide feedback and get talked into
>> helping them out, but it would have to be a pretty good plan. :)
>
> I have some cycles to work on this, but i would much rather have help,
> especially people that have more experience in these tools than I.
> This falls into the 'i either do it privately to benefit
> myself/company, or try and make it work in EPEL to benefit others that
> have expressed the need' category.  Personally, I prefer to work
> upstream on it, but unless others are gonna hop on board its going to
> be much easier in the short term for me to go the private route.
>
I think users of the EL ecosystem would really like a repo with
updated software etc, but if getting EPEL off the ground is any
indication, you'll have very low participation from a development and
infrastructure side, a *lot* of infrastructure needs.  It took months
(possibly years) to even find broken deps in EPEL due to lack of
time/focus from the EPEL community, and that's a pretty simple task.

Also, people who change jobs etc who were at one time very able to
help out suddenly can have a lot less time.  (Ask me how I know :)  )

If you could get 10-12 people willing to do the infrastructure work
(like a SIG etc) it might be viable setup.  Outside of that private
repos (or even public but not on Fedora properties) might be the way
to go.



> -greg
>
> _______________________________________________
> epel-devel-list mailing list
> epel-devel-list at redhat.com
> https://www.redhat.com/mailman/listinfo/epel-devel-list