Re: bad committers
On 10/29/07, Eddy Petrișor <eddy.petrisor@gmail.com> wrote:
> Gerfried Fuchs wrote:
> > * Jon Dowland <lists@alcopop.org> [2007-10-27 18:43:05 CEST]:
> >> I've removed the prboom.xpm icon that was added to prboom
> >> trunk. It is clearly derived from the cacodemon sprite in
> >> doom.wad / doom2.wad which are copyright ID Software, all
> >> rights reserved. I suppose a freedoom sprite could be used
> >> to derive an icon, not sure how good that would look.
> >
> > As this was yet another short sighted commit done by Kmos, can I
> > *please* get /any/ reaction on how the team plans to go on with such
> > cases? I've seen after the thread that I started yet another person
> > added - and I hope that there had been checks done on that person and
> > not the former habit of blindly accepting people just when they ask
> > continued.
>
> I totally agree with you. I set a personal goal to be really harsh releated to
> problematic changes for which a reply to my comments is not send in due time.
<...>
> BTW, I have read a little about ACL implementation in SVN and it can be
> implemented, but is a little bit tricky. If anybody is interested to talka bout
> this/experiment, please contact me in private. If not, I will try to find some
> time for the experiments (but I fear that this is a technical solution to a
> social problem, as Rhonda suggested on IRC).
As a team participant (relatively inactive) who doesn't come from
Debian, I'm a little hesitant to take a strong stance about pruning,
but I would suggest that it may make more sense to remove members who
consistently make inadvisable commits than to implement ACLs. If
there is someone trusted by team members who wants to fix bugs in
another package, and can do so well, this seems to reduce work (and
asking for ACL access is an impediment). If there is someone not
trusted by team members who is making changes that need to be
reverted, this seems to increase work (and ACL limitations require the
creation of ACLs, maintenance of ACLs, for extra work for those
packages, and don't help the situation for other packages).
As an applicant, I was surprised by the low level of checking
required before being given SVN access. I would have expected at
least minimal review of candidate patches, and evidence of previous
good work, presented as patches in the BTS. Further, as an applicant
from another community, I would have expected some check to see how I
was received in that community prior to being granted access.
--
Emmet HIKORY
Reply to: