On Tue, 1 Jul 2008 12:25:10 -0400, Andy Gospodarek wrote:

> > 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.

Danger lies ahead. This feels like the old Fedora Extras with Core as the
base, where you are stuck if you need base packages newer than what Core
offers. With it comes the desire to upgrade base. And for EPEL that would
mean to upgrade RHEL.

I think RHEL/EPEL/CentOS users should accept that they cannot get the
latest on top of a stable [several years old] base.

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

Michael Schwendt schrieb:

On Tue, 1 Jul 2008 12:25:10 -0400, Andy Gospodarek wrote:

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.


Danger lies ahead. This feels like the old Fedora Extras with Core as the
base, where you are stuck if you need base packages newer than what Core
offers. With it comes the desire to upgrade base. And for EPEL that would
mean to upgrade RHEL.

I think RHEL/EPEL/CentOS users should accept that they cannot get the
latest on top of a stable [several years old] base.


I think we should not split EPEL. One repo is good (because the separation
line between desktop and server is blurry, it will cause more work load for
all packagers, potentially dependency problems etc)., but maybe an unstable
branch is ok (so you can get some few selected packages which you like to get
updated). That would essentially mirror the Debian testing system.


This topic will occur more often I think when more people start using
CentOS/RHEL on the desktop.


But essentially EPEL should be (IMHO) about stability and reliability! What I
would like to see is that every update needs a short reasoning why the package
should be updated and that someone else can read the description and approve
the update (or reject it).


Its just that I'm somewhat more relaxed when "desktop" software should be updated.

fs

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

On Tue, Jul 1, 2008 at 1:23 AM, Felix Schwarz
<felix.schwarz@oss.schwarz.eu> wrote:
>
> Hi,
>
> 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."
>

Ok the big problem is that there are multiple types of users for EPEL,
and each group seems to wax and wane in asking for things. Several
months ago, the people who wanted to have newer stuff regularly versus
once a quarter asked and got enough push to get it done. Now we are
approaching the other side and the people who want it once a quarter
or never are asking for things... the problem is that the basic build
system and controls are limited in scope of what can be accomplished.
I would love to be able to have different channels for each of the
types of releases that people want, but everyone wants something
different.

In the end, we had few volunteers/packages and many more "we want
X"'ers than we could handle when we did quarterly releases. We moved
to a monthly schedule and we have more volunteers/packages and can
handle more of the "We want X" people. However, this does not work
well for various sites. How to solve this problem is really hard, and
I am not sure anyone has come up with a solution that more than 1 or 2
other people want to try.

--
Stephen J Smoogen. -- BSD/GNU/Linux
How far that little candle throws his beams! So shines a good deed
in a naughty world. = Shakespeare. "The Merchant of Venice"

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

Stephen John Smoogen schrieb:

Ok the big problem is that there are multiple types of users for EPEL,
and each group seems to wax and wane in asking for things. Several
months ago, the people who wanted to have newer stuff regularly versus
once a quarter asked and got enough push to get it done.


I think you are right that there are different types of users. You can't make
everyone happy.

But it is not (at least from my pov) about monthly vs. quarterly releases. I
really like monthly updates. But the EPEL policy (as I read it) states that
version updates should not happen unless there is a really good reason. IMHO
the question whether to push new packages on a quarterly, monthly or daily
basis is completely separate.


I would love to be able to have different channels for each of the
types of releases that people want, but everyone wants something
different.


That's why I think we should concentrate on the stable policy. If the
infrastructure gets in a shape that we can serve an unstable branch (and we
have the volunteers to do it!), we could extend EPEL's focus.

Felix Schwarz

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

On Tue, Jul 1, 2008 at 12:38 PM, Felix Schwarz
<felix.schwarz@oss.schwarz.eu> wrote:
>
> Stephen John Smoogen schrieb:
>>
>> Ok the big problem is that there are multiple types of users for EPEL,
>> and each group seems to wax and wane in asking for things. Several
>> months ago, the people who wanted to have newer stuff regularly versus
>> once a quarter asked and got enough push to get it done.
>
> I think you are right that there are different types of users. You can't
> make
> everyone happy.
>
> But it is not (at least from my pov) about monthly vs. quarterly releases. I
> really like monthly updates. But the EPEL policy (as I read it) states that
> version updates should not happen unless there is a really good reason. IMHO
> the question whether to push new packages on a quarterly, monthly or daily
> basis is completely separate.
>

I guess I need help parsing in what you are meaning by stable. are you meaning:

A) el5/nethack-3.4.3 should always be el5/nethack-3.4.3 with only
patches to that version of the software?

B) that once a month it could be minorly updated say from
el5/nethack-3.4.3 to el5/nethack-3.4.5 as long as the code base is
mostly the same without major patches?

C) that once a month it could go like el5/nethack-3.4.3 to el5/nethack-4.0?

or something else?

>> I would love to be able to have different channels for each of the
>> types of releases that people want, but everyone wants something
>> different.
>
> That's why I think we should concentrate on the stable policy. If the
> infrastructure gets in a shape that we can serve an unstable branch (and we
> have the volunteers to do it!), we could extend EPEL's focus.
>

The only time I have seen strong commitment to a stable branch is when
things break... and then it is forgotten a month or two later.



--
Stephen J Smoogen. -- BSD/GNU/Linux
How far that little candle throws his beams! So shines a good deed
in a naughty world. = Shakespeare. "The Merchant of Venice"

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

Stephen John Smoogen schrieb:

I guess I need help parsing in what you are meaning by stable. are you meaning:

A) el5/nethack-3.4.3 should always be el5/nethack-3.4.3 with only
patches to that version of the software?


A) with the exception that there can be 'good reasons' (like security fixes
can not be backported, version update has huge benefits because XYZ) that a
package should be updated. Especially because EPEL is driven by volunteers so
we don't have the manpower to do too much backporting.



The only time I have seen strong commitment to a stable branch is when
things break... and then it is forgotten a month or two later.


I guess you are right :-)
But I know some packagers who don't bring their packages into EPEL yet because
they want a version that is 'here to stay'. Therefore python-beaker is not yet
in EPEL (probably the 1.0 version will). pyPdf was not updated too.


And the old version of python-zope-interface currently blocks 3-4 other
packages of mine but I'm very hesitant to update that library so I guess I
will wait until I can make sure that there will be no backwards compatibility
problems.


fs

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

Felix Schwarz wrote:

Hi,

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'd like to give my opinion on this. I've pretty much been a Red Hat
user since MKLinux DR3 (based on RH 5.1) - RH 6.1 was my first i386
distribution.


Back then, Linux was just beginning to emerge, getting the latest
software was always a bonus because it was leaps and bounds ahead of the
rest.


I really liked Red Hat 8 once the first set of major bugs was fixed, but
jumped on the Fedora bandwagon because there were still extremely
exciting things happening with each new release.


Maybe part of it is because I'm older now than I was back then, but
honestly, I'm not as gung ho about having the freshest releases of
software as I use to be. In my opinion, OSS has matured to the point
where as a *desktop user* I would rather have a slighly older release
that is stable than a fresh release with new features and new bugs. For
example, for whatever reasons - evolution in Fedora 8 was unusable to
me, it had some cool new stuff but it had some major issues,
particularly with my laptop, which was a slow low memory machine.


There are a few exceptions. I do think RHEL is justified in moving
Firefox to FF3. The reason is twofold -


1) Firefox has a huge codebase. It would take extreme amount of man
power to continue to maintain FF 1.x without upstream.


2) The web evolves quickly, and a browser must keep in touch with modern
web innovations, particularly in the area of javascript and CSS
implementation.


I think RHEL moving to modern Firefox was the right decision.
For most other software though, my opinion - if you want to run the
latest versions, use Fedora. That's not what RHEL/CentOS are for.


At this point - there is enough functionallity in desktop apps to have
an extremely usable desktop system with apps that are not the latest and
greatest. RHEL should provide a stable desktop without introducing the
new bugs and new quirks that come with new software.


That's my 2 cents on the issue.

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

Michael A. Peters wrote:
There are a few exceptions. I do think RHEL is justified in moving
Firefox to FF3. The reason is twofold -


1) Firefox has a huge codebase. It would take extreme amount of man
power to continue to maintain FF 1.x without upstream.


2) The web evolves quickly, and a browser must keep in touch with modern
web innovations, particularly in the area of javascript and CSS
implementation.




A small addition here; RHEL does so by releasing a minor update to the
entire operating system (5.2) - so everyone knows to look for changes
like these. Is this something EPEL can do as well?


EPEL 5.1/nethack-3.4.3

EPEL 5.2/nethack-4.0 (for the right reasons)

Just a thought.

Kind regards,

Jeroen van Meeuwen
-kanarip

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

On Wed, Jul 2, 2008 at 3:27 PM, Jeroen van Meeuwen <kanarip@kanarip.com> wrote:

Michael A. Peters wrote:


There are a few exceptions. I do think RHEL is justified in moving Firefox to FF3. The reason is twofold -



1) Firefox has a huge codebase. It would take extreme amount of man power to continue to maintain FF 1.x without upstream.



2) The web evolves quickly, and a browser must keep in touch with modern web innovations, particularly in the area of _javascript_ and CSS implementation.






A small addition here; RHEL does so by releasing a minor update to the entire operating system (5.2) - so everyone knows to look for changes like these. Is this something EPEL can do as well?



EPEL 5.1/nethack-3.4.3



EPEL 5.2/nethack-4.0 (for the right reasons)



Just a thought.
I think that will imply to add another epel branch.
such as* move epel to EL-5.1 and then add EL-5.2






Kind regards,



Jeroen van Meeuwen

-kanarip



_______________________________________________

epel-devel-list mailing list

epel-devel-list@redhat.com

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



--
Xavier.t Lamien
--
http://fedoraproject.org/wiki/XavierLamien
GPG-Key ID: F3903DEB
Fingerprint: 0F2A 7A17 0F1B 82EE FCBF 1F51 76B7 A28D F390 3DEB
_______________________________________________
epel-devel-list mailing list
epel-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/epel-devel-list

Jeroen van Meeuwen wrote:

Michael A. Peters wrote:
There are a few exceptions. I do think RHEL is justified in moving
Firefox to FF3. The reason is twofold -


1) Firefox has a huge codebase. It would take extreme amount of man
power to continue to maintain FF 1.x without upstream.


2) The web evolves quickly, and a browser must keep in touch with
modern web innovations, particularly in the area of javascript and CSS
implementation.




A small addition here; RHEL does so by releasing a minor update to the
entire operating system (5.2) - so everyone knows to look for changes
like these. Is this something EPEL can do as well?


EPEL 5.1/nethack-3.4.3

EPEL 5.2/nethack-4.0 (for the right reasons)

Just a thought.


To be honest, I think it would be too much effort to keep separate
branches of EPEL for each point release just for the few cases where
there is a legitimate reason to update a package.


If a user doesn't want to upgrade to a point release, the user can add
nethack to their excludes for automatic updates.


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