So, at our last meeting:
http://meetbot.fedoraproject.org/meetbot/teams/epel/epel.2012-05-23-22.12.ht...
There seemed to be a fair bit of push to change our policy from:
"EPEL6 will not ship any packages that have src.rpms on public mirrors under 6* directories with the following exception: If the binary rpm is only shipped in some arches in RHEL, EPEL may ship a package as close as possible to the RHEL version with a leading package Release of 0. (ie, libfoo-1.2-0.x) (note that EPEL maintainer must keep up exactly with the RHEL src.rpm where possible)."
to
"EPEL6 will not ship any packages that have src.rpms on public mirrors under 6-Server, 6-Server-ha, 6-Server-optional, 6-Server-lb, except packages missing in one of our supported arches may be shipped by EPEL, but must abide by http://fedoraproject.org/wiki/EPEL:Packaging#Limited_Arch_Packages. Additionally, EPEL will drop packages that overlap with other RHEL channels/layered products on request of those channel owners"
Is that what folks in that meeting were thinking (I wrote up the statement that I thought people were agreeing to, I could well have messed up people's intent)?
So, what do people think of the above? Any amendments? Problems that we should note or might sway people to want to adjust it?
This gives channel owner/layered products people the ability to decide if overlaping with epel for their specific channel use/case makes sense or not, or if it would cause problems for them.
Anyhow, thoughts? concerns?
kevin
On Fri, 2012-05-25 at 15:24 -0600, Kevin Fenzi wrote:
So, at our last meeting:
http://meetbot.fedoraproject.org/meetbot/teams/epel/epel.2012-05-23-22.12.ht...
There seemed to be a fair bit of push to change our policy from:
"EPEL6 will not ship any packages that have src.rpms on public mirrors under 6* directories with the following exception: If the binary rpm is only shipped in some arches in RHEL, EPEL may ship a package as close as possible to the RHEL version with a leading package Release of 0. (ie, libfoo-1.2-0.x) (note that EPEL maintainer must keep up exactly with the RHEL src.rpm where possible)."
to
"EPEL6 will not ship any packages that have src.rpms on public mirrors under 6-Server, 6-Server-ha, 6-Server-optional, 6-Server-lb, except packages missing in one of our supported arches may be shipped by EPEL, but must abide by http://fedoraproject.org/wiki/EPEL:Packaging#Limited_Arch_Packages. Additionally, EPEL will drop packages that overlap with other RHEL channels/layered products on request of those channel owners"
Is that what folks in that meeting were thinking (I wrote up the statement that I thought people were agreeing to, I could well have messed up people's intent)?
So, what do people think of the above? Any amendments? Problems that we should note or might sway people to want to adjust it?
This gives channel owner/layered products people the ability to decide if overlaping with epel for their specific channel use/case makes sense or not, or if it would cause problems for them.
Anyhow, thoughts? concerns?
I think this is clear and concise with reasonable motivation. +1
-AdamM
On Fri, May 25, 2012 at 4:24 PM, Kevin Fenzi kevin@scrye.com wrote:
So, at our last meeting:
http://meetbot.fedoraproject.org/meetbot/teams/epel/epel.2012-05-23-22.12.ht...
There seemed to be a fair bit of push to change our policy from:
"EPEL6 will not ship any packages that have src.rpms on public mirrors under 6* directories with the following exception: If the binary rpm is only shipped in some arches in RHEL, EPEL may ship a package as close as possible to the RHEL version with a leading package Release of 0. (ie, libfoo-1.2-0.x) (note that EPEL maintainer must keep up exactly with the RHEL src.rpm where possible)."
to
"EPEL6 will not ship any packages that have src.rpms on public mirrors under 6-Server, 6-Server-ha, 6-Server-optional, 6-Server-lb, except
What is the logic behind protecting only these two layered products? Seems if we are ignoring other layered products we might as well just ignore all layered products and greatly simplify things.
packages missing in one of our supported arches may be shipped by EPEL, but must abide by http://fedoraproject.org/wiki/EPEL:Packaging#Limited_Arch_Packages.
I really like this policy.
Additionally, EPEL will drop packages that overlap with other RHEL channels/layered products on request of those channel owners"
What is the concern here? How would this impact the owners of the layered product channels?
Is that what folks in that meeting were thinking (I wrote up the statement that I thought people were agreeing to, I could well have messed up people's intent)?
So, what do people think of the above? Any amendments? Problems that we should note or might sway people to want to adjust it?
This gives channel owner/layered products people the ability to decide if overlaping with epel for their specific channel use/case makes sense or not, or if it would cause problems for them.
The RHEL owner can provide if for all channels and that will remove it from EPEL. I don't see any reason for them to just remove it from EPEL while not providing it universally in RHEL.
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.
John
On Fri, 25 May 2012 16:45:39 -0500 inode0 inode0@gmail.com wrote:
On Fri, May 25, 2012 at 4:24 PM, Kevin Fenzi kevin@scrye.com wrote:
So, at our last meeting:
http://meetbot.fedoraproject.org/meetbot/teams/epel/epel.2012-05-23-22.12.ht...
There seemed to be a fair bit of push to change our policy from:
"EPEL6 will not ship any packages that have src.rpms on public mirrors under 6* directories with the following exception: If the binary rpm is only shipped in some arches in RHEL, EPEL may ship a package as close as possible to the RHEL version with a leading package Release of 0. (ie, libfoo-1.2-0.x) (note that EPEL maintainer must keep up exactly with the RHEL src.rpm where possible)."
to
"EPEL6 will not ship any packages that have src.rpms on public mirrors under 6-Server, 6-Server-ha, 6-Server-optional, 6-Server-lb, except
What is the logic behind protecting only these two layered products? Seems if we are ignoring other layered products we might as well just ignore all layered products and greatly simplify things.
These are all channels that are enabled in our buildsystem: http://koji.fedoraproject.org/koji/taginfo?tagID=140
I think we enabled them for two reasons: a) rhel5 had the similar channels enabled, b) we have some things in epel that needed items in those channels to build.
packages missing in one of our supported arches may be shipped by EPEL, but must abide by http://fedoraproject.org/wiki/EPEL:Packaging#Limited_Arch_Packages.
I really like this policy.
It still needs a concrete list of packages that are using it, but I hope to work on that this weekend if I get time. ;)
Additionally, EPEL will drop packages that overlap with other RHEL channels/layered products on request of those channel owners"
What is the concern here? How would this impact the owners of the layered product channels?
If layered product folks start getting a flood of "I'm using version $foo of your product" and thats the version shipped in RHEL instead, we might drop this from EPEL to avoid causing undue support burden on them? Then again, another layered product might say "well, thats not what we ship, reinstall with $foo before we support you" Or another one might say "we think it's great that EPEL ships this so we can get more people testing it and providing feedback".
I don't know off hand, this was just a way to make sure we didn't cause problems for layered product people.
The RHEL owner can provide if for all channels and that will remove it from EPEL. I don't see any reason for them to just remove it from EPEL while not providing it universally in RHEL.
Perhaps. I don't know whats involved in all that. Perhaps their are reasons it's difficult.
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.
So, you would suggest dropping the ha and lb products from overlap? Or making it so no channels can overlap?
kevin
On Fri, May 25, 2012 at 5:05 PM, Kevin Fenzi kevin@scrye.com wrote:
On Fri, 25 May 2012 16:45:39 -0500 inode0 inode0@gmail.com 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.
So, you would suggest dropping the ha and lb products from overlap? Or making it so no channels can overlap?
My general preference as a consumer of both RHEL and EPEL would be in order:
1 - EPEL does not conflict with RHEL + Layered Products (all Layered Products)
I know that holds some important things back that lots of folks benefit from.
2 - EPEL does not conflict with RHEL base packages (base being loosely defined as what comes with a standard RHEL subscription, so would in the case of RHEL6 include the optional channel for example).
This would cause issues when using RHEL and Layered Products in spots.
Both of those preferences are either all or nothing with respect to EPEL's treatment of Layered Products. In 1 Layered Products are off limits in EPEL, in 2 they are all fair game. This is easy for EPEL consumers to understand either way.
I would be really happy also with EPEL doing 1 for its primary repository but also providing a secondary repository where all Layered Products can be trumped by EPEL versions. Separating those conflicts into a secondary repo would be a big help to EPEL's downstream users I think.
People wanting no RHEL conflicts can have that using the primary EPEL repo only. People using only RHEL without any Layered Products can use both EPEL repos to get access to bits of Layered Products that are helpful via EPEL. People using RHEL with Layered Products wanting EPEL support not affecting Red Hat supported components can restrict their use to the primary EPEL repo. The only complicated use case would be RHEL users with Layered Products wanting bits from the EPEL secondary repo, that group would need to be careful. I think the vast majority of EPEL consumers could just turn on or off their preferred combination of the two EPEL repos and go about their business conflict free.
John
On Fri, May 25, 2012 at 05:25:58PM -0500, inode0 wrote:
My general preference as a consumer of both RHEL and EPEL would be in order:
1 - EPEL does not conflict with RHEL + Layered Products (all Layered Products)
I know that holds some important things back that lots of folks benefit from.
2 - EPEL does not conflict with RHEL base packages (base being loosely defined as what comes with a standard RHEL subscription, so would in the case of RHEL6 include the optional channel for example).
<snip>
I would be really happy also with EPEL doing 1 for its primary repository but also providing a secondary repository where all Layered Products can be trumped by EPEL versions. Separating those conflicts into a secondary repo would be a big help to EPEL's downstream users I think.
I completely agree. Secondary repo which would be disabled by default holding packages that could conflict with RH-channels would be ideal for our usage. It would also open up for actively including stuff that's in RHEL layered products -- for unsupported usage.
I also wish for an epel-bleeding-edge repo, that could contain latest upstream versions of select packages that are in base rhel. We f.ex. pick the latest dovecot from the package-db and build for EL6 locally. Having this in an EPEL-channel were we could get more users/tester/quality would be great.
-jf
Once upon a time, Jan-Frode Myklebust janfrode@tanso.net said:
I completely agree. Secondary repo which would be disabled by default holding packages that could conflict with RH-channels would be ideal for our usage. It would also open up for actively including stuff that's in RHEL layered products -- for unsupported usage.
The problem with that is you'd need an ever-increasing combination of additional EPEL repos. There'd be an "EPEL base" that doesn't conflict with any layered products (but has almost no packages), but then you'd need a bunch of combinations of "doesn't conflict with foo and bar but may conflict with baz".
If there are RH layered products that can conflict with each other (as I believe somebody said there may be), it becomes an even more impossible problem to solve.
IIRC somebody suggested yum-priorities. I think that that is the only sane way to go; make epel-release require yum-priorities and set EPEL (a single repo) to a lower priority than then RHN channels. Let EPEL maintainers decide what they want to maintain and "let the buyer beware" if somebody fiddles with EPEL priorities. There are just too many potential combinations of conflicts to try to handle any other way.
That way, if RH directory server folks want to maintain a set of packages in EPEL as well, they can do so, and explain to their customers how to use them (which would basically be "unsubscribe your test systems from the directory server layered product RHN channel").
On 05/29/2012 04:44 PM, Chris Adams wrote:
Once upon a time, Jan-Frode Myklebust janfrode@tanso.net said:
I completely agree. Secondary repo which would be disabled by default holding packages that could conflict with RH-channels would be ideal for our usage. It would also open up for actively including stuff that's in RHEL layered products -- for unsupported usage.
The problem with that is you'd need an ever-increasing combination of additional EPEL repos. There'd be an "EPEL base" that doesn't conflict with any layered products (but has almost no packages), but then you'd need a bunch of combinations of "doesn't conflict with foo and bar but may conflict with baz".
I don't think "a bunch of combinations" is necessary here. Just create the base repo and an extension repo. The base repo is conservative in that it only carries packages that don't collide with any of the RHEL products. The extension repo is disabled by default and by enabling it you explicitly recognize that if its contents collide with layered products you have installed then it's your job to deal with that. If you don't like that feel free to only use the base repo.
Trying to specifically accomodate every possible combination of products installed sounds way too complicated and will most likely only create a big mess.
Regards, Dennis
Chris Adams cmadams@hiwaay.net wrote:
The problem with that is you'd need an ever-increasing combination of additional EPEL repos. There'd be an "EPEL base" that doesn't conflict with any layered products (but has almost no packages), but then you'd need a bunch of combinations of "doesn't conflict with foo and bar but may conflict with baz". If there are RH layered products that can conflict with each other (as I believe somebody said there may be), it becomes an even more impossible problem to solve.
If there are conflicts in versions, as well as trailing v. leading, this will be an issue in EPEL regardless of exclusion/inclusion. You could even build an unified "Fedora Enterprise Linux" repo with everything and it would still happen.
IIRC somebody suggested yum-priorities. I think that that is the only sane way to go; make epel-release require yum-priorities and set EPEL (a single repo) to a lower priority than then RHN channels. Let EPEL maintainers decide what they want to maintain and "let the buyer beware" if somebody fiddles with EPEL priorities. There are just too many potential combinations of conflicts to try to handle any other way.
Unfortunately that does not solve the issue for RHN Satellite Server, or even Spacewalk for that matter. Clone and custom channels become issues, anything where the packages are not located under the NULL (upstream) directories.
That way, if RH directory server folks want to maintain a set of packages in EPEL as well, they can do so, and explain to their customers how to use them (which would basically be "unsubscribe your test systems from the directory server layered product RHN channel").
Which leads to several suggestions to segment into two (2), so everyone realizes where something does and does not conflict. That solves most of the issues for all parties and users.
-- Bryan J Smith - Professional, Technical Annoyance http://www.linkedin.com/in/bjsmith
On 29 May 2012 09:09, Bryan J Smith b.j.smith@ieee.org wrote:
Chris Adams cmadams@hiwaay.net wrote:
That way, if RH directory server folks want to maintain a set of packages in EPEL as well, they can do so, and explain to their customers how to use them (which would basically be "unsubscribe your test systems from the directory server layered product RHN channel").
Which leads to several suggestions to segment into two (2), so everyone realizes where something does and does not conflict. That solves most of the issues for all parties and users.
So.. who is volunteering to do this work? Because it is going to be a LOT of work (and no handwavy it can't be that much.. because it shows pretty quickly the person who says it doesn't have a clue about the infrastructure involved.)
Stephen John Smoogen wrote:
So.. who is volunteering to do this work? Because it is going to be a LOT of work (and no handwavy it can't be that much.. because it shows pretty quickly the person who says it doesn't have a clue about the infrastructure involved.)
I never said it wouldn't be. But I'm not the only one suggesting it could address several details. My greater point is that there are many issues, regardless of what Red Hat does or does not do, in EPEL.
It's important to remember to take my comments in the context they were made (i.e., in response to other statements).
-- Bryan J Smith - Professional, Technical Annoyance http://www.linkedin.com/in/bjsmith
On Tue, 29 May 2012 11:37:57 -0400 Bryan J Smith b.j.smith@ieee.org wrote:
Stephen John Smoogen wrote:
So.. who is volunteering to do this work? Because it is going to be a LOT of work (and no handwavy it can't be that much.. because it shows pretty quickly the person who says it doesn't have a clue about the infrastructure involved.)
I never said it wouldn't be. But I'm not the only one suggesting it could address several details. My greater point is that there are many issues, regardless of what Red Hat does or does not do, in EPEL.
It's important to remember to take my comments in the context they were made (i.e., in response to other statements).
Just to note here, any addition of additonal repos is not going to be "oh, lets toss that out and it's all done".
A partial list of what we would need to do to add a repo:
* Patch bodhi to know about the new repo, what requirements it would have. If it would have a updates-testing version and how to promote to updates.
* Add a koji tag for the builds.
* Modify the fedora git processing scripts to allow branches to be made for this repo.
* Update mash and such to create the repo(s).
* Process all the packages that would need to be added.
* Add components to bugzilla for the new repo/channels/packages.
And I'm sure there's other issues... it would not be at all easy, and I would prefer to avoid it.
kevin
Kevin Fenzi wrote:
... another layered product might say "well, thats not what we ship, reinstall with $foo before we support you" ... ... I don't know off hand ...
Well you're on-the-money on all of those, but particular the one I've included here.
"Real world" here people ...
Not only does it sometimes take many hours to discover this. That's Red Hat Services and Support tied up. But here's the best part ...
It's not just the "EL Rebuild" and "community" users that cause this. Unpaid users in the community are the least of my concerns. I don't know a single person with Red Hat that complains about the community, upstream or downstream.
What really twerks me, and a lot of others, is when someone has wasted my time for a couple of days only for I to discover it was the "EL Rebuild" and "EPEL add-ons" a proprietary vendor shipped, bundled or pointed someone else to. A proprietary vendor that has a much larger contract and a number bigger set of support and service people than Red Hat does.
No good deed goes unpunished. At some point, Red Hat has to "draw the line" on charity, and say, "Will you please go get that vendor to partner with us so we can support you instead of using the unsupported stuff?"
First-hand, "real world" experience speaking. ;)
-- Bryan "okay, I'll shutup now" Smith
On Fri, May 25, 2012 at 5:05 PM, Kevin Fenzi kevin@scrye.com wrote:
On Fri, 25 May 2012 16:45:39 -0500 inode0 inode0@gmail.com wrote:
On Fri, May 25, 2012 at 4:24 PM, Kevin Fenzi kevin@scrye.com wrote:
packages missing in one of our supported arches may be shipped by EPEL, but must abide by http://fedoraproject.org/wiki/EPEL:Packaging#Limited_Arch_Packages.
I really like this policy.
It still needs a concrete list of packages that are using it, but I hope to work on that this weekend if I get time. ;)
I'll add here that I think applying this policy to all layered products while providing only a single EPEL repository seems quite nice to me as well. An EPEL user can then use EPEL knowing he/she won't have unwanted conflicts with any RHEL provided packages, including those provided by layered products. It has the disadvantage though that the conflicting packages aren't allowed to run ahead of RHEL which I'm sure a lot of users would like. Avoiding conflicts is a higher priority to me than getting version upgrades so I would be happy with this or a secondary channel for conflicting packages that did allow version upgrades.
John
On Fri, May 25, 2012 at 6:05 PM, Kevin Fenzi kevin@scrye.com wrote:
If layered product folks start getting a flood of "I'm using version $foo of your product" and thats the version shipped in RHEL instead, we might drop this from EPEL to avoid causing undue support burden on them? Then again, another layered product might say "well, thats not what we ship, reinstall with $foo before we support you" Or another one might say "we think it's great that EPEL ships this so we can get more people testing it and providing feedback".
In reality "layered product folks" is GSS. They get *all* support inquires, no matter how large the customer. If they have a TAM, that TAM is in the GSS org structure. So we can safely ignore the product management side of this (who could probably be considered the "owners" of the layered product channels).
In my world, we carefully screen every repo that we produce (via an internal repo building mechanism) for things that do not have the RPM signatures that we expect (which is the RHEL prod signature, plus a manually maintained whitelist of unsigned, EPEL, IHV, etc packages). Anything that snuck in from EPEL (or a RHEL beta, or whatever source it might be from, including unsigned) would be thus caught unless it was on the whitelist. I would posit that anyone who cares about the provenance of their packages, and knowingly consumes packages from alternative repos (EPEL being an example of such) does the same. If they don't, then the onus is on them to do something about it - not on EPEL to prevent them from shooting themselves in the foot.
$0.02 -Jon
On Sat, May 26, 2012 at 2:53 AM, Jon Stanley jonstanley@gmail.com wrote:
In reality "layered product folks" is GSS. They get *all* support inquires, no matter how large the customer. If they have a TAM, that TAM is in the GSS org structure. So we can safely ignore the product management side of this (who could probably be considered the "owners" of the layered product channels).
Tickets have SMEs assigned in GSS. Unless it's level 1 knowledge, many times they do reach back to engineering. Product management is impacted, engineering individuals are assigned. A great majority of my tickets at my customers do reach such resources every time.
So product management very much is involved, does have a say, and there are very much metrics on those impacts and costs.
-- Bryan J Smith - Professional, Technical Annoyance http://www.linkedin.com/in/bjsmith
On Sat, May 26, 2012 at 1:53 AM, Jon Stanley jonstanley@gmail.com wrote:
On Fri, May 25, 2012 at 6:05 PM, Kevin Fenzi kevin@scrye.com wrote:
If layered product folks start getting a flood of "I'm using version $foo of your product" and thats the version shipped in RHEL instead, we might drop this from EPEL to avoid causing undue support burden on them? Then again, another layered product might say "well, thats not what we ship, reinstall with $foo before we support you" Or another one might say "we think it's great that EPEL ships this so we can get more people testing it and providing feedback".
In reality "layered product folks" is GSS. They get *all* support inquires, no matter how large the customer. If they have a TAM, that TAM is in the GSS org structure. So we can safely ignore the product management side of this (who could probably be considered the "owners" of the layered product channels).
Who might be affected is certainly a wider a net than the "owner" of the layered channel. But at the same time inclusion of *any* package at all in EPEL can cause problems for GSS. I think this bit should be dropped or replaced by something more generic stating the willingness of the EPEL community to work with Red Hat to resolve any issues that EPEL causes that adversely affect Red Hat operations, but short of a guarantee that Red Hat can decide what is or isn't accepted by EPEL.
In my world, we carefully screen every repo that we produce (via an internal repo building mechanism) for things that do not have the RPM signatures that we expect (which is the RHEL prod signature, plus a manually maintained whitelist of unsigned, EPEL, IHV, etc packages). Anything that snuck in from EPEL (or a RHEL beta, or whatever source it might be from, including unsigned) would be thus caught unless it was on the whitelist. I would posit that anyone who cares about the provenance of their packages, and knowingly consumes packages from alternative repos (EPEL being an example of such) does the same. If they don't, then the onus is on them to do something about it - not on EPEL to prevent them from shooting themselves in the foot.
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. 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.
John
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
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
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.
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
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.
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
On Sat, 26 May 2012 12:24:14 -0400 Jon Stanley jonstanley@gmail.com wrote:
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.
I have been lurking along for a while here but I would like to put in my 2cents.
I think Jon's proposal above:
inclusive of what epel's default limits are, disallowing of exact rebuilds of any srpm from any channel and allowing for notification from red hat through a specific and established source (his example of spot is a good one but we don't need to necessarily throw spot under the bus, other folks could be the epel-go-between too)
is a good proposal. I think it is consistent, easy to understand and to explain and will help epel thrive.
my 2cents. I speak only for me not for my employer.
-sv
On Tue, May 29, 2012 at 8:40 AM, seth vidal skvidal@fedoraproject.org wrote:
On Sat, 26 May 2012 12:24:14 -0400 Jon Stanley jonstanley@gmail.com wrote:
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).
The notion of layered products in my mind got cloudy with the introduction of the Red Hat Enterprise LInux Add-On category. While I don't see layered products like those dealing with identity management (certificate system, directory server) as being part of RHEL it is hard for me to see the newer RHEL Add-Ons like Load Balancer as being not part of RHEL. They seem to be the result of customers wanting a lower cost basic version of RHEL that doesn't include all the bells and whistles while allowing RHEL users with different needs to include those bells and whistles from a menu of available parts of RHEL not included in the lowest cost version. To me it is just like the old AS vs. ES distinction but offered through a menu of add-ons rather than through different versions of RHEL. This is marketing more than anything else.
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.
I have been lurking along for a while here but I would like to put in my 2cents.
I think Jon's proposal above:
inclusive of what epel's default limits are, disallowing of exact rebuilds of any srpm from any channel and allowing for notification from red hat through a specific and established source (his example of spot is a good one but we don't need to necessarily throw spot under the bus, other folks could be the epel-go-between too)
is a good proposal. I think it is consistent, easy to understand and to explain and will help epel thrive.
This is certainly easy to understand and my only concern is from the perspective of the EPEL consumer. If the Load Balancer Add-On were provided by EPEL and I jumped on that only to have the epel-go-between object 6 months later and have it pulled out from under me I would be an unhappy camper. It is OK to say that is my tough luck, but in cases like this I'd feel more confident using EPEL if the epel-go-between said it was OK to include Load Balancer Add-On before it was included rather than coming along later to say it isn't OK and yanking it.
John
On Tue, 29 May 2012 09:31:11 -0500 inode0 inode0@gmail.com wrote:
...snip...
This is certainly easy to understand and my only concern is from the perspective of the EPEL consumer. If the Load Balancer Add-On were provided by EPEL and I jumped on that only to have the epel-go-between object 6 months later and have it pulled out from under me I would be an unhappy camper. It is OK to say that is my tough luck, but in cases like this I'd feel more confident using EPEL if the epel-go-between said it was OK to include Load Balancer Add-On before it was included rather than coming along later to say it isn't OK and yanking it.
So, you are suggesting an 'opt in' rather than 'opt out' ?
ie, if we hear nothing we shouldn't conflict, but if we specifically hear from them 'ok, we don't mind, it doesn't cause us any issues' we should only then allow conflicts from that channel/product?
One other thing that comes in here... there's a bunch of fasttrack and z-stream channels. Should any policy we draft address them as well?
kevin
On Tue, May 29, 2012 at 1:30 PM, Kevin Fenzi kevin@scrye.com wrote:
On Tue, 29 May 2012 09:31:11 -0500 inode0 inode0@gmail.com wrote:
...snip...
This is certainly easy to understand and my only concern is from the perspective of the EPEL consumer. If the Load Balancer Add-On were provided by EPEL and I jumped on that only to have the epel-go-between object 6 months later and have it pulled out from under me I would be an unhappy camper. It is OK to say that is my tough luck, but in cases like this I'd feel more confident using EPEL if the epel-go-between said it was OK to include Load Balancer Add-On before it was included rather than coming along later to say it isn't OK and yanking it.
So, you are suggesting an 'opt in' rather than 'opt out' ?
ie, if we hear nothing we shouldn't conflict, but if we specifically hear from them 'ok, we don't mind, it doesn't cause us any issues' we should only then allow conflicts from that channel/product?
I guess I would imagine it working more like a maintainer steps up and says I would like to include package X which conflicts with layered/add-on product Y. Any objection? Then the epel-go-between says fine or no wait.
One other thing that comes in here... there's a bunch of fasttrack and z-stream channels. Should any policy we draft address them as well?
fastrack only contains a subset of updates for the base channels associated with them so I think it is safe to completely ignore them from an EPEL policy perspective. z-stream seems redundant in a different way and I would expect z-stream users to just use EPEL like everyone else. If EPEL can't support two repositories then I'd look the other way when z-steam support comes up. :)
John
Kevin Fenzi wrote:
So, you are suggesting an 'opt in' rather than 'opt out' ? ie, if we hear nothing we shouldn't conflict, but if we specifically hear from them 'ok, we don't mind, it doesn't cause us any issues' we should only then allow conflicts from that channel/product?
I'm sure some would feel that goes too far "the other way."
One other thing that comes in here... there's a bunch of fasttrack and z-stream channels. Should any policy we draft address them as well?
I've commented on Fasttrack before when I mentioned ETEL originally. But that's a whole other can'o worms, especially when it comes to the conflicting version debates. In general, I would not even attempt to accommodate systems that are subscribed to Fasttrack in EPEL (among other things).
Now as far as Extended Update Support (EUS aka Z-stream), understand most layered entitlements are not under EUS. So EUS is almost a non-worry for EPEL. Yes, many enterprises do run completely on EUS, with only a handful of exceptions. But in most cases, the problem with EUS isn't one of conflict, but dependencies.
E.g., an EPEL package that has a dependency on something that, say, didn't ship until RHEL5.8, would not be resolvable on a system subscribed to RHEL 5.6 EUS. Again, not a conflict issue, so nothing to worry about.
If anything, EUS is "better" for EPEL. Things either resolve, or they have missing dependencies. I can deal with missing dependencies far easier than conflicts. ;)
Kevin Fenzi wrote:
Just to note here, any addition of additonal repos is not going to be "oh, lets toss that out and it's all done".
Again, my comment was in response to someone saying >>2 would be required, among other things, to implement the desired detail. I don't think anyone was suggesting that one would need to create a repo for every Red Hat layered product. That would be way, way too fluid.
My only comment was that if the project is going to yank packages, I'm not against them finding a home in another repository. The "two" comment then comes down to having one that does not conflict, and another that can. I'm not the only one to suggest such, and I recognize it's been considered before.
But >>2 was nothing anyone suggested. Don't know why someone went there.
-- Bryan J Smith - Professional, Technical Annoyance http://www.linkedin.com/in/bjsmith
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
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:
- 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
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:
- 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
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.
On Mon, May 28, 2012 at 11:42 PM, Stephen John Smoogen smooge@gmail.com wrote:
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.
I'm not sure it is that dire. Do we know if Red Hat cares about EPEL providing complete RHEL Add-Ons? If they don't then my concern is gone.
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.
I can imagine pulling in libraries needed as dependencies to be viewed as ok while completely replacing RHEL Add-Ons not being viewed as ok. There may be some middle ground even if EPEL doesn't provide RHEL Add-Ons.
John
inode0 inode0@gmail.com wrote:
I'm not sure it is that dire. Do we know if Red Hat cares about EPEL providing complete RHEL Add-Ons? If they don't then my concern is gone. I can imagine pulling in libraries needed as dependencies to be viewed as ok while completely replacing RHEL Add-Ons not being viewed as ok. There may be some middle ground even if EPEL doesn't provide RHEL Add-Ons.
If I may be so bold, I believe some (not yourself) are looking at this the wrong way. The way I have always looked at it, the Fedora Project is really designed to help Red Hat, both upstream and downstream, as much as the community. In that regard, we should really get past this "worry," and get to the bigger issue, even for Red Hat, as much as downstream.
I think you're hitting on it well here, so let me expand on my view if I may. Many in the EPEL SIG have already identified a lot of conflicts and issues, things that I feel Red Hat could benefit from. In my experience, Red Hat can always use more input and assistance. I think has been obvious ever since Red Hat Linux 10 Beta became Fedora Core 1 Test, at least to me.
So I honestly believe the answer lies in a more direct engagement with Red Hat product and release management. Most specifically, leverage the EPEL community SMEs to identify: 1. common support libraries and components which should be in RHEL base channels 2. resulting conflicts between support libraries and components in RHEL layered channels 3. package and other naming conventions to address possible needs for multiple versions
All of these details work in favor of RHEL as much as the EPEL SIG downstream. Let's make that point clear with Red Hat, it's that "extra set of broad eyes." I am willing to assist any way I can, since I'm heavily customer-facing and this continually affects large Red Hat customers. This is really a case where the Fedora Project can and does holds extensive value-add, and it's clear Red Hat could use some input at times.
BTW, this is in addition to my personal and continuing favorite (some of you have heard me harp on this via other avenues) ... - Facilitate easier access not just to RHEL entitlements for EPEL maintainers, but layered entitlements too -- e.g., a "pool" that can be assigned by Fedora Project leaders
My view has been the "gold standard" for development and builds in EPEL should be RHEL+layered entitlements. Red Hat only shoots itself in-the-foot if it doesn't not make them readily available to EPEL developers. It also gets back valuable feedback, things that help Red Hat avoid issues with its own customers. It's win-win-win for Red Hat-customer-community to do so, and that has been my long-standard, long-held view.
As always, my views are my own only.
-- Bryan J Smith - Professional, Technical Annoyance
On 28 May 2012 23:04, inode0 inode0@gmail.com wrote:
Well then the only way I can see to meet your point would be to stop EPEL.
I'm not sure it is that dire. Do we know if Red Hat cares about EPEL providing complete RHEL Add-Ons? If they don't then my concern is gone.
As in all cases, there is no Red Hat, there are 4000 different Red Hatters. We have groups (like IPA, Directory Services, Gluster, and some others) who rely on EPEL so that they can give customer who want to see where things are going but don't run Fedora because it is too far advanced from what they are running. You have other groups who really don't care and say "Well if someone is running EPEL and our conflicts, that is their problem." and we have consultants who end up having to fix those problems. And finally you have EPEL being a project run on Fedora servers by volunteers. None of us are paid to work on it, even in Fedora Infrastructure. We do so because it fits our needs, is useful to us, and for the most part is fun. Remove those and there is no need for it.
In order for EPEL to build against those channels it would require changes to Koji and the infrastructure. Some of the channels are not meant to be run on the same channel (one provides foo-1.2.3 and another provides foo-2.1.3.) it will require knowing that if you are building X that you required foo-2 and not foo-1 (or vice versa).
Once upon a time, inode0 inode0@gmail.com said:
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.
Um, it is all Open Source software, so if a third party (EPEL or somebody else) wants to also provide it, Red Hat doesn't really have a leg to stand on asking it to be removed. You are perfectly within your rights to purchase RHEL entitlements and load whatever software you want, even software that Red Hat offers to support at additional cost, without paying them any more money (you just won't get any support for it).
If you don't like that, then don't use EPEL (or any other third party software repository).
On Tue, 29 May 2012 09:33:11 -0500 Chris Adams cmadams@hiwaay.net wrote:
Once upon a time, inode0 inode0@gmail.com said:
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.
Um, it is all Open Source software, so if a third party (EPEL or somebody else) wants to also provide it, Red Hat doesn't really have a leg to stand on asking it to be removed. You are perfectly within your rights to purchase RHEL entitlements and load whatever software you want, even software that Red Hat offers to support at additional cost, without paying them any more money (you just won't get any support for it).
If you don't like that, then don't use EPEL (or any other third party software repository).
I think the point here is that no one wants to take a 'tough luck' position or any such dramatic statements. We're providing software packages to people who are, overwhelmingly, running servers that need to be stable. They are just looking for stability and consistency.
So I think we don't want to make any dramatic statements about whether or not red hat has a right to ask to have something removed. 1. it is probably unnecessary 2. it just doesn't help our core user base.
which is why I like Jon's proposal - it's simple and doesn't involve dramatic statements of any kind. It's how I would like my own servers to run: low key and straightforward.
-sv
Chris Adams wrote:
Um, it is all Open Source software, so if a third party (EPEL
Just keep in mind that the Fedora Project is quite differentiated from other Third Party Software (TPS) by many people, including community TPS repositories. From post #1, I've tried to put for the reasons why marginalizing Red Hat customers is not the way to go in the Red Hat sponsored Fedora Project.
or somebody else) wants to also provide it,
Indeed. The question becomes where do people get it in a way that it does not sprawl "out-of-control" from the standpoint of management. You have to consider not just ... A. Red Hat desktop subscriptions B. Red Hat server subscriptions C. Red Hat server subscriptions with optional enterprise channels (pricing up to 10x as much as "B", a pricing/support differential which has existed since RHEL 2.1)
But also ... D. EL Rebuilds who strive for bit-for-bit compatibilit y(who vary in what they have in base, extras, etc...) E. Other projects that may or may not be involved
Red Hat doesn't really have a leg to stand on asking it to be removed.
Again, why go there? I've never considered it to be "versus" in the Fedora Project, but trying to address the needs of Red Hat, customers and community. This helps no one.
You are perfectly within your rights to purchase RHEL entitlements and load whatever software you want, even software that Red Hat offers to support at additional cost, without paying them any more money (you just won't get any support for it).
Unfortunately, people do, not just intentionally, but unintentionally. Red Hat wastes resources, etc... And it's not the community that is really the concern, but more costly, proprietary vendors that intentionally put customers and community in the position of doing it, unintentionally.
If it is at all possible, I would advocate the Fedora Project provide diligence in mitigating this issue. Several people have many solid suggestions on how to mitigate this, even though it will still happen. The idea is to do what is technically and managerially possible to mitigate it, and that's all the Fedora Project can do.
If you don't like that, then don't use EPEL (or any other third party software repository).
The more you ignore the needs of one entity/userbase, the more you marginalize them, the more it loses value. This is hardly about "having a leg to stand on," so don't go there.
-- Bryan J Smith - Professional, Technical Annoyance
epel-devel@lists.fedoraproject.org