Changes to our Git infrastructure

[Christian Mollekopf]

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