On Wed, Jul 2, 2008 at 10:27 AM, Jeroen van Meeuwen <kanarip@kanarip.com> wrote:
>
> 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)
>

That is exactly my point on another mail I sent to this list. A
repository that don't follow the RHEL release is just a no go to me.

Regards,

Miguel


--
http://osysadmin.blogspot.com

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

Michael A. Peters wrote:

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.




It doesn't need to be actual CVS / build branches, it could be done the
way this-other-EL5-distribution does it.


It does mean keeping EPEL 5.1 RPM files around.

It may mean a maintainer can but doesn't need to update
non-current-point-releases.


Like I said, it's just a thought. Something to ponder, if you will. This
is how I anticipated EPEL would work back in Boston, February 2007. It
has been disappointing to see that it doesn't, but who am I to say that
not having been involved with setting it up and contributing to it's
infrastructure.


Miguel Filho wrote:
> That is exactly my point on another mail I sent to this list. A
> repository that don't follow the RHEL release is just a no go to me.
>

+1.

If there's anything that needs to happen to make it so, let me know and
I'll know what I can do (and I'd like to think some others will have
that too).


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

Miguel Filho wrote:

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

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)



That is exactly my point on another mail I sent to this list. A
repository that don't follow the RHEL release is just a no go to me.


Well since there isn't any third party reposiory following the EL
release model, it makes sense to explain why you need such a model.
Simply demanding that it should be done without providing a good
explanation isn't really motivating anybody.


Rahul

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

Miguel Filho wrote:

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

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)



That is exactly my point on another mail I sent to this list. A
repository that don't follow the RHEL release is just a no go to me.


Well since there isn't any third party repository following the EL
release model, it makes sense to explain why you need such a model.
Simply demanding that it should be done without providing a good
explanation isn't really motivating anybody.


Rahul

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

On Wed, 2 Jul 2008, Michael A. Peters wrote:

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

I generally agree. It'd be nice to have different branches and follow
them. but I can't imagine what the world will be like with RHEL6 comes
out, by then we could be maintaining 2 or 3 different RHEL4 branches,
potentially 5 or 6 RHEL5 branches, then the RHEL6.0 branch.

For my use case anyway, EPEL's served quite well, I haven't had too many
problems and the package updates are certainly less frequent then Fedora.

-Mike

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

I tend to agree with Mike and several of the previous comments in this thread.

EPEL was designed to supplement EL with packages not included in the
base. It has been, and will continue to do this. If the package is
updating too frequently, the solution is simple, don't update.
(disable automatic yum, or up2date or whatever). Create a release
strategy for your needs. The repository and upgrade strategy are not
(and should not) be one in the same. If it's not updating often
enough, you are welcome to uses other repos, or supplement with your
own updates.

I tend to think that currently, the Fedora Project and contributors
would not be able to sustain a quality-driven branch for unstable, or
5.1 vs 5.2 etc and so on. I still think that EPEL is much better than
me having to hand pick every RPM from Fedora SRPMS and recompile them
by hand, store them in my own repositories and then watch as
incompatibilities crop up.

Keep in mind that EPEL's goal is to make high-quality, fedora
approved, packages available. How you use them is up to you.

I also gave a talk on managing updates at the Red Hat Summit, if you
want to check it out, please do so.
http://stahnma.fedorapeople.org/summit/updates.odp


stahnma

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

After doing a lot of thinking at the vet this weekend, I just do not
see how we have the man-power to meet a 'super'-stable release model.
Super-stable requires a lot of effort to review and backport changes..
which is why many of us are paying 'Red Hat' or some consultant with
CentOS/SciLin to do for us. I do not see how we can do so without a
similar revenue stream to pay for people to sit and keep stuff from
bit-rotting or forcing updates to newer versions because the code
between 1.0.1 and 1.0.2 changed over 30%.

It is also hard to know what is 'stable' enough for some groups. For
everyone who wants to keep rt3 at an old version there are those who
want a newer version because it has the features they need. The only
solutions I could see to this were:

a) giving people the tools to easily stick to what they want (in the
way that Dag says for people wanting older stuff from him to use mrepo
or similar to make their own local repository... not that many people
do that... but those who were warned don't get much sympathy .)

b) make it possible to have multiple levels of support when the
bodhi/plague system is implemented. What I was seeing is that we have
say 4 channels:
alpha -- stuff from Fedora is built just like anything else for
EL-4,5,6 and is either 'blacklisted' or 'eats-babies'
beta -- stuff voted as being good enough is put here (eg EPEL-testing).
gamma -- stuff voted to here is good enough for production.
delta -- the last item from gamma is moved here... people can keep
track of old items via this.
epsilon -- really stable releases are here.

the progression is then open to people and they can become involved by
lobbying to keep something in gamma or moving it to delta.. elections
would be held on a monthly system for items they wanted. of course
this is all pie in the sky at the moment.. but worth looking at
someday.

anyway, back to the vet.

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