New releases for bugfixes

[Sven Brauch]

Hi,

I think all 3 of us envision very similar things, we just have different 
things we think/talk about, and different understandings of Nate's 
suggestion. I for example understood that Nate suggests to make bugs 
matching the named criteria the *trigger* for making (or discussing) a 
new release. I think you understood it differently, i.e. the maintainers 
initiate this discussion.

On 9/8/22 12:25, Harald Sitter wrote:
 > The way I understand the maintainer would do this?

I'd also imagine pretty much this to happen, yes. But as you say, what 
actually triggers the release discussion is "you ask the release team to 
spin an emergency release". To me this is the decision which matters, 
made by the maintainer(s), and everything else is just paperwork to back 
that up.

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

Yes, agreed. IMO requiring a bug with certain flags set isn't very 
helpful. I'd rather suggest to go for something like "Out-of-schedule 
bugfix releases are only considered to fix bugs which severely impact an 
application's functionality for one of its core use cases" or the like, 
and then one can argue about whether this definition is met.

At which point the whole thing has nothing to do with bug tickets any 
more, which I understood was the core point Francis was also trying to make.

Greetings,
Sven
-------------- next part --------------
A non-text attachment was scrubbed...
Name: OpenPGP_0xA4AAD0019BE03F15.asc
Type: application/pgp-keys
Size: 3147 bytes
Desc: OpenPGP public key
URL: <http://mail.kde.org/pipermail/kde-devel/attachments/20220908/c95727a1/attachment.key>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: OpenPGP_signature
Type: application/pgp-signature
Size: 840 bytes
Desc: OpenPGP digital signature
URL: <http://mail.kde.org/pipermail/kde-devel/attachments/20220908/c95727a1/attachment.sig>