Willy, Am 12.01.19 um 12:45 schrieb Willy Tarreau: >> 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.
The situation on GitHub does not need to mirror the situation on haproxy.org. You could still use separated repositories on haproxy.org to separate permissions and push the "validated" commits to GitHub. This is what the PHP project does. The canonical repositories lives on their infrastructure and GitHub is a mirror only. They have a pre-receive hook that prevents pushes if files / branches outside one's permission set are touched: https://github.com/php/karma/blob/master/hooks/pre-receive The post-receive hook would then do the following for dev: git push github master:master git push github --tags And this for 1.8: git push github master:1.8.x git push github --tags > 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! Just mentioning the issue does not close it! You have to prefix the number with a "(Fix(es)?|Closes?)". Mentioning the issue comes with the nice property that the commit appears in the timeline of the issue, which I consider useful. >> 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 :-) It's the Graph Query Language the v4 API of GitHub uses: https://developer.github.com/v4/. You send it as the body of the HTTP API request and get back a JSON formatted reply with the data you asked for. And if it's non-empty you send a new API request that opens / closes the issue in question. Where it needs to be stuffed: On some server that runs a cronjob / ingests the webhooks. :-) In the long run it can probably be stuffed as a GitHub Action and be part of the repository (in the .github folder). They are still a Beta, though: https://developer.github.com/actions/ >>>> - 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. At least you can use the .github/ hidden folder now. In former times they had to be placed at the root of the repository. >>>> 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. Does it? What if a bug is found that only affects the current stable branch, but not dev, because some refactoring "accidentally" fixed it? I don't strongly care either way, though. A "pending-backport" is only useful for the developers, not the end user. And if you don't consider that label useful we just don't add it. Best regards Tim Düsterhus
