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