| 1 |
On Tue, Jan 21, 2014 at 10:47:50AM -0500, Rich Freeman wrote: |
| 2 |
> If Comrel really objects to this I'm not entirely opposed to letting |
| 3 |
> QA have the reins (certainly we can't just let policy go unenforced |
| 4 |
> entirely). However, I would encourage the teams to give some thought |
| 5 |
> as to whether it makes sense to work together to separate the human vs |
| 6 |
> technical factors here. |
| 7 |
|
| 8 |
Well, I guess that's the big question isn't it -- what is personal vs |
| 9 |
technical? |
| 10 |
|
| 11 |
I think we can all agree that if qa changes an ebuild and a dev comes back |
| 12 |
with "You stupid *** leave my *** ebuild alone." and reverts qa's |
| 13 |
change, that is personal and goes straight to Comrel because it is now a |
| 14 |
CoC violation as well. |
| 15 |
|
| 16 |
What about the scenario where qa makes a change, then the dev, in a |
| 17 |
civil manor, explains to qa why he prefers his original method and |
| 18 |
reverts QA's change without the agreement of QA and without presenting |
| 19 |
his case to the council? Now you have another qa violation since GLEP |
| 20 |
48 states that QA's changes must stand until the council says otherwise. |
| 21 |
However, assuming the exchanges between qa and the dev are still |
| 22 |
respectful, I'm not sure there is a personal issue. |
| 23 |
|
| 24 |
wrt the commit rights issue: QA is asking for the ability to *suspend* |
| 25 |
not *revoke* commit rights. This was explained well by Tom; it is a |
| 26 |
temporary measure to get a dev's attention if nothing else works. |
| 27 |
|
| 28 |
I agree that it is strong. However, if qa gets out of hand with it, |
| 29 |
the council can always step in and take care of the matter. |
| 30 |
|
| 31 |
Thoughts? |
| 32 |
|
| 33 |
William |
Archives