Conversations with centos-devel

[Stephen John Smoogen]

I sent a ping a while back on putting in a weight of 2000 for EPEL-6
and the general consensus was that it did not matter to them what we
did. [More or less.] So I would say that when we update the
epel-release next time to put it in the epel.repo. [And make sure we
announce it for partners.]

-- 
Stephen J Smoogen.
“The core skill of innovators is error recovery, not failure avoidance.”
Randy Nelson, President of Pixar University.
"We have a strategic plan. It's called doing things.""
— Herb Kelleher, founder Southwest Airlines

[Paul Howarth]

On Sat, 18 Sep 2010 11:40:28 -0600
Stephen John Smoogen <smooge(a)gmail.com&gt; wrote:

>  I sent a ping a while back on putting in a weight of 2000 for EPEL-6
>  and the general consensus was that it did not matter to them what we
>  did. [More or less.] So I would say that when we update the
>  epel-release next time to put it in the epel.repo. [And make sure we
>  announce it for partners.] 
And if we do that, we should be able to clone RHEL Workstation packages
(the ones not in RHEL Server) and put them EPEL without causing issues
for RHEL Workstation users...

Shouldn't we?

Paul.

[Jesse Keating]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 09/18/2010 11:10 AM, Paul Howarth wrote:
>  On Sat, 18 Sep 2010 11:40:28 -0600
>  Stephen John Smoogen <smooge(a)gmail.com&gt; wrote:
>  
> > I sent a ping a while back on putting in a weight of 2000 for EPEL-6
> > and the general consensus was that it did not matter to them what we
> > did. [More or less.] So I would say that when we update the
> > epel-release next time to put it in the epel.repo. [And make sure we
> > announce it for partners.]
>  
>  And if we do that, we should be able to clone RHEL Workstation packages
>  (the ones not in RHEL Server) and put them EPEL without causing issues
>  for RHEL Workstation users...
>  
>  Shouldn't we?
>   
I'm of the opinion that we should still not do this, except for extreme
situations.  EPEL was not meant to be an end-run around RHEL packages or
RHEL pricing, and while we could technically do it and have less chance
of hurting people's systems, I don't think EPEL is the place for that.
There is plenty of room for a slightly more removed repository from EPEL
where one could provide updated versions of packages.


- -- 
Jesse Keating
Fedora -- Freedom² is a feature!
identi.ca: http://identi.ca/jkeating
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v2.0.16 (GNU/Linux)
> Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/
>
> iEYEARECAAYFAkyWVooACgkQ4v2HLvE71NXG/gCfbsbQuywNSVXOWsq8Z8MJk2rV
> vbAAnionBvNavd0QrAKaV8OJRrmYfZIA
> =OuCE
> -----END PGP SIGNATURE-----

[Paul Howarth]

On 19/09/10 19:29, Jesse Keating wrote:
>  -----BEGIN PGP SIGNED MESSAGE-----
>  Hash: SHA1
>
>  On 09/18/2010 11:10 AM, Paul Howarth wrote:
> > On Sat, 18 Sep 2010 11:40:28 -0600
> > Stephen John Smoogen<smooge(a)gmail.com>  wrote:
> >
> >> I sent a ping a while back on putting in a weight of 2000 for EPEL-6
> >> and the general consensus was that it did not matter to them what we
> >> did. [More or less.] So I would say that when we update the
> >> epel-release next time to put it in the epel.repo. [And make sure we
> >> announce it for partners.]
> >
> > And if we do that, we should be able to clone RHEL Workstation packages
> > (the ones not in RHEL Server) and put them EPEL without causing issues
> > for RHEL Workstation users...
> >
> > Shouldn't we?
> >
>
>  I'm of the opinion that we should still not do this, except for extreme
>  situations.  EPEL was not meant to be an end-run around RHEL packages or
>  RHEL pricing, and while we could technically do it and have less chance
>  of hurting people's systems, I don't think EPEL is the place for that.
>  There is plenty of room for a slightly more removed repository from EPEL
>  where one could provide updated versions of packages. 
Well let's suppose that when RHEL-6 comes out, there's no add-on 
repository to provide Workstation packages for Server customers. Are you 
suggesting that a server product like bugzilla, which has at least one 
dependency on a Workstation-only package 
(https://bugzilla.redhat.com/show_bug.cgi?id=626218) should be moved to 
a "slightly more removed repository"? And where might that be?

Paul.

[Mark Chappell]

On 19 September 2010 20:29, Jesse Keating <jkeating(a)redhat.com&gt; wrote:
>  On 09/18/2010 11:10 AM, Paul Howarth wrote:
> > And if we do that, we should be able to clone RHEL Workstation packages
> > (the ones not in RHEL Server) and put them EPEL without causing issues
> > for RHEL Workstation users...
> >
> > Shouldn't we?
> >
>
>  I'm of the opinion that we should still not do this, except for extreme
>  situations.  EPEL was not meant to be an end-run around RHEL packages or
>  RHEL pricing, and while we could technically do it and have less chance
>  of hurting people's systems, I don't think EPEL is the place for that.
>  There is plenty of room for a slightly more removed repository from EPEL
>  where one could provide updated versions of packages. 
Except that's not what we're talking about doing (the Fedora
discussion about recent versions of packages is separate).  *If* there
is no "productivity" channel for Server then we're not talking about
bypassing the pricing scheme, we're talking about something that
people just plain can't get through Red Hat.  Things like perl
packages which are in Workstation (b2 refresh) as dependencies for GUI
tools, but are used by server type services, eg RT, and which RHEL
Server doesn't provide.

The only time your argument hold up in this case is if there is a paid
for channel that provides the additional packages.  At which point
we'll need to decide which channels we're targeting.  What makes
things worse is that as RHEL becomes a more complex product, with more
bolt-ons and options, trying to create EPEL becomes more complex:
Exactly which combinations of channels and architectures are we aiming
to provide packages for?

With the perl tree this has become a nightmare, it was tough getting
things like RT in before when some packages were pinned to old
versions, but now you're suggesting that some we couldn't even have,
simply because a GUI happened to use it in RHEL Workstation?

However, at this point I am just going to say, let's wait until
details of how RHEL6 is going to be structured are public, so we can
at least make an informed decision and not do things that are going to
make Rel-Eng-EPEL's life difficult.  If this means that there's going
to be a lag of a few weeks before EPEL is completely ready, post GA,
then that's life.  If anyone wants to help get stuff ready, post GA
because they want to deploy ASAP well they can always help with the
EPEL effort, we are after all simply volunteers.


Mark

[Xavier Bachelot]

>  At which point
>  we'll need to decide which channels we're targeting.  What makes
>  things worse is that as RHEL becomes a more complex product, with more
>  bolt-ons and options, trying to create EPEL becomes more complex:
>  Exactly which combinations of channels and architectures are we aiming
>  to provide packages for? 
Maybe the question could be worded slightly differently : which channels
is CentOS targeting ? This is the only freely available tree to build
against and this is what the EPEL mock configs are pointing at.

Regards,
Xavier