Port and patch submissions via ticket vs. via PR.

[Mojca Miklavec]

On 4 April 2018 at 13:15, Ryan Schmidt wrote:
> On Apr 1, 2018, at 11:02, Perry E. Metzger wrote:
>
>> As some of you have noticed, I've been trying to keep the PR queue
>> relatively clear.
>
> Thanks very much for that!

Indeed. What you are doing is simply amazing.

>> Also, Mojca brought the question of the hundreds of open tickets with
>> port submissions a while back. It might be neat if we had some code
>> that caused a special Github account to generate a PR for a port
>> submission in trac. I wouldn't want this automatically invoked (at
>> least not yet!), but if a human (like me!) could manually invoke it on
>> a few ports at a time when they had free time, it might help to
>> clear out the backlog.
>
> 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.

The time saved comes from the author doing the cleanup based on
feedback (which you can leave while waiting for a bus or while going
for a walk :) vs. one of us having to do all the changes, fiddling
with branches.

In my opinion we should:
(a) create a page (either or Trac or on GitHub) explaining benefits of
Pull requests (+ excuse for the delay processing trac tickets)
(b) leave a comment on all submission tickets pointing to that page (I
guess this can be done automatically)

I expect some 10-20% of those submissions to be turned into pull
requests by original authors, but that's already a lot. If we end up
with 20 submissions one day, I don't mind going over all the twenty of
them manually, but this is "hopeless" with hundreds of them.

Alternatively / in addition, what we currently lack is a page
explaining how random unskilled users willing to spend some time
helping us could do. If we were able to communicate clearly what such
users can do when they just feel like helping us, this could be one of
the suitable tasks. (Other tasks include fixing ports with wrong
checksums after github switch their algorithm etc.)

The pull request queue is now amazingly short. Cutting down all other
queues one by one could be our next goal.

Mojca