<div dir="auto">I like the idea of a trac to PR script or something to make things easier. The github API is pretty easy to use, but I’m not a trac expert by any means. That said, I’d be willing to help.</div><div dir="auto"><br></div><div dir="auto">—Mark</div><div><br><div class="gmail_quote"><div>On Wed, Apr 4, 2018 at 8:18 AM Mojca Miklavec <<a href="mailto:mojca@macports.org">mojca@macports.org</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">On 4 April 2018 at 13:15, Ryan Schmidt wrote:<br>
> On Apr 1, 2018, at 11:02, Perry E. Metzger wrote:<br>
><br>
>> As some of you have noticed, I've been trying to keep the PR queue<br>
>> relatively clear.<br>
><br>
> Thanks very much for that!<br>
<br>
Indeed. What you are doing is simply amazing.<br>
<br>
>> Also, Mojca brought the question of the hundreds of open tickets with<br>
>> port submissions a while back. It might be neat if we had some code<br>
>> that caused a special Github account to generate a PR for a port<br>
>> submission in trac. I wouldn't want this automatically invoked (at<br>
>> least not yet!), but if a human (like me!) could manually invoke it on<br>
>> a few ports at a time when they had free time, it might help to<br>
>> clear out the backlog.<br>
><br>
> In my experience, port submissions, especially by new contributors, require more cleanup than port updates. It's not uncommon for a submission to have half a dozen or more things wrong with it. So you could either develop an automated system for copying a Portfile submitted on Trac into a pull request -- and then have to check out that PR branch into your git clone, fix all the problems, amend the commit, force push it -- or you could just download the Portfile from Trac yourself, put it into your git clone, fix it, commit it, and either send a PR or push to master. And either way, you're going to want to make sure it builds locally first. It doesn't seem like the former saves you that much time over the latter, plus of course you've had to spend all that time developing the automated Trac-to-PR system.<br>
<br>
The time saved comes from the author doing the cleanup based on<br>
feedback (which you can leave while waiting for a bus or while going<br>
for a walk :) vs. one of us having to do all the changes, fiddling<br>
with branches.<br>
<br>
In my opinion we should:<br>
(a) create a page (either or Trac or on GitHub) explaining benefits of<br>
Pull requests (+ excuse for the delay processing trac tickets)<br>
(b) leave a comment on all submission tickets pointing to that page (I<br>
guess this can be done automatically)<br>
<br>
I expect some 10-20% of those submissions to be turned into pull<br>
requests by original authors, but that's already a lot. If we end up<br>
with 20 submissions one day, I don't mind going over all the twenty of<br>
them manually, but this is "hopeless" with hundreds of them.<br>
<br>
Alternatively / in addition, what we currently lack is a page<br>
explaining how random unskilled users willing to spend some time<br>
helping us could do. If we were able to communicate clearly what such<br>
users can do when they just feel like helping us, this could be one of<br>
the suitable tasks. (Other tasks include fixing ports with wrong<br>
checksums after github switch their algorithm etc.)<br>
<br>
The pull request queue is now amazingly short. Cutting down all other<br>
queues one by one could be our next goal.<br>
<br>
Mojca<br>
</blockquote></div></div>-- <br><div dir="ltr" class="gmail_signature" data-smartmail="gmail_signature">Sent from Gmail Mobile on iPhone</div>