Re: New releases for bugfixes
Am 19.09.22 um 14:57 schrieb Neal Gompa: On Sat, Sep 10, 2022 at 5:41 AM Reindl Harald wrote: Am 09.09.22 um 11:42 schrieb samuel ammonius: Thanks. I hadn't thought of a lot of these issues before. I think the biggest one is that If there's an update that the package manager didn'tknow about, the user would have to update right after installing, and the bug would come back if the user re-installed or updated the app. Sorry everybody no the biggest issue on the userside is that nobody wants every random application tamper the system if i want applications asking me about updates i could have stayed at windows and "yum upgrade" was the main reason for Linux when you open that can of worms imagine where it ends security wise it's a nightmare because you not only have the distribution you need to trust - intrusion on any upstream would directly hit you at any random point in time while distribution updates are usually tested at least by some people and changes reviewed by downstream maintainers and who does the work and deal with bugreports "the update of kate destroyed it on my system and i don't know why nor how i revert it" with the package manager i type "dnf downgrade kate", file a bug against the distribution and kde upstream isn't involved at all upstream opensource developers write the code, that's it, they don't and shouldn't need to care about every downstream distribution and it's pitfalls - it's wasted time because that's what downstream component maintainers are for the fedora maintainer from kde likely has no knowledge about Gentoo, Ubuntu, SuSE for good reasons and you think blow that load to upstream developers would help anybody? Well, actually, most of us do know each other and we do collaborate from time to time. I personally know Fabian Vogt (the maintainer of the KDE stack in SUSE distributions) and I talk to Rik Mills (the Kubuntu maintainer) every once in a while. Same goes for Mageia, OpenMandriva, Debian, and others. don't change the fact that downstream and upstream are different worlds at the end of the day when it comes to apply a bufix patch Admittedly, I don't know who works on KDE Plasma for Gentoo, but I'm peripherally aware of their work. As maintainers of KDE software in our respective distributions, it's our job to bring our concerns upstream as needed. But also, when distributions have a conflict, we *all* have to work together to figure out a solution. If we don't, we risk a situation where KDE eventually evolves into other similarly-sized desktop environment projects where they give the downstream stakeholders the finger because they don't trust them. but the proposed idea was BYPASS you and apply updates directly from upstream Also, many of the upstream KDE Plasma developers are in fact distro developers. It's not the majority anymore like it was in the old days, but a good chunk of them are. but hardly the majority and even if that could change any time - especailly for small bugfix patches it's irrelevant when one comes to the idea apply them directly from upstream up to "build them local from source automagically" the general rule is "upstream is upstream, distro is distro" and for the sake of god that don#t mean they don't talk to each other
Re: New releases for bugfixes
On Sat, Sep 10, 2022 at 5:41 AM Reindl Harald wrote: > > > > Am 09.09.22 um 11:42 schrieb samuel ammonius: > > Thanks. I hadn't thought of a lot of these issues before. > > > > I think the biggest one is that If there's an update that the package > > manager didn'tknow about, the user would have to update right after > > installing, and > > the bug would come back if the user re-installed or updated the app. Sorry > > everybody > no the biggest issue on the userside is that nobody wants every random > application tamper the system > > if i want applications asking me about updates i could have stayed at > windows and "yum upgrade" was the main reason for Linux > > when you open that can of worms imagine where it ends > > security wise it's a nightmare because you not only have the > distribution you need to trust - intrusion on any upstream would > directly hit you at any random point in time while distribution updates > are usually tested at least by some people and changes reviewed by > downstream maintainers > > and who does the work and deal with bugreports "the update of kate > destroyed it on my system and i don't know why nor how i revert it" > > with the package manager i type "dnf downgrade kate", file a bug against > the distribution and kde upstream isn't involved at all > > upstream opensource developers write the code, that's it, they don't and > shouldn't need to care about every downstream distribution and it's > pitfalls - it's wasted time because that's what downstream component > maintainers are for > > the fedora maintainer from kde likely has no knowledge about Gentoo, > Ubuntu, SuSE for good reasons and you think blow that load to upstream > developers would help anybody? > Well, actually, most of us do know each other and we do collaborate from time to time. I personally know Fabian Vogt (the maintainer of the KDE stack in SUSE distributions) and I talk to Rik Mills (the Kubuntu maintainer) every once in a while. Same goes for Mageia, OpenMandriva, Debian, and others. Admittedly, I don't know who works on KDE Plasma for Gentoo, but I'm peripherally aware of their work. As maintainers of KDE software in our respective distributions, it's our job to bring our concerns upstream as needed. But also, when distributions have a conflict, we *all* have to work together to figure out a solution. If we don't, we risk a situation where KDE eventually evolves into other similarly-sized desktop environment projects where they give the downstream stakeholders the finger because they don't trust them. Also, many of the upstream KDE Plasma developers are in fact distro developers. It's not the majority anymore like it was in the old days, but a good chunk of them are. -- 真実はいつも一つ！/ Always, there's only one truth!
Re: New releases for bugfixes
Am 09.09.22 um 11:42 schrieb samuel ammonius: Thanks. I hadn't thought of a lot of these issues before. I think the biggest one is that If there's an update that the package manager didn'tknow about, the user would have to update right after installing, and the bug would come back if the user re-installed or updated the app. Sorry everybody no the biggest issue on the userside is that nobody wants every random application tamper the system if i want applications asking me about updates i could have stayed at windows and "yum upgrade" was the main reason for Linux when you open that can of worms imagine where it ends security wise it's a nightmare because you not only have the distribution you need to trust - intrusion on any upstream would directly hit you at any random point in time while distribution updates are usually tested at least by some people and changes reviewed by downstream maintainers and who does the work and deal with bugreports "the update of kate destroyed it on my system and i don't know why nor how i revert it" with the package manager i type "dnf downgrade kate", file a bug against the distribution and kde upstream isn't involved at all upstream opensource developers write the code, that's it, they don't and shouldn't need to care about every downstream distribution and it's pitfalls - it's wasted time because that's what downstream component maintainers are for the fedora maintainer from kde likely has no knowledge about Gentoo, Ubuntu, SuSE for good reasons and you think blow that load to upstream developers would help anybody? wasted time and resources
Re: New releases for bugfixes
Thanks. I hadn't thought of a lot of these issues before. I think the biggest one is that If there's an update that the package manager didn't know about, the user would have to update right after installing, and the bug would come back if the user re-installed or updated the app. Sorry everybody.
Re: New releases for bugfixes
On Thu, Sep 8, 2022 at 12:51 PM samuel ammonius wrote: > Bug fixes don't change the entire package, only the executable, so > why can't apps just be programmed to update themselves? There > could be precompiled binaries stored on the git repos of each project > for a few CPU architectures, or maybe the app could even recompile > itself inside /tmp since most systems KDE runs on come with a compiler > by default (and macros could also be stored so that apps have the > same configuration throughout updates). > That depends entirely on whether the fix was in the executable or a library that it links to. If a library we can't be updating libraries willy nilly on user devices. Plus think about how it was built, which use flags in gentoo, which compile flags, etc. Which distribution specific patches were applied. Once you take all that into account there are many many ways to build kde applications. > > Cheers, > Sam > > On Thu, Sep 8, 2022 at 11:58 AM Heiko Becker wrote: > >> On Thursday, 8 September 2022 13:59:43 CEST, Ahmad Samir wrote: >> > From the git-archive manual page: >> > >> > «git archive behaves differently when given a tree ID versus >> > when given a commit ID or tag ID. In the first case the current >> > time is used as the modification time of each file in the >> > archive. In the latter case the commit time as recorded in the >> > referenced commit object is used instead. Additionally the >> > commit ID is stored in a global extended pax header if the tar >> > format is used; it can be extracted using git get-tar-commit-id. >> > In ZIP files it is stored as a file comment.» >> >> Before anybody tries that *now*, at least for Gear the tarballs are >> currently created with git archive --remote=kde:$repo $branch .. >> So they currently won't have that information. >> >> Regards, >> Heiko >> >>
Re: New releases for bugfixes
I'm sad other emails sound kinda harsh and without detailed elaboration. Folks, please, let's keep the discussion peaceful. Different people have different set of knowledge, that's life. Angry comments would push people away from the community. On Thu, 2022-09-08 at 19:23 -0230, samuel ammonius wrote: > > and you marry upstream binaries with the distribution update-manager how? > > You don't need to. The app can just check the latest bugfix for that version > on git > and install it if it isn't installed. I don't understand why you stress the > need for the > package manager to have anything to do with the update if it's just a bug fix. You see: when you have versioning of the same file managed by two or more programs, you will inevitably get into conflicts. One program updated the file to one version, then another program overwrote the file with something else. I think it is clear that this will result in all kinds of problems. The obvious one is that your bugfix-update may get overwritten by something else. And this is exactly what you suggest. You suggest we have program update itself, disregarding the package manager. That's not gonna end well. Then there's another problem: tracking of the files. If your "autoupdater" put a new file to the system, and later the user decides "I'm not using the app, let's just remove it", the file would just be left there. Because only package manager knows what files contains the program, but your autoupdater didn't communicate that new file to the package manager. So, as the number of such apps grows bigger, you would have junk all over the system. On a related note, you as a user or developer often want to know where a file on your syste came from. At my $WORK we bulid a system with some proprietary apps, it's a very old project, and the building process for quite some time would just put configs/binaries/stuff into the system, without consulting package manager. While this didn't result in conflicts since the filenames were mostly unique, however this did have a problem, where you often just don't know where a given file came from. You can't run a package manager, point it to the file, and ask it "do you know who owns this file?". We later migrated to creating packages that hold all of that stuff, which greatly simplified things.
Re: New releases for bugfixes
Am 08.09.22 um 23:53 schrieb samuel ammonius: > and you marry upstream binaries with the distribution update-manager how? You don't need to. The app can just check the latest bugfix for that version on git and install it if it isn't installed. I don't understand why you stress the need for the package manager to have anything to do with the update if it's just a bug fix no it's not just a bugfix when you start mixing random binaries or self compiled stuff with distribution binaries maybe you guys inform yourself how a linux distribution works - on Fedoar at example every Fedoar releaae builds everything from scratch with the same GCC, glibc and tons of other libraries which differ largely between distro releases what you dream about is flatpak - sorry, one of my main reasons switching to linux was a central pakcage management
Re: New releases for bugfixes
> and you marry upstream binaries with the distribution update-manager how? You don't need to. The app can just check the latest bugfix for that version on git and install it if it isn't installed. I don't understand why you stress the need for the package manager to have anything to do with the update if it's just a bug fix. > in the way that distributions have different library versions Ok, I think I get your point. Some libraries add/remove/replace features and KDE projects may be using macros to make all library versions work. I hadn't thought of that. > bla So the teensy weensy security risk is suddenly a huge deal and when I try to fix it for you I'm talking nonsense? > more space than some of my systems at a whole It's like 30 megabytes. > a little bit of more realistic view for such nosense would be nice too > if anything you propose would become real i had to switch away from KDE If you got a notification saying "Minor bug fix released for Kate. Would you like to install an update without using the package manager?", would it be so bad that you would drop KDE? Because that's all I was suggesting (only without the "without the package manager" part because I was just communicating my point).
Re: New releases for bugfixes
Am 08.09.22 um 22:24 schrieb samuel ammonius: > because outside the windows world central package management is the norm > and based on "least privileges" applications must not have the > permissions to change itself I didn't mean a background update. I meant the user could get a dialog or notification asking them to update, and if they press "yes" they can enter their root password and the app can update itself and restart. and you marry upstream binaries with the distribution update-manager how? > and for each distribution with different dependencies and libraries How does KDE have different dependencies for different distros? (To be honest though, I only mentioned this method because I thought having multiple options would advertise the idea in the second method) in the way that distributions have different library versions if you don't care for security The security risk is very small, and it can be fixed in a lot of different ways. The app could create a folder that only root can access within the /tmp folder. If even that's not secure enough, the app could create source files with just "#define MAIN_CPP_SOURCE" and compile with "-DMAIN_CPP_SOURCE=[the source code] so that it never has to be stored on the disk before being compiled. bla > which distribution installs a compiler by default so that one can avoid > touching it? I don't think I've ever used one that /doesn't/ come with at least gcc installed i didn't see a defualt install for a long time but have a compiler on 99,9% of all systems is useless bloatware I've tried Ubuntu, Debian, Fedora, and OpenSUSE. Now that I think about it though, they don't come with g++ installed, and they definitely don't come with Qt headers installed, but they don't take that much space more space than some of my systems at a whole It didn't take me 10 minutes to answer these questions in my head, so I don't see why you're trying to scrap the idea so quickly for its faults instead of trying to fix them. A bit of constructive criticism would be nice a little bit of more realistic view for such nosense would be nice too if anything you propose would become real i had to switch away from KDE
Re: New releases for bugfixes
> because outside the windows world central package management is the norm > and based on "least privileges" applications must not have the > permissions to change itself I didn't mean a background update. I meant the user could get a dialog or notification asking them to update, and if they press "yes" they can enter their root password and the app can update itself and restart. > and for each distribution with different dependencies and libraries How does KDE have different dependencies for different distros? (To be honest though, I only mentioned this method because I thought having multiple options would advertise the idea in the second method) > if you don't care for security The security risk is very small, and it can be fixed in a lot of different ways. The app could create a folder that only root can access within the /tmp folder. If even that's not secure enough, the app could create source files with just "#define MAIN_CPP_SOURCE" and compile with "-DMAIN_CPP_SOURCE=[the source code] so that it never has to be stored on the disk before being compiled. > which distribution installs a compiler by default so that one can avoid > touching it? I don't think I've ever used one that *doesn't* come with at least gcc installed. I've tried Ubuntu, Debian, Fedora, and OpenSUSE. Now that I think about it though, they don't come with g++ installed, and they definitely don't come with Qt headers installed, but they don't take that much space, and maybe they can also just be placed in /tmp and removed after the update. It didn't take me 10 minutes to answer these questions in my head, so I don't see why you're trying to scrap the idea so quickly for its faults instead of trying to fix them. A bit of constructive criticism would be nice. Cheers, Sam
Re: New releases for bugfixes
Am 08.09.22 um 20:50 schrieb samuel ammonius: Bug fixes don't change the entire package, only the executable, so why can't apps just be programmed to update themselves? because outside the windows world central package management is the norm and based on "least privileges" applications must not have the permissions to change itself could be precompiled binaries stored on the git repos of each project for a few CPU architectures and for each distribution with different depencdencies and libraries or maybe the app could even recompile itself inside /tmp if you don't care for security since most systems KDE runs on come with a compiler by default which distribution installs a compiler by default so that one can avoid touching it?
Re: New releases for bugfixes
Bug fixes don't change the entire package, only the executable, so why can't apps just be programmed to update themselves? There could be precompiled binaries stored on the git repos of each project for a few CPU architectures, or maybe the app could even recompile itself inside /tmp since most systems KDE runs on come with a compiler by default (and macros could also be stored so that apps have the same configuration throughout updates). Cheers, Sam On Thu, Sep 8, 2022 at 11:58 AM Heiko Becker wrote: > On Thursday, 8 September 2022 13:59:43 CEST, Ahmad Samir wrote: > > From the git-archive manual page: > > > > «git archive behaves differently when given a tree ID versus > > when given a commit ID or tag ID. In the first case the current > > time is used as the modification time of each file in the > > archive. In the latter case the commit time as recorded in the > > referenced commit object is used instead. Additionally the > > commit ID is stored in a global extended pax header if the tar > > format is used; it can be extracted using git get-tar-commit-id. > > In ZIP files it is stored as a file comment.» > > Before anybody tries that *now*, at least for Gear the tarballs are > currently created with git archive --remote=kde:$repo $branch .. > So they currently won't have that information. > > Regards, > Heiko > >
Re: New releases for bugfixes
On Thursday, 8 September 2022 13:59:43 CEST, Ahmad Samir wrote: From the git-archive manual page: «git archive behaves differently when given a tree ID versus when given a commit ID or tag ID. In the first case the current time is used as the modification time of each file in the archive. In the latter case the commit time as recorded in the referenced commit object is used instead. Additionally the commit ID is stored in a global extended pax header if the tar format is used; it can be extracted using git get-tar-commit-id. In ZIP files it is stored as a file comment.» Before anybody tries that *now*, at least for Gear the tarballs are currently created with git archive --remote=kde:$repo $branch .. So they currently won't have that information. Regards, Heiko
Re: New releases for bugfixes
On 9/8/22 05:51, Nicolas Fella wrote: Hi, I don't think Nate or anyone wants to propose a strict policy that when X then Y has to happen. That's just not how we operate in KDE. I do think it is valuable though to discuss and create some guidelines/shared understanding/soft policy that maintainers can use as a reference when making decisions. That would match very well how decisions and policies are made in KDE. Correct. My suggestion for a basic set of criteria was designed to be a suggestion, not an iron straitjacket. :) Things in KDE are not so rigid that we need to bind ourselves with strict rules that we never deviate from. Nate
Re: New releases for bugfixes
On 8/9/22 13:51, Nicolas Fella wrote: Hi, I don't think Nate or anyone wants to propose a strict policy that when X then Y has to happen. That's just not how we operate in KDE. I do think it is valuable though to discuss and create some guidelines/shared understanding/soft policy that maintainers can use as a reference when making decisions. That would match very well how decisions and policies are made in KDE. Cheers Nico As I said somewhere else in this thread, any fixes should be backported to the stable branch/tag in git (that is most likely the current work flow for the release teams). From the git-archive manual page: «git archive behaves differently when given a tree ID versus when given a commit ID or tag ID. In the first case the current time is used as the modification time of each file in the archive. In the latter case the commit time as recorded in the referenced commit object is used instead. Additionally the commit ID is stored in a global extended pax header if the tar format is used; it can be extracted using git get-tar-commit-id. In ZIP files it is stored as a file comment.» so: - backport fix to the stable branch - packagers can look at that branch to find what extra commits their downstream packages don't have yet Regards, Ahmad Samir OpenPGP_signature Description: OpenPGP digital signature
Re: New releases for bugfixes
Hi, I don't think Nate or anyone wants to propose a strict policy that when X then Y has to happen. That's just not how we operate in KDE. I do think it is valuable though to discuss and create some guidelines/shared understanding/soft policy that maintainers can use as a reference when making decisions. That would match very well how decisions and policies are made in KDE. Cheers Nico
Re: New releases for bugfixes
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 OpenPGP_0xA4AAD0019BE03F15.asc Description: OpenPGP public key OpenPGP_signature Description: OpenPGP digital signature
Re: New releases for bugfixes
On Thu, Sep 8, 2022 at 8:30 AM Sven Brauch wrote: > > 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. 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
Re: New releases for bugfixes
I'm sorry, I neither wanted to upset nor insult. frameworks has 83 projects, plasma has 65 projects, release service has 297 = 445 projects to which your blanket statement does not apply. Their releases run on rails, that's why Nate suggests a way to introduce additional stops, as it were. On Thu, Sep 8, 2022 at 3:44 AM wrote: > > 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
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: New releases for bugfixes
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
Re: New releases for bugfixes
On 8/25/22 22:59, Albert Astals Cid wrote: c) Who decides which bugs "are important" because for every bug, there's always a person out there that thinks it's the most important bug ever. d) What do we release? i.e. imagine we find one of those "important bugs" in dolphin and we have to release 22.08.0.1. Do we just release the 22.08 branch with any changes it may have had since the 22.08.0 release or do we create a special branch that only contains the new patch and release that? It's always subjective, but I was specifically thinking of bugs like https://bugs.kde.org/show_bug.cgi?id=458099 in which we accidentally introduced an API break and then fixed it. I was going to send out a patch request, but something like this really deserves a new release IMO, just in the interest of our API compatibility promise. Nate
Re: New releases for bugfixes
As a distro packaging it's much easier and more reliable to just let the new version get added automatically to our builds. As a release manager it shouldn't be any harder to automate making a new bugfix release. I do this already for Plasma when requested. It should be the default method. Jonathan On Thu, 25 Aug 2022 at 17:55, Nate Graham wrote: > Hello everyone, > Right now when we fix a significant bug in our software that may take a > while to reach users to to the release schedule of its repo, we contact > distros and ask them to backport it. This puts the burden on distros to > react to us. I'm wondering how people feel about KDE instead making > immediate point releases ourselves. Thus we would take responsibility > for releasing fixes for our own regressions, and distros that monitor > KDE infrastructure for new tarballs could be notified automatically. > > Thoughts? > > Nate >
Re: New releases for bugfixes
El dijous, 25 d’agost de 2022, a les 18:55:08 (CEST), Nate Graham va escriure: > Hello everyone, > Right now when we fix a significant bug in our software that may take a > while to reach users to to the release schedule of its repo, we contact > distros and ask them to backport it. This puts the burden on distros to > react to us. I'm wondering how people feel about KDE instead making > immediate point releases ourselves. Thus we would take responsibility > for releasing fixes for our own regressions, and distros that monitor > KDE infrastructure for new tarballs could be notified automatically. > > Thoughts? In theory it makes sense but there's some issues that need working out. a) Which version number to use if it's part of a (bigger release, Plasma, Frameworks, Gear). I guess the answer is to do x.y.z.k but we need to make sure all our tooling supports that b) Again, for repos that are part of a bigger release, this creates more work on the (from what i can see) relatively overloaded release folks so we may need to make sure this happens very seldom or recruit more releasers c) Who decides which bugs "are important" because for every bug, there's always a person out there that thinks it's the most important bug ever. d) What do we release? i.e. imagine we find one of those "important bugs" in dolphin and we have to release 22.08.0.1. Do we just release the 22.08 branch with any changes it may have had since the 22.08.0 release or do we create a special branch that only contains the new patch and release that? Cheers, Albert > > Nate
Re: New releases for bugfixes
Same here, I like the idea of point releases to fix impactful bugs. On Thu, Aug 25, 2022 at 6:56 PM Harald Sitter wrote: > make sense to me > > On Thu, Aug 25, 2022 at 6:55 PM Nate Graham wrote: > > > > Hello everyone, > > Right now when we fix a significant bug in our software that may take a > > while to reach users to to the release schedule of its repo, we contact > > distros and ask them to backport it. This puts the burden on distros to > > react to us. I'm wondering how people feel about KDE instead making > > immediate point releases ourselves. Thus we would take responsibility > > for releasing fixes for our own regressions, and distros that monitor > > KDE infrastructure for new tarballs could be notified automatically. > > > > Thoughts? > > > > Nate >
Re: New releases for bugfixes
make sense to me On Thu, Aug 25, 2022 at 6:55 PM Nate Graham wrote: > > Hello everyone, > Right now when we fix a significant bug in our software that may take a > while to reach users to to the release schedule of its repo, we contact > distros and ask them to backport it. This puts the burden on distros to > react to us. I'm wondering how people feel about KDE instead making > immediate point releases ourselves. Thus we would take responsibility > for releasing fixes for our own regressions, and distros that monitor > KDE infrastructure for new tarballs could be notified automatically. > > Thoughts? > > Nate
New releases for bugfixes
Hello everyone, Right now when we fix a significant bug in our software that may take a while to reach users to to the release schedule of its repo, we contact distros and ask them to backport it. This puts the burden on distros to react to us. I'm wondering how people feel about KDE instead making immediate point releases ourselves. Thus we would take responsibility for releasing fixes for our own regressions, and distros that monitor KDE infrastructure for new tarballs could be notified automatically. Thoughts? Nate
