Hi Tim,
On Sat, Jan 12, 2019 at 12:24:23PM +0100, Tim Düsterhus wrote:
> > This one is less of a problem because the likelihood that someone writes
> > "fixes haproxy/haproxy/#4" in a commit message is particularly low, unless
> > they do it on purpose to annoy us of course.
>
> It would only close on us, if the person creating the other commit had
> the necessary permissions in our issue tracker.
OK.
> This example makes me wonder, though: Should the various branches be
> separate repositories on GitHub like on haproxy.org or should they be
> actual branches (e.g. 1.8.x in haproxy/haproxy instead of
> haproxy/haproxy-1.8) for the mirror?
I've been thinking about this for a while in the past, which is the
reason why we purposely didn't upload the other branches yet. On the
one hand having all branches at once in a single repository is
convenient to retrieve everything at once. On the other hand, most
people cloning the repo are not interested in retrieving maintenance
versions for old branches. In addition, while at the moment and for
simplicity reasons, all stable maintainers do have write access to
the master repository, in the future we could imagine delegating some
outdated branches to certain contributors who still need to maintain
them for whatever reason, and in this case we might not feel much at
ease with granting them a write access to all other repos and have to
face their occasional mistakes.
This matches perfectly the situation I've been into with the kernel:
I inherited old ones and other developers didn't have to be scared by
my mistakes because I could only affect the part I was responsible for.
As such it makes me think that it's probably better to only have the
master branch in the main repo, and create separate repos for the
maintenance branches.
> The former would require referencing issues as haproxy/haproxy#123. The
> latter allows for a more simple #123.
Given that we'd prefer *not* to see them automatically closed, I don't
see this as a limitation, on the opposite!
> > I'm wondering if based on the previous work you did on the
> > pull requests using the API it would be possible to :
> > - reopen closed issues that still have a "*-affected" or "needs triage"
> > label
> > - close issues that don't have "*-affected" nor "needs triage"
> >
> > In this case it would mean we just need to use the labels and not care
> > about the state at all.
>
> Yes. You can pull issues with a specific state and a specific label from
> the API and you can receive webhooks when an issue is being opened or
> closed.
Fine!
> The following GitHub v4 API query pulls issues with
> state == OPEN && (label == "1.6-affected" || label == "enhancement")
> for Lukas' test repository from the API. "enhancement" is to be replaced
> by the other "*-affected" labels.
>
> {
> repository(owner: "lukastribus", name: "hap-issue-trial") {
> issues(states: [OPEN], labels: ["1.6-affected", "enhancement"],
> last: 100) {
> nodes {
> title
> }
> }
> }
> }
Mind you that I don't have any idea what language this code block uses nor
where it has to be stuffed, so I'll trust you :-)
> >> - and issue and feature request template
> >
> > For this one I have no idea since I don't know much how it works.
>
> You need to a markdown file to the .github/ISSUE_TEMPLATE folder in the
> repository:
>
> https://github.com/lukastribus/hap-issue-trial/blob/master/.github/ISSUE_TEMPLATE/Bug.md
>
> see:
> https://help.github.com/articles/manually-creating-a-single-issue-template-for-your-repository/
OK, that's manageable I guess, thanks. I find it a bit annoying that it uses
the code repository to store the github interface configuration but aside
this it's probably OK.
> >> status: pending-backport
> >
> > I think this one is implied by the presence of "affects:"
>
> Not necessarily. "affects" without "pending-backport" probably needs
> more work finding the issue first, while "pending-backport" can be as
> easy as a cherry-pick.
OK I see your point but in this case the dev branch is fixed,
"affects: dev" is not there anymore then pending-backport is implied
by ("affects: 1.x" and not "affects: dev"). This even works for bugs
that only affect older branches. It's even better as we have always
implied that a backport to a branch is not welcome until the next
branch is fixed. Thus the "backport-pending" for a branch is always
deduced from "affects: branch" and not "affects:next branch".
Willy
