On Wed, Oct 16, 2019 at 02:22:56PM +0200, Andrea Bolognani wrote:
First of all, we'd remove the ominous message from GitHub mirror
repositories (interestingly, the same is not present on GitLab).
Well if you're using GitLab then you're already aware of the fact that
not everything is hosted on GitHub.
Then, we'd starting accepting PRs/MRs. The way we'd handle
them is
that, when one comes in, one among the handful of core developers who
volunteered to do so would review the patches on the respective
platform, working with the submitter to get it into shape just like
they would do on the mailing list; once the series is finally ready
to be merged, the core developer would update the PR/MR as necessary,
for example picking up R-bs or fixing the kind of trivial issues that
usually don't warrant a repost, and then push to master as usual.
More in detail: GitHub and GitLab have a feature that allows project
members to update PRs/MRs: basically the way it works is that, if the
PR/MR was created by the user 'foo' from their branch 'bar', the
libvirt developer is allowed to (force-)push to the foo/libvirt/bar
branch, and doing so updates the corresponding PR/MR; after that, if
the updated branch is locally merged into master and master is pushed
to the
libvirt.org repo, once it gets mirrored GitHub/GitLab will
recognize that the commit IDs match and automatically mark the PR/MR
as merged. I have tested this behavior on both platforms (minus the
mirroring part) with Martin's help.
One last important bit. In the spirit of not requiring core
developers to alter their workflow, the developer who reviewed the
patches on GitHub/GitLab will also be responsible to format them to
the mailing list after merging them: this way, even those who don't
have a GitHub/GitLab account will get a chance to take notice of the
code changes and weigh in. Unlike what we're used to, this feedback
will come after the fact, but assuming that issues are spotted only
at that point we can either push the relevant fixes as follow-up
commits or even revert the series outright, so I don't feel like it
would be a massive problem overall.
Here it deviates from the usual mailing list workflow where the patch
has (in theory) a chance to be seen by all the developers.
But given that the requests will probably
a) be close to trivial
b) seen by a group of developers, not just one
sending it to the mailing list after it's pushed is better treatment
than our language bindings get.
Jano
Thoughts?
[1]
https://github.com/libvirt/libvirt/pulls?q=is:pr+is:closed
--
Andrea Bolognani / Red Hat / Virtualization
--
libvir-list mailing list
libvir-list(a)redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list