Re: Should we stop distributing source tarballs?
Am Freitag, 5. April 2024, 13:45:35 CEST schrieb Carl Schwan: > On Friday, April 5, 2024 12:04:28 PM CEST Albert Vaca Cintora wrote: > > - Tarballs should only be generated in a reproducible manner using > > scripts. Ideally by the CI only. > > - We should start to sign tarballs in the CI. > > I disagree. I want my tarball to be signed with my GPG key stored in my > Yubiky and not by a generic KDE key. It should be a proof that I as a > maintainer of a project did the release and not someone else. Same with the > upload to download.kde.org, while this adds some overhead in the process, I > think it is important that KDE Sysadmins are the one who move the tarball > to their final location and do some minimal check (checksum match, it's not > a random person doing the release, ...). Signing with a KDE key could have some benefits, though. It's far easier for distros (or users) to check KDE software against a single, well known key. On could mitigate the downside that you mentioned by having the script check the tag signature against a keyring of trusted keys. Cheers, Johannes signature.asc Description: This is a digitally signed message part.
Re: Defining a developer name for our applications metadata
Hi Albert, Am Dienstag, 30. Jänner 2024, 22:27:22 CET schrieb Albert Astals Cid: > "The KDE Community" is like "ATM Machine", KDE is *already* the community. I have to say this is definitely *not* like "ATM Machine". At least I hope nobody is saying "the C in KDE stands for Community"... ;-) Apart from that nitpick, no objection from me on either variant. Cheers, Johannes
Re: KDE Gear projects with failing CI (master) (23 January 2024)
Am Dienstag, 23. Jänner 2024, 22:11:23 CET schrieb Ben Cooksley: > > kipi-plugins - NEW > > > > * https://invent.kde.org/graphics/kipi-plugins/-/pipelines/589461 > > > > * CI fails to find libmediawiki > > Do we know how much this is still used, and whether KIPI can be retired? No objections from me. As far as kphotoalbum is concerned, we consider it dead (even though we still support building with libkipi). Cheers, Johannes signature.asc Description: This is a digitally signed message part.
Re: Unified internal communications channel
Hi David, Am Freitag, 8. Dezember 2023, 14:09:03 CET schrieb Laura David Hurka: > I had the idea for such a channel before. But I admit that I did not search > whether such a channel already exists. > > I would subscribe to a channel which is readable via email and has messages > like these examples: > [...] I think you touched an important issue there - we should define the scope of the proposed communication channel(s) and give guidelines for when and how to use them. There's no use in having another channel if people will end up sidestepping it because they were unsure if their topic was relevant. Cheers, Johannes
Re: Per project repository snapcraft files?
Hi! Am Donnerstag, 17. August 2023, 17:53:13 CEST schrieb Scarlett Moore: > Thoughts? I can't really weigh in on the more technical merits or problems. So here's my take on the practical implications: For me as a project maintainer, having snapcraft and flatpak files in the repo seems like a good thing. Not only does this enable a more direct integration with CI, but it may enable more direct communication between snap/flatpak authors and project maintainers. Cheers, Johannes
Re: Retiring Phabricator - Migrating tasks to Gitlab
Am Samstag, 27. Mai 2023, 23:13:08 CEST schrieb Ben Cooksley: > On Sun, May 28, 2023 at 8:24 AM Johannes Zarl-Zierl > wrote: > > I'm fine with having columns be mapped as labels. > > However, if it is easy to implement, having some columns be converted to > > milestones would be quite nice, since we have been using columns to track > > tasks related to our releases. > > I haven't started looking into the full detail of what is needed to bring > detail across yet, however I imagine that may require a degree of extra > work. > I'll comment more on this once i've examined the Gitlab and Phabricator > APIs I need to work with to do the data migration. If it helps, I can also do some manual cleanup on kphotoalbum after the migration. If we're the only affected project, it is probably a better investment of time for me to assigne ~40 issues to milestones than it is for you to develop an automated migration script... Cheers, Johannes
Re: Retiring Phabricator - Migrating tasks to Gitlab
That's great news! Am Montag, 22. Mai 2023, 17:17:50 CEST schrieb Wolthera: > Overall, I've noticed that milestones are best for collecting tasks > related to a release or a defined project (Say, a new tool, importer > or workflow), while the boards are better for if you need to track the > state of multiple issues, because Gitlab Free doesn't allow filtering > of issues on a board (only having columns for a specific issue label), > which effectively makes it a different UI for the issue list. Because > the board columns map to a label, it makes sense to have columns be > converted to labels for the vast majority of projects, yes. I'm fine with having columns be mapped as labels. However, if it is easy to implement, having some columns be converted to milestones would be quite nice, since we have been using columns to track tasks related to our releases. Cheers, Johannes
Re: "Gardening" old bugreports
Hi, Am Donnerstag, 19. Jänner 2023, 12:26:08 CET schrieb Nicolas Fella: > Am 19.01.23 um 04:04 schrieb Justin: > > The gardening team aims to find out if the bug reports are still > > relevant by involving the users who reported them in determining if > > they are still valid. This increases community involvement and helps > > KDE as there isn't anywhere near enough manpower to review the > > thousands upon thousands of bugs that haven't been touched in years. > > Anecdotally many people don't like such automated changes being done to > their bugreports that don't actually engage with the content of the report. Well, anecdotally you will mostly get feedback from people who don't like it. Unless something is exceptionally great, few people will take the time to speak out in favor of something that is already happening. > > The bugs that we are interacting with are ones that have not had any > > activity for over 2 years. We are simply trying to reinvigorate > > discussion on those bugs to see if they are still valid. If the user > > does not reply within the standard 30 day period after a bug is set to > > NEEDSINFO, it is automatically closed by the Bug Janitor. > > > > I am not simply closing bugs, so I do take offense that care is not > > applied. > > Properly "triaging" old reports requires at least some level of > understanding of the project, codebase etc. I'm afraid there is no > simple solution to that and rule-based approaches aren't good enough. > Even taking things like CONFIRMED status or wishlist priority into > account assumes that these have actually been consistently applied. As a maintainer on a small project, I'm quite happy to get an occasional nudge on old reports. Yes, I do occasionally go over old reports to see if they are still valid, but having somebody else doing this methodically makes sure I don't gloss over some bug that could be closed or fixed. Having this done by someone else without too much internal knowledge is an absolute plus in my opinion. After all, if you want to clean up your attic, you try to find a helper who does not have the same emotional attachment as yourself. > > I will halt it until it is approved by more developers. However if it > > is decided that it isn't wanted then the KDE as a whole will need to > > entice more people in sorting old bugs individually as it is clearly > > not a priority right now for the majority. Speaking for KPhotoAlbum, I really appreciate the bugzilla gardening. Thank you for doing it! Cheers, Johannes
Re: Copying po/docbook files to repositories nightly
Hi Albert, Thanks for the change ! Am Sonntag, 2. Oktober 2022, 07:51:04 CEST schrieb Albert Astals Cid: > Nothing broke but at least it seems the po files did not get commited to > these projects (maybe there are some more problematic repots, please check > yours if it's not part of KDE Gear, KDE Framworks or Plasma, those are the > ones i did check more thoroughly and fix if found something) > > digikam > gcompris > kaffeine > kbibtex > kphotoalbum > kst-plot > rkward > skrooge > trojita > ubiquity-slideshow-neon > > Because it is ignoring the po folder at the .gitignore file level, please > don't do that anymore. I'm not sure why kphotoalbum is listed here - the "Sync po/docbooks with svn" commit did land in our repo and po is not listed in our .gitignore. > > > This is a heads up, as a developer there's nothing you need to do, at > > > most > > > remove the po/ folder from .gitignore if for some reason it is there. Should I add "ki18n_install(po)" to my CMakeLists.txt? Cheers, Johannes
Re: Product organization in Bugzilla
Am Freitag, 16. September 2022, 14:05:36 CEST schrieb Nicolas Fella: > you are on to something that I wanted to raise anyway: Quite often > people report bugs for a frameworks they think is related to the problem > instead of the product we expect them to use. Some examples: To me these examples look like a systematic problem in KDE components rather than the users fault. I don't think a user can be expected to know the component in any of these cases. For applications, the Help | Report bugs action at least leads to a good starting point and makes sure that the bug is seen by some person who can further triage it into the proper component. Is it really not possible to get a similar (if not better) user experience for the more integrated components of the desktop stack? Suppose I experience a problem with, say, the clock widget: I can right click on it and even get a settings dialog for it. But clicking on the "about" tab I get the localized widget name and a link to kde.org/plasma-desktop. Why does the user have to find bugs.kde.org on their own, find that "plasma-desktop" is not actually a component in bugzilla, but that they need to file their bug in plasmashell and then reverse translate the component name to file the bug? To end my rant on a productive note: Yes, sure - hide internal components as you see fit (maybe hide archived/unmaintained components as well, while you're at it). But IMO the main problem is that users have to search on bugzilla instead of clicking a link inside the actual software component that they use. Cheers, Johannes
Re: Product organization in Bugzilla
Am Donnerstag, 15. September 2022, 10:21:02 CEST schrieb Ben Cooksley: > On Thu, Sep 15, 2022 at 7:02 PM Halla Rempt wrote: > > On woensdag 14 september 2022 22:12:26 CEST Nate Graham wrote: > > > We could do the same, providing a few user-friendly groups for common > > > software people use: That's a really good idea. > > > > > > - KDE apps > > > - KDE Plasma Desktop > > > - KDE Plasma Mobile > > > - KDE Frameworks > > > - KDE Neon > > > - Something else (which would contain everything not in any of those > > groups) > > > - Unknown (which would lead to the generic "kde" component > > > > > > (note: this suggestion is not a formal proposal set in stone, it's just > > > an example of a system of grouping we could use) > > My only comment here would be that users shouldn't need to concern > themselves with how we release applications. > > I'd therefore suggest that Applications be grouped similar to the Launcher > category they are in (which should align with the Invent grouping) which > should be fairly intuitive for users to follow. Is the launcher category the same as on https://apps.kde.org/? If so, I would strongly prefer to use that as well. From a user perspective, apps.kde.org should be the single source of truth. Cheers, Johannes signature.asc Description: This is a digitally signed message part.
Re: Gitlab CI Dashboards and retirement of build.kde.org
Hi Ben, Am Samstag, 3. September 2022, 21:37:53 CEST schrieb Ben Cooksley: > On Sat, Sep 3, 2022 at 10:12 PM Johannes Zarl-Zierl > wrote: > > On a related note: would it be possible to add badges for CI/CD status to > > repositories? > > Gitlab provides a limited selection of badges - which can be found at: > - https://invent.kde.org/multimedia/kdenlive/badges/master/pipeline.svg > - https://invent.kde.org/multimedia/kdenlive/badges/master/coverage.svg > - https://invent.kde.org/multimedia/kdenlive/-/badges/release.svg > > (replace project path and "master" as appropriate) Cool, thanks for the quick and detailed reply! > Note that the Release badge relies on the Gitlab Releases feature being > utilised, so that will likely not be usable for any of our projects. > Likewise, our Cobertura coverage job currently doesn't have the necessary > regular expression configured so that one also won't work - however the > general "Pipeline" one should work fine. Good to know. > Unfortunately Gitlab does not support generating per job badges based on > job names. Not what I wanted to hear, but also not a deal-breaker... Cheers, and keep up the good work ;-) Johannes
Re: Gitlab CI Dashboards and retirement of build.kde.org
Hi Ben, Thanks for the reminder! On a related note: would it be possible to add badges for CI/CD status to repositories? Quite a few projects (used to) have this in their README.md, but if I unterstand the situation correctly, Gitlab CI doesn't produce a build-status badge that one can link to. Examples: https://invent.kde.org/multimedia/kdenlive/-/blob/master/README.md[1] https://invent.kde.org/graphics/kphotoalbum/-/blob/master/README.md[2] https://invent.kde.org/graphics/digikam/-/blob/master/README.md[3] Cheers, Johannes Am Samstag, 3. September 2022, 06:45:31 CEST schrieb Ben Cooksley: > On Sat, Aug 27, 2022 at 9:44 PM Ben Cooksley wrote: > > Hi all, > > > > This evening I completed the necessary setup required to complete our > > Gitlab CI dashboards, which can now be found at > > https://metrics.kde.org/dashboards/f/aNxvXJW4k/gitlab-ci (KDE Developer > > account login required) > > > > These allow any developer to get a view on the current CI status of > > projects and groups of projects on a branch and platform basis - and > > should > > hopefully provide useful insight into the overall status that can > > currently > > be obtained from Jenkins. > > > > As this was the last thing holding us back from shutting down > > build.kde.org, i'd like to proceed with retiring and shutting down > > build.kde.org as soon as possible so the capacity it occupies can be > > released and reallocated to Gitlab. > > As previously indicated, I have now shutdown build.kde.org along with the > domain that supported it's version of the CI tooling. > The repository containing that tooling has now also been archived, and the > former build.kde.org domain has been redirected to metrics.kde.org. > > The server which was acting as a builder for build.kde.org will be rebuilt > in the coming days and reallocated to support Gitlab CI workloads. > > > If anyone would like to experiment with customised views for their own > > purposes (where the above provided ones are insufficient) please file a > > Sysadmin ticket. > > > > Please let me know if there are any questions on the above. > > > > Thanks, > > Ben > > Thanks, > Ben [1] https://invent.kde.org/multimedia/kdenlive/-/blob/master/README.md [2] https://invent.kde.org/graphics/kphotoalbum/-/blob/master/README.md [3] https://invent.kde.org/graphics/digikam/-/blob/master/README.md
Re: Gwenview Telemetry (was Re: The KIPI fate)
Am Sonntag, 17. April 2022, 00:01:53 CEST schrieb o lu:
> Developers having information like this will eliminate the need for
> conversations like this...
Not really. Usage data could play a role in informing part of the discussion
("which plugins are actively used?"), but won't change the big picture:
1. There is a legacy technology (kipi) that used to be great but was in
decline for many years before it was abandoned by its authors.
Nobody stepped up to rescue the old technology.
2. There is a newer technology (purpose) that fits at least the part of the
use-case that is discussed here (export plugins).
3. The new technology has not yet(?) implemented part of the functionality of
the legacy technology [1]
[1] https://phabricator.kde.org/T10525#189748
4. Nobody stepped up to port/implement the missing functionality for the new
technology
So, yes, telemetry data could help us in making an informed choice where to
put the effort. Still, somebody would need to actually do the work.
Telemetry data would not change the discussion on two of the following three
points:
a. Do applications need to support both technologies even if they are very
similar in scope?
b. Is having two slightly different plugin systems an acceptable user
experience?
c. Is dropping support for the legacy technology an acceptable user
experience?
Cheers,
Johannes
Re: Migration to collaborate.kde.org
Am Freitag, 27. August 2021, 22:27:55 CEST schrieb Ben Cooksley: > This is somewhat expected behaviour, as we need to force logins via the > MyKDE flow in order to ensure user details - including group memberships - > are synchronised appropriately. That is unfortunate, but understandable... > At some point in the future I would like to see FIDO2 (U2F) support being > deployed on MyKDE which would enable this flow for you. That would of course be the best solution. The reason I'm not entirely happy with the redirection to MyKDE is that it forces me to get my TOTP device and type in the security number. If the second factor on MyKDE could be a FIDO2 device, the whole nuisance would disappear (and not only for collaborate). Thanks for the insight! Cheers, Johannes signature.asc Description: This is a digitally signed message part.
Re: Migration to collaborate.kde.org
Hi, Would it be possible to enable login via U2F device on collaborate.kde.org? It is possible to enroll devices, but the login page doesn't expose the "login via device" link... Cheers, Johannes Am Sonntag, 8. August 2021, 07:27:01 CEST schrieb Ben Cooksley: > Hi all, > > The following is just a heads up that we've now completed the transfer of > files from share.kde.org to collaborate.kde.org. > > Files stored within the Sysadmin managed shared folders should now be > accessible to those who already had access. Should you be missing a shared > folder, please let us know. > > If you had files stored in your personal namespace, those are currently > being held in an archive - please file a Sysadmin ticket to request those > to be released to you. > > As mentioned previously, due to limitations in Nextcloud we had to set up a > completely new instance and as such existing shared links have been lost. > Please accept our apologies for this - we're aware it is not ideal. > > Please let us know if you have any questions on the above. > > Thanks, > Ben Cooksley > KDE Sysadmin signature.asc Description: This is a digitally signed message part.
Re: Progress is good for us but bad for documentation
Hi, Am Mittwoch, 9. Juni 2021, 01:20:23 CEST schrieb Frederik Schwarzer: > I would like to ask you to report such documentation to me. We see the > topic come up here and there but it then sometimes sinks into oblivion > again because it was part of a merge request that has then been merged > or so. > [...] > So what to report? Documentation that ... > - explains outdated technology or concepts like KDE 4 or HAL. > - has holes in it. For example a tutorial where you suddenly think, >you skipped an important step. > - you wish was there but you could not find it. Is this an effort with universal scope, or is there a limit? Obviously you are at least talking about the wikis. Are you also (at the current time) talking about other websites and/or application handbooks? Cheers, Johannes signature.asc Description: This is a digitally signed message part.
Re: Progress is good for us but bad for documentation
Hi, Am Mittwoch, 9. Juni 2021, 01:20:23 CEST schrieb Frederik Schwarzer: > I would like to ask you to report such documentation to me. We see the > topic come up here and there but it then sometimes sinks into oblivion > again because it was part of a merge request that has then been merged > or so. > [...] > So what to report? Documentation that ... > - explains outdated technology or concepts like KDE 4 or HAL. > - has holes in it. For example a tutorial where you suddenly think, >you skipped an important step. > - you wish was there but you could not find it. Is this an effort with universal scope, or is there a limit? Obviously you are at least talking about the wikis. Are you also (at the current time) talking about other websites and/or application handbooks? Cheers, Johannes signature.asc Description: This is a digitally signed message part.
Re: Can we get tags and tarballs for the KDE Qt patch collection
Am Dienstag, 8. Juni 2021, 16:56:56 CEST schrieb David Faure: > On mardi 8 juin 2021 15:04:20 CEST Nate Graham wrote: > > That being the case, what is the problem with us tagging it as 5.15.3? > > We would not be using our own version number but rather the one set by > > upstream. If the issue is one of not wanting to mislead people into > > thinking that this is some kind of officially sanctioned thing, could it > > be something like "5.15.3-kde-patches"? > > It's not just about official or not. One day the Qt Company *will* release > 5.15.3 (as per the KDE/FreeQt agreement), no? > So we cannot release something called 5.15.3 which is in fact different > (older) from what will one day be 5.15.3. > > I'm unsure whether we should stick to "those are patches, grab them" > or, for convenience, giving it a version number that is more than 5.15.2, > less than 5.15.3, says it comes from kde, and allows multiple releases Setting apart the technicalities of 5.15.3 vs 5.15.2.x vs 5.15.3.kde.N, I think the best place to come up with a solution is the KDE side, not downstream distributions: If we tell people "this is just a bunch of patches, but you should really apply them" we create a much bigger problem that nobody can tell for sure anymore whether that particular distro version of Qt does contain the patches or not. If not for the packagers we should provide somewhat canonical versions for ourselves and save ourselves some headaches over bug triaging... Cheers, Johannes signature.asc Description: This is a digitally signed message part.
Re: Exiv2 project submission to the KDE community
Dear Alex & Robin, [Re-adding the list-address because there are people who know better than me there and to me it looks like the list was dropped by accident] > Thank you for your enthusiastic and kind reply. You're right. With no plan > we meant that we haven't made up our minds for anything beyond fall 2021 > due to the lack of a sustainable maintainer-ship model. That is something > which needs to be sorted out but at the moment we don't know how! Thanks for clarifying. > We have seen the incubator process which is on the webpage. How would this > work? There are other people on this list that can probably explain better than me (and who have first-hand experience with the process), but I'll try to answer to the best of my knowledge: > Would the Exiv2 project be required to transfer all the history of > git, issues, pull request etc. to a new location within the KDE environment > or could the project stay where it is at the moment? Short answer: yes, you need to move. @sysadmin: Is the migration tool available on invent.kde.org? Longer answer: If your project was not hosted on Github it would theoretically be possible to remain there, but not very practical. To look at it from the positive side: only by moving to KDE infrastructure you can take full advantage of what KDE has to offer you. I mean knowing that you have financial, organizational, and legal support from one of the bigger FLOSS communities is cool, but have you ever experienced a situation where: * An international team of phenomenal translators take care of all your localization needs to the point it almost seems like magic? * Community members actively triage bugs so that you don't have to deal with every duplicate bug report yourself? * The CI not only builds your own software on multiple platforms but several projects that depend on it - so you get feedback if a change accidentally breaks downstream projects? (I hope I'm not overselling on this point) > Could you elaborate a > bit on the process and what would be required from our end to be done? In > order to get the resources and plan the transition we would need to do some > forecasting on the work and plan it accordingly. That's the part where I kindly refer you to more experienced people on this list who have sponsored an incubator project before. > Regarding the applications for grants, that is something very interesting > but many of us have day-to-day jobs and the question would be if someone > would leave his job and step into this uncertainty. I don't know if someone > would do it or not. Mostly likely it would depend on the amount of money > and security etc. Understandable. I just wanted to make sure that you are aware of the possibility. Cheers, Johannes
Re: Exiv2 project submission to the KDE community
Dear Alex and Robin, As maintainer of KPhotoAlbum I want to thank you for creating and maintaining Exiv2 over the years! Exiv2 is basically the de-facto standard when it comes to writing any kind of image handling application. Not directly related to the topic at hand, but have you considered applying for a grant at the core infrastructure initiative [1]? It seems that at least some problems of the recent past (such as an influx of automated security bug reports overwhelming the core development team) could be partly solved with grant money. > The Exiv2 project is hosted at the moment on GitHub ( > https://github.com/Exiv2/exiv2). We would like to evaluate the possibility > of onboarding the Exiv2 project into the KDE community. In case that you did not already see it, you can read about the incubator process here: https://community.kde.org/Incubator I would be proud to have Exiv2 join the KDE community! As far as I can see there are 6 core contributors that intend to remain committed to Exiv2? The sentence "There is no active plan for development of Exiv2 beyond 2021" in the issue 1466 sounds rather glumly. I assume (hope?) that the sentence is missing something like "...if no sustainable maintainership-model can be found"? > Last Saturday (2021-02-27) there was a meeting concerning the future of the > Exiv2 and we tried to find a new maintainer. Regrettably because of the > time demand imposed on the maintainer, no one volunteered. By joining the > KDE community we hope to address this issue and keep this important project > alive. The meeting notes can be found on the GitHub issue ( > https://github.com/Exiv2/exiv2/issues/1466). Joining the KDE project will not magically bring about a new maintainer as I am sure you are aware. That being said, the benefits[2] of being a KDE project may lift some of the day-to-day burdens that a maintainer would otherwise have to deal with on their own. Talking about my own experience: maybe adopting some kind of group- maintainership in the short to mid term can help with the transition. Becoming the maintainer for a project can feel like a daunting task at first (especially if the previous maintainer did a good job). Having such a transition period allows a potential new maintainer to grow into the role... Kind regards and cheers, Johannes Zarl-Zierl [1] https://www.coreinfrastructure.org [2] https://manifesto.kde.org/benefits.html
Re: Officially adopt "Noteworthy" label into KDE policy
Hi Julian, Thanks for taking ownership of this policy proposal! On Freitag, 18. September 2020 10:05:47 CEST Julian / xyquadrat wrote: > A few remarks: > - Of course all contributions are noteworthy and important. Promo does > not want to discount the work that goes into small and unnoticeable fixes. > - If you are not sure whether a MR or issue should be "Noteworthy" or > not, tag it with "Noteworthy" (-> be liberal with the label usage). > Promo will then consider such edge cases in detail. > - Not all things tagged might make it into an official announcement. > This is (usually) not due to us overlooking them, but because we have to > carefully prioritize what we include. If you think something was left > out that should definitely have been included, reach out to us on > #kde-promo and we will be happy to discuss individual cases and solutions. I really like this framing. Especially the "if you're not sure, then tag it" part and the editorial process make it easier (at least for an introvert like me) to actually use it. > *Examples of noteworthy changes:* > > * User facing feature additions (e.g. /New useful effect added to > Kdenlive/) > * Big changes in UI (e.g. /a KCM is rewritten in QML and now looks > distinctively different/) > * Long-standing, annoying bugs (e.g. /Rework of the previously > bug-ridden MTP implementation in KIO/) > * Large technology shifts (e.g. /Port to Qt 6/) > * Significant performance improvements (best paired with concrete > numbers, but not necessary) > > *Examples of changes not considered noteworthy: * > > * Small UX annoyances and fixes. Whilst those add up to something very > important, the individual changes (e.g. "more consistent padding in > dialogs") are not interesting to users. > * Shifts in technology that do not affect the behavior of the product > (e.g. /porting from library X version Y to library X version Y+1/) > * Minor changes to tools and backends used in the development process Detailed guidelines are so much better than the "Notify Commit Digest team of something interesting" in the current git commit template ;-) Cheers, Johannes
Re: KDE accessibility with orca improvement.
Hello Boguslaw, I think the best way to improve the situation would be to file bug reports for the accessibility problems that you encounter. There is also an accessibility group mentioned in the community wiki[1]. As far as I can tell, the best place to ask questions related to accessibility is the #kde-accessibility IRC channel on freenode. Cheers, Johannes [1] https://community.kde.org/Accessibility On Donnerstag, 28. Mai 2020 22:47:21 CEST Bogusław Augustyniak wrote: > Hello, > > I’m trying to use KDE with debian SID, I installed it, and I was > disappointed. The desktop wasn’t accessible with orca. The settings panel > was also inaccessible. I could only search for programs in menu, and press > enter. Could you improve it? I could be a tester. > > Thank you. > > Nice day > >
Re: Transition to Gitlab Complete
On Sonntag, 17. Mai 2020 12:47:35 CEST Ben Cooksley wrote: > -- Work Branches -- > [...] Is this information available somewhere in the wikis? > Apologies for the disruption this caused - please note that a number > of systems that work closely with the Git repositories are in the > process of catching up with the transition at the moment. > During this time there may be some disruption to them, however we hope > that this will all be completed over the coming week. Thanks for the good work! So far, I couldn't have wished for a smoother transition... Cheers, Johannes
Re: Context information needed for isolated words
On Samstag, 2. Mai 2020 14:46:12 CEST David Hurka wrote: > Yes, I am suggesting to forbid i18n() without c. For longer strings, the version without context is usually fine. This will only lead to people writing empty or nondescript comments, starting a habit that is worse than the current behaviour. If you really want to improve this on the tooling side, you could create a linter that is run by the CI and that warns for *short* i18n calls without context. Johannes
Re: Proposal: "Noteworthy" label for Promo application updates
On Montag, 20. April 2020 13:46:47 CEST Carl Schwan wrote: > I think the easiest would be to use the GitLab tags. Hopefully, we will soon > use Gitlab for everything and then it won't be a problem. > > For example, promo will just need to go to these two links to find all the > information we need: > > * https://invent.kde.org/groups/kde/-/issues?label_name%5B%5D=Noteworthy > * https://invent.kde.org/groups/kde/-/merge_requests? label_name%5B%5D=Noteworthy Actually this seems like a good approach. At KPhotoAlbum, we don't use the merge request workflow much, but use issues (well, currently Phabricator tasks) to track feature development. Having both issue and merge-request labels should fit most projects, I guess... Cheers, Johannes signature.asc Description: This is a digitally signed message part.
Re: Proposal: "Noteworthy" label for Promo application updates
On Donnerstag, 16. April 2020 23:15:18 CEST Nate Graham wrote: > On 4/16/20 2:38 PM, Albert Astals Cid wrote: > > It may make sense to highlight them a bit more somehow, suggestions > > welcome i guess. > The promo people just need a list of all CHANGELOG entries in a release > so they can rewrite it in more human-friendly terms. Right now this is > done manually by me and others by looking through commit logs and blog > posts and adding the equivalent of CHANGELOG text into an > etherpad/share.kde.org document. Automating that somehow would be nice. >From a developer point of view, a tag in the commit itself seems like a nice interface. One thing I fear, though, is that people like me forget to actually add it to the commit before pushing, so maybe something that can be added later would definitely have its advantages. Personally, I'd like to have some clear guidelines from the promo team on what kind of features they are looking for. That way it's way easier for me to match those expectations ;-) Btw. isn't the DIGEST keyword as documented in the standard commit template basically the same idea? Cheers, Johannes
Re: CI system maintainability
Hi, (Sorry for top-posting) I fear that a mandatory reviews would add too juch strain on smaller teams. If there's just one person with an intimate knowledge of the code-base, plus two co-developers, then who should do the reviews? How about a distinction based on importance of a project instead? I.e. mandatory reviews for frameworks and any app that wants to be included in KDE apps releases. Non-mandatory reviews can then also come with a "price" to pay: if CI errors are not dealt with in a timely manner, you should be free to disable the CI for administrative reasons... Johannes Am 28. März 2019 10:17:18 MEZ schrieb Tomaz Canabrava : >On Thu, Mar 28, 2019 at 10:09 AM Luca Beltrame >wrote: >> >> In data giovedì 28 marzo 2019 09:50:47 CET, Kevin Ottens ha scritto: >> > I'd argue we're loosing more with the current state of PIM than >we'd loose >> > with mandatory reviews. >> >> Perhaps, instead of an all-or-nothing approach, why not a minimal set >of >> "requirements" that would require a review? Yes, it requires more >discipline >> from those involved, but at least it will help people getting >"ingrained" with >> the concept without being a wall. >> >> Examples: >> >> - No review: typo fixes, compile errors, version bumps (internal) >> - Review: build system adjustments (perhaps CC some people >knowledgeable in >> this case), non-trivial changes like patches >> - "Deprecation" removals (as in the casus belli here) - review if >touching >> more than a handful of files / multiple repos >> >> (list made by someone who has a passing knowledge of C++, so feel >free to rip >> me to shreds) >> >> Pre-commit CI (i.e. once the switch to GitLab occurs) and perhaps >direct >> mailing to the user (as I suggested earlier) in case of continuous >failures >> will also help. >> >> If this thing works, one can gradually ramp up the requirements of >things that >> go through review when the "muscle memory" is formed. > >The problem is that a git comit is a git commit, there's no way that a >typo will be treated differently then another commit. >I strongly advocate for "reviews always", but since I was outvoted a >few times on this I would at least say "can we at least have reviews >for non project members" ? > > >> -- >> Luca Beltrame >> GPG key ID: A29D259B
Re: CI system maintainability
Hi, (Sorry for top-posting) I fear that a mandatory reviews would add too juch strain on smaller teams. If there's just one person with an intimate knowledge of the code-base, plus two co-developers, then who should do the reviews? How about a distinction based on importance of a project instead? I.e. mandatory reviews for frameworks and any app that wants to be included in KDE apps releases. Non-mandatory reviews can then also come with a "price" to pay: if CI errors are not dealt with in a timely manner, you should be free to disable the CI for administrative reasons... Johannes Am 28. März 2019 10:17:18 MEZ schrieb Tomaz Canabrava : >On Thu, Mar 28, 2019 at 10:09 AM Luca Beltrame >wrote: >> >> In data giovedì 28 marzo 2019 09:50:47 CET, Kevin Ottens ha scritto: >> > I'd argue we're loosing more with the current state of PIM than >we'd loose >> > with mandatory reviews. >> >> Perhaps, instead of an all-or-nothing approach, why not a minimal set >of >> "requirements" that would require a review? Yes, it requires more >discipline >> from those involved, but at least it will help people getting >"ingrained" with >> the concept without being a wall. >> >> Examples: >> >> - No review: typo fixes, compile errors, version bumps (internal) >> - Review: build system adjustments (perhaps CC some people >knowledgeable in >> this case), non-trivial changes like patches >> - "Deprecation" removals (as in the casus belli here) - review if >touching >> more than a handful of files / multiple repos >> >> (list made by someone who has a passing knowledge of C++, so feel >free to rip >> me to shreds) >> >> Pre-commit CI (i.e. once the switch to GitLab occurs) and perhaps >direct >> mailing to the user (as I suggested earlier) in case of continuous >failures >> will also help. >> >> If this thing works, one can gradually ramp up the requirements of >things that >> go through review when the "muscle memory" is formed. > >The problem is that a git comit is a git commit, there's no way that a >typo will be treated differently then another commit. >I strongly advocate for "reviews always", but since I was outvoted a >few times on this I would at least say "can we at least have reviews >for non project members" ? > > >> -- >> Luca Beltrame >> GPG key ID: A29D259B
Re: CI system maintainability
Hi, (Sorry for top-posting) I fear that a mandatory reviews would add too juch strain on smaller teams. If there's just one person with an intimate knowledge of the code-base, plus two co-developers, then who should do the reviews? How about a distinction based on importance of a project instead? I.e. mandatory reviews for frameworks and any app that wants to be included in KDE apps releases. Non-mandatory reviews can then also come with a "price" to pay: if CI errors are not dealt with in a timely manner, you should be free to disable the CI for administrative reasons... Johannes Am 28. März 2019 10:17:18 MEZ schrieb Tomaz Canabrava : >On Thu, Mar 28, 2019 at 10:09 AM Luca Beltrame >wrote: >> >> In data giovedì 28 marzo 2019 09:50:47 CET, Kevin Ottens ha scritto: >> > I'd argue we're loosing more with the current state of PIM than >we'd loose >> > with mandatory reviews. >> >> Perhaps, instead of an all-or-nothing approach, why not a minimal set >of >> "requirements" that would require a review? Yes, it requires more >discipline >> from those involved, but at least it will help people getting >"ingrained" with >> the concept without being a wall. >> >> Examples: >> >> - No review: typo fixes, compile errors, version bumps (internal) >> - Review: build system adjustments (perhaps CC some people >knowledgeable in >> this case), non-trivial changes like patches >> - "Deprecation" removals (as in the casus belli here) - review if >touching >> more than a handful of files / multiple repos >> >> (list made by someone who has a passing knowledge of C++, so feel >free to rip >> me to shreds) >> >> Pre-commit CI (i.e. once the switch to GitLab occurs) and perhaps >direct >> mailing to the user (as I suggested earlier) in case of continuous >failures >> will also help. >> >> If this thing works, one can gradually ramp up the requirements of >things that >> go through review when the "muscle memory" is formed. > >The problem is that a git comit is a git commit, there's no way that a >typo will be treated differently then another commit. >I strongly advocate for "reviews always", but since I was outvoted a >few times on this I would at least say "can we at least have reviews >for non project members" ? > > >> -- >> Luca Beltrame >> GPG key ID: A29D259B
Re: Feasibility of KDE application
Hi Ade, (Sorry for top-posting I'm typing on the phone) From a user perspective: yes, we definitely should have something like this. There should not be a need for root privileges, though. As for getting information about which config file to use: maybe we could add that information to the appstream files? Hardcoding configuration files in you program certainly won't scale. Overwriting config files while programs are running won't work. That's probably going to be an issue with desktop settings (and apps as well). Regarding system-dependent configuration: we briefly talked about this during the configuration box at Akademy. The consensus seems to be that this is actually resolution-dependent configuration. Some apps already store window placement and state per resolution. Not all, though... HTH, Johannes Am 14. August 2018 22:11:15 MESZ schrieb Anders Gade : >Hi > >I'm contemplating building an export tool for Plasma 5 configurations >based >on config files on an existing system - from what I can gather mainly >located in ~/.config, ~/share and the likes. It will need to use ksudo, >since I figure some things will rely on installing third party programs >such as Latte Dock for example. >The thought is to make it possible to import the exported file to a >fresh >system and get both look and feel, keyboard shortcuts and other >behaviors >(Dolphin settings etc) setup in no time. > >I've made a mockup in designer so you can see the general idea (I'm >planning to build it in Python3 & PyQt5) : > >[image: PEK.png] >Is this feasible at all? I'm a bit concerned if I should use my energy >elsewhere if I have to fight the system all the way to make this >happen. >Specifically I'm wondering: > >- Can I just replace these files on a new system (I've found accounts >on >the net of these files being overwritten if changed - is there any >truth to > this)? > - It seems like especially the desktop setup is tied to the specific >system it is configured on (in regards to screen resolution and >placement > of panels etc.) > Is this prevailant through a lot of the settings? > - Is there some sort of overview anywhere of which settings files > belongs to where? > From what I've found so far I need to concentrate on *rc files, but it > seems easy to miss some crucial parts? >- Is there a better way? I've read about kwrite a bit, but it seems the > script then needs to run at every boot > - Any other pitfalls or inputs? > >I hope someone will chime in with some input. And apologies if >something is >unclear - english is not my first language. > >Thank you
