'policy' for multiple versions of same software in EPEL

[Kevin Fenzi]

On Wed, 24 Oct 2012 11:30:53 -0500
Greg Swift <gregswift at gmail.com> wrote:

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

I'm still leary of the seperate branch. ;) 

Even aside from more work I worry that we will run into several
possible problems: 

- New unstable branch is too unstable. Ie, people will enable that and
  yum upgrade and it breaks them and they will be unhappy. Even if the
  expectation of the branch is that it will be not stable. 

- Old branch gets forgotten about... ie, maintainer pushes new and
  ignores bugs/security issues on old branch because they now don't
  have the same incentive to make it work. ;( 

- Extra confusion around tools and branch changes... 

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

Perhaps it would help if you could spell out exactly what things you
need for yourself/company and we could try and figure out a better way
to get them... if it's just a few packages that must be newer, perhaps
a side repo would be best. 

kevin
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: not available
URL: <http://listman.redhat.com/archives/epel-devel-list/attachments/20121024/68d9d924/attachment.sig>