Package Priorites
"Kevin Horn" <[email protected]> Fri, 11 Jul 2003 03:39:13 -0500
| Newsgroups | gmane.linux.zynot.devel |
|---|---|
| Message-ID | <005301c34787$e89dab30$0301a8c0@maxilius> |
(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 Kevin Horn