On Mon, 10 Dec 2007 13:11:53 -0700
Kevin Fenzi <kevin@tummy.com> wrote:

> Personally, my vote is to always add the updates in.
> It's easier to tell people that they must have an updated system in
> order to use EPEL packages.
>
> Any other thoughts?

I agree with Kevin. The latest updates should be made available in the
buildroot. The /only/ time where this might not be done is at a point
release date, where a /lot/ of updates will be released. Depending on
how EPEL works with CentOS, there might be a delay at this point.

--
Jesse Keating
Fedora -- All my bits are free, are yours?
_______________________________________________
epel-devel-list mailing list
epel-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/epel-devel-list

On Dec 10, 2007 2:19 PM, Jesse Keating <jkeating@redhat.com> wrote:
> On Mon, 10 Dec 2007 13:11:53 -0700
> Kevin Fenzi <kevin@tummy.com> wrote:
>
> > Personally, my vote is to always add the updates in.
> > It's easier to tell people that they must have an updated system in
> > order to use EPEL packages.
> >
> > Any other thoughts?
>
> I agree with Kevin. The latest updates should be made available in the
> buildroot. The /only/ time where this might not be done is at a point
> release date, where a /lot/ of updates will be released. Depending on
> how EPEL works with CentOS, there might be a delay at this point.
>
> --
> Jesse Keating
> Fedora -- All my bits are free, are yours?
>
> _______________________________________________
> epel-devel-list mailing list
> epel-devel-list@redhat.com
> https://www.redhat.com/mailman/listinfo/epel-devel-list
>
>
That's probably reasonable and sane. It would be nice if we could put
together some sort of schedule like when our builders get updates
after a RHEL (or I guess CentOS actually) update. Is it 2 weeks? Is
it whenever we get to it?

stahnma

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

On 11.12.2007 01:33, Michael Stahnke wrote:
> On Dec 10, 2007 2:19 PM, Jesse Keating <jkeating@redhat.com> wrote:
>> On Mon, 10 Dec 2007 13:11:53 -0700
>> Kevin Fenzi <kevin@tummy.com> wrote:
>>
>>> Personally, my vote is to always add the updates in.

+1 -- that actually was the plan, but it got forgotten afaics as we iirc
had no way to get the updates easily when we started EPEL. Does reposync
provide a solution these days for RHEL5?

>>> It's easier to tell people that they must have an updated system in
>>> order to use EPEL packages.
>>> Any other thoughts?
>> I agree with Kevin. The latest updates should be made available in the
>> buildroot. The /only/ time where this might not be done is at a point
>> release date, where a /lot/ of updates will be released. Depending on
>> how EPEL works with CentOS, there might be a delay at this point.
> That's probably reasonable and sane.

+1

> It would be nice if we could put
> together some sort of schedule like when our builders get updates
> after a RHEL (or I guess CentOS actually) update. Is it 2 weeks? Is
> it whenever we get to it?

Soon after the CentOS updates ships?

CU
knurd

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

Kevin Fenzi wrote:

[...]
Should the builders build against just the base stock OS, or
should they also pull in the released updates?


[...]
So, if we build an app against base only, anyone with updates will not
be able to use it or update until they remove it.


If we build against updates as well then they will be forced to apply
the dependent packages from updates.

Personally, my vote is to always add the updates in.
It's easier to tell people that they must have an updated system in
order to use EPEL packages.


Any other thoughts?


All RH's announcements include:


4. Solution:

Before applying this update, make sure that all previously-released
errata relevant to your system have been applied.


Therefore I would definitely go with using updates.

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

On Tue, 11 Dec 2007 09:15:09 +0100
Thorsten Leemhuis <fedora@leemhuis.info> wrote:

> Soon after the CentOS updates ships?

That could create undue delay. Especially if EPEL packages are
preventing customers from getting the next update packages from
RHEL/RHN. We don't want to be the cause of their upgrades/updates not
working.

I guess you have to pick whom you're going to upset. The RHEL/RHN
customers or the CentOS folks, because either way you're going to block
somebody from getting some form of updates. Either CentOS folks are
going to be blocked from getting EPEL updates as EPEL builds get done
against a point release update, or you're going to block RHN customers
from getting the RHEL point release if any EPEL packages require
something that is getting updated in the point release.

--
Jesse Keating
Fedora -- All my bits are free, are yours?
_______________________________________________
epel-devel-list mailing list
epel-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/epel-devel-list

On 11.12.2007 14:14, Jesse Keating wrote:
> On Tue, 11 Dec 2007 09:15:09 +0100
> Thorsten Leemhuis <fedora@leemhuis.info> wrote:
>
>> Soon after the CentOS updates ships?
> That could create undue delay. Especially if EPEL packages are
> preventing customers from getting the next update packages from
> RHEL/RHN. We don't want to be the cause of their upgrades/updates not
> working.

The proper answer IMHO is to do what we planed from the start, but never
realized: create per dist dirs like epel/5.1. When 5.2 ships to a "cp
-al 5.1 5.2", update the builders and ship all newly build packages in
the 5.2 dir. Once CentOS 5.2 is out delete the 5.1 dir.

The only problem: we'd need to push security updates to both the 5.1 and
5.2 dir during the delta where CentOS catches up.

BTW, we will likely cause problems for RHEL/RHN customers in any case in
rare situations when RH ships updates because we don't get new RHEL
update releases in advance -- thus we might now and then need a day or
two to catch up in case something from EPEL needs to be build against a
new updated package (firefox, pidgin, ...) from RHEL.

Cu
knurd

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

On Tue, 11 Dec 2007 14:28:14 +0100
Thorsten Leemhuis <fedora@leemhuis.info> wrote:

> The proper answer IMHO is to do what we planed from the start, but
> never realized: create per dist dirs like epel/5.1. When 5.2 ships to
> a "cp -al 5.1 5.2", update the builders and ship all newly build
> packages in the 5.2 dir. Once CentOS 5.2 is out delete the 5.1 dir.
>
> The only problem: we'd need to push security updates to both the 5.1
> and 5.2 dir during the delta where CentOS catches up.
>
> BTW, we will likely cause problems for RHEL/RHN customers in any case
> in rare situations when RH ships updates because we don't get new RHEL
> update releases in advance -- thus we might now and then need a day or
> two to catch up in case something from EPEL needs to be build against
> a new updated package (firefox, pidgin, ...) from RHEL.

This is where RHEL z-stream updates will come into play.

Please ping me for the next EPEL meeting as I'd like to discuss this
during the meeting.

--
Jesse Keating
Fedora -- All my bits are free, are yours?
_______________________________________________
epel-devel-list mailing list
epel-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/epel-devel-list

On 11.12.2007 15:35, Jesse Keating wrote:
> On Tue, 11 Dec 2007 14:28:14 +0100
> Thorsten Leemhuis <fedora@leemhuis.info> wrote:
>
>> The proper answer IMHO is to do what we planed from the start, but
>> never realized: create per dist dirs like epel/5.1. When 5.2 ships to
>> a "cp -al 5.1 5.2", update the builders and ship all newly build
>> packages in the 5.2 dir. Once CentOS 5.2 is out delete the 5.1 dir.
>> The only problem: we'd need to push security updates to both the 5.1
>> and 5.2 dir during the delta where CentOS catches up.
>> BTW, we will likely cause problems for RHEL/RHN customers in any case
>> in rare situations when RH ships updates because we don't get new RHEL
>> update releases in advance -- thus we might now and then need a day or
>> two to catch up in case something from EPEL needs to be build against
>> a new updated package (firefox, pidgin, ...) from RHEL.
> This is where RHEL z-stream updates will come into play.

That's another issue. But there is one thing about them that I never
understood: when does RH do them? Only for selected releases?

And BTW: I'm wondering if EPEL should just ignore them for now; sure,
would be nice to support them, but I suspect we don't have the manpower
nor the tools to properly support them right now. Yeah, that sucks, but
there are bigger problems to solve first IMHO.

> Please ping me for the next EPEL meeting as I'd like to discuss this
> during the meeting.

Sure, will do (next meeting will be next weeks Wednesday at 18:00 UTC,
in case it matters), but maybe you can find the time to explain your
thoughts first here on the list first over the next few days -- having
the major thoughts shared before discussing a issue on IRC IMHO makes
everything a whole lot easier and quicker. And mailing lists have no
timezone problems ;-)

CU
knurd

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

On Tue, 11 Dec 2007 16:03:59 +0100
Thorsten Leemhuis <fedora@leemhuis.info> wrote:

> That's another issue. But there is one thing about them that I never
> understood: when does RH do them? Only for selected releases?

Z-stream is for Server only, critical security only, and lasts until
the third subsequent minor release. IE when 5.4 is released, the 5.1.z
stream ends. It will be offered as a separate subscription, so you
have to opt-in (and pay).

>
> And BTW: I'm wondering if EPEL should just ignore them for now; sure,
> would be nice to support them, but I suspect we don't have the
> manpower nor the tools to properly support them right now. Yeah, that
> sucks, but there are bigger problems to solve first IMHO.

Well, I was saying that they could be used as a source for an update
that you need to get out between the period of say 5.2 releasing and
CentOS catching up. You could do a "5" build using the 5.1.z stream
released package in the buildroot and place it with confidence in your
5 directory.

> > Please ping me for the next EPEL meeting as I'd like to discuss this
> > during the meeting.
>
> Sure, will do (next meeting will be next weeks Wednesday at 18:00 UTC,
> in case it matters), but maybe you can find the time to explain your
> thoughts first here on the list first over the next few days -- having
> the major thoughts shared before discussing a issue on IRC IMHO makes
> everything a whole lot easier and quicker. And mailing lists have no
> timezone problems ;-)

I'm still trying to poke folks to get public docs up regarding the
z-stream, which would make a discussion much more easily done.

--
Jesse Keating
Fedora -- All my bits are free, are yours?
_______________________________________________
epel-devel-list mailing list
epel-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/epel-devel-list