'policy' for multiple versions of same software in EPEL

[Ken Dreyer]

On Mon, Oct 29, 2012 at 12:52 PM, Kevin Fenzi <kevin at 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 <kevin at 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