On Sat, Jan 12, 2019 at 01:09:08PM +0100, Tim Düsterhus wrote:
> 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

Well, maybe indeed. However if a new maintainer comes and wants to follow
a different process he will need the permissions to push to GH. But you're
making a point that anyway GH is only a mirror so he'll have to have access
to haproxy.org and publish the reference there, so that might work anyway.
As you see, I'm mentioning use cases, though I'll probably not be the one
having the last word on the implementation given that I'll rely on others'
help.

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

Got it, I didn't think about this, makes sense indeed. I agree that
given that we'll have unique ID numbers across all branches, it would
be sad not to be able to easily reference them.

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

Thanks for the explanation.

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

Thanks for the link, I wasn't aware of this.

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

Ah so we're seeing the improved version :-)

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

In practice we *always* first try to diagnose the issue in -dev. The
only case where dev is not affected but an older branch is affected is
when we have diagnosed it enough to know that dev is really not affected.

However I'm seeing the problem with -dev : we need to know that a fix
is known. It's the "status: resolved" that brings this in my opinion.
There's no fix to merge anywhere until the issue is resolved.

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

I'm pretty sure that after a few weeks/months of usage, we'll progressively
adapt our workflow and need other labels, and possibly notice we never use
some of them that we'll simply remove.

I think that at this stage we seem to have something that works on the
paper, plus or minus minor tweaking. It's great.

Willy

Reply via email to