On 04/04/2013 04:28 PM, Lucas Meneghel Rodrigues wrote:
> Hi folks,
>
> As we're always looking to streamline autotest and the offspring
> projects (such as virt-test) development, one thing that occurred
> to us is that code reviewing/patch management done through the mailing
> list has disadvantages [1]:
>
> 1) Downloading/applying/reviewing patches is not very convenient. We
> used to have a public patchwork instance that had to be disabled as we
> decomissioned test.kernel.org. We have an internal patchwork instance,
> but as the name says, it is internal, therefore we alienate people that
> are not from Red Hat to conveniently download and apply patches.
>
> 2) Reviewing means a long thread of emails, with no visual cues to help
> the reviewer, such as colors.
>
> 3) Following patch series is harder (you keep making searches on your
> mailing list folders to look for previous versions of a patch and all
> that).
>
> 4) We already use github pull requests, so having to scan for new work
> items on the ML and github is kind of an overhead.
#4 is true, I'd love to have the sources consolidated.
#3 has bitten me several times (reviewing patch set only to find a newer
one already posted.
#2 totally agree, I love the rich-text and ability to use
<code>foobar</code> tags.
#1 is my main concern. There are a few features provided by e-mail +
patchwork that I use heavily:
* Easily picking out item state (new, someone else working on it,
I'm working on it, author is working on it). Perhaps tracking-issues
can address this.
* Notification of new items (to my knowledge there's no way for
"maintainers" to receive pull request notifications, only "owners").
Maybe I'm missing a setting, but I did look and couldn't find one.
* Content is available irrespective of merge state. With github,
only "automatic merge" pull requests have the "i" button w/ links to
work on the code locally.
https://github-images.s3.amazonaws.com/help/pullrequest-mergebar-i.png
Any pull request that can't be automatically merged requires navigating
around to find the authors source branch.
* Categorization of items among a large list. With e-mail, I can
easily mark libvirt related patches, but with pull requests they all end
up in the same list. Maybe current tracking-issue workflow can address
this.
Likely all items we can work out, but it would be good to have the
solutions be "official" and documented.
_______________________________________________
Virt-test-devel mailing list
[email protected]
https://www.redhat.com/mailman/listinfo/virt-test-devel
