Hi all, Going to reply to all the various bits and pieces that have been mentioned in order now. Apologies for the long mail.
For deleting branches, I think we can allow this - given some protection for certain branches (like the KDE/* branches for instance). Note that courtesy of the backup functionality in our hooks, no branch or tag is ever truly deleted from a repository on git.kde.org. I don't know how easy it would be to alter this behaviour based on the account name of the developer. In terms of tools: for both clear messaging, and to minimize maintenance effort we need to have just a single tool. It isn't just the tool itself which has to be maintained: we have commit hooks, integration with other bits of infrastructure and so forth which also needs to both be implemented and maintained. The more custom work we have, the harder it is to upgrade things. We'll confuse newcomers if projects A, B and C are reviewed on tool X while projects D, E and F are reviewed on tool Y. A single tool would be best here. Let me make clear that it is not a case of Reviewboard vs. Gerrit here - as other options need to be evaluated too. In regards to the difficulty of Gerrit - I tend to agree with this argument (it took me at least a minute to find the comment button, and I didn't even get to reviewing a diff). Plus there are major concerns with integration into our infrastructure, such as pulling SSH keys from LDAP for instance (no, you can't have the tool maintain them itself - as mainline Git and Subversion need the keys too). In terms of Reviewboard statistics - I don't have those to hand. Someone would need to come up with some scripts which could be run against the web server logs to generate some numbers here. We do have the logs though. Please note that any discussion of tools should be on the merits of the tools themselves. Things like CI integration are addons, which both Reviewboard and Gerrit are capable of. The only reason we don't have Reviewboard integration yet is a combination of technical issues (lack of SNI support in Java 6) and resource ones (some projects take a long time to complete, and i'm concerned we don't have the processing power). In terms of a modern and consistent project tool - I agree here. A long term todo item of sysadmin is to replace projects.kde.org. The question is of course - with what. Chiliproject is now unmaintained, so we do have to migrate off to another solution at some point. If the new tool happens to be more integrated in terms of code review, that is a bonus from my point of view (as it means the integration will be better, and there is one less piece of infrastructure to maintain). Thanks to Luca, we have a list of possible options to review. Contact has already been made previously with the Gogs developers, so it is possible they would be amenable to making changes necessary to support what we need. Phabricator is also interesting, although we may have to overcome some barriers with callsigns due to the sheer number of repositories we have. It's code review tool is similar to Reviewboard, but it has a much more sophisticated CLI client you can use. If anyone has any other possible solutions, I would like to hear about them as well. @Jan: could you please outline what you consider to be the key advantages? At the moment I understand that you are after: 1) CI integration to pre-validate the change before it gets reviewed 2) Ability to directly "git pull" the patch (which Phabricator's arc tool would meet I believe?) Thanks, Ben
