Am 09.01.19 um 05:31 schrieb Willy Tarreau:
> Except that the "naturally" part here is manually performed by someone,
> and an issue tracker is nothing more than an organized todo list, which
> *is* useful to remind that you missed some backports. It regularly happens
> to us, like when the safety of some fixes is not certain and we prefer to
> let them run for a while in the most recent versions before backporting
> them to older branches. This is exactly where an issue tracker is needed,
> to remind us that these fixes are still needed in older branches.

So the commits are not being cherry-picked in the original order? I
imagined that the process went like this:

1. List all the commits since the last cherry-picks
2. Look in the commit message to see whether the commit should be
3. Cherry-pick the commit.

In the specific case of GitHub's issue tracker: If a issue is referenced
in a commit message the commit will automatically appear in the timeline
of that issue. This works even across repositories (by using
haproxy/haproxy#123 instead of just #123). It only shows when
specifically looking at a single issue, though and thus is not available
directly in the list of issues.

> If the issue tracker only tracks issues related to the most recent branch,

I believe you misunderstood me. What I attempted to say is:

The issue tracker tracks which branches the bug affects. But IMO it does
not need to track whether the backport already happened, because the
information that the backport needs to happen is in the commit itself
(see above).

> it will only solve the problem for this branch. For example, Veiko Kukk
> reported in November that compression in 1.7.11 was broken again. How do
> I know this ? Just because I've added an entry for this in my TODO file.
> This bug is apparently a failed backport, so it requires that the original
> bug is reopened and that any backport attempt to an older version is paused.

Is the failed backport a new bug or is it not? I'd say it's a new bug,
because the situation changed. It's a new bug (someone messed up the
backport) that affects haproxy-1.7, but does not affect haproxy-dev. You
describe it as an old bug that needs to be re-opened.

>> I'd throw my hat into the ring as well. I maintain a few Open Source
>> projects myself (though not of the size and importance of haproxy) and
>> actually use the GitHub issue tracker.
> Thanks. From what I've been used to see on github, very very few projects
> do care about maintenance. Most of them are rolling releases. It actually
> took me a very long time to try to figure one project with multiple
> maintenance branches to see how they dealt with issues, and the few I
> found by then had disabled issues, which could have already been a hint
> about its suitability to the task. Just a few examples :
> *snip*
> You'll note that for many of them the repository is only a mirror by
> the way, so that's another hint.

I suspect the reason is simple: The project already had a working issue
tracker that predated GitHub. Many of these projects are way older than

Here's some more recent projects that probably grew up with GitHub. I
can't comment how they do the backports, though:

https://github.com/nodejs/node/issues (has LTS / Edge)
https://github.com/zfsonlinux/zfs/issues (has stable / dev)
https://github.com/moby/moby/issues (tons of automation based on an
issue template)

>>> With that said at the moment we don't have anything and the situation is
>>> not better than having a suboptimal tool.
>> I agree.
> To be totally transparent, I really think the tool is not well suited and
> that its main value is its large user base. But I also know that with you
> and Lukas suggesting to use it, you both will deploy a lot of efforts to
> build something good to prove me I'm wrong, possibly resulting in a nice
> solution in the end. And if some people are willing to invest time
> building something, it would be unfair from me to try to steer their

Clearly it's important that the developer team / you are able to
efficiently work with it as well.

> technical choices. Also, Lukas already managed to use the API to develop
> some tools, maybe this will be welcome to add some automated state
> transitions at some point.
> So unless anyone has a better idea for now, and if you're feeling brave
> enough, let's give it a try.

It's probably impossible to build something absolutely perfect without
real world data points. If a pain point arises it can be specifically
worked on. Currently this discussion is completely hypothetical.

Best regards
Tim Düsterhus

Reply via email to