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

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

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

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

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 J Smoogen.
"The core skill of innovators is error recovery, not failure avoidance."
Randy Nelson, President of Pixar University.
"Years ago my mother used to say to me,... Elwood, you must be oh
so smart or oh so pleasant. Well, for years I was smart. I
recommend pleasant. You may quote me." Â*—James Stewart as Elwood P. Dowd

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

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

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

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

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

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

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

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

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

Tue May 29 22:30:02 2012
Return-path: <devel-bounces@lists.fedoraproject.org>
Envelope-to: tom@linux-archive.org
Delivery-date: Tue, 29 May 2012 22:01:31 +0300
Received: from bastion01.fedoraproject.org ([209.132.181.2]:37431 helo=bastion.fedoraproject.org)
by s2.java-tips.org with esmtp (Exim 4.77)
(envelope-from <devel-bounces@lists.fedoraproject.org>)
id 1SZRff-0007Cz-9P
for tom@linux-archive.org; Tue, 29 May 2012 22:01:31 +0300
Received: from lists.fedoraproject.org (collab03.vpn.fedoraproject.org [192.168.1.70])
by bastion01.phx2.fedoraproject.org (Postfix) with ESMTP id F04CD20B1F;
Tue, 29 May 2012 19:00:57 +0000 (UTC)
Received: from collab03.fedoraproject.org (localhost [127.0.0.1])
by lists.fedoraproject.org (Postfix) with ESMTP id E684040ACB;
Tue, 29 May 2012 19:00:55 +0000 (UTC)
X-Original-To: devel@lists.fedoraproject.org
Delivered-To: devel@lists.fedoraproject.org
Received: from smtp-mm01.fedoraproject.org (smtp-mm01.fedoraproject.org
[80.239.156.217])
by lists.fedoraproject.org (Postfix) with ESMTP id B3B8C409EC
for <devel@lists.fedoraproject.org>;
Tue, 29 May 2012 19:00:53 +0000 (UTC)
Received: from mail-ee0-f45.google.com (mail-ee0-f45.google.com [74.125.83.45])
by smtp-mm01.fedoraproject.org (Postfix) with ESMTP id A5D25C086C
for <devel@lists.fedoraproject.org>;
Tue, 29 May 2012 19:00:52 +0000 (UTC)
Received: by eekd41 with SMTP id d41so1358459eek.32
for <devel@lists.fedoraproject.org>;
Tue, 29 May 2012 12:00:53 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
h=message-id:date:from:user-agent:mime-version:to:subject:references
:in-reply-to:content-type;
bh=andiNeSBWvBtmoVvVpbfOUlpD2qI6MOvavGxISqE4rI=;
b=jRHNFxOHk1Sr4jawlHE4eIR26lU1OVoXPyPL1sxZOLEvdIC6 NR0DIriY/xr8xNM/7U
o+elNqEPIw6sSMM2dUh8xl0AHGzZubJzzo6xXZCxrpX1kEfqFM pNuhKCPsgUgGcWXnd6
E96PQb2jmrIQ4my49MMjxsSvHbyEkAFYYecQyka8qi96ssyrLO 5QTXk8u1+8uISylJvx
dk4Adx7n3ZT8a+gxOTpU/IiCBZFO8LDbEArEcvX1og3hWZspAfD4ZmyjfKfrefmzm+NR
0b6Fac5RYXcBRlk3ZuLK/t7lGGl++5QdG5qnwNu6fkNrPUEEskH05TNaHVDd8vyEvPIo
Pd4w==
Received: by 10.14.189.7 with SMTP id b7mr4358832een.126.1338318053639;
Tue, 29 May 2012 12:00:53 -0700 (PDT)
Received: from localhost.localdomain (85-220-55-128.dsl.dynamic.simnet.is.
[85.220.55.128])
by mx.google.com with ESMTPS id y54sm51950938eef.10.2012.05.29.12.00.51
(version=SSLv3 cipher=OTHER); Tue, 29 May 2012 12:00:52 -0700 (PDT)
Message-ID: <4FC51C38.8010801@gmail.com>
Date: Tue, 29 May 2012 18:58:00 +0000
From: =?UTF-8?B?IkrDs2hhbm4gQi4gR3XDsG11bmRzc29uIg==?=
<johannbg@gmail.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
rv:12.0) Gecko/20120430 Thunderbird/12.0.1
MIME-Version: 1.0
To: devel@lists.fedoraproject.org
Subject: Re: How can we make security updates faster?
References: <alpine.LFD.2.02.1205281250001.18391@bofh.nohats.c a>
<1338241795.23681.21.camel@liliana.cdg.redhat.co m>
<1338268886.10232.2.camel@adam> <4FC462BE.1040200@gmail.com>
<jq33fi$7ru$1@dough.gmane.org>
In-Reply-To: <jq33fi$7ru$1@dough.gmane.org>
X-BeenThere: devel@lists.fedoraproject.org
X-Mailman-Version: 2.1.12
Precedence: list
Reply-To: Development discussions related to Fedora
<devel@lists.fedoraproject.org>
List-Id: Development discussions related to Fedora
<devel.lists.fedoraproject.org>
List-Unsubscribe: <https://admin.fedoraproject.org/mailman/options/devel>,
<mailto:devel-request@lists.fedoraproject.org?subject=unsubscrib e>
List-Archive: <http://lists.fedoraproject.org/pipermail/devel/>
List-Post: <mailto:devel@lists.fedoraproject.org>
List-Help: <mailto:devel-request@lists.fedoraproject.org?subject=help>
List-Subscribe: <https://admin.fedoraproject.org/mailman/listinfo/devel>,
<mailto:devel-request@lists.fedoraproject.org?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============4800770284601620960=="
Sender: devel-bounces@lists.fedoraproject.org
Errors-To: devel-bounces@lists.fedoraproject.org

This is a multi-part message in MIME format.
--===============4800770284601620960==
Content-Type: multipart/alternative;
boundary="------------060703010102030005080801"

This is a multi-part message in MIME format.
--------------060703010102030005080801
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit

On 05/29/2012 06:13 PM, Rex Dieter wrote:
>> > It makes no sense to have a gui application ( or an application for that
>> > matter ) without having written the relevant how to debug/how to test
>> > pages for each component to accommodate it.
> Indeed. However, I'd argue*both* pieces, a karma app and good test-cases,
> are needed, and one not need block on the other.

Well we then agree on disagreeing since updating the component and
running the relevant application is hardly what I call testing and
requiring karma points to just do that makes absolutely no sense to me.

This whole scenario is a bit more complicated than that and me and James
did discuss few ideas to solve this when he was with the project but
things did not progress any further than that for various reasons
including the FPC/FESCO decisions to make things optional instead of
mandatory.

For security updates arguably we should be having faith in maintainers
actually eating and testing their own food and use a time based limit
instead of karma based as in after x many days in updates testing and no
reporter has reported any problem the update gets pushed regardless of
it's karma.

In any case this is something we solve in the QA community and arguably
we should be the one that decide all this and FPC just implements what
we have decided and tell them to.

This really does not involve Fesco and we already have a good working
relationship with releng.

JBG

--------------060703010102030005080801
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: 7bit

<html>
<head>
<meta content="text/html; charset=UTF-8" http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
On 05/29/2012 06:13 PM, Rex Dieter wrote:
<blockquote cite="mid:jq33fi$7ru$1@dough.gmane.org" type="cite">
<blockquote type="cite" style="color: #000000;">
<pre wrap=""><span class="moz-txt-citetags">&gt; </span>It makes no sense to have a gui application ( or an application for that
<span class="moz-txt-citetags">&gt; </span>matter ) without having written the relevant how to debug/how to test
<span class="moz-txt-citetags">&gt; </span>pages for each component to accommodate it.
</pre>
</blockquote>
<pre wrap="">Indeed. However, I'd argue <b class="moz-txt-star"><span class="moz-txt-tag">*</span>both<span class="moz-txt-tag">*</span></b> pieces, a karma app and good test-cases,
are needed, and one not need block on the other.</pre>
</blockquote>
<br>
Well we then agree on disagreeing since updating the component and
running the relevant application is hardly what I call testing and
requiring karma points to just do that makes absolutely no sense to
me. <br>
<br>
This whole scenario is a bit more complicated than that and me and
James did discuss few ideas to solve this when he was with the
project but things did not progress any further than that for
various reasons including the FPC/FESCO decisions to make things
optional instead of mandatory. <br>
<br>
For security updates arguably we should be having faith in
maintainers actually eating and testing their own food and use a
time based limit instead of karma based as in after x many days in
updates testing and no reporter has reported any problem the update
gets pushed regardless of it's karma. <br>
<br>
In any case this is something we solve in the QA community and
arguably we should be the one that decide all this and FPC just
implements what we have decided and tell them to. <br>
<br>
This really does not involve Fesco and we already have a good
working relationship with releng. <br>
<br>
JBG<br>
</body>
</html>

--------------060703010102030005080801--

--===============4800770284601620960==
Content-Type: text/plain; charset="utf-8"
MIME-Version: 1.0
Content-Transfer-Encoding: base64
Content-Disposition: inline

LS0gCmRldmVsIG1haWxpbmcgbGlzdApkZXZlbEBsaXN0cy5mZW RvcmFwcm9qZWN0Lm9yZwpodHRw
czovL2FkbWluLmZlZG9yYXByb2plY3Qub3JnL21haWxtYW4vbG lzdGluZm8vZGV2ZWw=

--===============4800770284601620960==--