[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

Re: 'policy' for multiple versions of same software in EPEL

On Wed, Oct 24, 2012 at 11:51 AM, Michael Stahnke
<stahnma puppetlabs com> wrote:
> On Wed, Oct 24, 2012 at 9:30 AM, Greg Swift <gregswift gmail com> wrote:
>> On Tue, Oct 23, 2012 at 10:43 AM, Kevin Fenzi <kevin scrye com> wrote:
>>> ...snip...
>>>>                                             \--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 :)  )

yea... i'm well aware of that pitfall.. i've suffered from it as well

> 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.

So.. just spent like 30m digging through the wiki and somehow did not
stumble across the 'how to start a sig' page. anyone got a pointer?

[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]