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 pe...@piermont.com