On Mon, Oct 29, 2012 at 12:52 PM, Kevin Fenzi <ke...@scrye.com> wrote: > This plan has also come up before. ;)
I didn't realize this had been brought up before. Do you have a link to the discussion? I've browsed through the EPEL archives and I didn't see something like this. On Mon, Oct 29, 2012 at 12:52 PM, Kevin Fenzi <ke...@scrye.com> wrote:> > - We never know when exactly a point release is going to appear until > it does. RH never announces them in advance. So, might lead to > scrambling. It's pretty unlikely we could push those updates the same > day as the point release... so when would we? would they go through > testing as usual? We could publish a policy that the "EPEL flag day" is two weeks after the day that RHEL ships a point release. Pros: * A maintainer can push an "incompatible update" into epel-testing on the day that RHEL ships, and then have their package hit epel-stable two weeks later on the agreed-upon flag day. (Of course, if a maintainer wanted to get their update into updates-testing sooner, that's fine too.) * Easy to remember: "two weeks" is the same time as Bodhi testing. * CentOS and SL are important, but we can't really affect the release schedules for these projects, so it's yet another one-way street. I think we have to just make a best effort. A consistent two week gap would these projects some leeway while not compromising on consistency. Cons: * We would need some coordination to ensure that the signing process happens on the day of RHEL's point release, and two weeks afterward. I'm not involved with the sigining task... hopefully this is not a huge deal? * Technically we would have two release days (RHEL + EPEL) instead of one (RHEL). > - Once we push those incompatible ones that require the new point > release, does that just leave people who are on an older one out in > the cold? Or they get the updates and it breaks them even though they > didn't apply the point release? I'm having trouble picturing a scenario where this problem could happen in RHEL+EPEL. Can you explain more? (I'm not envisioning that these new packages would have dependencies on the redhat-release package version number; only that we would try to hit the dates on the calendar.) - Ken _______________________________________________ epel-devel-list mailing list epel-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/epel-devel-list
