| 1 |
On Wed, 2004-07-21 at 02:50, Daniel Ostrow wrote: |
| 2 |
> Most of the sys admins I have worked with belong to 2 schools, #1 is fix |
| 3 |
> security issues only and #2 is fix security issues and bugs. Those who |
| 4 |
> belong to school #1 generally fix bugs when and only when they directly |
| 5 |
> affect the operation of the company and then it is a highly scheduled |
| 6 |
> and highly localized event. Those belonging to school #2 usually have |
| 7 |
> wider maintenance windows built into their environments so that they can |
| 8 |
> achieve a more sweeping update. As such I believe that it is very |
| 9 |
> important to delineate weather a package is being updated in the "stable |
| 10 |
> tree" for security reasons or to fix a bug, and the changelog for the |
| 11 |
> package should have detailed information regarding what the security |
| 12 |
> vulnerability/bug is so that sys admins can pick and choose if need be. |
| 13 |
> So sys admins also like to be able to do it in one motion so there would |
| 14 |
> also have to be a way to "emerge security" and/or "emerge bugfix" the |
| 15 |
> same way that we have a emerge world/system now. |
| 16 |
|
| 17 |
My proposal could work with either camp. I really don't care either |
| 18 |
way, as I simply think we need something implemented "soon" to start the |
| 19 |
ball rolling and see what happens. Better to try and fail than to never |
| 20 |
try at all and all that jazz.... |
| 21 |
|
| 22 |
We would use emerge world to do the same as an emerge security, since |
| 23 |
only security fixes would be added...... or..... We would use emerge |
| 24 |
world to update everything, and emerge glsa to do only security fixes. |
| 25 |
|
| 26 |
-- |
| 27 |
Chris Gianelloni |
| 28 |
Release Engineering QA Manager/Games Developer |
| 29 |
Gentoo Linux |
| 30 |
|
| 31 |
Is your power animal a penguin? |
Archives