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/
