lilypond-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: GOP-PROP 13: patch management tools


From: Reinhold Kainhofer
Subject: Re: GOP-PROP 13: patch management tools
Date: Tue, 20 Sep 2011 02:08:42 +0200
User-agent: KMail/1.13.6 (Linux/2.6.38-11-generic; KDE/4.7.0; i686; ; )

Am Tuesday, 20. September 2011, 01:09:20 schrieb Graham Percival:
> ** Different patch and issue managment tools

I have only looked at a few code review tools...

>     * http://code.google.com/p/gerrit/: appears to be a fork of
>       Rietveld. Not certain about hosting.

While gerrit is tailored for git, it is really limited to git. E.g. 
-) You can only upload whole commits and each commit will have one separate 
review. With rietveld we can have a review for the diff of several commits 
combined, with gerrit you will have one review per commit.
-) To submit a review, you have to push to a really strange gerrit branch on 
the server, so you have to know quite a lot about git, or accept some strange 
syntax... Definitely not something we want to require from newcomers or non-
coders.

>     * http://www.reviewboard.org/: offers hosting.

The problem is that there is no simple tool to create a review. There are some 
python  scripts, but they need separate installation (as administrator) using 
some custom python installation framework, and there is no tool like git-cl to 
store the issue within the branch.

>     * 30-120 minutes: modify git-cl to automatically add a
>       Patch-new issue whenever there’s an upload. If the issue
>       description contains "issue 1234" or "fix 1234", it adds the
>       rietveld url to the appropriate issue instead. I’ve already
>       forked the git-cl repo and started work on this on
>       https://github.com/gperciva/git-cl

BTW, we can also install a post-commit hook on the git server that closes an 
issue if the commit message contains something like "Fixes #xxxx" or so. KDE 
uses keywords:
BUG: ...     (closes the given bug(s))
CCBUG: ...   (adds the commit msg as a comment to the bug(s))
CCMAIL: ...  
etc.

>     * 1-3 hours: write a script that checks that every Patch-new
>       can apply to master, compiles correctly, and creates a
>       regtest comparison so the local human can check it and make
>       it Patch-review instead. If there’s a problem before the
>       regtest comparison, the script automatically changes it to
>       Patch-needs_work.

The problem is that if someone pushes a broken commit, it will cause all 
patches to Patch-needs_work, even if the patch is not to blame...

>     * 1-5 hours: automatically switch any Patch-review to
>       Patch-needs_work if there are any non-LGTM comments.

If one of my comments does not contain "LGTM", that does NOT mean that I have 
objections. Rather, I might be giving some input and ideas, or have a 
question, but I just don't feel qualified enough to give the go. If I object 
to a patch, I clearly state it. Absense of LGTM does definitely NOT mean my 
objection.

Cheers,
Reinhold
-- 
------------------------------------------------------------------
Reinhold Kainhofer, address@hidden, http://reinhold.kainhofer.com/
 * Financial & Actuarial Math., Vienna Univ. of Technology, Austria
 * http://www.fam.tuwien.ac.at/, DVR: 0005886
 * LilyPond, Music typesetting, http://www.lilypond.org



reply via email to

[Prev in Thread] Current Thread [Next in Thread]