Re: New releases for bugfixes
On 2022-09-06 19:41, Nate Graham wrote: To revive this thread, I think the issue is that it feels sort of subjective what kind of bugs are bad enough that we think like a new release is worth it. So maybe we can try to get specific and say that we should make a new release for fixes of Bugzilla bug reports where: - Priority is VHI or HI - Severity is critical, grave, or major - Possibly also the "crash" severity? What do people think about that? Nate Thanks for trying to progress this, but I don't see the purpose of such a policy. The decision to make an extra release is quite objective really -- it's a concrete yes/no decision with known costs and a fairly clear estimate of the benefit to users. Triaging of bugs is far *more* subjective, especially if they're (partially) feature requests, because the solution and its impact are often rather hypothetical and because there are so many more options to select. In most projects the maintainers who'd make a release decision are the same people who triage bugs, so this policy would only add 'paperwork' while leaving the choice in the same hands. Such a rigid policy would frequently give undesired decisions in practice, for example fixes for "HI" issues that involve code changes too large for a bugfix release or "crash" bugs that only occur in very rare circumstances. The result would either be routine exceptions to the policy, which would undermine the point of having it, or maintainers being pressured to alter bug priorities to produce the correct decision at the cost of wasted time and possibly less-accurate bug tagging. -Francis H
Re: New releases for bugfixes
On Wed, Sep 7, 2022 at 5:20 PM wrote: > In most projects the maintainers who'd make a release decision are the > same people who triage bugs You quite clearly have no idea how this community works. I'll thank you not to misdirect discussions. Ta
Re: New releases for bugfixes
On 2022-09-07 16:28, Harald Sitter wrote: On Wed, Sep 7, 2022 at 5:20 PM wrote: In most projects the maintainers who'd make a release decision are the same people who triage bugs You quite clearly have no idea how this community works. I'll thank you not to misdirect discussions. Ta I find that quite insulting. I've *been* the guy who had to ask for a new KDevelop release because a trivial patch turned out to crash the parser with a specific distro's Python setup. When I had time to work on kdev-python I spent quite a bit of effort triaging our bugs and deciding which to work on, and then wbich fixes were reasonable to backport. I was in the room at Akademy with the whole team doing much the same. We never had any separation between the people regularly doing bug triaging and the maintainers, and until KDevelop joined the release service quite recently the same people did all the releases too. If you think my perspective from one corner of KDE is skewed, or outdated because I've not been active much in the last couple of years, I'd be happy to hear it and you'd probably be right. But a one-line brush-off as if I've never been part of the community...that does upset me. -Francis H
Re: New releases for bugfixes
Hi, On 9/7/22 17:28, Harald Sitter wrote: On Wed, Sep 7, 2022 at 5:20 PM wrote: In most projects the maintainers who'd make a release decision are the same people who triage bugs You quite clearly have no idea how this community works. I'll thank you not to misdirect discussions. in kate it also works very much like this, so while "most projects" is a bit of a stretch, there are certainly relevant projects where this is the case, so Francis' point is well worth discussing. In fact I share Francis' concern, and I think re-using the severity/priority fields to make this decision will add more confusion than it provides value. Also consider that a lot of people will set these fields in the tracker which are not aware of this policy. I'd instead leave the decision to the project maintainers and they can voice it by writing an email to some list. It would be nice if you could address the point if you disagree, instead of brushing it off without explanation. Greetings, Sven OpenPGP_0xA4AAD0019BE03F15.asc Description: OpenPGP public key OpenPGP_signature Description: OpenPGP digital signature
