New releases for bugfixes

Harald Sitter sitter at kde.org
Thu Sep 8 11:25:10 BST 2022


On Thu, Sep 8, 2022 at 8:30 AM Sven Brauch <mail at svenbrauch.de> wrote:
>
> Hi,
>
> On 9/7/22 17:28, Harald Sitter wrote:
> > On Wed, Sep 7, 2022 at 5:20 PM <mail at flherne.uk> 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.

You'll really have to enlighten me what it looks like when kate makes
a release decision. I suspect we are talking about different things.

> 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.

Why?

> Also consider that a lot of people will set
> these fields in the tracker which are not aware of this policy.

I am sure Nate was envisioning some sort of auditing :) A random user
setting their bug vhi most certainly wouldn't warrant an emergency
release.

> I'd
> instead leave the decision to the project maintainers and they can voice
> it by writing an email to some list.

The way I understand the maintainer would do this?

- user creates bug report: foo crashes on startup
- you identify this as a serious problem because it crashes on first start
- you set the priority vhi
- you fix the bug
- you ask the release team to spin an emergency release on account of
having fixed a vhi bug
- release team makes release

Just to be clear, I'm not sure we need the paperwork of having a bug
and setting it vhi, but we probably do need some workflow to hold on
to. The release team won't be happy if everyone starts asking for
releases because they fixed some random bug. There certainly needs to
be some explanation of why this bug requires immediate fixing. So,
long story short the release team would have to ultimately decide if
this fix is really worth the hassle based on "something".

HS


More information about the kde-devel mailing list