| 1 |
On Fri, Dec 5, 2014 at 2:02 PM, Ulrich Mueller <ulm@g.o> wrote: |
| 2 |
>>>>>> On Fri, 5 Dec 2014, Andrew Savchenko wrote: |
| 3 |
> |
| 4 |
>> If GLEP doesn't reflect current best practices maybe this is a good |
| 5 |
>> time to supersede it with a new one? |
| 6 |
> |
| 7 |
> Not this again, please. :( The GLEP outlines the framework under which |
| 8 |
> QA operates, but there is no need to codify every detail in a GLEP |
| 9 |
> (which is somewhat hard to change). |
| 10 |
> |
| 11 |
> In fact, the QA team has its own internal policy document: |
| 12 |
> https://wiki.gentoo.org/wiki/Project:Quality_Assurance/Policies#Communication_When_Making_Fixes |
| 13 |
> If something should be missing there, we are certainly open for |
| 14 |
> additions or changes. |
| 15 |
> |
| 16 |
|
| 17 |
++ |
| 18 |
|
| 19 |
The GLEP should give QA reasonably wide discretion to act when it |
| 20 |
feels it is an emergency. It shouldn't spell out every detail of how |
| 21 |
they operate. View it like a "grant of authority" or "charter" in a |
| 22 |
company. |
| 23 |
|
| 24 |
QA should of course try to work with maintainers and communicate with |
| 25 |
them as quickly as it can under the circumstances. Not everything |
| 26 |
should be treated as an emergency. |
| 27 |
|
| 28 |
It sounds like the policy already is to communicate when making |
| 29 |
changes (either before or after the fact depending on severity). If |
| 30 |
it wasn't followed, well, let's try to follow it next time. As long |
| 31 |
as it isn't a regular thing I don't know that it has to go further |
| 32 |
than that (we have QA because all of us make mistakes, and I'm sure QA |
| 33 |
will make mistakes as well). If it is a regular thing by all means |
| 34 |
feel free to escalate it. |
| 35 |
|
| 36 |
-- |
| 37 |
Rich |
Archives