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: Aura Browser in KDE Review
Hi, Thanks for the reviews. * Application crash on shutdown fixed * Desktop file issues have been fixed * Executable name has been fixed to be lowercase * AppStream file has been added * SPDX licensing has been fixed * Reuse compliance has been added * KDE CI has been added * Screenshot merge request has been opened https://invent.kde.org/websites/product-screenshots/-/merge_requests/30 * * i18n issues have been fixed * Messages.sh has been fixed The third-party are sub-optimal but there is no external library / package for this, so for now this will stay in, I have tested building with GCC and CLANG both throw similar warnings on the third-party they do not break the build, it compiles ok. If third party is still a blocker I can remove the AdBlock feature completely for now, until I have a better solution. Regards, Aditya From: Aditya Mehra Sent: Friday, August 26, 2022 7:57 PM To: kde-core-devel Subject: Aura Browser in KDE Review Hi, Aura Browser is in KDE Review and would like to release it along with Plasma Bigscreen Aura browser is a web browser specifically designed to work with remote controls and key navigation for Plasma Bigscreen, it supports a virtual mouse cursor and multiple tabs it also includes a third party AdBlock from brave browser based on easy list. You can find the repository here: https://invent.kde.org/plasma-bigscreen/aura-browser Request to please review Aura Browser. Regards, Aditya
Re: Plank Player in KDE Review
Hi, Thanks for the reviews. * Desktop file issues have been fixed * AppStream file has been added * Reuse compliance has been added * KDE CI has been added * Screenshot merge request has been opened https://invent.kde.org/websites/product-screenshots/-/merge_requests/30 * i18n issues have been fixed * Messages.sh has been added * Folders are not sorted case sensitive Regards, Aditya From: Aditya Mehra Sent: Friday, August 26, 2022 7:59 PM To: kde-core-devel Subject: Plank Player in KDE Review Hi, Plank Player is in KDE Review and would like to release it along with Plasma Bigscreen Plank Player is a local media player specifically designed to work with remote controls and key navigation for bigscreen. You can find the repository here: https://invent.kde.org/plasma-bigscreen/plank-player Request to please review Plank Player. Regards, Aditya
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
The KDE Patchset Collection has been rebased on top of Qt 5.15.6
The KDE Patchset Collection has been rebased on top of Qt 5.15.6 Cheers, Albert
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
