[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

Re: A way out of the update trap

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 [1].

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[2] package
set, which should have some additional sanity checks / scrutiny applied
during updates, release testing, and so on.


[1] Completely Fucking Fucked. A common QA term that I just now made up.
[2] Not To Be Fucked With. More QA parlance that I just now made up.[3]
[3] Us QA guys have dirty mouths. Or, at least, I do.[4]
[4] 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.

Attachment: smime.p7s
Description: S/MIME cryptographic signature

[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]