Once upon a time, Jesse Keating <[email protected]> said: > I think part of the reason is that non-RHT customers have no binaries in > which to test their builds upon. Ballparking here, but I think not a > small amount of EPEL packagers are CentOS (or other) users and not RHEL > users.
I've probably come off sounding short/argumentative in this, and I want to apologize for that. I'm really just trying to figure out the reasons behind the choices and decisions. What does "released" mean for EPEL? AFAIK it doesn't mean "100% packages available". There is a set of packages that are (or at least are believed to be) ready now; why not release them now? If someone is waiting on CentOS to get their packages ready, that's okay; those packages won't be in the EPEL 6 release tree until they are. That's why I asked if there is some metric to use to decide when EPEL is "ready". If it is X% of packages, or certain "major" packages, that should be documented somewhere, and then when that point is reach, EPEL can be released. I don't see any reason for just waiting an arbitrary amount of time (what if nothing really changes in a month?). EPEL doesn't have separate release and updates trees; there's just the EPEL tree. Packages are added as somebody picks them up, so I would say just release what is considered ready now and let EPEL 6 grow over time (just like previous EPEL versions have done). > That said, I think it would be quite fair to grant each EPEL packager > with a RHEL developer entitlement which could be used to test their > builds upon. That would be nice, although it would probably require some minimum level of commitment (e.g. not people like me that only maintain a couple of very minor packages, and otherwise just agitate in Bugzilla and on mailing lists :-) ). I still think some clear direction about which OS is the primary target for EPEL (RHEL or CentOS) should be stated. Since CentOS will always lag RHEL (not through any failure of CentOS; it is just a fact), EPEL can either target RHEL and update things when new RHEL updates come out that require EPEL changes, or wait until CentOS gets the compatible update in place. You can't have it both ways, at least not for the same packages, and I would think the policy should be the same for all of EPEL. CentOS also already has its own set of add-on repos (although not near as large as EPEL) that have some overlap with EPEL. My personal preference (of course because I use RHEL) would be for EPEL to stay current with RHEL, rather than wait for CentOS. For example, in the situation where RHEL releases a backwards incompatible security update that requires an updated EPEL package, but the EPEL package is waiting for CentOS, a "yum update" will not load the RHEL security update unless you first remove the old EPEL package, blocking the update from RHEL users. On the other hand, if the EPEL package is updated before CentOS gets the security update, the CentOS users can use --skip-broken to just skip the EPEL update they can't yet load, and RHEL users can load all their updates. Once CentOS gets the update, they'll get the EPEL update as well. I think that's a better situation. -- Chris Adams <[email protected]> Systems and Network Administrator - HiWAAY Internet Services I don't speak for anybody but myself - that's enough trouble. _______________________________________________ epel-devel-list mailing list [email protected] https://www.redhat.com/mailman/listinfo/epel-devel-list
