From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 24447 invoked from network); 21 Jul 2004 02:51:16 +0000 Received: from smtp.gentoo.org (156.56.111.197) by lists.gentoo.org with AES256-SHA encrypted SMTP; 21 Jul 2004 02:51:16 +0000 Received: from lists.gentoo.org ([156.56.111.196] helo=parrot.gentoo.org) by smtp.gentoo.org with esmtp (Exim 4.34) id 1Bn7CN-0003qv-39 for arch-gentoo-dev@lists.gentoo.org; Wed, 21 Jul 2004 02:51:15 +0000 Received: (qmail 19003 invoked by uid 89); 21 Jul 2004 02:51:14 +0000 Mailing-List: contact gentoo-dev-help@gentoo.org; run by ezmlm Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-Id: Gentoo Linux mail X-BeenThere: gentoo-dev@gentoo.org Received: (qmail 15689 invoked from network); 21 Jul 2004 02:51:14 +0000 Message-ID: <40FE121B.3040206@gentoo.org> Date: Wed, 21 Jul 2004 02:50:03 -0400 From: Daniel Ostrow User-Agent: Mozilla Thunderbird 0.6 (X11/20040517) X-Accept-Language: en-us, en MIME-Version: 1.0 To: gentoo-dev@lists.gentoo.org, dostrow@gentoo.org References: <20040720131405.GW18023@mail.lieber.org> <40FDCD20.6080302@scms.waikato.ac.nz> In-Reply-To: <40FDCD20.6080302@scms.waikato.ac.nz> X-Enigmail-Version: 0.83.6.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [gentoo-dev] Revisiting GLEP 19 X-Archives-Salt: a7821d1b-996a-4de1-a5de-756326b0c9cd X-Archives-Hash: d5744238727666644e46341b5558f8fa -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 All: Having been a Network Engineer (at 3 different companies) for most of my professional career so I feel relatively confident that I have a good picture of what is needed for GLEP 19 to work from the outside perspective, how it is implemented is another story. Most of the sys admins I have worked with belong to 2 schools, #1 is fix security issues only and #2 is fix security issues and bugs. Those who belong to school #1 generally fix bugs when and only when they directly affect the operation of the company and then it is a highly scheduled and highly localized event. Those belonging to school #2 usually have wider maintenance windows built into their environments so that they can achieve a more sweeping update. As such I believe that it is very important to delineate weather a package is being updated in the "stable tree" for security reasons or to fix a bug, and the changelog for the package should have detailed information regarding what the security vulnerability/bug is so that sys admins can pick and choose if need be. So sys admins also like to be able to do it in one motion so there would also have to be a way to "emerge security" and/or "emerge bugfix" the same way that we have a emerge world/system now. To that end in addition to having a tree that only gets security/bugfix updates (and yes this can mean whole new versions if an important bugfix is contained therein) we would need to expand on the stable keyword concept to allow for the separation of security and bug related updates. ~ This is all contingent on us adopting this methodology which I am by no means tied to, but I believe that any methodology needs to accommodate this functionality. As for retention, all 3 of the companies that I worked for did triannual updates on the core system of their servers so I think 3 years is a safe bet, where we are going to get the man power to support that is another question entirely. I'll probably think of more later, this is it for now. Thanks, Daniel Ostrow dotrow@gentoo.org Operational Lead Gentoo/macos -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFA/hIbsb0gXCN8LgURAv3wAJ9mPQT06H6uJEOdV76dQPN/D0cYywCeN4dZ iRnbtBzfQN4z8Q8uhzpWzLw= =mJtH -----END PGP SIGNATURE----- -- gentoo-dev@gentoo.org mailing list