Re: Test case review

On 05/12/2011 12:18 AM, Aryeh Gregor wrote:
> On Wed, May 11, 2011 at 12:02 PM, Linss, Peter<peter.linss@hp.com>  wrote:
>> One of the issues that I'm dealing with here, however, is that many of our test contributors are simply not engineers, they don't use vcs (let alone dvcs) on a daily basis, and don't fully grok how those systems work. Forcing them to learn these systems is an unacceptable barrier to entry. I'd rather deal with tool issues on my end than lose their oh so valuable contributions. I also don't know how many other potential contributors are out there, and I don't want a complicated set of tools to scare them away before they even try.
>
> It's not complicated at all.  We can provide step-by-step instructions
> on how to do all the important tasks.  The advantage of using built-in
> VCS features instead of a home-grown tool (even one that already
> exists) is that more people will already be familiar with the existing
> tool, and the existing tool will have much more development effort put
> into it.  I don't know so much about hg, but in git, the way to apply
> a commit from one branch to another is just
>
> git checkout branch-to-change
> git cherry-pick commit-id

Right. Similar workflows are possible using hg transplant.

The important thing to note is that normal users don't have to do this 
stuff themselves. If all you want to do is submit some tests that should 
be as easy as clone/commit/push. It is only the people administering the 
testsuite who who have to worry about the more complex operations.

> I'm not sure how well this would work in the long term without
> occasionally rebasing the unstable branch on the stable branch,
> though.  Would mq work for that, in Mercurial?  For the Linux kernel,
> the way it works is that -stable is regularly rebased on Linus' tree,
> as are individual development trees, but that complicates pulls (and
> we're not using git anyway).

There are certainly details to think through. The good news is that the 
happy path for a test repository should be very happy indeed; someone 
who is just submitting tests should never hit a merge conflict doing 
that and, assuming that each test has a unique owner people just 
updating tests they own should never hit a conflict there either.

> If you don't do any kind of rebasing,
> won't you have a hard time keeping track of which revisions were
> actually merged and which need to be merged, as opposed to
> branch-specific commits or reverted commits or such?  Or is the review
> tool meant to solve that?  If so, is there some specific tool that
> people have in mind?

The code review tool I have in mind doesn't exist. In general there 
seems to be a paucity of good code review tools for mercurial (at least 
ones that aren't tied to some SaaS like Google Code or whatever). 
ReviewBoard is free but is patch based rather than sequence-of-commits 
based. It also has a bunch of unnecessary features around users and 
permissions although they might be ignorable. Atlassian have Crucible 
which is non-Free, may or may not be free for W3C to use and has a 
crazy-complex UI that I think is enough to put anyone off.

Generally the situation for Git seems to be a bit better e.g. Gerrit 
seems to be quite close to what I have in mind (although I only looked 
briefly) but that doesn't help us.

Received on Thursday, 12 May 2011 09:04:11 UTC