Am 19.09.2017 um 16:22 schrieb Arun Isaac: > Just thinking out loud: Maybe, we need more people with commit > access. Theoretically, anyone can review a patch, but ultimately it is > people with commit access who will have to finally apply and push the > patch. As the rate of submission of patches grows, this increases the > work load on those with commit access.
It is not only the work load, but also the work-flow which makes it hard for occasional reviewers and committers. The mail-interface might be great for those who are used to it, but it requires one to subscribe to the patch-mainling-list, keep an eye on review, download the patch, lint the patch, reply to the mail. If the patch is okay, I need to pull--rebase on the current master, push, write a mail for closing the bug-entry. This means switching forth and back between mail, shell, and browser. These are far too much manual steps. An if I only have little time, patches are piling up. The mailbox get cluttered by patches I do not follow. This woes! And this is why I'm not regularly reviewing patches. Compare it with an integrated workflow on e.g. Gitlab or github: The list of patches to review is always up to date, same for the state and comments. Using CI (gitlabs integrated pipeline are great!) saves me a lot of work, e.g. linting. If the patch is okay, it is a single click (okay, maybe 5 clicks) to rebase i on top of master. The patch is closed automatically, the submitter is notified, bookkeeping (referencing to the commit) is done. We already discussed using e.g. goks last year with no result. Maybe it's time to restart the approach. -- Regards Hartmut Goebel | Hartmut Goebel | h.goe...@crazy-compilers.com | | www.crazy-compilers.com | compilers which you thought are impossible |
