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