Hi Tim, On Wed, Jan 09, 2019 at 12:58:30PM +0100, Tim Düsterhus wrote: > 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.
It's what we *try* to do, but cherry-picking never is rocket science, for various reasons, some ranging from uncertainty regarding some fixes that need to cool down later, other because an add-on was made, requiring an extra patch that are much more convenient to deal with together (think about bisect for example). That's why I created the git-show-backport script which gives us significant help in comparing lists of commits from various branches. > > 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). For me it is important to have the info that the branch is still unfixed because as I explained, the presence of a given commit is not equivalent to the issue being fixed. A commit is for a branch. It will often beckport as a 1-to-1 to the closest branches, but 10% of the time you need to backport extra stuff as well that is not part of the fix but which the fix uses, and sometimes you figure that the issue is still not completely fixed despite the backport being there because it's more subtle. > > 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. For me it's not a new bug at all, it's the same description. Worse, often it will even be the one the reporter used! For example someone might report an issue with 1.7, that we diagnose covers 1.7 to 2.0-dev. We finally find the bug and if it in 2.0-dev then backport it. The backport stops working when reaching 1.7. It's hard to claim it's a new bug while it exactly is the bug the person reported! Doing otherwise would make issue lookups very cumbersome, even more than the mailing list archives where at least you can sort by threads. Thus for me it's only the status in the old branch which is not resolved. It's also more convenient for users looking for a solution to figure that the same bug is already fixed in 1.8 and that possibly an upgrade would be the path to least pain. > > 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. It's possible. > 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) I only knew 3 of them by name and never used any ;-) Node is interesting here. the have tags per affected version. E.g. https://github.com/nodejs/node/issues/25221 I tend to think that if labels already mark the relevance to a branch, then they override the status and probably we don't really care about the status. The "moby" project above does that by the way, with "status/foo" labels. We could possibly have had "v1.8-open" and "v1.8x-done". This way instead of searching by status users can search by clicking on the labels. I could just be missing something. > > 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. I agree of course, which is also why I'm sharing my experience dealing with maintenance for almost two decades on this project, being aware of certain weaknesses because we're human, stuff happens, bugs rarely are black or white, and each time you're certain you fixed it right there's a small risk that it re-surfaces. I just want to be sure that we don't start with something too naive that will break after one month, leaving you and Lukas as the only users. That would be the biggest failure. Of course we can also fail with the process and the tools and adjust afterwards, but then we need to be prepared to this possibility so that it's not the end of the world if it happens. > 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. Definitely! And I'm not looking for a perfect solution, just trying to be sure the most basic needs can at least be addressed in theory. > Currently this discussion is completely hypothetical. Not completely because I'm still explaining some elements that I've been using for many years to determine what has to be done in various areas. If we all continue to rely on our respective todos and never consult the issue tracker because it's always out of sync with reality, misleading, or confusing, there's no point wasting your valuable time on it. So we're not just in hypothesis but trying to describe a workflow and see how to best map it to a tool not designed for it without putting too much pain on any side (setup, maintenance, use). Thanks, Willy
