Changes to our Git infrastructure
mail at milianw.de
Tue Dec 23 12:21:37 GMT 2014
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
> 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
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.
mail at milianw.de
More information about the kde-core-devel