| 1 |
-----BEGIN PGP SIGNED MESSAGE----- |
| 2 |
Hash: SHA1 |
| 3 |
|
| 4 |
On 01/31/2014 09:07 AM, Peter Stuge wrote: |
| 5 |
> Alec Warner wrote: |
| 6 |
>>> hmm? |
| 7 |
>> |
| 8 |
>> To be fair, I had a long discussion with this regarding when QA |
| 9 |
>> has the authority to temporarily ban a developer. |
| 10 |
> |
| 11 |
> Cool. |
| 12 |
> |
| 13 |
> |
| 14 |
>> In the case where policy is missing, QA does not have a clear |
| 15 |
>> case of authority there. It becomes a more murky area. I've tried |
| 16 |
>> to very much encourage QA to both publish the policies they want |
| 17 |
>> to enforce, and automate enforcement with better tooling (repoman |
| 18 |
>> or otherwise). Being transparent and consistent in enforcement |
| 19 |
>> of policy goes a long way for getting developers on your side. |
| 20 |
> |
| 21 |
> Absolutely. |
| 22 |
> |
| 23 |
> |
| 24 |
>> So in short, while one could read that passage as you did, I |
| 25 |
>> don't think that is their intention. |
| 26 |
> |
| 27 |
> To be clear, I don't think so either. |
| 28 |
> |
| 29 |
> |
| 30 |
> Rich Freeman wrote: |
| 31 |
>> I was really happy to see a public notice of meeting and a |
| 32 |
>> published summary. |
| 33 |
> |
| 34 |
> Yes, me too! |
| 35 |
> |
| 36 |
> |
| 37 |
> I still think it seems like QA could essentially introduce |
| 38 |
> arbitrary new policies and 2 weeks later be expected to effect |
| 39 |
> them. |
| 40 |
> |
| 41 |
> Fine when everyone agrees. Not so much at other times. The |
| 42 |
> responsibility is with QA to build support among the developers, |
| 43 |
> and I agree that the transparency goes a long way! |
| 44 |
> |
| 45 |
> |
| 46 |
> //Peter |
| 47 |
> |
| 48 |
|
| 49 |
Regarding the question in your first email: We will not create a |
| 50 |
policy then immeiately use the policy as justification to to go edit |
| 51 |
packages. The intention of the "we may ask the developer to stop" line |
| 52 |
is for cases where we suspect that what the developer is doing is |
| 53 |
causing a problem and would like to discuss it further. I feel that |
| 54 |
that is well within the bounds of GLEP 48. As for the "when/how we |
| 55 |
make and communicate fixes," I think that just about any policy we |
| 56 |
make will fall into the middle ground you omitted of "file a bug, wait |
| 57 |
2 weeks, fix." So no, we will not be making arbitrary fixes just |
| 58 |
because we can. |
| 59 |
|
| 60 |
Regarding your concern about us introducing arbitrary policies: again, |
| 61 |
most will fall into the "file a bug" middle ground. We also are |
| 62 |
perfectly aware that you can't expect people to change overnight, and |
| 63 |
we will not be shouting at devs just because they didn't implement |
| 64 |
$(new-policy) right away. We will file bugs asking for changes, and we |
| 65 |
will try to offer suggestions or patches wherever possible to make it |
| 66 |
easier for maintainers. |
| 67 |
|
| 68 |
Chris Reffett |
| 69 |
Gentoo QA Lead |
| 70 |
-----BEGIN PGP SIGNATURE----- |
| 71 |
Version: GnuPG v2.0.22 (GNU/Linux) |
| 72 |
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ |
| 73 |
|
| 74 |
iKYEARECAGYFAlLrv0hfFIAAAAAALgAoaXNzdWVyLWZwckBub3RhdGlvbnMub3Bl |
| 75 |
bnBncC5maWZ0aGhvcnNlbWFuLm5ldEM2NzU5RjUyMDczREJDQkVDQTBDRkE1NERC |
| 76 |
Nzk1QThBNDI2MTgzNTQACgkQ23laikJhg1QZ+wCeJre5n44E9BdZcUBgZdC5DjPe |
| 77 |
WR8AoJ1W9QuqVIFXxsVAWBO23yx+etak |
| 78 |
=5CIT |
| 79 |
-----END PGP SIGNATURE----- |
Archives