Port and patch submissions via ticket vs. via PR.

[Ryan Schmidt]

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!


> I'm wondering if we should therefore encourage people to submit github
> PRs if they have working patches (or are submitting new ports) rather
> than trac tickets. (Not suggesting we should _prevent_ the latter,
> just that maybe we should explicitly encourage the former.)

Yes, I think encouraging PRs instead of ticket attachments, when the submitter already has specific changes in mind, would be a good idea.


> 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.