On Tuesday 23 December 2014 13.21:37 Milian Wolff wrote: > On Wednesday 24 December 2014 00:20:18 Ben Cooksley wrote: > > Hi all, > > > > As has been made evident in the prior thread there are quite a few > > interesting ideas floating around about what our Git infrastructure > > should be capable of. > > > > Our current one was constructed when KDE first seriously migrated to > > Git following the Gitorious experiments, and it shows. (As a sysadmin > > I can attest that parts of it are held together by digital glue and > > tape). > > > > Before we go ahead and jump to a new platform though - we need to know > > what we want. > > Can everyone please suggest what they think are the things they'd like > > to see feature wise? > > > > In doing so, please refrain from mentioning any existing solutions - > > all we want to do at this point is construct a wishlist of what people > > would like to see the system be capable of. > > > > Items that we (sysadmin) would like to see community comment on > > include the code review system, clone and scratch repositories and how > > they function, and whether people would be bothered by repository > > locations changing as they move around. Also useful would be comment > > on how anongit and other systems that rely on the Git infastructure > > work. > > Here's a list of things that I'd like to have for my workflow, which is > basically two folded: On one hand, I actively develop new software and new > features. On the other hand, I spent a considerable amount of KDE time > reviewing other peoples work. > > ## The Developer > > For productivity, I'd love to have the ability to push changes directly from > the command line to somewhere others can then review the code. This should > support both, individual commits as well as feature branches. I.e. when > pushing a merge request for review, I still want others to see individual > commits. Updating such reviews should be trivial and keeps the review > history intact. I can just continue hacking and push new changes as they > come without influencing the previous patches sent for review. > > Optimally, I'm never forced to go to a website to manipulate the review. > I.e. to add reviewers, or select branches or other metadata. Nor do I want > to be forced to manually "publish" a review, I just pushed it for review > after all. > > ## The Reviewer > > Here, my biggest wish reflects that of the developer: I want to be able to > see the developers intent, i.e. individual commits that make up one bigger > mergeable hunk. I want to comment directly on lines of code in the patch. > The patch should be displayed as easily readable as possible, with syntax > highlighting and side-by-side diff view. As much as possible should be > shown on a single page, I do not want to be forced to navigate between > different files or the like, I need to see the big picture. > > Optimally, I could apply hotfixes, such as whitespace changes, directly when > doing the review. Finally, once the review is good to go, I want to click a > button (or better: hotkey) to merge the patch into the upstream branch. > > Furthermore, I'd like to use the same review mechanism for post-review. When > a patch is triggering problems, I'd like to start a discussion in the > context of the commit that was merged. Again, I want to annotate source > lines. So rather than sending mails to kde-commits which are then lost, I > want to have that tracked on a website for others to see. >
Excellent summary, I fully agree. Cheers, Christian
