[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

Re: 'policy' for multiple versions of same software in EPEL

Note1: I do *not* use CentOS nor am I it's advocate. Take that into account 
reading below [rough] ideas. I am however RHEL subscriber in the office and 
Fedora user at home.

Note2: I may be missing certain aspects of inter-distribution relations thus 
please don't throw heavy objects my way if I start sounding like heritic 
around here ;)

On October 29, 2012 12:52:01 Kevin Fenzi wrote:
> Cons:
> - 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?

Maybe aligning more with CenOS schedule? They end up trailing RHEL as well so 
whatever time they get before pushing "the latest" may be enough for EPEL?

> - Do we want for CentOS/SL/whatever to release their version? If not,
>   it could lead to breakage for users who use epel with those until
>   they do.

question from the different dimension: would it not make sense to merge 
CentOS[-extras] community with EPEL as two essentially are trying to 
compliment (augument) RHEL with more software? Was that ever considered in the 
past? Not trying to insigate, but rather suggest alternative approaches to 
above model.

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

Dmitry Makovey
Web Systems Administrator
Athabasca University
(780) 675-6245
Confidence is what you have before you understand the problem
    Woody Allen

When in trouble when in doubt run in circles scream and shout 

    This communication is intended for the use of the recipient to whom it
    is addressed, and may contain confidential, personal, and or privileged
    information. Please contact us immediately if you are not the intended
    recipient of this communication, and do not copy, distribute, or take
    action relying on it. Any communications received in error, or
    subsequent reply, should be deleted or destroyed.

[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]