On 04/09/2013 01:33 PM, Feng Yang wrote:
On 04/05/2013 04:28 AM, 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.
I'd personally like to have something more gerrit
(http://code.google.com/p/gerrit/) like on github, but the pull
requests infrastructure is 'good enough' for what we want, and we
don't get to maintain infrastructure, which is a big "yay!" for us.
Therefore, I'd like to move to a model where we mandate pull requests
for contribution to autotest, virt tests and projects inside the
autotest umbrella. Of course, I don't want you guys to think I'm
shovelling this down your throats, so I'd like to hear if anybody
feels very strongly about it. Also, we could consider exceptions in
cases like:
* I hate github so much that I can't stand using it and I think you
are all morons for even considering this OMG.
* I can't use github because, I don't know, my company forbids using
web browsers or send any requests to the port 80 or 443, or whatever.
So please, let us know what you think. By moving to a single,
concentrated point of review I believe we'll have less development
overhead and generally reduce stress levels of the maintainers.
Hi Lucas
Just come back from holidays and PTO. So maybe reply this mail too later.
Already got your meaning from this email. But I think we'd better
still use emails (patchwork) and github at same times.
Github may cannot access in china sometimes. This used to happen
before, may happens again late. So I want to say that github is not
stable for us.
Aha, yes, this problem is exist in china.
And another problem is that some company have restricts to outside network.
(such as upload and download file' size)
So completely moving to github's pull request looks a little difficult.
Maybe we can try to use pull request in this way:
1.if you send patches with emails, then pasting the issue of this patchset.
but if it is possible to send pull request, please do it, then just
pasting the link of pull request.
2.People make comments in issue of website, other than line comments of
email patches.
3.Sending single patch which fixes bug to email only, otherwise there
will be a long pull request list.
And creating issue of this bug if it is necessary.
send patch with emails has some disadvantage as you list. But it also
have some point make me still use it:
1. Full history is saved in emails. From Archives of the email list,
I can know all the information happened on this patch, such as the
difference between difference version and why we need a new version...
. With github seems some information will lost.
2. With email all the patches will come to my client automatically. I
can comment and test the patch locally. At least I know the patch and
will review the patch summary. Does github can works in this way? If
we have to login web page to review patches. I think some people will
just ignore pull request. Less people care the patches, I think this
is not what we want.
As github is not always stable in china. Hope that we can still use
emails to make sure we can always connect with upstream.
Waiting your comments!
Thanks
Yang Feng
Cheers,
Lucas
[1] At least for us, lame people that like web browsers, IDEs and
graphical email clients. I know, we are awful, but maybe you can bear
with us.
_______________________________________________
Autotest-kernel mailing list
[email protected]
https://www.redhat.com/mailman/listinfo/autotest-kernel
_______________________________________________
Virt-test-devel mailing list
[email protected]
https://www.redhat.com/mailman/listinfo/virt-test-devel
--
Best Regards
Yu Mingfei
_______________________________________________
Virt-test-devel mailing list
[email protected]
https://www.redhat.com/mailman/listinfo/virt-test-devel
