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) > > As Lance said in an earlier post, infra already does this "temporary > removal of access" if it is an immediate security threat and then > submits the evidence to devrel for followup. Why can't it work exactly > the same for the QA team? If they have done their due diligence by > contacting the dev in question, pointing out their mistakes and offering > assistance to correct the mistakes and the dev just keeps right on > commiting bad stuff QA should be able to "temporarily" stop them until > devrel has a chance to follow up and investigate. That's what QA is, > Quality Assurance, if they have no power to actually "Assure Quality" > then why does this team even exist? > QA and devrel have two different jobs. QA doesn't have to be devrel's problem and devrel tasks don't have to be QA's problem (how much do the QA folks really want to deal with the usual bitchfest when somebody with a lot of friends gets suspended for something?) if they work together on repeated problem developers. > I'll give an example: Saturn car company has a great big red "STOP" > button at every point in the assembly line that can turn off the entire > manufacturing line if QA spots a mistake. The QA team does not have to > ask anyone first, they simply push the button so the low quality car > does not get through, remove the offending car from the line > "temporarily" until a team investigates and decides if the quality is > good enough to put it back on the assembly line. Saturn is known for the > quality of it's cars because of this. The gentoo QA team should have > this same ability. > Does Saturn's stop button also kick the apparently responsible individual out of the building? Otherwise this analogy would work better if applied to ebuilds and the maintainership thereof, not developers and their CVS access. (And on another note, Saturn? Known for quality? Bwahahahah... err. :) ) -- Jon Portnoy avenj/irc.freenode.net -- gentoo-dev@gentoo.org mailing list
