On Thu, Jan 30, 2014 at 9:48 PM, Peter Stuge <pe...@stuge.se> wrote: > Chris Reffett wrote: > > - -The QA team policymaking workflow will look like the following: > .. > > If we think a developer's actions are causing problems, we may ask > > them to stop/undo pending discussion by the QA team at the next meeting. > > plus > > > - -Rules for the QA team editing peoples' packages: > .. > > *For trivial fixes, such as repoman errors, we fix the issue and send > > the developer a friendly reminder > > *For large but non-critical fixes, we open a bug, wait 2 weeks, and if > > it is not fixed within that time frame we make the change. > > sounds to me like QA is giving itself carte blanche to make any "fix" > they want as per "we think a developer's actions are causing problems" > hmm? >
To be fair, I had a long discussion with this regarding when QA has the authority to temporarily ban a developer. This discussion came about because on occasion, a developer and the QA team will have a disagreement regarding a package, and QA will attempt to assert their authority. My interpretation is that the authority of the QA team nominally comes from the idea that we want a certain level of quality in the tree, and that we have policies in place to facilitate that quality level. So in a case where a developer is clearly violating an existing documented policy, then QA does have the authority to modify their package after a short discussion about it. In the case where policy is missing, QA does not have a clear case of authority there. It becomes a more murky area. I've tried to very much encourage QA to both publish the policies they want to enforce, and automate enforcement with better tooling (repoman or otherwise). Being transparent and consistent in enforcement of policy goes a long way for getting developers on your side. So in short, while one could read that passage as you did, I don't think that is their intention. When developers 'cause problems' it should be obvious to everyone how and why that is, and not simply obvious to say...the QA lead. -A > > > //Peter > >
