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 regards Tim Düsterhus
