Port and patch submissions via ticket vs. via PR.

[Jan Stary]

(Not a member, speaking from a user point of view.)

On Apr 01 12:02:23, perry at piermont.com wrote:
> As some of you have noticed, I've been trying to keep the PR queue
> relatively clear.

Thank you for that! It really is rewarding
to see the PRs being acted upon in a timely manner,
as opposed to oh so many other projects.

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

Also, it is easy to merge _other_ changes into the proposed PR,
including the master changes newer than the PR (rebase).

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

I have switched to exclusively use github months ago.
I only deal with TRAC tickets if I have to; similarly,
I create github issues, not TRAC tickets.

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

I'm a afraid this requires human labor that cannot be much helped
by any automation. The gist of it is to work on the port itself,
motivatad by need and/or love. The only way for any of
https://trac.macports.org/query?status=new&type=submission
to become an actual port is that _some_guy_ cares enough
to _have_that_ in MP to turn it into a port, test etc,
and prefrably create a PR to be merged. Whether this guy
downloads the attached Portfile from a trac ticket or
clones somebody's branch is a technicality compared to that.

For example, if anyone cared about dbxml
https://trac.macports.org/ticket/24429
we would have a dbxml port by now. The reason we don't
is not that it's a trac submission, instead of a PR.

On Apr 04 06:15:48, ryandesign at macports.org wrote:
> 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.

Speaking as a user, I can attest to the fact that my submissions
usually need a fair amount of cleaning before being ready to merge.

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

Exactly. Turning the trac into a PR _before_ the actual work is done
saves nothing.

On Apr 04 14:18:42, mojca at macports.org wrote:
> 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.

That has nothing to do with trac vs PR:
the author can get feedback on the PR too (I do).

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

That is imho a good way to get involved with MP.
The motivation has to come from within though:
nobody's gonna fix ports they neither use nor care about as a first step.

For example, I like audio. If there is a a problem with an audio port
that does something interesting, I will look at it. I will not do the
same for graphics, because I simply don't care. The random unskilled
user will need _some_ motivation beside "I feel like helping".

> checksums after github switch their algorithm etc.)

That's a good example of what I mean: what could be more boring
than fixing rmd160 checksums if you don't care about the port itself?

So the page you have in mind would imho need to motivate people
with actual motivation: find a bug that bugs you, find a port
you use that needs fixing.

Also: go through the patches of a port you use and push them upstream,
so that the same does not have to be re-done with every release.

	Jan