Re: stable-bot: WARNING: 54 bug fixes in queue for next release - 2.1
Hi Daniel, On Wed, Feb 12, 2020 at 06:47:07PM -0500, Daniel Corbett wrote: > I'll do what I can to improve it starting with working on moving these items > to a thread and increasing the calculations for expected release dates for > older branches. Probably we can start simple for the calculations: if we consider that there are "recent" and "older" branches, that the last two ones (i.e. one LTS and one non-LTS) are "recent", and others are "older". Just double all delays for older ones, and maybe update them at most once every two weeks (don't do complicated calculations, do it only on sundays whose day-of-year is even). > I'll also take your other suggestions into account as well but I think these > might be a good starting point. > > I may be a little slow on this but I'll put something together that can > hopefully make the bot more useful. No problem. I do really value these announces (even if I totally understand how they can be boring). Regularly when I see them, I can't help but have a quick check and think "ah shit, we're late", and that was exactly the point. I'm also thinking right now that it could probably be more productive to send them in the middle of the week (wednesday?) than on sundays: they will be seen instantly instead of appearing in the middle of the backlog noise of the past week-end. I think in the mean time you can already kill 1.9 from the list of announces. Thanks, Willy
Re: stable-bot: WARNING: 54 bug fixes in queue for next release - 2.1
On 12 Feb 18:47, Daniel Corbett wrote: > Hello, > > > On 2/12/20 12:55 PM, Tim Düsterhus wrote: > > > > Threading would solve most of the pain points for me, because the emails > > will nicely be merged on both my computer and my phone. For the > > remaining points I don't really care that much. I'll leave this up to > > the people that actually read the emails. I'm currently just marking > > them as read without taking a single look :-) Most of by curiosity is > > satisfied using git and the bug list on haproxy.org. > > > I just wanted to acknowledge this thread and let you know that I appreciate > the suggestions. > > I'll do what I can to improve it starting with working on moving these items > to a thread and increasing the calculations for expected release dates for > older branches. > > I'll also take your other suggestions into account as well but I think these > might be a good starting point. > > I may be a little slow on this but I'll put something together that can > hopefully make the bot more useful. > > > Thanks again, > > -- Daniel Hi Daniel, I want to tell another story. I find the bot useful and appreciate it. We get more real spam on the mailing list than emails from the bot, and it gives a good reminder about what's coming next and what are the bugs. In the current status of HAProxy development, where lots of things only happen on the mailing list, and branches are not all mirrored on github, this is really welcome. -- (o-Julien Pivotto //\Open-Source Consultant V_/_ Inuits - https://www.inuits.eu signature.asc Description: PGP signature
Re: stable-bot: WARNING: 54 bug fixes in queue for next release - 2.1
Hello, On 2/12/20 12:55 PM, Tim Düsterhus wrote: Threading would solve most of the pain points for me, because the emails will nicely be merged on both my computer and my phone. For the remaining points I don't really care that much. I'll leave this up to the people that actually read the emails. I'm currently just marking them as read without taking a single look :-) Most of by curiosity is satisfied using git and the bug list on haproxy.org. I just wanted to acknowledge this thread and let you know that I appreciate the suggestions. I'll do what I can to improve it starting with working on moving these items to a thread and increasing the calculations for expected release dates for older branches. I'll also take your other suggestions into account as well but I think these might be a good starting point. I may be a little slow on this but I'll put something together that can hopefully make the bot more useful. Thanks again, -- Daniel
Re: stable-bot: WARNING: 54 bug fixes in queue for next release - 2.1
Willy, Am 12.02.20 um 18:09 schrieb Willy Tarreau: > Hi Tim, > > On Wed, Feb 12, 2020 at 04:36:58PM +0100, Tim Düsterhus wrote: >>> Thus the computed ideal release date for 2.1.3 would be 2020/02/03, which >>> was one week ago. >>> [...] >>> --- >>> The haproxy stable-bot is freely provided by HAProxy Technologies to help >>> improve the quality of each HAProxy release. If you have any issue with >>> these emails or if you want to suggest some improvements, please post them >>> on the list so that the solutions suiting the most users can be found. >>> >> >> It appears that with the new backporting helper scripts you immediately >> backport fixes, instead of doing that in bulk whenever you feel like a >> new release. This causes this bot to send more emails than before. It's >> regularly 4 emails every Sunday now. > > I don't think the bot gets triggered on new patches additions, though > I could be wrong. Instead I think that as it now announces 4 versions, > the messages are becoming more visible. It sends an email once per week (on Sunday), but only if there are actually patches in queue. Previously the backporting process for the older branches often happened right before actually releasing a new version with no Sunday in between. Thus no email for those. >> 2. I don't expect any 1.8 releases for the nearer future, > > So I had a quick look. Last one was 2 months ago, pending fixes there > are mostly non-critical so I think we can make it wait a bit more. That's exactly what I assumed. >> so the bot >> will continue to annoy the list about an optimal release date on >> December, 24th which is long in the past. Not acting on the emails and >> the calculated date makes this whole "optimal" release date calculation >> rather useless. > > Not that much because it bores us and adds pressure on the stable team > to produce a release to shut them up. The bot is only a human manipulation > tool, nothing more. Yes. That's what I was attempting to say: I've never seen a release at the calculated "optimal release date". If that's never happening we could also employ a random number generator for the "optimal release date". >> 3. They are "boring": One does not need to be reminded about the same >> bugs every week, with a single addition buried somewhere deep in the list. >> >> Proposal: >> >> - Merge the 4 emails into a single one. Alternatively make sure they >> thread so that they can be collapsed within the recipients mailers. > > I'd rather not merge them into a single one because having a visual > reminder of a rotting branch is useful, however I agree that having The branch information could be put into the subject. Like this: stable-bot: Bugfixes waiting for a release 2.1 (60), 2.0 (50), 1.9 (34) > a single thread would be nice! Also we might possibly prefer to split > the list of pending patches from the announces of desired releases. > > But I'm having an idea based on what we're doing right now with the > backports: the reality is that older stable branches need to move slower > than recent ones. So the algorithm calculating the delays should be > adjusted to modulate the delay based on the branch's age. And very likely > it should avoid talking about a branch when the expected release date is > more than 20 days ahead, and maybe talk about it less often if the date > was missed (e.g. once every two weeks only, then once a month, i.e. > when the age is 7-13 days, then 21-27, then 35-41, then 65-71, then > 95-101, then 125-131 and so on). > > In addition, I think that once we emit a technical version (an odd one) > we can stop talking about the previous one. Thus, we have 2.1 so we can > stop talking about 1.9 at all. It will also help remind users that it > is about to disappear. > >> - Instead of listing all patches backported just list what *changed* in >> the past week. This would make the emails more interesting, because they >> contain *new* information. Or list all of them with a special 'new >> patches' section at the top. > > That's an interesting idea. What would you think about this then : > > - limited set of announces as detailed above ; > - one mail per branch (threaded) with only the changes since > the last announce ; > - a summary one at the end of the thread with a summary of all > pending patches for all supported branches. I'd make the summary the top level email of the thread, because the first email is the one that's most readily available. It should also be easier to implement, because the other ones can simply be 'In-Reply-To' that summary. Threading would solve most of the pain points for me, because the emails will nicely be merged on both my computer and my phone. For the remaining points I don't really care that much. I'll leave this up to the people that actually read the emails. I'm currently just marking them as read without taking a single look :-) Most of by curiosity is satisfied using git and the bug list on haproxy.org. Best re
Re: stable-bot: WARNING: 54 bug fixes in queue for next release - 2.1
Hi Tim, On Wed, Feb 12, 2020 at 04:36:58PM +0100, Tim Düsterhus wrote: > > Thus the computed ideal release date for 2.1.3 would be 2020/02/03, which > > was one week ago. > > [...] > > --- > > The haproxy stable-bot is freely provided by HAProxy Technologies to help > > improve the quality of each HAProxy release. If you have any issue with > > these emails or if you want to suggest some improvements, please post them > > on the list so that the solutions suiting the most users can be found. > > > > It appears that with the new backporting helper scripts you immediately > backport fixes, instead of doing that in bulk whenever you feel like a > new release. This causes this bot to send more emails than before. It's > regularly 4 emails every Sunday now. I don't think the bot gets triggered on new patches additions, though I could be wrong. Instead I think that as it now announces 4 versions, the messages are becoming more visible. > I assume that 1.7 and lower is already excluded from the emails. It seems to to me as well. > 1. Can we get a 2.1 release in the next days? I'm primarily asking > because of the backported Lua package path patches :-) Comment ignored, as requested :-) Others have been requesting it as well for about a week now, it's just that it takes time and it's always hard to settle on something when you see issues accumulating. > 2. I don't expect any 1.8 releases for the nearer future, So I had a quick look. Last one was 2 months ago, pending fixes there are mostly non-critical so I think we can make it wait a bit more. > so the bot > will continue to annoy the list about an optimal release date on > December, 24th which is long in the past. Not acting on the emails and > the calculated date makes this whole "optimal" release date calculation > rather useless. Not that much because it bores us and adds pressure on the stable team to produce a release to shut them up. The bot is only a human manipulation tool, nothing more. > 3. They are "boring": One does not need to be reminded about the same > bugs every week, with a single addition buried somewhere deep in the list. > > Proposal: > > - Merge the 4 emails into a single one. Alternatively make sure they > thread so that they can be collapsed within the recipients mailers. I'd rather not merge them into a single one because having a visual reminder of a rotting branch is useful, however I agree that having a single thread would be nice! Also we might possibly prefer to split the list of pending patches from the announces of desired releases. But I'm having an idea based on what we're doing right now with the backports: the reality is that older stable branches need to move slower than recent ones. So the algorithm calculating the delays should be adjusted to modulate the delay based on the branch's age. And very likely it should avoid talking about a branch when the expected release date is more than 20 days ahead, and maybe talk about it less often if the date was missed (e.g. once every two weeks only, then once a month, i.e. when the age is 7-13 days, then 21-27, then 35-41, then 65-71, then 95-101, then 125-131 and so on). In addition, I think that once we emit a technical version (an odd one) we can stop talking about the previous one. Thus, we have 2.1 so we can stop talking about 1.9 at all. It will also help remind users that it is about to disappear. > - Instead of listing all patches backported just list what *changed* in > the past week. This would make the emails more interesting, because they > contain *new* information. Or list all of them with a special 'new > patches' section at the top. That's an interesting idea. What would you think about this then : - limited set of announces as detailed above ; - one mail per branch (threaded) with only the changes since the last announce ; - a summary one at the end of the thread with a summary of all pending patches for all supported branches. I really want to have the last one so that we don't forget the critical bug merged at the beginning that deserves a quick fix that we didn't have the time to emit due to being at a conference and that we later forgot about, you see. I remember having let some versions rot for a long time with very important fixes in them. When you're on the backporter side, you remember having done the painful backport work and you never know if a release was emitted with this or that fix. For users it's the opposite, they need their fixes in a released version. This complete list is what reminds the divergence between what one thinks he's done and what others expect. Note, I'm commenting on the process and what we'd like to have, but I'm not the one maintaining the script, I don't know how feasible all of this is :-) Cheers, Willy
Re: stable-bot: WARNING: 54 bug fixes in queue for next release - 2.1
Willy, Am 12.02.20 um 16:36 schrieb Tim Düsterhus: > 1. Can we get a 2.1 release in the next days? I'm primarily asking > because of the backported Lua package path patches :-) Talk about timing. I'm seeing a 2.1.3 tag in git now. So ignore that point (1). Best regards Tim Düsterhus
Re: stable-bot: WARNING: 54 bug fixes in queue for next release - 2.1
List, Willy, [removed bot from Cc] Am 09.02.20 um 01:00 schrieb stable-...@haproxy.com: > This is a friendly bot that watches fixes pending for the next haproxy-stable > release! One such e-mail is sent periodically once patches are waiting in > the last maintenance branch, and an ideal release date is computed based on > the severity of these fixes and their merge date. Responses to this mail > must be sent to the mailing list. > > Last release 2.1.2 was issued on 2019/12/21. There are currently 54 patches > in the queue cut down this way: > - 2 MAJOR, first one merged on 2020/01/20 > - 20 MEDIUM, first one merged on 2020/01/09 > - 32 MINOR, first one merged on 2020/01/07 > > Thus the computed ideal release date for 2.1.3 would be 2020/02/03, which was > one week ago. > [...] > --- > The haproxy stable-bot is freely provided by HAProxy Technologies to help > improve the quality of each HAProxy release. If you have any issue with > these emails or if you want to suggest some improvements, please post them on > the list so that the solutions suiting the most users can be found. > It appears that with the new backporting helper scripts you immediately backport fixes, instead of doing that in bulk whenever you feel like a new release. This causes this bot to send more emails than before. It's regularly 4 emails every Sunday now. I assume that 1.7 and lower is already excluded from the emails. 1. Can we get a 2.1 release in the next days? I'm primarily asking because of the backported Lua package path patches :-) 2. I don't expect any 1.8 releases for the nearer future, so the bot will continue to annoy the list about an optimal release date on December, 24th which is long in the past. Not acting on the emails and the calculated date makes this whole "optimal" release date calculation rather useless. 3. They are "boring": One does not need to be reminded about the same bugs every week, with a single addition buried somewhere deep in the list. Proposal: - Merge the 4 emails into a single one. Alternatively make sure they thread so that they can be collapsed within the recipients mailers. - Instead of listing all patches backported just list what *changed* in the past week. This would make the emails more interesting, because they contain *new* information. Or list all of them with a special 'new patches' section at the top. Best regards Tim Düsterhus
