On 01.07.2008 10:32, Paul Howarth wrote:

Felix Schwarz wrote:

in the past few months there were quite a few packages in EPEL
which got version updates. This has come to a point where I
seriously doubt my understanding of the EPEL policy.

Rahul Sundaram wrote [1]:
"The simple rule: Don't release an update unless absolutely necessary.
This is to avoid regressions."

This was exactly my understanding of how package updates should be
done in EPEL.

But obviously other packagers don't see this policy so strictly - or
maybe I'm just too blind to find important information why all these
updates were absolutely necessary.

[examples striped]

I understand that there are packages like Firefox, Wine and clamav which must be
always at the latest version because it makes no sense/its impossible to backport
all the important stuff. But what I don't understand is why all these library
packages are updated so often.

IMHO EPEL should have more control over updates so that every package update gets
a solid reasoning why the package has to updated, if there are known compatibility
issues and so on...

I always thought of EPEL as 'this is an repository where I can pull updates without
too much caution because the guys will really make sure that every package is
necessary'.
</rant>
[1]
https://www.redhat.com/archives/epel-devel-list/2008-April/msg00019.html
Agree 100%. I tend to take the same approach on stable Fedora releases
too, but it's even more important to do so in EPEL.


I don't have time to discuss the details right now, but I tend to agree.

Some suggestions how to fix this:

- do the general testing -> stable moves less often (every three or four
months maybe?); that was in the initial EPEL plans (but was changed
later on) and will indirectly force maintainers to slow down a bit (but
that doesn't solve the problem completely; further: new packages IMHO
should be moved more often)


- educate EPEL contributors; e.g. let someone watch the CVS commits to
EL branches closely; if there is a big update ask the maintainer why
that is needed (I did that in the past now and then when I was EPEL
chair, but I don't have time for it anymore; sorry); if unneeded remove
the build before it gets pushed to testing


CU
knurd

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

Thorsten Leemhuis wrote:

On 01.07.2008 10:32, Paul Howarth wrote:

Felix Schwarz wrote:

in the past few months there were quite a few packages in EPEL
which got version updates. This has come to a point where I
seriously doubt my understanding of the EPEL policy.

Rahul Sundaram wrote [1]:
"The simple rule: Don't release an update unless absolutely necessary.
This is to avoid regressions."

This was exactly my understanding of how package updates should be
done in EPEL.

But obviously other packagers don't see this policy so strictly - or
maybe I'm just too blind to find important information why all these
updates were absolutely necessary.

[examples striped]
I understand that there are packages like Firefox, Wine and clamav
which must be
always at the latest version because it makes no sense/its
impossible to backport
all the important stuff. But what I don't understand is why all
these library

packages are updated so often.

IMHO EPEL should have more control over updates so that every
package update gets
a solid reasoning why the package has to updated, if there are known
compatibility

issues and so on...

I always thought of EPEL as 'this is an repository where I can pull
updates without
too much caution because the guys will really make sure that every
package is

necessary'.
</rant>
[1]
https://www.redhat.com/archives/epel-devel-list/2008-April/msg00019.html

Agree 100%. I tend to take the same approach on stable Fedora
releases too, but it's even more important to do so in EPEL.


I don't have time to discuss the details right now, but I tend to agree.

So do I. But with a grain of salt





Some suggestions how to fix this:

- do the general testing -> stable moves less often (every three or
four months maybe?); that was in the initial EPEL plans (but was
changed later on) and will indirectly force maintainers to slow down a
bit (but that doesn't solve the problem completely; further: new
packages IMHO should be moved more often)

We could follow the RH pace, but I really really do not like it.



- educate EPEL contributors; e.g. let someone watch the CVS commits to
EL branches closely; if there is a big update ask the maintainer why
that is needed (I did that in the past now and then when I was EPEL
chair, but I don't have time for it anymore; sorry); if unneeded
remove the build before it gets pushed to testing

I agree 100% here. Education is the key.

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

On Tue, Jul 01, 2008 at 11:06:16AM +0200, Thorsten Leemhuis wrote:
> On 01.07.2008 10:32, Paul Howarth wrote:
>> Felix Schwarz wrote:
>>> in the past few months there were quite a few packages in EPEL
>>> which got version updates. This has come to a point where I
>>> seriously doubt my understanding of the EPEL policy.
>>>
>>> Rahul Sundaram wrote [1]:
>>> "The simple rule: Don't release an update unless absolutely necessary.
>>> This is to avoid regressions."
>>>
>>> This was exactly my understanding of how package updates should be
>>> done in EPEL.
>>>
>>> But obviously other packagers don't see this policy so strictly -
>>> or maybe I'm just too blind to find important information why all
>>> these updates were absolutely necessary.
>>>
>>> I understand that there are packages like Firefox, Wine and clamav
>>> which must be always at the latest version because it makes no
>>> sense/its impossible to backport all the important stuff. But what
>>> I don't understand is why all these library packages are updated so
>>> often.
>>>
>>> IMHO EPEL should have more control over updates so that every
>>> package update gets a solid reasoning why the package has to
>>> updated, if there are known compatibility issues and so on...
>>>
>>> I always thought of EPEL as 'this is an repository where I can pull
>>> updates without too much caution because the guys will really make
>>> sure that every package is necessary'. </rant>
>>> [1]
>>> https://www.redhat.com/archives/epel-devel-list/2008-April/msg00019.html
>> Agree 100%. I tend to take the same approach on stable Fedora
>> releases too, but it's even more important to do so in EPEL.

I would love to see there be a place for some elasticity. And it'll
end up being pretty arbitrary to enforce I imagine. Not all of us have
the technical ability or time to backport fixes and so the risk of
regression is always going to be higher than it would with a normal
RHEL package.

>
> I don't have time to discuss the details right now, but I tend to
> agree.
>
> Some suggestions how to fix this:
>
> - do the general testing -> stable moves less often (every three or
> four months maybe?); that was in the initial EPEL plans (but was
> changed later on) and will indirectly force maintainers to slow down
> a bit (but that doesn't solve the problem completely; further: new
> packages IMHO should be moved more often)
>
> - educate EPEL contributors; e.g. let someone watch the CVS commits
> to EL branches closely; if there is a big update ask the maintainer
> why that is needed (I did that in the past now and then when I was
> EPEL chair, but I don't have time for it anymore; sorry); if unneeded
> remove the build before it gets pushed to testing

This would definitely be a necessary step, and probably not a fun job.
Lots of people simply push new updates to their packages when upstream
releases it... and by and large it's been harmless but certainly
doesn't fit in with EPEL's goals...

I'm somewhat torn though. It's one thing to not update something that
provides an API to other programs, but maybe less of an issue to update
a client only program -- something like freehoo (CLI Yahoo messenger
client) which is something I would hate to see stuck at a really old
version just because it's against policy to update it.

Is there a place for a -unstable branch for those of us who want to
have updated / newer packages?

I just want to avoid a situation where I end up either maintaining a
personal repository of "newer" packages for EL-5 simply because I'm
stuck at an old version in EPEL, or end up deciding to maintain a new
package in a repository with less restrictive rules....

Take with a grain of salt; this is coming from a guy who only maintains
a few packages for personal and work use.

Ray

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

Ray Van Dolson wrote:

I'm somewhat torn though. It's one thing to not update something that
provides an API to other programs, but maybe less of an issue to update
a client only program -- something like freehoo (CLI Yahoo messenger
client) which is something I would hate to see stuck at a really old
version just because it's against policy to update it.


I think there's a good case for a distinction between "top-level"
packages (like freehoo) and those that other packages depend on as you
say. And there's precedent for that in RHEL too, given that RHEL 5.2 has
a firefox 3 beta for instance.


Paul.

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

On Tue, Jul 01, 2008 at 02:54:36PM +0100, Paul Howarth wrote:
> Ray Van Dolson wrote:
> >I'm somewhat torn though. It's one thing to not update something that
> >provides an API to other programs, but maybe less of an issue to update
> >a client only program -- something like freehoo (CLI Yahoo messenger
> >client) which is something I would hate to see stuck at a really old
> >version just because it's against policy to update it.
>
> I think there's a good case for a distinction between "top-level"
> packages (like freehoo) and those that other packages depend on as you
> say. And there's precedent for that in RHEL too, given that RHEL 5.2 has
> a firefox 3 beta for instance.
>

Well put, Paul. Packages that mostly run standalone are appropriate
candidates for a rebase (like freehoo and firefox), but those that serve
as libraries or building blocks for other components should try to stay
as stable as possible from an ABI/API perspective.

I would like to think we can make this as open as possible (no rules
yet) and defer to the judgment of individual package maintainers when
deciding whether a rebase or backport is the way to go. Generally those
closest to the code know which change is best -- they will just need to
be prepared with an answer that is better than, "I was too lazy to
backport" if they cause a lot of problems for users when rebasing.

-andy

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

Andy Gospodarek schrieb:

Well put, Paul. Packages that mostly run standalone are appropriate
candidates for a rebase (like freehoo and firefox), but those that serve
as libraries or building blocks for other components should try to stay
as stable as possible from an ABI/API perspective.


I would like to add the distinction between "server" and "desktop" software.
While both categories are not always disjoint, it this the distinction is useful
nevertheless: Some things like Firefox, OpenOffice etc. can be updated more
often than something like Exim, Apache, ...

This is a bit like Red Hat does it these days.

fs

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

Hi Ray,

first of all, I do appreciate your concerns: My free time is very limited
too and I'm doing most of my (very few!) package activities in my free time.
But I think the raison d'être for EPEL is well packaged software which is
nearly as good as RHEL packages (as good you can be with only volunteers).

Ray Van Dolson schrieb:

Is there a place for a -unstable branch for those of us who want to
have updated / newer packages?


IMHO an unstable branch would be a quite good idea.

Just to share some other idea of mine which is only loosely related to the
unstable EPEL thing:
I have a slightly different problem when it comes to updated versions: E.g.
I'm doing much TurboGears-related development so I like having the latest
TurboGears and related components but the rest should be as stable as possible.

Other example: I'm compiling EL4/5 RPM packages for Bacula which are published on
Bacula's SF page. Of course there are some admins out there who really want the new
Bacula version - even on RHEL. Bacula in EPEL 5 is at 2.0 (and not even present in
EPEL 4 - ixs: *hint* ;-). I thought about updating the high-quality EPEL RPMs for
newer versions and to provide updated RPMs on a Fedora-associated (user) page.

So after all I think there is no 'one fits it all' solution but more something
like an 'updated stack' which are just additional repositories.


fs

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

On Tue, Jul 01, 2008 at 05:46:15PM +0200, Felix Schwarz wrote:
> Andy Gospodarek schrieb:
> >Well put, Paul. Packages that mostly run standalone are appropriate
> >candidates for a rebase (like freehoo and firefox), but those that serve
> >as libraries or building blocks for other components should try to stay
> >as stable as possible from an ABI/API perspective.
>
> I would like to add the distinction between "server" and "desktop" software.
> While both categories are not always disjoint, it this the distinction is
> useful
> nevertheless: Some things like Firefox, OpenOffice etc. can be updated more
> often than something like Exim, Apache, ...
>

That is an excellent point. Should we consider breaking EPEL into an
EPEL-Base and EPEL-Desktop? If we had separate repos it might be
helpful.

I would be in favor of that and then possibly change the way we queue
something to move from testing to stable so that it can remain in
testing longer.

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

On Tue, Jul 01, 2008 at 12:25:10PM -0400, Andy Gospodarek wrote:
> On Tue, Jul 01, 2008 at 05:46:15PM +0200, Felix Schwarz wrote:
> > Andy Gospodarek schrieb:
> > >Well put, Paul. Packages that mostly run standalone are appropriate
> > >candidates for a rebase (like freehoo and firefox), but those that serve
> > >as libraries or building blocks for other components should try to stay
> > >as stable as possible from an ABI/API perspective.
> >
> > I would like to add the distinction between "server" and "desktop" software.
> > While both categories are not always disjoint, it this the distinction is
> > useful
> > nevertheless: Some things like Firefox, OpenOffice etc. can be updated more
> > often than something like Exim, Apache, ...
> >
>
> That is an excellent point. Should we consider breaking EPEL into an
> EPEL-Base and EPEL-Desktop? If we had separate repos it might be
> helpful.
>
> I would be in favor of that and then possibly change the way we queue
> something to move from testing to stable so that it can remain in
> testing longer.
>

Would the same package exist potentially in either repository? I'm
just trying to think how this might effect CentOS users who don't have
the concept of Desktop/Server...

I kind of like the -unstable option myself...

Ray

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

On Tue, Jul 01, 2008 at 09:33:08AM -0700, Ray Van Dolson wrote:
> On Tue, Jul 01, 2008 at 12:25:10PM -0400, Andy Gospodarek wrote:
> > On Tue, Jul 01, 2008 at 05:46:15PM +0200, Felix Schwarz wrote:
> > > Andy Gospodarek schrieb:
> > > >Well put, Paul. Packages that mostly run standalone are appropriate
> > > >candidates for a rebase (like freehoo and firefox), but those that serve
> > > >as libraries or building blocks for other components should try to stay
> > > >as stable as possible from an ABI/API perspective.
> > >
> > > I would like to add the distinction between "server" and "desktop" software.
> > > While both categories are not always disjoint, it this the distinction is
> > > useful
> > > nevertheless: Some things like Firefox, OpenOffice etc. can be updated more
> > > often than something like Exim, Apache, ...
> > >
> >
> > That is an excellent point. Should we consider breaking EPEL into an
> > EPEL-Base and EPEL-Desktop? If we had separate repos it might be
> > helpful.
> >
> > I would be in favor of that and then possibly change the way we queue
> > something to move from testing to stable so that it can remain in
> > testing longer.
> >
>
> Would the same package exist potentially in either repository? I'm
> just trying to think how this might effect CentOS users who don't have
> the concept of Desktop/Server...

Good question. I would think that EPEL-Desktop would be everything and
EPEL-Base would be just the components that we deem important enough to
not take huge backports each time. Basically Base would be a subset of
Desktop.


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