Am 09.01.2019 um 15:22 schrieb Willy Tarreau: > 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 like this as then you can see all effected Versions for a issue and PR. > 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. Full Ack. >>> 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). In general I also see a huge benefit to add a issue tracker I also know that's a workflow change for the developers. As I also follow the discussion let suggest me the following. * add some templates for the different cases e. g.: ISSUE_TEMPLATE.md https://blog.github.com/2016-02-17-issue-and-pull-request-templates/ * use some labels, as labels are very flexible and easy to use as selector. for example: bug, 1.7, backport-1.7, 2.0-dev, fixed_in_1.9.1, ... * in the commit message(s) can the issue number be added to create a corelation to the issue with `#`. https://help.github.com/articles/basic-writing-and-formatting-syntax/#referencing-issues-and-pull-requests * add a SUPPORT.md where is described that the mailing list is the main point for discussion, help and pull requests there is also a forum for discussions. There are also some suggestions from GH for communities. https://help.github.com/articles/setting-up-your-project-for-healthy-contributions/ I can offer you to add this templates and labels in https://github.com/haproxy/haproxy after we have found a workable conclusion. > Thanks, > Willy Best regards Aleks
