On 12/11/2009 4:52 PM, Chani wrote: >> I'm talking about technical capabilities. Policy is something else >> entirely. It's nice that webkit does things <whatever way it does it> >> but that doesn't mean anything to us. > > so... you two are debating whether everyone in kde-developers should have > permission to update/merge a project's merge requests? > > hmm.
No. I'm claiming that reviewers should also have commit access because there's not much point to reviewing patches if you can't apply it. (So your reviewers for a particular repo, which will probably be those familiar with particular code, are a superset of +kde-developers). Personally, I'm not really afraid of random kde devs coming along and doing something silly like closing merge requests when they shouldn't -- if someone is behaving badly, just take away their privs and be done with it. I think as long as we can separate who gets all the merge request emails from who has review capability (so everyone isn't driven bananas), +kde-developers should have the ability to handle merge requests for all KDE repos. This way, if a module's maintainers falls off the face of the earth, someone else can easily work on merging in needed patches. What I gather from Ossi's claims is that Webkit is a pretty untrusting community where they trust people to fix typos and commit those fixes themselves but you'll be kicked out if you apply that same typo fix that someone sent in as a merge request and you're not one of the official reviewers. Yuck. I'm not sure of the relevancy of Ossi's arguments, but I think I summed up the technical needs that are important to us well enough here: http://mail.kde.org/pipermail/kde-scm-interest/2009-December/000871.html --Jeff
signature.asc
Description: OpenPGP digital signature
_______________________________________________ Kde-scm-interest mailing list Kde-scm-interest@kde.org https://mail.kde.org/mailman/listinfo/kde-scm-interest
