Re: kio-extras versions on Bugzilla
I like that. Further question on details - I can see any bug filed against (for example) a specific git commit is eventually fixed by a released version. Do you consider it really filed against that version, or just fixed in that version, which didn't actually exist at the time, and no longer (hopefully) exhibits the bug) or against the previously released version (where it might not exist if it was introduced by a later commit.? There is a field for "fixed in" so I don't see any reason to change the "filed against" version. Am I missing something? On 6/15/23 11:30, Nate Graham wrote: The inherent challenge here is that everything reported against a git version eventually turns into a report against a specific released version once that version gets released. Ideally all such bug reports would have the version number changed accordingly to the appropriate number once the release is made. But that sounds really challenging to do. In the absence of that, maybe just "git stable branch" and "git master branch"? Nate On 6/15/23 09:14, Jack wrote: I'll also ask what to do for reporting against head of a git branch other than master? For programs that have a release or stable branch (often named for the release number) there is a big difference between head of that branch and git master. For example, KMyMoney has 5.1 branch. Unfortunately, I don't know if there is any way for this naming to be consistent across applications and frameworks and unless something like "git production branch." Thoughts? On 6/15/23 09:26, Nate Graham wrote: My preference would be for "git master" but I'll gladly go with any alternative consensus. What I think matters more is to get *something* standardized. Nate On 6/15/23 00:52, Heiko Becker wrote: On 6/14/23 20:15, Justin Zobel wrote: I asked Nate but he said versions on Bugzilla are added by a script. Can you please add git-master as a version for kio-extras on Bugzilla on your next batch of updates, thank you. On Thursday, 15 June 2023 04:17:09 CEST, Nate Graham wrote: ...And while we're doing this, maybe we can coordinate on a consistent name for it. I see we use "master", "git master" and "git-master" in various different places. While it's true that a script is used to add Gear versions to Bugzilla, it reads those versions from CMake's project(). So it'll not be useful without a bit of hacking, once we decide on a consistent name. Regards, Heiko
Re: kio-extras versions on Bugzilla
I'll also ask what to do for reporting against head of a git branch other than master? For programs that have a release or stable branch (often named for the release number) there is a big difference between head of that branch and git master. For example, KMyMoney has 5.1 branch. Unfortunately, I don't know if there is any way for this naming to be consistent across applications and frameworks and unless something like "git production branch." Thoughts? On 6/15/23 09:26, Nate Graham wrote: My preference would be for "git master" but I'll gladly go with any alternative consensus. What I think matters more is to get *something* standardized. Nate On 6/15/23 00:52, Heiko Becker wrote: On 6/14/23 20:15, Justin Zobel wrote: I asked Nate but he said versions on Bugzilla are added by a script. Can you please add git-master as a version for kio-extras on Bugzilla on your next batch of updates, thank you. On Thursday, 15 June 2023 04:17:09 CEST, Nate Graham wrote: ...And while we're doing this, maybe we can coordinate on a consistent name for it. I see we use "master", "git master" and "git-master" in various different places. While it's true that a script is used to add Gear versions to Bugzilla, it reads those versions from CMake's project(). So it'll not be useful without a bit of hacking, once we decide on a consistent name. Regards, Heiko
Re: Amor Game
On 2022.12.22 05:59, Justin Zobel wrote: For some reason, the reply emails aren't coming to me. I have seen the replies though on the mailing list web interface. Can we add it back in if it compiles and works as it is carried in Fedora but hasn't been updated for a while due to the lack of tarballs. On Thu, Dec 22, 2022 at 2:18 AM Justin Zobel wrote: > > Is this no longer released? No tags since 2015. > > https://invent.kde.org/games/amor Useless info: Gentoo provide a build from git master. I just tried it and it works. Question: Does the amor team want to support a released version? Someone would have to handle release related tasks, and there would likely be an increase in bug reports.
Re: ghostwriter KDE Gear inclusion
On 2022.11.01 14:09, Megan wrote: Nor super sure, the issue i mentioned in the kde-core-devel review thread of all the icons on the status bar having the same "broken" icon is still there. > Are you sure you want to release something to the world that is that hard to use? Well technically the app has been released in the wild for years, and you are the first person to raise the issue. Unfortunately I cannot replicate it and will need your help to do so. I’m thinking there must be something unique to your system’s configuration. What Linux distro are you using? What Qt version? Is the Qt you are using the system default or custom built (with kdesrc-build)? If custom built, did you use freetype or harfbuzz for the configuration? Anything else you could add to that? I will set up a VM with your configuration and try to replicate the issue again. Thank you very much! I help support KMyMoney, and we get the occasional complaint that some/many of the icons are missing, and it usually comes down to needing to choose a different icon theme. I have no idea if that is the case here, as I doubt Albert uses some obscure icon-theme, but it might be worth checking. Jack -- Megan ghostwriter developer On Tue, Nov 1, 2022, at 3:20 AM, Albert Astals Cid wrote: > El dimarts, 1 de novembre de 2022, a les 6:43:07 (CET), Megan va escriure: >> No worries. I hadn't expected to make this next release. But I presume >> the release cycle after will be okay? > > Nor super sure, the issue i mentioned in the kde-core-devel review thread of > all the icons on the status bar having the same "broken" icon is still there. > > Are you sure you want to release something to the world that is that hard to > use? > > Cheers, > Albert > >> >> Thanks! >> >> On 10/30/22 16:09, Albert Astals Cid wrote: >> > El diumenge, 30 d’octubre de 2022, a les 8:25:16 (CET), Megan va escriure: >> >> Hello, >> >> >> >> The ghostwriter app <https://invent.kde.org/office/ghostwriter> has just >> >> exited KDE review. As such, I would like to request that it please be >> >> included for KDE Gear releases. If there is anything you need me to do >> >> on my end, please let me know. >> > >> > As mentioned in the Mobile Gear thread i think we're too late in the >> > schedule to add a bunch of new apps. >> > >> > Cheers, >> > >> >Albert >> >> >> >> Thanks! >> >> >> >> Megan
Re: Umbrello, hybrid repository, Applications/17.08
On 2017.07.16 18:11, Luigi Toscano wrote: Hi all, umbrello follows an hybrid structure (both Qt4 and Qt5 version at the same time, with a lot of if-defs) which poses some complications to our infrastructure. The maintainer turned on the KF5 version for non-Windows platform in Applications/17.08 today: You can read my comments, but in a nutshell: - the English documentation use a trick (the cmake equivalent of sed) to use the native DTD of Frameworks documentation; - the translated DTDs can't do the same. So they will rely on the DTD of the original - when the translated documentation are injected back, as it happens now for KF5 applications, they will introduce an implicit dependency on KDELibs4Support, which is not defined. I tried to explain the issue with the documentation in the past but with no success. There is also a similar issue related to the usage of a piece of documentation on its own inside the program. The stated reason for keeping this hybrid model is the support of Windows. Now, I think that it's possible to keep this: - keep a "kdelibs4" branch for Windows, commit there the bugfixes - upmerge into "master" (or "Applications/xy.zt"), which would be pure Qt5. I would like to ask to revert the change and keep umbrello officially kdelibs4, and work to move to pure Qt5 before Applications 17.12 (aka fixing the issues on Windows). Otherwise I will have to workaround this in the release scripts in various ways: - not injecting the localized documentation (at least visible on the website) - adding an extra dependency to kdelibs4support in the umbrello cmake code - fixing the DTD while injecting the localized documentation (definitely hard) The last one would be a special rule just for one program, which takes time for no reasons and add a maintenance cost. I personally don't like how the common rule and expectation has not been followed for this repository, which introduces difficulties for the rest of the community. Ciao -- Luigi Luigi, I have not used KDE/Windows in quite a while, but are they not capable of handling Frameworks and Qt5 based builds? I do not have my Windows box handy to actually check myself. Jack
