Backporting (was: Release and update procedure for EPEL)

[Axel Thimm]

On Tue, Feb 27, 2007 at 02:46:04PM -0500, Bill Nottingham wrote:
> Matthias Saou (thias at spam.spam.spam.spam.spam.spam.spam.egg.and.spam.freshrpms.net) said: 
> > - Do we want a moving (and potentially breaking) set of packages which
> >   is constantly being updated?
> > - De we want a fixed set of packages when a RHEL release is made and
> >   focus on major bugfixes and security updates from there on?
> > 
> > Or maybe something in between, or even both at the same time in
> > separate repositories... all is possible, as long as we have enough man
> > power to make it happen.
> 
> I'd lean somewhat towards the latter. If we actually intend to maintain
> stuff for 7 years, we're not going to be wanting to do that many upgrades.
> 
> Are packagers really signing up for backporting?

A good question, backporting is the name of evil in software
engineering and packaging. FL died on the amount of efforts this
requires. Simply upgrading is the fast way out, but maybe not the RHEL
API/ABI stable way.

Backporting would be really great, but we need tons of slaves or
masochists to commit to this. Maybe it depends on how many paid jobs
from RH and external will be involved, since volunteers are less
likely to do backporting.

I would say, if we think that manpower will be low, we need to follow
a rolling release model w/o backporting. If we know that there is
enough momentum and interest (in the sense of doing it, not just
wanting it) then we should consider backporting, it would raise
quality/stability standards to two of the "E"s in RHEL/EPEL ;)
-- 
Axel.Thimm at ATrpms.net
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://listman.redhat.com/archives/epel-devel-list/attachments/20070301/c22591eb/attachment.sig>