Additional labels for pull requests (and Trac tickets)

[Jeremy Lavergne]

Perhaps we can give these all a common prefix since they appear to fit a
theme: wait/waiting/hold. Assuming it can be helpful if one can search
tags themselves so everything that's "waiting-*" shows up, or at the
very least get a list of tags to then view.

Think we're also on track for indicating who owns the next step:
 * reporter (them)
 * macports/maintainer (us)
 * third party (other)

On 11/11/2017 02:35 PM, Mojca Miklavec wrote:
> On 11 November 2017 at 20:04, Jeremy Lavergne wrote:
>>> - needs_review: nobody with sufficient expertise took a look yet to
>>> provide some qualified feedback
> This is kind of default state anyway. But some PRs might be extra
> tricky to do and I would reserve the tag for those.

Agreed: it draws specific/extra attention to needing a/additional
review. Do you feel it's distinct from "wait_for_opinion" or perhaps
they can be combined?


>>> - wait_for_maintainer: someone from our team thinks the commit is ok,
>>> but would prefer to wait for the port maintainer to take a look first
> This is also kind-of-evident from:
> - a green check given by some reviewer (but it's never clear whether
> this check was given by the actual maintainer or someone else; this
> would make it more clear)
> - a request for the maintainer to make a review
> but it would be nice to have an obvious label
> 
> This would probably be most useful for Trac.

Hoping for clarity on the Trac implication.

Does this mean we need to copy/reference the issue from GitHub in a
ticket in Trac if we want specific devs to notice action is requested?
Curious if our "process" has a hole, that devs aren't available on
GitHub and so we have to do extra work on tickets to fill the gap.

Can you further explain what you meant? Don't want to have myself go on
accidental tangents :-)


>>> - more_changes_needed: the changes are not quite ready yet
> A while ago I created a tag WIP and people argued that
> work-in-progress should not even be submitted as a PR. It was then
> removed. I would still find it useful though. It might turn out that
> 90% of work is done and someone finds a problem that needs to be
> resolved first.
> 
> There's another potentially related thing (not sure if it should be
> the same or another tag). Like "no, please don't commit an update to
> lua because this breaks many ports". Or, "wait-a-moment, it turns out
> that something is broken after this, I need a couple of more days to
> fix it".

This group appears to be more of "incomplete" or "do not act on this",
right? If it's going to break many things, that could be seen as arguing
it's incomplete. Tempted to say keep these combined.


>>> - wait_for_upstream_feedback: we would prefer if upstream would take a
>>> look, or at least to get an upstream ticket open before merging the
>>> changes

Worried about an issue lingering in GitHub. Is upstream only invoked if
a maintainer made contact, and can we expect the maintainer to have
already determined the course of action regardless of upstream involvement?


>>> - wait_for_opinion: there's still an ongoing debate, opinions
>>> potentially differ, we need more brainstorming etc.