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