On Wed, Oct 24, 2012 at 2:40 PM, Kevin Fenzi <ke...@scrye.com> wrote: > On Wed, 24 Oct 2012 11:30:53 -0500 > Greg Swift <gregsw...@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.
So... going back to my REPEL name recommendation ;) Okay... seriously though. Fedora has the same issue. Fedora is not stable. Doesn't claim to be. But people still install it and expect it to be. I don't see us actually changing what Fedora is just because of that. (lots of talk on occasion and i guess maybe there is a action item I haven't heard of...) > - 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. ;( That is a problem. However, its already the case from what I've observed. The old packages stagnate and the users move to an internal/separate repository or start a separate package path, or in a few cases just update the package. > - Extra confusion around tools and branch changes... To me the biggest set of confusion around this whole thing is that it is inconsistent and not set forth in a policy. Right now the policy ends up being 'well.. don't break the customer, otherwise figure it out'. If the policy was: EPEL is a slow moving, safe to upgrade, but not always safe from a security standpoint after X amount of time repository. REPEL is a faster moving repository that may include updates that require manual intervention. Use at your own risk, but you'll probably have more secure updates since its staying current. or going to Ken's suggestion: EPEL is a slower moving repository. In line with RHEL dot releases new packages maybe released that require manual intervention to work post install, however this is due to the need to keep software secure and current. As long as a release branch is receiving updates from upstream, that package will be able to update safely. Once upstream has EOL'd the tool it will be updated based on an assessment of the tool's newer releases. To stay aware of these potential updates we do X, Y, and Z to notify users. You can protect yourself from the change by placing the package in your exclude list per these instructions. >> 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. So what got me going on this _this time_ was wanting to have rspec-puppet and collectd5 in EPEL. Which led to the need for rspec to be updated to rspec2 (for EPEL5/6). Combine that with my past interest in bugzilla, zabbix, puppet, and a few other projects. Because of that I thought it would be nice to try and address the obvious overall issue rather than just get my two packages taken care of. -greg _______________________________________________ epel-devel-list mailing list epel-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/epel-devel-list
