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.
—Mark On Wed, Apr 4, 2018 at 8:18 AM Mojca Miklavec <mo...@macports.org> wrote: > 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 > -- Sent from Gmail Mobile on iPhone