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

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

On October 29, 2012 16:06:59 Seth Vidal wrote:
> On Mon, 29 Oct 2012, Michael Stahnke wrote:
> > On Mon, Oct 29, 2012 at 12:52 PM, Chris Adams <cmadams hiwaay net> wrote:
> >> Once upon a time, Dmitry Makovey <dmitry athabascau ca> said:
> >>> 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?>> 
> >> CentOS has had some pretty long delays sometimes in the past, so I don't
> >> see that as a valid policy.
> > 
> > They've certainly worked to shorten that timeline.  We could probably
> > engage their core team and find out future plans as well, if so
> > desired.
> I do not recommend synchronizing with any specific distribution.

Seth, with all due respect, my understanding of EPEL is precisely bridge 
between releases of specific distributions (unless I got it wrong). It's aim 
is to bring "latest goodness" from current Fedora over to slower-paced 

Why would you recommend against synchronization with any distribution? 

My reasons for bringing CenOS up: both groups (CentOS & EPEL) seem to suffer 
from the lack of man-power. Both groups target the same platform: RHEL and 
both are going through the same pains. Synchronizing work of such groups does 
sound "logical" as Mr. Spock would suggest. 

not stirring things up but rather genuinely interested.

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]