From thias at spam.spam.spam.spam.spam.spam.spam.egg.and.spam.freshrpms.net Tue Feb 27 19:30:50 2007 From: thias at spam.spam.spam.spam.spam.spam.spam.egg.and.spam.freshrpms.net (Matthias Saou) Date: Tue, 27 Feb 2007 20:30:50 +0100 Subject: Release and update procedure for EPEL Message-ID: <20070227203050.096d8b69@python3.es.egwn.lan> FP! :-) Joke aside, I'd like to see which views we have on the release and update procedure to apply to EPEL. - 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. Matthias -- Clean custom Red Hat Linux rpm packages : http://freshrpms.net/ Fedora Core release 6 (Zod) - Linux kernel 2.6.19-1.2895.fc6 Load : 1.10 1.28 1.18 From rdieter at math.unl.edu Tue Feb 27 19:34:58 2007 From: rdieter at math.unl.edu (Rex Dieter) Date: Tue, 27 Feb 2007 13:34:58 -0600 Subject: Release and update procedure for EPEL In-Reply-To: <20070227203050.096d8b69@python3.es.egwn.lan> References: <20070227203050.096d8b69@python3.es.egwn.lan> Message-ID: <45E487E2.1090907@math.unl.edu> Matthias Saou wrote: > FP! :-) > > Joke aside, I'd like to see which views we have on the release and > update procedure to apply to EPEL. > > - Do we want a moving (and potentially breaking) set of packages which > is constantly being updated? > - Do we want a fixed set of packages when a RHEL release is made and > focus on major bugfixes and security updates from there on? While some folks certainly have an interest in the latter, I think it wiser to simply focus on the former, at least until we reach a critical mass of packages/maintainers. At that point, reconsideration would be reasonable. -- Rex From dennis at ausil.us Tue Feb 27 19:37:02 2007 From: dennis at ausil.us (Dennis Gilmore) Date: Tue, 27 Feb 2007 13:37:02 -0600 Subject: Release and update procedure for EPEL In-Reply-To: <20070227203050.096d8b69@python3.es.egwn.lan> References: <20070227203050.096d8b69@python3.es.egwn.lan> Message-ID: <200702271337.02795.dennis@ausil.us> On Tuesday 27 February 2007 01:30:50 pm Matthias Saou wrote: > FP! :-) > > Joke aside, I'd like to see which views we have on the release and > update procedure to apply to EPEL. > > - 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. > > Matthias I think somewhere in between. with the maintainer being responsible for making the decision. basically we want it to be as stable and consistent as possible but some times it just makes sense to update to a newer version. -- Dennis Gilmore, RHCE From notting at redhat.com Tue Feb 27 19:46:04 2007 From: notting at redhat.com (Bill Nottingham) Date: Tue, 27 Feb 2007 14:46:04 -0500 Subject: Release and update procedure for EPEL In-Reply-To: <20070227203050.096d8b69@python3.es.egwn.lan> References: <20070227203050.096d8b69@python3.es.egwn.lan> Message-ID: <20070227194604.GC3330@nostromo.devel.redhat.com> 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? Bill From fedora at leemhuis.info Wed Feb 28 06:43:11 2007 From: fedora at leemhuis.info (Thorsten Leemhuis) Date: Wed, 28 Feb 2007 07:43:11 +0100 Subject: Release and update procedure for EPEL In-Reply-To: <20070227203050.096d8b69@python3.es.egwn.lan> References: <20070227203050.096d8b69@python3.es.egwn.lan> Message-ID: <45E5247F.1000204@leemhuis.info> On 27.02.2007 20:30, Matthias Saou wrote: > > Joke aside, I'd like to see which views we have on the release and > update procedure to apply to EPEL. > > - 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? A mix afaics. Not that rolling like Extras was, but a bit rolling. In other words: We IMHO should have a two repos per release: - a testing repo, where new package and bigger updates enter and get tested for a while. They get moved to the proper repo with each RHEL update (say 4.4 -> 4.5) - a proper repo, that only gets updates for security reasons or to fix major bugs We should also make sure that we have a mostly constant look and feel to the outside. That's why I wrote this for the wiki: --- Is these packages a rolling release with "latest and greatest software" or a more "stable base and updates only when really needed"? That needs to be discussed. But it will probably be a mix -- for example, a kind of rolling release, but with a careful and strict update policy where parts are only updated for a good reason, or not at all. Updating to the latest and greatest version is not possible in most cases, as a lot of newer packages depend on new versions of certain core-libs (for example, gtk, qt, and many others), which are often not available once the supported distribution is 12 months or older. It also does not make sense to have a repo where some packages are always latest while most others and the distribution are on older versions. The nature of the distributions in question show the user choice. These users prefer a stable base -- that's why they are using an Enterprise-class distribution that only gets updates every ~18 months. So why should an add-on repository for an Enterprise-class distribution be different? --- CU thl