On Tue, Oct 15, 2019 at 08:58:14PM +0200, Han-Wen Nienhuys wrote: > On Tue, Oct 15, 2019 at 6:07 PM Greg KH wrote: > > When you are reviewing thousands of patches a year, time matters. > > Gerrit just does not cut it at all. Remember, we only accept 1/3 of the > > patches sent to us. We are accepting 9 patches an hour, 24 hours a day. > > That means we reject 18 patches an hour at that same time. > I'm curious how you come to this number. When I look at Linus' tree. > git show --no-merges > 43b815c6a8e7dbccb5b8bd9c4b099c24bc22d135..8e0d0ad206f08506c893326ca7c9c3d9cc042cef > | grep ^Date | wc > This range is two recent merge commits by Linus about 232 hours apart. > During that window, 386 non-merge change were merged, ie. about 1.6 > commit/hour. The overwhelming majority of commits are merged into Linus' tree during the two week merge window after each release, at other times only bug fix commits get merged so the volume is way down. Between v5.2 (July 7th) and v5.3 (September 15th) there were 14605 commits, which comes out at about Greg's number of 9 per hour. > > Like Daniel said, the kernel is multi-repos for a mono-tree. I don't > > think Gerrit is set up to handle that at all from what I can see. > What problem is solved by having multiple copies of the same tree? A lot of what it gives is comprehensibility - people being able to see what's going on in all the different branches in a given area of the kernel. You could use namespaced branches to do this but the UIs for that aren't nearly so good and all this workflow predates even git, this was all very idiomatic for bitkeeper. > The normal Gerrit approach would be to have one server, with one Linux > repository, with multiple branches. Gerrit has per-branch permissions, > so you can define custom permissions (eg. merge, vote, read, amend > other people's changes) for different branches. Using branches in this > way would allow you to retarget a change to another branch without > losing the review history, or cherry-picking a change to another > branch from within the UI. Permissions are all socially enforced for the kernel, there's no technical restrictions since there's admin overhead for that and at times it makes sense to do things differently.