| 1 |
Jon Portnoy wrote: |
| 2 |
> On Wed, Sep 14, 2005 at 12:06:13AM -0400, Curtis Napier wrote: |
| 3 |
> |
| 4 |
>>I'm not an ebuild dev so I may not know enough about this situation to |
| 5 |
>>competantly comment on it but it seems to me that QA should have some |
| 6 |
>>sort of limited ability to "temporarily" take away write access to the |
| 7 |
>>tree until devrel has a chance to look over the evidence and come to a |
| 8 |
>>decision. This would fix the problem of "devrel takes to long" plus it |
| 9 |
>>would really help to ensure higher quality work is submitted (because |
| 10 |
>>ebuild devs WILL stop purposely commiting bad work if they know a QA |
| 11 |
>>team member can take away their write access at a moments notice for |
| 12 |
>>repeated violations). |
| 13 |
> |
| 14 |
> |
| 15 |
> The other thing that'd fix the 'devrel takes so long' problem would be |
| 16 |
> if people would let devrel fix its resolution policies 8) (see recent |
| 17 |
> -devrel ml thread) |
| 18 |
> |
| 19 |
|
| 20 |
It's not about devrel taking a long time. Please don't think that I was |
| 21 |
bashing devrel in any way, in fact I have great respect for the devrel |
| 22 |
members. I know what a thankless task they have taken on and the |
| 23 |
bullshit they have to put up with on an almost daily basis. Kudos to you. |
| 24 |
|
| 25 |
|
| 26 |
|
| 27 |
We all know that devrel is a team of people that have a responsibility |
| 28 |
to investigate any claim of wrongdoing and ensure that both sides are |
| 29 |
able to make their case. Afterwards, the devrel team members have to |
| 30 |
discuss the evidence and reach a conclusion. All of this takes time no |
| 31 |
matter how streamlined the process is and in the meantime the offending |
| 32 |
dev is allowed to continue to pollute the tree unchecked. |
| 33 |
|
| 34 |
If QA is able to "temporarily" fix the perceived problem by removing |
| 35 |
ONLY write access to the portage CVS tree until devrel is able to finish |
| 36 |
their process, overall quality will go up. Even if it is found that no |
| 37 |
QA violations were made in some cases, I would rather have a few devs |
| 38 |
"temporarily" lose their write priveledges until devrel can pass/fail |
| 39 |
them than let even one bad dev through. |
| 40 |
|
| 41 |
Personally, I think any dev that is made a member of the QA team is made |
| 42 |
a member because the rest of the devs trust that the person knows enough |
| 43 |
about Gentoo and the way it works to actually spot quality issues. I |
| 44 |
would trust these QA devs with this "temporary" ability wholeheartedly |
| 45 |
because if any of them abuse it they will be caught and removed from the |
| 46 |
QA team and they all know it. Plus, I think the people who are currently |
| 47 |
(or used to be) members of QA are respected enough for their technical |
| 48 |
knowledge that no one should have a problem with this *unless* they are |
| 49 |
one of the devs whos quality levels are in question. (personality issues |
| 50 |
are a different subject and have nothing to do with this discussion - |
| 51 |
this is a 100% technical correctness issue) |
| 52 |
|
| 53 |
I have seen numerous debates on this list and on -core where almost |
| 54 |
every dev agrees that *something* must be done to ensure that all of the |
| 55 |
QA mistakes in the past are not repeated. All of the proposed plans |
| 56 |
relied on peer-review or other means that would greatly increase the |
| 57 |
number of devs we would need to implement it. In this case we already |
| 58 |
have the QA team in place and simply giving them this one ability would |
| 59 |
go greatly towards solving the inherent problems in the system. No new |
| 60 |
devs required and no new teams to create. A perfect solution to an |
| 61 |
endless problem. |
| 62 |
|
| 63 |
Gentoo can't afford to peer review every single line of code but this |
| 64 |
small thing would greatly help in catching the largest of the mistakes |
| 65 |
that are made. |
| 66 |
-- |
| 67 |
gentoo-dev@g.o mailing list |
Archives