Hi all, I've gone over the comments everyone has made thus far and came up with the following community wishlist as it were. It represents a combination of what everyone has said, in a fairly distilled form.
Regrettably there were one or two items which conflicted. I sided with the option which kept the barrier to entry as low as possible as that seemed to be the greater consensus within the thread. - Code Reviews: - CLI client to make changes to the code review system and to manage the review (including retrieving the commits/patches) Client should have good documentation. - System should automatically set the CC / Reviewers / etc for a review rather than the submitter needing to know who to set. - Changes should be shown per-commit. - Updates to reviews should leave prior reviews intact. - Patches should be readable, commentable on line by line. - Proposed changes are vetted by the CI system (compilability, tests, etc). - Ability to accept the changes through the code review system - Can mark a review as Bad (Don't Ship This) / Okay (Fine with it going in) / Good (Ship It) - Can determine whether the review was by someone with commit rights. - Can produce a list of review requests given a certain set of criteria easily (preferrably savable) - Developers can tweak proposed changes easily before they are landed without the involvement of the submitter. - Post Commit Review: - Be able to comment on reviews, other than by replying to a mail on kde-commits - Project Management: - Coherent and Performant - One canonical place to get the desired information (no more duplication) - Can either be links to elsewhere or directly hosted by the system - Covers items like documentation (wiki, api), bug tracking, task boards, CI, code browsing and reviews, etc. - Repository Hosting: - Strong case has been made for retaining scratch repositories. - A weaker case exists for clone repositories - making them more nice to have than critical. - Anongit propagation should be within 1 minute. - Overall: Sensible email notifications - Overall: Capable web APIs for the system as a whole There are also a couple of items which come from sysadmin, to make things easier for us in the long run: - Supported well: Upstream should be stable with a viable future. We should also be able to build a relationship with one or more developers who authored/maintain the application. This is helpful in obtaining assistance should it be necessary and assists us in getting additions upstreamed. - Integrated: A single application which handles everything will always be able to offer a better and more coherent experience than several applications we have connected to each other. There is also a lower maintenance burden from an integrated application, as it is one piece of software to update - not 3 or 4. - Care about compatibility: Upstream should have an interest in stable interfaces, both externally facing (Web APIs) and internal (application plugins, etc) As the recent Dr Konqi problems have demonstrated, upstreams which act without regard for backwards compatibility can introduce significant problems for us. - Scalable: The applications which make up our infrastructure need to be able to handle the demands we place on them without consuming resources unnecessarily. Commentary on the above would be appreciated. As this is quite an extensive list of requirements, we won't be able to get everyone what they're after. We'll have to do things on a best effort basis - depending on what is available, what features are missing, etc. Unfortunately there is no perfect solution here - it just does not exist. Thanks, Ben