On Sun, 2008-12-14 at 12:00 -0600, Jerry Amundson wrote: > On Fri, Dec 12, 2008 at 2:40 PM, Jeff Spaleta <jspaleta gmail com> wrote: > > On Fri, Dec 12, 2008 at 10:59 AM, Patrice Dumas <pertusus free fr> wrote: > >> I'd propose, more largely @code, @base and dependencies. > > > > I think that's too broad a target to start with and you don't have the > > QA resourses in place to support a policy that broad. Definitely too large.. but not by a lot. > > Right now. I am asking us as a project to suck it up and identify a > > top functionality priority and to live within our means as it comes to > > existing QA expectations. The informal Critical Path for current QA testing is: yum and its deps. No matter how bad *other* things are broken, as long as yum works you can 'yum update' and download fixes. But if yum breaks, you have a Severity CFF issue . Note that by "yum and its deps" I don't mean the actual "Requires:" on the 'yum' package, I mean "everything required to have yum run properly". So this includes stuff like - duh - networking. So, throw in NetworkManager and its deps. Like it or not, NetworkManager is the default network management system, and if it doesn't work, we are once again registering Severity CFF issues. Since this discussion is about defining a *formal* critical path, I propose the following: Bootloader: grub (yaboot on ppc), kernel, and all dependent packages. Networking: NetworkManager and all dependent packages. Update system: yum and all dependent packages. I *believe* that would pull in everything Patrice mentioned earlier (e.g. kernel requires initscripts, mkinitrd, module-init-tools, etc. mkinitrd requires lvm, e2fsprogs, bash, coreutils, etc.) and all those things that are completely vital that sometimes we don't think about (dbus, cough cough cough). This will define our Tier-1 / Core / Critical Path / NTBFW package set, which should have some additional sanity checks / scrutiny applied during updates, release testing, and so on. -w  Completely Fucking Fucked. A common QA term that I just now made up.  Not To Be Fucked With. More QA parlance that I just now made up.  Us QA guys have dirty mouths. Or, at least, I do.  Oh come on. Show me a QA engineer who has *not* shouted curses so vile as to cause scarring and/or spontaneous combustion in lab animals, and I will show you a ticking time bomb of rage. Or a mute. Or someone who is no fun at parties.
Description: S/MIME cryptographic signature