On Apr 4, 2018, at 07:18, Mojca Miklavec wrote: >>> 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.
Fiddling with branches only becomes necessary if we implement this Trac-to-PR plan! Fiddling with branches wasn't necessary when we committed to our old Subversion repository, and it's not necessary if a committer just downloads the patches from Trac into their Git clone of macports-ports, fixes the port, and commits it to master. > 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) It should be in the guide, along with our other documentation. > (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.) How would an automated Trac-to-PR tool write a good commit message? If we're just talking about submissions, maybe that's easier. But what if the ticket contains multiple revisions of the Portfile? Trac automatically appends a number to the file if that filename has already been used, unless the attacher clicks the "Replace existing attachment of the same name" checkbox. What about multiple patchfiles? Multiple revisions of multiple patchfiles? What if some patchfiles became unnecessary during the development of the ticket? I'm dubious of the quality of some of the submissions in Trac. Certainly some are good and have simply been forgotten. But I feel like many have had reviews already posted, and the required changes have not been made. Creating a PR for the incomplete work would disassociate the work from the existing reviews. Would you remember to click the link for each auto-created PR to see what existing discussion had occurred? Would repeating that feedback in the PR have any effect -- if the submitter ignored it originally, why will posting it again in a PR make them respond to it now?
