Linux Archive

Linux Archive (http://www.linux-archive.org/)
-   EPEL Development (http://www.linux-archive.org/epel-development/)
-   -   Thoughts from last meeting (http://www.linux-archive.org/epel-development/671146-thoughts-last-meeting.html)

Kevin Fenzi 05-25-2012 09:24 PM

Thoughts from last meeting
 
So, at our last meeting:

http://meetbot.fedoraproject.org/meetbot/teams/epel/epel.2012-05-23-22.12.html

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
_______________________________________________
epel-devel-list mailing list
epel-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/epel-devel-list

Adam Miller 05-25-2012 09:36 PM

Thoughts from last meeting
 
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.html
>
> 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


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

inode0 05-25-2012 09:45 PM

Thoughts from last meeting
 
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.html
>
> 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

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

Kevin Fenzi 05-25-2012 10:05 PM

Thoughts from last meeting
 
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.html
> >
> > 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
_______________________________________________
epel-devel-list mailing list
epel-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/epel-devel-list

inode0 05-25-2012 10:25 PM

Thoughts from last meeting
 
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

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

Bryan J Smith 05-25-2012 10:55 PM

Thoughts from last meeting
 
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

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

inode0 05-25-2012 11:21 PM

Thoughts from last meeting
 
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

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

Jon Stanley 05-26-2012 06:53 AM

Thoughts from last meeting
 
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

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

Bryan J Smith 05-26-2012 10:53 AM

Thoughts from last meeting
 
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

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

inode0 05-26-2012 01:01 PM

Thoughts from last meeting
 
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

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


All times are GMT. The time now is 06:47 AM.

VBulletin, Copyright ©2000 - 2014, Jelsoft Enterprises Ltd.
Content Relevant URLs by vBSEO ©2007, Crawlability, Inc.