Guidelines about trac tickets and pull requests

[Mojca Miklavec]

On 29 December 2016 at 19:30, John Patrick wrote:
> From a users point of view, it's not clear what I should be doing and
> how Ticket's link with Pull Requests and vs versa?

Neither is this entirely clear to us :) :)

But I feel that it doesn't make so much sense to have both opened at
the same time and spread discussion between both.

> The MacPorts Guide
> still mostly talks about patches and trac, it doesn't feel like it's
> been update with how git should be used.

We are all still learning. There is a wiki page
    https://trac.macports.org/wiki/WorkingWithGit
which could of course be improved in many aspects.

We should probably update guide as well. The group of people that
is/was slightly more involved with transition to GIT is somewhere in
the order of 3-5 people who all have to take care of plenty of other
administrative tasks.

> At the moment I;
> 1) raise a trac ticket
> 2) create/rename the branch based upon the trac number

This is probably not necessary.

But a worse scenario is that some people open both and don't make
references, so tickets on Trac might stay opened "forever".

> 3) push that to my fork
> 4) open pull request and add link to trac
> 5) update trac ticket with pull request url
>
> I'm use to Git and Jira where if the git commit message contains a
> valid jira ticket, jira can be automatically update the ticket
> details.

> Also it's strange that pull requests are not merged, as this
> would help give credit to people supplying pull requests as at the
> moment your asked to close your pull request.

This is only partially true.

We discovered that the only way to handle things "properly" (in a way
that the PR will appear to be merged) is to either:

(a) Press the button to merge the changes, but the disadvantage is
that committer's email is then "quasi-random" (it cannot be configured
on per-project basis and I would get my personal email there instead
of the macports one).

(b) Rebase, force push to the PR branch first (contributor needs to
allow that), then force push to master. Unless it's done in exactly
that way, the tickets are not closed automatically. I'm sure that many
committers are not aware of that and even those who are might easily
make a mistake. I made plenty of mistakes even after we figured out
how that works. Some committers might not care about whether or not
GitHub sees the commits as merged or closed, not everyone sees/treats
"closed" as "rejected". GitHub is not too user-friendly in this
respect, but ...

You already "get credit". Your name appears as the commit author and
if you look closely at individual tickets, you'll see "closed with
commit <sha>".

Mojca