Re: Package Priorites

On Fri, 11 Jul 2003 03:39:13 -0500
"Kevin Horn" <[email protected]> wrote:

> (I am posting this to the list in order that it doesn't get lost in
> the chaos that is my brain)
> 
> A random idea:
> 
> When it comes time for us to maintain a bunch of build scripts
> (ebuilds), might it be a good idea to assign each ebuild a 'priority'
> or a 'tier' (I just like that word...).  The 'priority' of a package
> indicates it's[relative importance|installed user base] thus
> determining how often it should be checked for updates, patches,
> security alerts, etc.  Also how quickly a patch/update needs to be
> integrated to meet with our QA spec.  So, you might have:
> 
> 1) Zynot 'core' packages (base-layout, gcc, glibc, kernel, etc.)
> 2) Server packages often used in production/enterprise environments
> (Apache,[send|s|Q|Exim]mail, POP IMAP etc.)
> 3) Client apps often used (Mozilla, OpenOffice, other office apps?
> etc.) 4) Stuff some people use...
> -- and so on --
> X) Stuff one guy at the south pole uses, and noone else has heard
> of...
> 
> Things in the higher tiers get priority over the things in the lower
> tiers.
> 
> Could also be used for defining QA process: things in higher tiers get
> reviewed more times...
> (BTW, in this case 'higher' means higher on the page, or closer to
> '1')
> 
> 
> The question is:
> would this idea be useful from a QA standpoint?  I think it _might_
> be, but I also know that others probably know better thanI do...
> 
> as usual, feedback appreciated and encouraged

I agree that some things need much more careful QA than others. A bad
glibc version causes a lot more grief than a bad web browser. However I
think you are mixing a few different requirements.

Core packages need a high degree of QA but do not necessarily need to be
updated to the latest and greatest quickly.

Packages mainly targeted for production server environments need a high
level of QA before going stable, but possibly not as much as core
packages before reaching testing.

Userland packages probably don't need the same level of QA, particularly
uncommon ones, but may want to track the latest greatest version much
faster.

As a general rule, Security fixes want to be handled as fast as
practical (without introducing more problems) even on packages where
otherwise we are not worried about tracking the latest & greatest very
quickly. For instance, a security fix for Apache you want to get out
ASAP but you will want to keep Apache3 (then they do it) in testing for
a long time.

In summary, there is a requirement for various levels of QA depending on
the risk involved.

There is a requirement for following the latest and greatest version
more closely on some packages than others.

There is always a requirement on getting security fixes out ASAP for all
packages.

The level of QA required and speed of response are not directly related,
but they do influence each other since QA activities do take a finite
time.

Well, that's my opinion, but I might change my mind in 30 seconds time
;-)
-- 
Mark Gordon
Paid to be a Geek & a Senior Software Developer
Although my email address says spamtrap, it is real and I read it.