| 1 |
-----BEGIN PGP SIGNED MESSAGE----- |
| 2 |
Hash: SHA1 |
| 3 |
|
| 4 |
All: |
| 5 |
|
| 6 |
Having been a Network Engineer (at 3 different companies) for most of my |
| 7 |
professional career so I feel relatively confident that I have a good |
| 8 |
picture of what is needed for GLEP 19 to work from the outside |
| 9 |
perspective, how it is implemented is another story. |
| 10 |
|
| 11 |
Most of the sys admins I have worked with belong to 2 schools, #1 is fix |
| 12 |
security issues only and #2 is fix security issues and bugs. Those who |
| 13 |
belong to school #1 generally fix bugs when and only when they directly |
| 14 |
affect the operation of the company and then it is a highly scheduled |
| 15 |
and highly localized event. Those belonging to school #2 usually have |
| 16 |
wider maintenance windows built into their environments so that they can |
| 17 |
achieve a more sweeping update. As such I believe that it is very |
| 18 |
important to delineate weather a package is being updated in the "stable |
| 19 |
tree" for security reasons or to fix a bug, and the changelog for the |
| 20 |
package should have detailed information regarding what the security |
| 21 |
vulnerability/bug is so that sys admins can pick and choose if need be. |
| 22 |
So sys admins also like to be able to do it in one motion so there would |
| 23 |
also have to be a way to "emerge security" and/or "emerge bugfix" the |
| 24 |
same way that we have a emerge world/system now. |
| 25 |
|
| 26 |
To that end in addition to having a tree that only gets security/bugfix |
| 27 |
updates (and yes this can mean whole new versions if an important bugfix |
| 28 |
is contained therein) we would need to expand on the stable keyword |
| 29 |
concept to allow for the separation of security and bug related updates. |
| 30 |
~ This is all contingent on us adopting this methodology which I am by no |
| 31 |
means tied to, but I believe that any methodology needs to accommodate |
| 32 |
this functionality. |
| 33 |
|
| 34 |
As for retention, all 3 of the companies that I worked for did triannual |
| 35 |
updates on the core system of their servers so I think 3 years is a safe |
| 36 |
bet, where we are going to get the man power to support that is another |
| 37 |
question entirely. |
| 38 |
|
| 39 |
I'll probably think of more later, this is it for now. |
| 40 |
|
| 41 |
Thanks, |
| 42 |
|
| 43 |
Daniel Ostrow |
| 44 |
dotrow@g.o |
| 45 |
Operational Lead |
| 46 |
Gentoo/macos |
| 47 |
-----BEGIN PGP SIGNATURE----- |
| 48 |
Version: GnuPG v1.2.4 (GNU/Linux) |
| 49 |
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org |
| 50 |
|
| 51 |
iD8DBQFA/hIbsb0gXCN8LgURAv3wAJ9mPQT06H6uJEOdV76dQPN/D0cYywCeN4dZ |
| 52 |
iRnbtBzfQN4z8Q8uhzpWzLw= |
| 53 |
=mJtH |
| 54 |
-----END PGP SIGNATURE----- |
| 55 |
|
| 56 |
-- |
| 57 |
gentoo-dev@g.o mailing list |
Archives