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
