Port and patch submissions via ticket vs. via PR.

[Perry E. Metzger]

As some of you have noticed, I've been trying to keep the PR queue
relatively clear. We're down to just one PR from 2017 which I think is
a nice thing -- indeed, most of our open PRs are less than a week old,
and all but two are less than a month old.

Part of this is because it is significantly easier to handle new ports
and submitted patches that come in via pull requests on github than in
trac tickets.

1. You can comment on individual lines in a PR, which is really nice
   for code review purposes, and easily track which comments
   have been addressed.
2. When something arrives via PR, it is automatically put through the
   CI system, which, although flawed, provides reasonable assurance
   things build if it works.
3. It's easy to invoke (even with automation) appropriate people to
   look at a PR.
4. Merging the PR when it is ready is easy.

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

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.

Perry
-- 
Perry E. Metzger		perry at piermont.com