Willy, 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 backported. 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 GitHub. 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/antirez/redis/issues 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
