Changes to our Git infrastructure

[Jan Kundrát]

Hi, here's my possibly incomplete wishlist of how I would like to work on 
SW within KDE.

- The tools should recognize that we have a limited number of people 
familiar with the code, while the pool of newcomers tends to be bigger. 
This means that we should teach these newcomers on how to eventually become 
project maintainers. Without swamping them with unintuitive trivia, of 
course.

- I want tight CI integration. If there's a missing semicolon in that new 
C++ code, I don't want to find it myself. A tool should tell the submitter 
about that as fast as possible, and show them what the error is.

- Stuff that breaks tests should not be allowed to even hit the target 
branch. Yes, this means that I would like to abolish the rule which says 
that any KDE developer (myself included) can commit straight to the tree of 
any project on the day-to-day basis. There should be an opt-out for 
projects to enforce CI coverage. I'm OK with self-approvals (we're too 
short on manpower), but I still want CI checks. I've introduced too many 
breakages already.

- Emergencies will happen, so I want all KDE devs being able to push an 
automated button to bypass the CI's verdict. (An realistically, any 
stricter ACL would not ever get approved.)

- Machine time is cheaper than people time. If some automation can save our 
time, we should use it IMHO. Don't know whom to Cc on a review request? Let 
the tool suggest people who have touched this area of file recently. Don't 
know project maintainers? No problem, they get an e-mail by default, with 
no user action.

- The tools should take care of all aspects of a particular change hitting 
the git tree. I'd like to be work on commits and git trees because that's 
what I'll end up managing. A patch review is not enough because it 
delegates some of the responsibilities to project maintainers. I want 
people submitting a git commit, not a patch. (A git commit consists of the 
diff, the commit message,  the parent(s) and additional metadata.) I would 
like to be able to review all of it.

- I want to be able to fix contributor's mistakes reasonably easy. If I can 
fix trivial typos, add BUG: keywords or rebase stuff right from the code 
review system webpage, that sounds good.

- While a change initially got started by someone, other should be able to 
help and fix anything about that change, including replacing the patch. A 
change doesn't "belong" to its author because we are a collaborative 
project.

- The tool(s) we use should have reaosnable APIs for building other tools 
around them.

- The review system should be self-contained. I do not want to ever ask 
people "this is a nice patch, where can I pull from".

I also agree with essentially all points which were raised by other people 
who commented on this thread with about a single exception -- "Upload 
patches via git diff + web" is not relevant for me, and I'm afraid it 
conflicts with my wishlist item of patch creators preparing git history 
trees for me.

Hope this helps,
Jan

-- 
Trojitá, a fast Qt IMAP e-mail client -- http://trojita.flaska.net/