<div dir="ltr"><div dir="ltr"><br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Wed, Oct 16, 2019 at 6:42 PM Daniel Henrique Barboza <<a href="mailto:danielhb413@gmail.com" target="_blank">danielhb413@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><br>
<br>
On 10/16/19 9:22 AM, Andrea Bolognani wrote:<br>
> As we look to make the libvirt project easier to contribute to, one<br>
> fact that certainly comes to mind is that we only accept patches via<br>
> the mailing list. While the core developers are comfortable with the<br>
> email-based workflow and swear by it, many perspective contributors<br>
> are used to the PR/MR workflow common to many Open Source projects<br>
> these days, and similarly swear by it.<br>
><br>
> If we look at the PRs submitted on GitHub against the libvirt mirror<br>
> repository[1], there's just three of them per year on average, which<br>
> is arguably not a lot; however, it should be noted that each<br>
> repository also carries a fairly loud "PULL REQUESTS ARE IGNORED"<br>
> message right at the top, and it's not unlikely that a number of<br>
> perspective contributors simply lost interest after seeing it.<br>
><br>
> As a way to make contributions easier without forcing core developers<br>
> to give up their current workflow or making the project dependent on<br>
> a third-party provider, I suggest we adopt a hybrid approach.<br>
><br>
> First of all, we'd remove the ominous message from GitHub mirror<br>
> repositories (interestingly, the same is not present on GitLab).<br>
><br>
> Then, we'd starting accepting PRs/MRs. The way we'd handle them is<br>
> that, when one comes in, one among the handful of core developers who<br>
> volunteered to do so would review the patches on the respective<br>
> platform, working with the submitter to get it into shape just like<br>
> they would do on the mailing list; once the series is finally ready<br>
> to be merged, the core developer would update the PR/MR as necessary,<br>
> for example picking up R-bs or fixing the kind of trivial issues that<br>
> usually don't warrant a repost, and then push to master as usual.<br>
<br>
This would mean that there will be patches that will get accepted<br>
without the ML being aware of. The core developer (or the author<br>
itself) would need to send the revised patches to the ML before<br>
pushing to make people aware of it before pushing to master, IMO.<br></blockquote><div><br></div><div>The activemq mailing list as a bot or something installed which posts events like a new PR or a merged PR to their mailing list.</div><div><br></div><div>Best Regards,</div><div>Roman</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
I have a 2 year experience maintaining a now defunct project in<br>
Github (a KVM web management tool called Kimchi) in which we used a<br>
hybrid approach like I think you're suggesting, with mailing list, people<br>
opening bugs in Github + Github PRs. It was annoying - people will <br>
inevitably<br>
discuss issues using the Github tracking system, which means that you'll<br>
have to subscribe via email to Github notifications if you didn't want <br>
to miss<br>
out. It was common for people that used the ML to start discussions that<br>
were already happening in the Web, and vice-versa.<br>
<br>
All that to make a case against Libvirt having additional ways of<br>
communication. I don't mind pull requests from Github/Gitlab as long as the<br>
ML is made aware of, before the patches are accepted. But people bringing<br>
up discussions in the ML and Github/Gitlab scales poorly, in my experience.<br>
<br>
<br>
DHB<br>
<br>
<br>
><br>
> More in detail: GitHub and GitLab have a feature that allows project<br>
> members to update PRs/MRs: basically the way it works is that, if the<br>
> PR/MR was created by the user 'foo' from their branch 'bar', the<br>
> libvirt developer is allowed to (force-)push to the foo/libvirt/bar<br>
> branch, and doing so updates the corresponding PR/MR; after that, if<br>
> the updated branch is locally merged into master and master is pushed<br>
> to the <a href="http://libvirt.org" rel="noreferrer" target="_blank">libvirt.org</a> repo, once it gets mirrored GitHub/GitLab will<br>
> recognize that the commit IDs match and automatically mark the PR/MR<br>
> as merged. I have tested this behavior on both platforms (minus the<br>
> mirroring part) with Martin's help.<br>
><br>
> One last important bit. In the spirit of not requiring core<br>
> developers to alter their workflow, the developer who reviewed the<br>
> patches on GitHub/GitLab will also be responsible to format them to<br>
> the mailing list after merging them: this way, even those who don't<br>
> have a GitHub/GitLab account will get a chance to take notice of the<br>
> code changes and weigh in. Unlike what we're used to, this feedback<br>
> will come after the fact, but assuming that issues are spotted only<br>
> at that point we can either push the relevant fixes as follow-up<br>
> commits or even revert the series outright, so I don't feel like it<br>
> would be a massive problem overall.<br>
><br>
> Thoughts?<br>
><br>
><br>
> [1] <a href="https://github.com/libvirt/libvirt/pulls?q=is:pr+is:closed" rel="noreferrer" target="_blank">https://github.com/libvirt/libvirt/pulls?q=is:pr+is:closed</a><br>
<br>
--<br>
libvir-list mailing list<br>
<a href="mailto:libvir-list@redhat.com" target="_blank">libvir-list@redhat.com</a><br>
<a href="https://www.redhat.com/mailman/listinfo/libvir-list" rel="noreferrer" target="_blank">https://www.redhat.com/mailman/listinfo/libvir-list</a><br>
</blockquote></div></div>