FAQ Search Today's Posts Mark Forums Read
» Video Reviews

» Linux Archive

Linux-archive is a website aiming to archive linux email lists and to make them easily accessible for linux users/developers.


» Sponsor

» Partners

» Sponsor

Go Back   Linux Archive > Redhat > EPEL Development

 
 
LinkBack Thread Tools
 
Old 05-26-2012, 01:46 PM
Bryan J Smith
 
Default Thoughts from last meeting

inode0 <inode0@gmail.com> wrote:
> Who might be affected is certainly a wider a net than the "owner" of
> the layered channel.

Indeed. Every single customer of Red Hat I've been at in any capacity
realizes this. I've seen reachback by consultants and support to
engineering, including the actual coders. I've seen numerous,
"special cases" where Red Hat has been leveraged for non-Red Hat
software, because they have the upstream mindshare. I cannot
emphasize this enough.

That alone causes many stakeholders, when either downtime and/or
unexplained results, to realize the value of entitlements. Because in
those cases, the entitlements are pennies on the dollar, especially
against either "unpaid" or, worse yet, proprietary options that cost
10x more. That's where my concern is at, not the downstream community
users (who help Red Hat in many ways) and the thin margins like in the
ISP/web space, where "EL Rebuilds" are admittedly more popular
(especially for those that operate in-the-red).

> But at the same time inclusion of *any* package at all in EPEL can
> cause problems for GSS.

As I sorta hinted earlier, I do have to admit that it goes beyond just
things in Fedora like EPEL. There will always be the reality of
people who will try to utilize Red Hat's support for not merely what
is called "unpaid" open source, but open source that Red Hat has not
unit, integration and regression tested as a whole As much as it may
bother some when people take advantage of Red Hat individuals and
their goodwill to "share" in paid, subsidized aspects, there can be
grave contractual issues when it's in an enterprise.

Most of the time, it's overlooked. But when it's on behalf of paid,
but proprietary IHV/ISV who is shipping, referring to or otherwise
providing an "unpaid" open source they don't even support, I really
hate to have to remind people that it's unfair to do that to Red Hat
(let alone "throw them under the bus" when I see it). The better
response would be for a customer to go back to the costly, proprietary
IHV/ISV and ask them why some of their money is not funding Red Hat
entitlements instead of ripping the "unpaid" open source from the
community.

So while I'm sure anything that can be done to avoid "accidental"
support is appreciated, no guidelines can prevent intentional misuse
of Red Hat's trust. To me, it's not much just users who are "caught
in a bind," which happens, and I've never seen anyone in Red Hat just
say "no" to such users. But far worse from my view, it's proprietary
vendors who do it very, very intentionally, and leverage the users and
the community to "walk through the open door" they already have with
Red Hat, instead of doing it themselves and walking in with the
customer.

> For large, well-heeled, enterprises it doesn't matter what content
> EPEL includes because those enterprises take full responsibility for
> what content they allow into their enterprises. I doubt most EPEL
> consumers actually function this way though, even though they might
> very much like to.

Actually, most do. EPEL gets special consideration as a Fedora
Project, understood to be unsupported, but a better release avenue
than "rolling your own." The key is for stakeholders and SMEs to put
this in the proper context for other, both technical and
non-technical, stakeholders. It's hardly alone in the software world,
as even proprietary, commercial vendors have their unsupported tools
and utilities, along with other communities.

Sometimes that reality, and the folly of believing it doesn't exist,
is fun to point to with fellow MCSEs and MCITPs.

> If EPEL doesn't want to take this responsibility then it is just another 3rd party
> repository and it might as well drop all restrictions based on conflicts with RHEL
> packages and leave sorting out the mess to the people using EPEL.

I don't know if that is correct, but I do share that feeling. If EPEL
is not helping enterprises mitigate much of their release model load,
then it's just like tapping CentOS Extras, DAG, RPMForge and others.
These are all good projects, no one is arguing that they are not, very
helpful. I use their SPEC files myself, when required, and then I
take maintainership, or document how to for others. But EPEL, at
least in my experience, used to bring certain benefits, ones that
mitigated the workload in the release life cycle.

As always ...

--
Bryan J Smith - Professional, Technical Annoyance

_______________________________________________
epel-devel-list mailing list
epel-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/epel-devel-list
 
Old 05-26-2012, 02:22 PM
inode0
 
Default Thoughts from last meeting

On Sat, May 26, 2012 at 8:46 AM, Bryan J Smith <b.j.smith@ieee.org> wrote:
> inode0 <inode0@gmail.com> wrote:
>> But at the same time inclusion of *any* package at all in EPEL can
>> cause problems for GSS.
>
> As I sorta hinted earlier, I do have to admit that it goes beyond just
> things in Fedora like EPEL. *There will always be the reality of
> people who will try to utilize Red Hat's support for not merely what
> is called "unpaid" open source, but open source that Red Hat has not
> unit, integration and regression tested as a whole *As much as it may
> bother some when people take advantage of Red Hat individuals and
> their goodwill to "share" in paid, subsidized aspects, there can be
> grave contractual issues when it's in an enterprise.
>
> Most of the time, it's overlooked. *But when it's on behalf of paid,
> but proprietary IHV/ISV who is shipping, referring to or otherwise
> providing an "unpaid" open source they don't even support, I really
> hate to have to remind people that it's unfair to do that to Red Hat
> (let alone "throw them under the bus" when I see it). *The better
> response would be for a customer to go back to the costly, proprietary
> IHV/ISV and ask them why some of their money is not funding Red Hat
> entitlements instead of ripping the "unpaid" open source from the
> community.
>
> So while I'm sure anything that can be done to avoid "accidental"
> support is appreciated, no guidelines can prevent intentional misuse
> of Red Hat's trust. *To me, it's not much just users who are "caught
> in a bind," which happens, and I've never seen anyone in Red Hat just
> say "no" to such users. *But far worse from my view, it's proprietary
> vendors who do it very, very intentionally, and leverage the users and
> the community to "walk through the open door" they already have with
> Red Hat, instead of doing it themselves and walking in with the
> customer.

None of this is a problem that EPEL can solve. We accept packages that
meet various criteria that are more restrictive than other 3rd party
repositories. If an EPEL consumer, whether a Red Hat customer or not,
wants something in an upstream repo and EPEL won't provide it for
whatever reason there are others that will provide it. So Red Hat will
have whatever support problems result from customers using the package
either way.

>> For large, well-heeled, enterprises it doesn't matter what content
>> EPEL includes because those enterprises take full responsibility for
>> what content they allow into their enterprises. I doubt most EPEL
>> consumers actually function this way though, even though they might
>> very much like to.
>
> Actually, most do. *EPEL gets special consideration as a Fedora
> Project, understood to be unsupported, but a better release avenue
> than "rolling your own." *The key is for stakeholders and SMEs to put
> this in the proper context for other, both technical and
> non-technical, stakeholders. *It's hardly alone in the software world,
> as even proprietary, commercial vendors have their unsupported tools
> and utilities, along with other communities.

Are you seriously saying that most EPEL consumers behave in their IT
shops like large financial institutions? I'd bet not 1 in 10 do. I'd
probably bet not 1 in 100 do. EPEL is the 1st choice of many small IT
shops because they make the decision that they can trust EPEL to vet
packages for them. They want to get a package they need by enabling a
repo, installing it, and going back to figuring out why backups are
failing.

John

_______________________________________________
epel-devel-list mailing list
epel-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/epel-devel-list
 
Old 05-26-2012, 04:24 PM
Jon Stanley
 
Default Thoughts from last meeting

On Sat, May 26, 2012 at 9:46 AM, Bryan J Smith <b.j.smith@ieee.org> wrote:

> Indeed. *Every single customer of Red Hat I've been at in any capacity
> realizes this. *I've seen reachback by consultants and support to
> engineering, including the actual coders. *I've seen numerous,
> "special cases" where Red Hat has been leveraged for non-Red Hat
> software, because they have the upstream mindshare. *I cannot
> emphasize this enough.

Of course, you'd have to be living on some other planet to not
understand this. But mostly that's a highly technical discussion, with
understanding that things are either upstream heading into RHEL, and
extremely unsupported (at least via GSS). I can't count how many times
I've had Red Hat engineering ask me to try something on a Fedora box
and give feedback, etc. That's just the way it works.

> As I sorta hinted earlier, I do have to admit that it goes beyond just
> things in Fedora like EPEL. *There will always be the reality of
> people who will try to utilize Red Hat's support for not merely what
> is called "unpaid" open source, but open source that Red Hat has not
> unit, integration and regression tested as a whole *As much as it may

I'm not sure what this has to do with EPEL - folks often use much more
than the stock RHEL bits. For example, pretend you had a web server
running Red Hat's httpd, but it loads a proprietary module to talk to
an app server. If that web server breaks, the first place people are
going to call is likely Red Hat. I wouldn't expect RHT to say "well,
you've got this module loaded over here. Your problem admittedly has
nothing to do with that, but we can't help you anyhow".

> Actually, most do. *EPEL gets special consideration as a Fedora
> Project, understood to be unsupported, but a better release avenue
> than "rolling your own." *The key is for stakeholders and SMEs to put
> this in the proper context for other, both technical and
> non-technical, stakeholders. *It's hardly alone in the software world,
> as even proprietary, commercial vendors have their unsupported tools
> and utilities, along with other communities.

Exactly. If something is in EPEL we hold it in higher regard than
"hey, look! I found this cool thing on the Internet!". Not saying that
we wouldn't take the cool thing found on the Internet, but it gets
subject to much more scrutiny than if it were packaged in EPEL.

> I don't know if that is correct, but I do share that feeling. *If EPEL
> is not helping enterprises mitigate much of their release model load,
> then it's just like tapping CentOS Extras, DAG, RPMForge and others.
> These are all good projects, no one is arguing that they are not, very
> helpful. *I use their SPEC files myself, when required, and then I
> take maintainership, or document how to for others. *But EPEL, at
> least in my experience, used to bring certain benefits, ones that
> mitigated the workload in the release life cycle.

I agree with the sentiment, but it can help that even without
explicitly avoiding every single bit of package overlap.Do I think
that EPEL should ship a new kernel, coreutils, etc? Of course not. But
I don't think that EPEL should be categorically prohibited from
shipping something that overlaps with something else that is not RHEL
that Red Hat sells. I consider the layered entitlements (including
cluster and lb) to *not* be a part of RHEL - they are part of a
different product, sold and priced differently (the fact that you have
to have the base product in order to buy the layered ones makes no
difference either - I have to have a car, or else buying floormats
doesn't make any sense).

So to put it in concrete terms, I advocate that EPEL does not ship
anything that is in -server and -server-optional. Anything else is
fair game, unless explicitly asked by Red Hat to remove the bits.

_______________________________________________
epel-devel-list mailing list
epel-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/epel-devel-list
 
Old 05-26-2012, 04:37 PM
Bryan J Smith
 
Default Thoughts from last meeting

On Sat, May 26, 2012 at 12:24 PM, Jon Stanley <jonstanley@gmail.com> wrote:
> I consider the layered entitlements (including cluster and lb)

Which were always part of the "AS"/"Advanced Platform" entitlements,
and rebuilt by most "EL Rebuilds," from virtually day 1. And these
have not been allowed under the past EPEL guidelines from day 1 as
well, unless I am mistaken.

> to *not* be a part of RHEL - they are part of a different product,

So you would suggest EPEL take over this role, and the EL Rebuilds
drop it as well?

> sold and priced differently (the fact that you have to have the base product in order
> to buy the layered ones makes no difference either - I have to have a car, or else
> buying floormats doesn't make any sense).

Then why isn't that left to "EL Rebuilds" instead of Red Hat's
sponsored Fedora Project when it comes to Enterprise Linux bits?

Also, what do you believe this does to Red Hat customers who use EPEL?
Or are you under the believe Red Hat customers should not, which has
been suggested prior? Who does EPEL serve?

Does Fedora's EPEL serve as the unified rebuild tree from Red Hat's
SRPMS? Or where is the line drawn?

> So to put it in concrete terms, I advocate that EPEL does not ship
> anything that is in -server and -server-optional. Anything else is
> fair game, unless explicitly asked by Red Hat to remove the bits.

And what if Red Hat does? Do you accept such? And who from Red Hat?
And how does that work?


--
Bryan J Smith - Professional, Technical Annoyance
http://www.linkedin.com/in/bjsmith

_______________________________________________
epel-devel-list mailing list
epel-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/epel-devel-list
 
Old 05-26-2012, 08:43 PM
Jon Stanley
 
Default Thoughts from last meeting

On Sat, May 26, 2012 at 12:37 PM, Bryan J Smith <b.j.smith@ieee.org> wrote:

> Which were always part of the "AS"/"Advanced Platform" entitlements,
> and rebuilt by most "EL Rebuilds," from virtually day 1. *And these
> have not been allowed under the past EPEL guidelines from day 1 as
> well, unless I am mistaken.

Perhaps for RHEL5, for RHEL6 they are sold and priced as separate
entitlements. Which brings up an interesting point, perhaps we should
treat EPEL5 and EPEL6 differently here, but have one unifying policy -
anything that you can get as a single line-item with the operating
system without extra add-on entitlements (i.e. for RHEL5, that would
be AP) is not to be included. If Red Hat decides to change the model
with RHEL7 or future, then that gives us flexibility without coming
back to this discussion at that time.

> So you would suggest EPEL take over this role, and the EL Rebuilds
> drop it as well?

Not rebuilding the exact SRPM's provided by Red Hat in the layered
products, no. However, if someone (who would most likely be the
engineering owner of that prodcut at Red Hat, let's face it) wants to
put their upstream bits into EPEL, I don't think that there should be
policy that stops them from doing that.

> Then why isn't that left to "EL Rebuilds" instead of Red Hat's
> sponsored Fedora Project when it comes to Enterprise Linux bits?

Like I said above, I think that EPEL should *not* just rebuild the
SRPM's that are shipped as part of RHEL layered prodcuts, that's not
the purpose of EPEL.

> Also, what do you believe this does to Red Hat customers who use EPEL?
> *Or are you under the believe Red Hat customers should not, which has
> been suggested prior? *Who does EPEL serve?

As a large Red Hat customer, I use EPEL - i.e. in pulling packages
from it internally and cherry-picking those that I want. If you just
want to enable the EPEL repo and are a RHEL customer, you should
probably use something like yum-priorities to make sure that we don't
override stuff in base RHEL+your entitled channels.
>
> Does Fedora's EPEL serve as the unified rebuild tree from Red Hat's
> SRPMS? *Or where is the line drawn?

Absolutely not. In fact, I would say that any packages that are
submitted to EPEL must NOT be simple rebuilds of SRPMS, and unique
NEVRA is a requirement. I would be mighty ticked if identical NEVRA
packages to what's shipped in layered products, all of which I
subscribe to, started showing up in EPEL, in fact. This is mostly
technical on my side, my storage mechanism works based on uniqueness
of NEVRA.

> And what if Red Hat does? *Do you accept such? *And who from Red Hat?
> And how does that work?

If Red Hat does what? In reality, I would think such a request would
come from Spot, who I always defer to in matters like this. The
request would be something like "stop shipping package XYZ, please"
and we would then do that.

_______________________________________________
epel-devel-list mailing list
epel-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/epel-devel-list
 
Old 05-27-2012, 12:16 AM
Bryan J Smith
 
Default Thoughts from last meeting

Jon Stanley <jonstanley@gmail.com> wrote:
> Perhaps for RHEL5, for RHEL6 they are sold and priced as separate entitlements.

So what about existing customers with AP subscriptions who still have
the layered equivalents on RHEL6 as a result of their current
subscriptions?


--
Bryan J Smith - Professional, Technical Annoyance
http://www.linkedin.com/in/bjsmith

_______________________________________________
epel-devel-list mailing list
epel-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/epel-devel-list
 
Old 05-28-2012, 11:53 PM
Toshio Kuratomi
 
Default Thoughts from last meeting

On Fri, May 25, 2012 at 04:45:39PM -0500, inode0 wrote:
> On Fri, May 25, 2012 at 4:24 PM, Kevin Fenzi <kevin@scrye.com> wrote:
>
> > Anyhow, thoughts? concerns?
>
> As an EPEL consumer I find this all rather confusing. I don't want to
> have to know which layered products are protected and which aren't. I
> think I'd rather live with a simpler uniform policy regarding layered
> products.
>
As a non-administrator of RHEL I find it confusing too. I don't know what
fee structure and other non-repository divisions occur between base RHEL and
layered products and whether they are the same for all layered products or
only some.

So instead of going into specifics of what layered products should be
included or not included, I'd rather post the things that I'd like
a decision to allow:

1) We must be able to build against a version of the package -- either in
RHEL or in EPEL. This is a deal breaker to me. If we can't use the
layered products in the buildsystem then we can't exclude them from EPEL.

2) It is highly desirable that contributors who do not have access to RHEL
can still build and test their packages on their own systems. We've
pointed mock at CentOS repositories for this purpose in the past. If
CentOS provides the layered products as well, there's no change to the
status quo. If CentOS doesn't provide them or only provides a subset,
then we need to think about how much this degradation affects
contributors.

3) Users should be able to use our packages. If someone has bought RHEL but
hasn't paid for support for a layered product, will they still be able to
use our Foo package that depends upon puppet that's provided by a layered
product? If a user runs CentOS will they be able to use our Foo package
that depends on puppet that is provided by a layered product?

-Toshio
_______________________________________________
epel-devel-list mailing list
epel-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/epel-devel-list
 
Old 05-29-2012, 02:16 AM
inode0
 
Default Thoughts from last meeting

On Mon, May 28, 2012 at 6:53 PM, Toshio Kuratomi <a.badger@gmail.com> wrote:
> On Fri, May 25, 2012 at 04:45:39PM -0500, inode0 wrote:
>> On Fri, May 25, 2012 at 4:24 PM, Kevin Fenzi <kevin@scrye.com> wrote:
>>
>> > Anyhow, thoughts? concerns?
>>
>> As an EPEL consumer I find this all rather confusing. I don't want to
>> have to know which layered products are protected and which aren't. I
>> think I'd rather live with a simpler uniform policy regarding layered
>> products.
>>
> As a non-administrator of RHEL I find it confusing too. *I don't know what
> fee structure and other non-repository divisions occur between base RHEL and
> layered products and whether they are the same for all layered products or
> only some.

The nature of layered products is changing as RHEL is offered as more
of an a la carte product now. While EPEL including something like
puppet isn't such a big concern to me as it is a small component of a
larger offering from Red Hat, EPEL providing piranha + ipvsadm which
comprise the Load Balancer Add-On is a much bigger concern to me. I
don't really think EPEL should put Red Hat in the position of having
to ask for it to be removed. So unless we know that including such
things is fine with Red Hat in advance I think we should exclude them
as EPEL providing complete "layered products" or "Red Hat Enterprise
Linux Add-Ons" seems like crossing a line we shouldn't cross to me.

> So instead of going into specifics of what layered products should be
> included or not included, I'd rather post the things that I'd like
> a decision to allow:
>
> 1) We must be able to build against a version of the package -- either in
> * RHEL or in EPEL. *This is a deal breaker to me. *If we can't use the
> * layered products in the buildsystem then we can't exclude them from EPEL.

Can you say that last sentence a different way. I can't really make sense of it.

John

_______________________________________________
epel-devel-list mailing list
epel-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/epel-devel-list
 
Old 05-29-2012, 04:36 AM
Toshio Kuratomi
 
Default Thoughts from last meeting

On Mon, May 28, 2012 at 09:16:56PM -0500, inode0 wrote:
> On Mon, May 28, 2012 at 6:53 PM, Toshio Kuratomi <a.badger@gmail.com> wrote:
>
> > So instead of going into specifics of what layered products should be
> > included or not included, I'd rather post the things that I'd like
> > a decision to allow:
> >
> > 1) We must be able to build against a version of the package -- either in
> > * RHEL or in EPEL. *This is a deal breaker to me. *If we can't use the
> > * layered products in the buildsystem then we can't exclude them from EPEL.
>
> Can you say that last sentence a different way. I can't really make sense of it.
>
Sure. At the meeting, nirik brought up that we'd have to find out if we
could pull packages from the layered products into the repositories that
koji builds packages from. (1) We might not have a subscription to it or
otherwise have access to the packages. (2) Some layered products might
conflict with each other. This might prevent us from building against
a repo of all the packages in RHEL+all layered products.

If that's the case, then, for me, we'd have to be able to have those
packages in EPEL to allow people to build packages that have those packages
as dependencies.

-Toshio
_______________________________________________
epel-devel-list mailing list
epel-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/epel-devel-list
 
Old 05-29-2012, 04:42 AM
Stephen John Smoogen
 
Default Thoughts from last meeting

On 28 May 2012 20:16, inode0 <inode0@gmail.com> wrote:
> On Mon, May 28, 2012 at 6:53 PM, Toshio Kuratomi <a.badger@gmail.com> wrote:
>> On Fri, May 25, 2012 at 04:45:39PM -0500, inode0 wrote:
>>> On Fri, May 25, 2012 at 4:24 PM, Kevin Fenzi <kevin@scrye.com> wrote:
>>>
>>> > Anyhow, thoughts? concerns?
>>>
>>> As an EPEL consumer I find this all rather confusing. I don't want to
>>> have to know which layered products are protected and which aren't. I
>>> think I'd rather live with a simpler uniform policy regarding layered
>>> products.
>>>
>> As a non-administrator of RHEL I find it confusing too. ¬*I don't know what
>> fee structure and other non-repository divisions occur between base RHEL and
>> layered products and whether they are the same for all layered products or
>> only some.
>
> The nature of layered products is changing as RHEL is offered as more
> of an a la carte product now. While EPEL including something like
> puppet isn't such a big concern to me as it is a small component of a
> larger offering from Red Hat, EPEL providing piranha + ipvsadm which
> comprise the Load Balancer Add-On is a much bigger concern to me. I
> don't really think EPEL should put Red Hat in the position of having
> to ask for it to be removed. So unless we know that including such
> things is fine with Red Hat in advance I think we should exclude them
> as EPEL providing complete "layered products" or "Red Hat Enterprise
> Linux Add-Ons" seems like crossing a line we shouldn't cross to me.

Well then the only way I can see to meet your point would be to stop EPEL.

There are very very few packages left after the conflicting packages
and their requirements are pulled. You can't include any of the other
configuration management tools because they also use pulled in
libraries (augeus and such). Anything with Perl dependencies are
pulled from other items in the layered products. And since many of the
items that would be left are supported by maintainers whose main
packages would be pulled.. I doubt they would want to support those
eithers. It quickly becomes a cascade of pulls to the point where it
is not worth keeping going.



--
Stephen J Smoogen.
"The core skill of innovators is error recovery, not failure avoidance."
Randy Nelson, President of Pixar University.
"Years ago my mother used to say to me,... Elwood, you must be oh
so smart or oh so pleasant. Well, for years I was smart. I
recommend pleasant. You may quote me." ¬*‚ÄĒJames Stewart as Elwood P. Dowd

_______________________________________________
epel-devel-list mailing list
epel-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/epel-devel-list
 

Thread Tools




All times are GMT. The time now is 08:57 PM.

VBulletin, Copyright ©2000 - 2014, Jelsoft Enterprises Ltd.
Content Relevant URLs by vBSEO ©2007, Crawlability, Inc.
Copyright ©2007 - 2008, www.linux-archive.org