'policy' for multiple versions of same software in EPEL

[Kevin Fenzi]

On Mon, 29 Oct 2012 13:39:26 -0600
Ken Dreyer <ktdreyer at ktdreyer.com> wrote:

> 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.

Not off hand. I know it was suggested in the past tho. ;) 

> 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?

Not a big deal. I sign and push updates almost every day. 

> * Technically we would have two release days (RHEL + EPEL) instead of
>   one (RHEL).

Right. 

> > - 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.)

So, say RHEL 6.4 comes out. We set our EPEL6 'incompatible upgrade day'
as 2 weeks after that. 

Some people upgrade to 6.4 immediately. Should be ok, as our upgrades
haven't happened yet. 

Some people wait and stay on 6.x. 

2 weeks pass. EPEL incompatible upgrade day arrives, we push updates
out. 

People who upgraded to 6.4 already see a bunch of updates that are
incompatible and are annoyed since they already did their point
release. 

People on say 6.1 who never applied the point release see a bunch of
updates out of the blue. Perhaps some of these EPEL updates require
newer packages or new packages in 6.4 only, so they just see broken
updates. Granted we have never catered to those folks on old releases
much... 

Anyhow, I guess the big problem I see is that some people will upgrade
before our 2 weeks and then have to go through 2 'major' upgrades in a
row. 

kevin
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: not available
URL: <http://listman.redhat.com/archives/epel-devel-list/attachments/20121031/809002ce/attachment.sig>