[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

Backporting (was: Release and update procedure for EPEL)



On Tue, Feb 27, 2007 at 02:46:04PM -0500, Bill Nottingham wrote:
> Matthias Saou (thias 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

Attachment: pgpfnwvgnLacH.pgp
Description: PGP signature


[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]