On 13.09.2014 17:49, Martin Gräßlin wrote:
my understanding was that it's still possible to bypass the code review, so I cannot see that it's against the KDE Manifesto as it's only a kind of social contract. Or am I missing something. Personally I like the idea of having the +2 limited to the devs familiar with the code.
I *strongly* disagree with and even object to this. One of the biggest achievements of the KDE community is having become multi-generational and turnover-proof, whereas most pro- jects peter out when their initial developer generation moves on. Note how few people in this thread were around in 1998. I attribute this to a few traits of our structure: * Flat hierarchies and few, mostly informally held titles. * Broad, equal write access. * Encouraging people to feel responsible for what we make. These things reinforce each other in multiple ways. If main- tainers are not entrenched positions, they're easy to replace when they move on (whether they can accept this themselves or not). Once you codify them in ACLs (and yes, we do this in some places already, and I think this was a mistake as well) you add inertia because those ACLs need to be updated, and someone needs to work up the gumption to ask for that update. (Case study of what can happen when we lose track of this: We lost KDM. There are many more positive case studies where contributors kept projects alive once maintainers disappeared just by slowly ramping up their involvement, without needing "hand over the keys" flag days.) If maintainers aren't entrenched, you also can't rely on them picking up the slack; hence encouraging stepping up. How do you become a maintainer? By actively doing review, for one. I.e. it's up to *maintainers* to stay active and involve themselves in the process, and provide guidance so that good code goes in and bad code stays out. The safety net we have for review working is our brains when making or picking through arguments. The argument "but you can still bypass Gerrit and push directly, this is just social etiquette" doesn't matter because the whole thing is about social etiquette. The ACLs we already have reflect our social etiquette, and that means we need to be careful and think smart about evolving it. Personally I think social etiquette encouraging the use of review tools is fine. Social etiquette that entrenches some developers as special on those review tools is not. Cheers, Eike