Backporting (was: Release and update procedure for EPEL)
On Tue, Feb 27, 2007 at 02:46:04PM -0500, Bill Nottingham wrote:
Matthias Saou
(thias(a)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
Attachments:
- attachment.sig (application/pgp-signature — 189 bytes)