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
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-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: Cleaning up cdash.org integration, what to do, or any hidden usage still?
On Mon, Sep 5, 2022 at 10:18 AM Friedrich W. H. Kossebau wrote: > > > T3) Add a note on the respective Wiki page about being outdated: > > > https://techbase.kde.org/Development/CMake/DashboardBuilds > > Anyone can tell what the official way to tag a page as outdated/historic is on > techbase? I've marked the page as archived. Regards, Eli
