Port and patch submissions via ticket vs. via PR.

[Mark Anderson]

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 <mojca at 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.macports.org/pipermail/macports-dev/attachments/20180404/412d8306/attachment.html>