Re: Welcoming Nicolas Fella, KDE e.V.'s new Software Platform Engineer
Congratulations Nicolas! Is it correct to assume that this role is for this job ad https://ev.kde.org/resources/callforproposals-platform2022/ ? On Tue, Feb 14, 2023 at 6:43 PM Paul Brown wrote: > Great news! Welcome Nicolas to the grind. > > Cheers > > Paul > -- > Promotion & Communication > > www: http://kde.org > Mastodon: https://floss.social/@kde > Facebook: https://www.facebook.com/kde/ > Twitter: https://twitter.com/kdecommunity > LinkedIn: https://www.linkedin.com/company/kde > > > -- Alexander Potashev
Re: How do we feel about non 100% KDE job offers being sent here?
Option 3: create a dedicated mailing list for job openings. On Thu, Nov 25, 2021, 17:18 Ingo Klöcker wrote: > Hi Albert, > > On Donnerstag, 25. November 2021 14:44:56 CET Albert Astals Cid wrote: > > I know a company that would like to hire people with a skill set that > > is relatively common inside the KDE community, the job is not strictly > > KDE related, one could call it KDE-adjacent. > > > > How do we feel about such job offers being sent here? > > I'm not sure whether you are talking about jobs that will benefit KDE > because > working on KDE's offering (e.g. KDE Frameworks) is part of the job or > whether > you are talking about some Qt job which will not benefit KDE because the > person will work on code that is orthogonal to KDE and maybe even > proprietary. > > I'm not okay with job offers for non-Free Software jobs. There are more > than > enough portals to look for non-Free Software C++ and Qt jobs. > > I think I would be okay with Free Software job offers that are > "KDE-adjacent". > In fact, I might be interested. > > > Pro: > > * We want people of the community to get [potentially better] jobs > > ... which still allow them to contribute to KDE at least a bit. > > > Con: > > * The list could filled with job offers that are not really KDE > > related since it's hard to define what "KDE-adjacent" really means. > > I think it should be restricted to jobs that benefit the Free Software > ecosystem. > > OTOH, I think I would prefer to use a separate dedicated mailing list for > this. I have mixed feelings about mixing community discussions with job > advertisements. Maybe it would be okay if the job ads were clearly marked > in > the subject, e.g. with "[Job]" so that one can easily filter them out > (physically or mentally). There should also be a clear policy that replies > to > job offers must not be send to the list and that job offers should not be > commented or discussed on this list. All of this would be much easier with > a > separate mailing list. > > Regards, > Ingo
Re: Extending the license policy to include ODbL-1.0
Thank you Volker! On Thu, Sep 23, 2021 at 6:01 PM Volker Krause wrote: > > done > > On Mittwoch, 22. September 2021 23:20:56 CEST Alexander Potashev wrote: > > Thanks! > > > > Could you please update the changelog section > > https://community.kde.org/Policies/Licensing_Policy#Changelog ? > > > > On Wed, Sep 22, 2021 at 5:38 PM Volker Krause wrote: > > > Thanks everyone, I've added the suggested change to the wiki now. > > > > > > Regards, > > > Volker > > > > > > On Mittwoch, 15. September 2021 17:26:57 CEST Volker Krause wrote: > > > > Hi, > > > > > > > > there's a MR [1] for ki18n containing data tables generated from OSM > > > > data, > > > > which implies the ODbL-1.0 license [2]. We also already have other > > > > places > > > > ([3], [4]) actually doing this. > > > > > > > > However that's a license not yet covered by our license policy, so I > > > > suggest we add it. > > > > > > > > ODbL is essentially LGPL-y but for data rather than code, so > > > > conceptually > > > > compatible with our existing licensing. > > > > > > > > It's also not like there's any viable alternative to OSM data, so not > > > > doing > > > > this would imply not being able to implement features integrating > > > > OSM-derived data. > > > > > > > > The proposed addition to the policy section of > > > > https://community.kde.org/ > > > > Policies/Licensing_Policy would be: > > > > > > > > > > > > # ''Geographic data'', in particular data based on or derived from > > > > OpenStreetMap may be licensed under the '''[https://spdx.org/licenses/ > > > > ODbL-1.0.html Open Data Commons Open Database License v1.0]'''. > > > > > > > > > > > > What do you think? > > > > > > > > Regards, > > > > Volker > > > > > > > > [1] https://invent.kde.org/frameworks/ki18n/-/merge_requests/19 > > > > [2] https://spdx.org/licenses/ODbL-1.0.html > > > > [3] > > > > https://invent.kde.org/pim/kitinerary/-/blob/master/src/lib/knowledgedb > > > > / timezonedb_data.cpp > > > > [4] > > > > https://invent.kde.org/libraries/kpublictransport/-/blob/master/src/lib > > > > / knowledgedb/linemetadata_data.cpp > -- Alexander Potashev
Re: Extending the license policy to include ODbL-1.0
Thanks! Could you please update the changelog section https://community.kde.org/Policies/Licensing_Policy#Changelog ? On Wed, Sep 22, 2021 at 5:38 PM Volker Krause wrote: > > Thanks everyone, I've added the suggested change to the wiki now. > > Regards, > Volker > > On Mittwoch, 15. September 2021 17:26:57 CEST Volker Krause wrote: > > Hi, > > > > there's a MR [1] for ki18n containing data tables generated from OSM data, > > which implies the ODbL-1.0 license [2]. We also already have other places > > ([3], [4]) actually doing this. > > > > However that's a license not yet covered by our license policy, so I suggest > > we add it. > > > > ODbL is essentially LGPL-y but for data rather than code, so conceptually > > compatible with our existing licensing. > > > > It's also not like there's any viable alternative to OSM data, so not doing > > this would imply not being able to implement features integrating > > OSM-derived data. > > > > The proposed addition to the policy section of https://community.kde.org/ > > Policies/Licensing_Policy would be: > > > > > > # ''Geographic data'', in particular data based on or derived from > > OpenStreetMap may be licensed under the '''[https://spdx.org/licenses/ > > ODbL-1.0.html Open Data Commons Open Database License v1.0]'''. > > > > > > What do you think? > > > > Regards, > > Volker > > > > [1] https://invent.kde.org/frameworks/ki18n/-/merge_requests/19 > > [2] https://spdx.org/licenses/ODbL-1.0.html > > [3] https://invent.kde.org/pim/kitinerary/-/blob/master/src/lib/knowledgedb/ > > timezonedb_data.cpp > > [4] https://invent.kde.org/libraries/kpublictransport/-/blob/master/src/lib/ > > knowledgedb/linemetadata_data.cpp > -- Alexander Potashev
Extending the license policy to include Apache-2.0
Hi, Parts of https://invent.kde.org/websites/aether-sass/ are licensed under Apache License 2.0. This disagrees with the KDE licensing policy. Considering Apache-2.0 is similar to MIT, I don't see why it shouldn't be allowed by the policy. Is anyone aware of past discussions of the KDE licensing policy and reasoning behind this fact? The proposed addition to the policy section of https://community.kde.org/ Policies/Licensing_Policy would be: """ 4. Source files that are part of a library with a public API which is part of the KDE Platform (kdelibs, kdepimlibs, kde-runtime and KDE Frameworks) must be licensed under: ... [new bullet point] * Apache-2.0: Apache License 2.0 as listed below. """ What do you think? -- Alexander Potashev
Re: Releasing a non-KF5 library under MIT License
On Wed, Mar 31, 2021 at 12:54 AM Luigi Toscano wrote: > > Alexander Potashev ha scritto: > > The https://community.kde.org/Policies/Licensing_Policy says I can't > > do this because (according to this policy) the MIT License is only > > allowed for parts of the "KDE Platform". > > Does it? I see: > > 4. Source files that are part of a library with a public API which is part of > the KDE Platform (kdelibs, kdepimlibs, kde-runtime and KDE Frameworks) must be > licensed under: > [... licenses, including: ...] > * MIT: MIT license as listed below. > [...] > > 5. Any other source files must be licensed under one of the terms listed under > 4) or: > [ other licenses] Makes sense. Thanks for pointing this out! (IOW the licensing policy "KDE Platform" is even tighter and for the other projects, and this is great for me!) -- Alexander Potashev
Releasing a non-KF5 library under MIT License
Hi, I would like to release a Go library under the terms of the MIT License and host it at invent.kde.org. The library definitely won't fit in KF5 because it has nothing to do with Qt. The https://community.kde.org/Policies/Licensing_Policy says I can't do this because (according to this policy) the MIT License is only allowed for parts of the "KDE Platform". Can we please review the policy and stop this discrimination against projects that don't happen to be part of the "KDE Platform"? P.S. It seems like MIT is already used outside of the "KDE Platform": - https://invent.kde.org/network/kaidan (at least two files are under MIT) - http://invent.kde.org/sdk/cutehmi (dual-licensed, including MIT) -- Alexander Potashev
Re: On the reappointment of Richard Stallman as a director of the FSF
Thanks for the effort Aleix! It would be nice to clarify whose opinions this linked message represents. If this is something that the KDE e.V. Board voted for, then probably a signature "KDE e.V. Board of Directors" on the bottom of the page would make sense. -- Alexander Potashev On Wed, Mar 24, 2021, 23:27 Aleix Pol wrote: > Dear community, > From the KDE e.V. we followed closely the discussions on the last few > days regarding this recent decision within the Free Software > Foundation's leadership. > > We have tried to sum up our thoughts in the following announcement > with the hope to foster collectively the Free Software leadership we > need. > https://ev.kde.org/2021/03/24/on-the-reappointment-of-rms-fsf/ > > Looking forward to a more inclusive discussion that will shape the > Free Software movement of tomorrow. > > Best regards, > Aleix Pol with the KDE e.V. Board of Directors >
Re: Information regarding upcoming Gitlab Migration
On Fri, May 1, 2020 at 10:14 PM Ben Cooksley wrote: > On Sat, May 2, 2020 at 6:17 AM Alexander Potashev > wrote: > > I have a similar use case. Sometimes I need to share a URL to a > > project. For this purpose I used to share e.g. > > https://cgit.kde.org/releaseme.git/about > > > > Does this migration make such permalinks impossible? > > > > > > From what I see, we lose permalinks because > > 1. cgit.kde.org will be discontinued > > We provide the commits.kde.org redirector for permanent links. > Anywhere needing a long life link to a particular repository, commit, > etc (like documentation) should be using these links and not anything > else. This is helpful. Thank you Ben! -- Alexander Potashev
Re: Information regarding upcoming Gitlab Migration
On Tue, Apr 28, 2020 at 6:47 AM Bhushan Shah wrote: > Use case 4 : Tom is a student in Germany and is interested in > contributing to wikitolearn, and he asks where can I find code of the > wikitolearn? Hi, I have a similar use case. Sometimes I need to share a URL to a project. For this purpose I used to share e.g. https://cgit.kde.org/releaseme.git/about Does this migration make such permalinks impossible? >From what I see, we lose permalinks because 1. cgit.kde.org will be discontinued 2. A once valid URL https://invent.kde.org/games/knetwalk may become unavailable if the project moves to another group, for example https://invent.kde.org/unmaintained/knetwalk -- Alexander Potashev
Re: Help with KDE PIM and Google Privacy Policies needed
пт, 6 мар. 2020 г. в 08:21, Nicolás Alvarez : > > El vie., 6 de mar. de 2020 a la(s) 03:41, Martin Flöser > (mgraess...@kde.org) escribió: > > Reading [0] I see "Your use of data obtained via the Restricted Scopes > > must comply with these requirements:" ... "Only transfer the data to > > others if necessary to provide or improve user-facing features that are > > prominent in the requesting application's user interface" > > > > And reading the screenshot I think that's the problem. We state in our > > privacy policy about 3rd party plugins and Akonadi. Especially Akonadi > > is a "transfer of data to others" and that allows all applications to > > access the data. If KWin accesses the data it would be in violation of > > the additional requirements of the requested scope. > > If I add my Google account to KDE PIM, it will sync my email and > calendar events with Akonadi. Third-party apps can then access my > email and calendar events via Akonadi. Hi, Thanks for the constructive discussion! I'm not an expert, and I only judged by the info from this email thread and from the linked documents, but tend to agree with Martin. We should clearly communicate the intent to the end user before accessing their data. For now there may be various cases where the user stays unaware about how our software handles their data. Consider this scenario for example: 1. A user installs KMail and e.g. an E-mail notifier Plasma widget on the same machine, 2. The user runs KMail and grant access to their Gmail account, expecting that it will only be used by KMail, 3. The user enables the E-mail notifier widget. The widget will just work without asking the user for permission to access their data from Gmail account. This conflicts with Google’s API Services User Data Policy. In our https://community.kde.org/KDE_PIM/Privacy_Policy, the red flag is clearly "It is possible for any locally running software to interact with Akonadi and thus access, modify or delete any data stored there." Here are two approaches that in my opinion would (at least partially) resolve the issue: [Approach #1]. Have all Akonadi clients create and use their own Google API app IDs/keys. Isolate cached data in Akonadi per app, so that e.g. an E-mail notifier widget cannot reach through Akonadi API to access the data downloaded specially for Kmail. It will need to ask Akonadi IMAP resource to request the same emails again. This implies huge data duplication in Akonadi in some cases, however it can probably be deduplicated inside Akonadi to save storage space. [Approach #2]. Apps still don't need to have their own API keys, just like today. Add metadata to Akonadi resources about which apps are "cleared" for data access by the end user. In this above mentioned scenario: - When starting KMail, Akonadi IMAP resource will request Gmail API token, - Akonadi will ask the user again if it's OK to hand their Gmail data over to Kmail, - When an Email notifier Plasma widget [1] is enabled, it requests access to Gmail from Akonadi. Before this access can be granted, Akonadi asks the user the same question - if it's OK to hand their Gmail data over to Email notifier Plasma widget. If the user says "yes", then it may be OK to reuse the same Gmail API key. Although this second approach still seems to me like walking on thin ice, I don't find it to be in a direct conflict with Google API Services User Data Policy and its first part [2] specifically. Not sure which of the approaches would be more desirable nor easiest to implement since I'm not familiar with Akonadi internals. I would suggest that KDEPIM developers first choose an approach, write a design doc, make a new draft of KDEPIM Privacy Policy and submit for additional review before putting effort in implementing any of these changes that might be large-scale. [1] *(or another software that wants to access the same Gmail account through Akonadi, e.g. Akonadi Indexing Agent) [2] https://developers.google.com/terms/api-services-user-data-policy#accurately_represent_your_identity_and_intent Disclaimer: My personal views, thoughts, and opinions expressed in the text above belong solely to me, and not necessarily my employer, organization, committee or other group or individual. -- Alexander Potashev
Re: December Apps Update
чт, 5 дек. 2019 г. в 02:45, Alexander Potashev : > > вт, 3 дек. 2019 г. в 19:59, Jonathan Riddell : > > > > Our monthly apps update story is being moved onto kde.org for December and > > being make to match the release from the release service (previously KDE > > Applications). > > > > If you have new features you'd like highlighted that have been released > > this month or will be part of the 19.12 releases please let me know or make > > merge requests to the story which is in Git here > > Hi, > > Am I the only one who reads the wording "this month" as December 2019? > > However the news report clearly talks about software releases made in > November. Should we say "last month" everywhere instead? Now we have an answer to this: It covers new releases of anything up until we publish on Thursday Between the last story and Thursday So I guess "last month" can be read as "last ~30 days", it's not a given calendar month. -- Alexander Potashev
Re: December Apps Update
вт, 3 дек. 2019 г. в 19:59, Jonathan Riddell : > > Our monthly apps update story is being moved onto kde.org for December and > being make to match the release from the release service (previously KDE > Applications). > > If you have new features you'd like highlighted that have been released this > month or will be part of the 19.12 releases please let me know or make merge > requests to the story which is in Git here Hi, Am I the only one who reads the wording "this month" as December 2019? However the news report clearly talks about software releases made in November. Should we say "last month" everywhere instead? -- Alexander Potashev
Re: Sysadmin Load Reduction: Code Related Services
пн, 18 нояб. 2019 г. в 15:35, Harald Sitter : > > On Sat, Nov 16, 2019 at 9:40 PM Ben Cooksley wrote: > > > > On Sun, Nov 17, 2019 at 5:19 AM Carl Schwan wrote: > > > > > > Hi all, > > > > Hi Carl, > > > > > > > > Can the gitlab api be of useful in the future? > > > > > > e.g https://invent.kde.org/api/v4/groups/7 > > > > While for many purposes Gitlab's API wil be perfectly fine, it doesn't > > provide us with the i18n branch information which some users will > > require. > > Something to perhaps consider at this point is to revise the > repo-metadata format in general and offload data to gitlab? > > Notably I'd kick the following yaml properties in favor of their > literal replacements in gitlab: description, icon, members, name. On a > related note I guess there'd be need to figure out how to map from a > "kde project" to a gitlab project. Currently the paths between > repo-metadata and invent do not line up. > > Additionally we may able able to remove: > > - hasrepo (repopath==null implies this) > - repoactive (totally not sure what this communicates) > > And lastly, fold the i18n data into the yaml. Which I think means we > could drop the excessive use of directories and just have one file per > project, e.g. projects/kde/workspace/sddm-kcm.yaml or perhaps even > more ideally projects/sddm-kcm.yaml (because the current dir structure > duplicates information encoded in repopath; so I would think either we > should drop the property or flatten projects/). I think it's too early to offload properties from repo-metadata.git to gitlab because we are still far from migrating all project to gitlab. Here is how the i18n data can be folded into yaml (example of Konsole [1]): description: KDE's terminal emulator. [...] projectpath: kde/applications/konsole repoactive: true repopath: konsole type: project i18n: branches: trunk: none stable: none stable_kf5: release/19.12 trunk_kf5: master The idea is to insert the data from i18n.json into the main YAML under i18n.branches. Also, the "none" values can be omitted, I guess. [1] https://cgit.kde.org/sysadmin/repo-metadata.git/tree/projects/kde/applications/konsole -- Alexander Potashev
Re: Sysadmin Load Reduction: Code Related Services
пт, 15 нояб. 2019 г. в 22:05, Ben Cooksley : > > On Sat, Nov 16, 2019 at 3:27 AM Alexander Potashev > wrote: > > > > пт, 15 нояб. 2019 г. в 15:46, Harald Sitter : > > > > > > On Sat, Nov 9, 2019 at 11:37 PM Alexander Potashev > > > wrote: > > > > > > > > сб, 9 нояб. 2019 г. в 02:51, Ben Cooksley : > > > > > In the category of no longer in use, we have the compatibility > > > > > generator for the kde_projects.xml file. This was introduced when we > > > > > shutdown Redmine/Chiliproject and migrated to Phabricator, as a way of > > > > > keeping services that needed to discover a list of KDE Projects > > > > > functional. > > > > > > > > > > As we've since migrated to using YAML files within the > > > > > sysadmin/repo-metadata repository for both the CI System and > > > > > kdesrc-build (and with LXR using kdesrc-build to do it's code > > > > > checkouts) there shouldn't to my knowledge be anything still relying > > > > > on this (aside from perhaps scripty). > > > > > > > > > > I'd therefore like to shut this generator down as well, along with the > > > > > compaibility redirector running at projects.kde.org (given that it has > > > > > been some time since we were using that site, and many projects have > > > > > moved around in the virtual structure since then, making the redirects > > > > > it is able to offer useless) > > > > > > > > Hi Ben, > > > > > > > > I am developing a new version of the "opensrc" plugin for Lokalize [1] > > > > and it currently depends on kde_projects.xml. Of course I can add new > > > > code to scan the Git repo instead of just fetching kde_projects.xml, > > > > however it would be more complicated. > > > > > > https://projects.kde.org/api/doc/ specifically deals with this problem > > > by abstracting the repo away behind a micro service. > > > > This looks like another view of the data available in > > kde_projects.xml, however the API is very limited. For example I can't > > query repo descriptions using this API. Thus not helpful. > > > > However if we were going to kill kde_projects.xml, are you sure > > projects.kde.org/api/ would be still available and not shut down as > > well? > > The API that Harald mentions is based off the YAML files, and is not > reliant on the legacy kde_projects.xml file. I can implement kde_projects.xml or a modernized version of it as part of projects.kde.org/api/. Does this sound like a good idea? We don't need to support the exact same XML format, so I would prefer a JSON listing all projects with all their properties, at something like GET https://projects.kde.org/api/v1/export or may be return all project properties in GET https://projects.kde.org/api/v1/projects -- Alexander Potashev
Re: Sysadmin Load Reduction: Code Related Services
пт, 15 нояб. 2019 г. в 15:46, Harald Sitter : > > On Sat, Nov 9, 2019 at 11:37 PM Alexander Potashev > wrote: > > > > сб, 9 нояб. 2019 г. в 02:51, Ben Cooksley : > > > In the category of no longer in use, we have the compatibility > > > generator for the kde_projects.xml file. This was introduced when we > > > shutdown Redmine/Chiliproject and migrated to Phabricator, as a way of > > > keeping services that needed to discover a list of KDE Projects > > > functional. > > > > > > As we've since migrated to using YAML files within the > > > sysadmin/repo-metadata repository for both the CI System and > > > kdesrc-build (and with LXR using kdesrc-build to do it's code > > > checkouts) there shouldn't to my knowledge be anything still relying > > > on this (aside from perhaps scripty). > > > > > > I'd therefore like to shut this generator down as well, along with the > > > compaibility redirector running at projects.kde.org (given that it has > > > been some time since we were using that site, and many projects have > > > moved around in the virtual structure since then, making the redirects > > > it is able to offer useless) > > > > Hi Ben, > > > > I am developing a new version of the "opensrc" plugin for Lokalize [1] > > and it currently depends on kde_projects.xml. Of course I can add new > > code to scan the Git repo instead of just fetching kde_projects.xml, > > however it would be more complicated. > > https://projects.kde.org/api/doc/ specifically deals with this problem > by abstracting the repo away behind a micro service. This looks like another view of the data available in kde_projects.xml, however the API is very limited. For example I can't query repo descriptions using this API. Thus not helpful. However if we were going to kill kde_projects.xml, are you sure projects.kde.org/api/ would be still available and not shut down as well? -- Alexander Potashev
Re: Sysadmin Load Reduction: Subversion Infrastructure
пн, 11 нояб. 2019 г. в 17:02, Luigi Toscano : > > Alexander Potashev ha scritto: > > вс, 10 нояб. 2019 г. в 18:09, Luigi Toscano : > >> Most of translators are not so technical as the developers. And even > >> developers can shoot them in the foot with git, I see many issues coming > >> from > >> unwanted merges. > > > > We can block unwanted merged on the server with a Git hook like this: > > https://github.com/FabreFrederic/git-hook-pre-receive-reject-merge-commit > > When I talk about local merges, I foresee a bit of mess when resolving a merge > locally, which may result in proper commits whose content has an invalid > syntax. I don't get it. If you have conflicting changes, either with SVN or Git, you have to resolve the conflict manually. Of course it's easy to break the syntax while doing so, however SVN does not make it any easier than Git. > > Cloning the whole repo would be too much for some translators, however > > the new Git feature "git clone --filter" might be a solution: > > https://unix.stackexchange.com/a/468182 > > Documentation does not seem to help (or at least I don't seem to find it in > the man pages for git 2.24). Do you know how it could filter just some > directories? It seems more focused on filtering by object type. OK, I now tried this approach with Git 2.23 (see attached log) and found horrible problems that make it basically unusable: 1. git-checkout downloads each file in a new SSH connection. It make the download really slow: less than 1 file per second in my setup. That means downloading of translations into one language would take more than an hour. 2. git-status silently tries to download to whole Git repository. 3. git-commit tries to download some files one by one again. > > Shall I create a new Phabricator task "[WIP] Migrate translations from > > SVN to Git" so we can put relevant ideas in one place? > > I don't know. For me having a board and tasks (it's not just a single task, > it's an entire project) sounds like there is something that can be > implemented, and I don't think it's the case. The tag [WIP] would hint that we are not sure if it can be implemented. We can even name it "Reasons why translations cannot migrate to Git", if necessary. > I think we should first document all the answers to this recurring questions > first. Agreed. IMO a Phabricator "task" would be the most appropriate place to document these answers because we don't have better options: Community Wiki and Nextcloud are not very suitable for discussions. -- Alexander Potashev [aspotashev@candy kde-git]$ git clone --no-checkout --filter=blob:none "aspotashev@10.8.0.4:/home/aspotashev/kde-git/krita/.git" krita Cloning into 'krita'... remote: Enumerating objects: 321084, done. remote: Counting objects: 100% (321084/321084), done. remote: Compressing objects: 100% (64401/64401), done. remote: Total 321084 (delta 257379), reused 319306 (delta 255807) Receiving objects: 100% (321084/321084), 36.15 MiB | 593.00 KiB/s, done. Resolving deltas: 100% (257379/257379), done. [aspotashev@candy kde-git]$ cd krita/ [aspotashev@candy krita]$ git checkout master -- cmake/ remote: Enumerating objects: 1, done. remote: Counting objects: 100% (1/1), done. remote: Total 1 (delta 0), reused 1 (delta 0) Receiving objects: 100% (1/1), 445 bytes | 445.00 KiB/s, done. remote: Enumerating objects: 1, done. remote: Counting objects: 100% (1/1), done. remote: Total 1 (delta 0), reused 0 (delta 0) Receiving objects: 100% (1/1), 294 bytes | 294.00 KiB/s, done. remote: Enumerating objects: 1, done. remote: Counting objects: 100% (1/1), done. remote: Total 1 (delta 0), reused 1 (delta 0) Receiving objects: 100% (1/1), 1020 bytes | 1020.00 KiB/s, done. remote: Enumerating objects: 1, done. remote: Counting objects: 100% (1/1), done. remote: Total 1 (delta 0), reused 0 (delta 0) Receiving objects: 100% (1/1), 730 bytes | 730.00 KiB/s, done. remote: Enumerating objects: 1, done. remote: Counting objects: 100% (1/1), done. remote: Total 1 (delta 0), reused 1 (delta 0) Receiving objects: 100% (1/1), 3.42 KiB | 3.42 MiB/s, done. remote: Enumerating objects: 1, done. remote: Counting objects: 100% (1/1), done. remote: Total 1 (delta 0), reused 0 (delta 0) Receiving objects: 100% (1/1), 362 bytes | 362.00 KiB/s, done. remote: Enumerating objects: 1, done. remote: Counting objects: 100% (1/1), done. remote: Total 1 (delta 0), reused 1 (delta 0) Receiving objects: 100% (1/1), 358 bytes | 358.00 KiB/s, done. remote: Enumerating objects: 1, done. remote: Counting objects: 100% (1/1), done. remote: Total 1 (delta 0), reused 1 (delta 0) Receiving objects: 100% (1/1), 465 bytes | 465.00 KiB/s, done. remote: Enumerating objects: 1, done. remote: Counting objects: 100% (1/1), done. remote: Total 1 (d
Re: Sysadmin Load Reduction: Subversion Infrastructure
вс, 10 нояб. 2019 г. в 18:09, Luigi Toscano : > > Nate Graham ha scritto: > > On 11/9/19 4:50 PM, Nicolás Alvarez wrote: > >> El sáb., 9 de nov. de 2019 a la(s) 20:29, Nate Graham (n...@kde.org) > >> escribió: > >>> > >>> Not knowing anything about the translation system we use... what are the > >>> blockers to moving it over to git? > >>> > >> Not necessarily in order: > >> - Experiment conversion to git and see if the resulting repo(s) are of > >> a reasonable size (I vaguely recall seeing bad results with this) > >> - Convince and teach every translator to use git (expect lots of friction > >> here) > >> - Make scripty use git instead of svn (likely lots of work) > >> - Some language teams have their own tooling (local for translation, > >> or web for statistics) that would need to be gitified too. For > >> example, the Spanish team developed KSvnUpdater. > >> - Update lots of documentation in different languages (eg. > >> https://es.l10n.kde.org/repositorio.php) > >> > >> You may even need to migrate languages one by one (as you convince > >> each language team?), so in the meantime all tooling would need to > >> support both repos at the same time. > >> > >> It doesn't sound like fun... > > > > Thanks for the background. > > > > If we're going to keep SVN, I think we need to fully support it. If we don't > > have the resources to do this on an ongoing basis, then we need to invest > > the > > resources now/soon to move away from it. I don't see any other realistic > > options. > > New resources is the solution. Please see the other emails: the problem > discussed is not subversion itself, but the web interface. > > > > > Again, from a totally non-translation perspective, I am somewhat surprised > > to > > hear that individual translators are required to be proficient in a source > > control system. Perhaps de-coupling the workflow from direct interaction > > with > > the SCM would be beneficial? Isn't this what GUI apps like KLocalize do? If > > not, can it be modified to do the SCM interaction? This seems like a > > solvable > > problem. > > Most of translators are not so technical as the developers. And even > developers can shoot them in the foot with git, I see many issues coming from > unwanted merges. > Also, in addition to some of the problem described above (not all of them are > blocker IMHO), more relevant: how would you convert the SVN repositories into > git? > - a unique repository would be the easier way, and required by people who do > changes to all the languages (renamed and moves) but I can only foresee tons > of merging issues when committing (see above). > - a repository per language would mean a tons of work whenever you need to do > a global operation, and right now it's a no go. Hi Luigi, We can block unwanted merged on the server with a Git hook like this: https://github.com/FabreFrederic/git-hook-pre-receive-reject-merge-commit > >> - Experiment conversion to git and see if the resulting repo(s) are of > >> a reasonable size (I vaguely recall seeing bad results with this) I expect that a single Git repository would be several GBs in size. Cloning the whole repo would be too much for some translators, however the new Git feature "git clone --filter" might be a solution: https://unix.stackexchange.com/a/468182 Shall I create a new Phabricator task "[WIP] Migrate translations from SVN to Git" so we can put relevant ideas in one place? -- Alexander Potashev
Re: Sysadmin Load Reduction: Subversion Infrastructure
пн, 11 нояб. 2019 г. в 02:01, Nate Graham : > > On 11/10/19 8:09 AM, Luigi Toscano wrote: > > Most of translators are not so technical as the developers. And even > > developers can shoot them in the foot with git, I see many issues coming > > from > > unwanted merges. > > That's why I would expect that non-technical translators would be able > to use a nice GUI app that abstracts away all the technical details, > including the backend SCM. Doesn't Lokalize do this? No, Lokalize cannot interact with SCMs. Until 2015 there was a Lokalize plugin "newprojectwizard" - all it could do were "svn checkout" and "svn update". Once there is an SVN conflict, you are doomed to using fully functional SVN clients. -- Alexander Potashev
Re: Sysadmin Load Reduction: Subversion Infrastructure
вс, 10 нояб. 2019 г. в 23:56, Ingo Klöcker : > > On Sonntag, 10. November 2019 16:09:34 CET Luigi Toscano wrote: > > Nate Graham ha scritto: > > > Again, from a totally non-translation perspective, I am somewhat surprised > > > to hear that individual translators are required to be proficient in a > > > source control system. Perhaps de-coupling the workflow from direct > > > interaction with the SCM would be beneficial? Isn't this what GUI apps > > > like KLocalize do? If not, can it be modified to do the SCM interaction? > > > This seems like a solvable problem. > > > > Most of translators are not so technical as the developers. And even > > developers can shoot them in the foot with git, I see many issues coming > > from unwanted merges. > > GitLab allows editing files directly in the browser. Maybe that's an > alternative to having to deal with an SCM-CLI. > > > Also, in addition to some of the problem described above (not all of them > > are blocker IMHO), more relevant: how would you convert the SVN > > repositories into git? > > - a unique repository would be the easier way, and > > required by people who do changes to all the languages (renamed and moves) > > but I can only foresee tons of merging issues when committing (see above). > > Why do those merging issues not occur with svn? Because git-pull merges by default. And even if you teach all translators to use rebase, there is another obstacle: "git pull --rebase" does not work with uncommitted changes while "svn update" works. Editing translation files on GitLab is by complexity close to editing SVG images... on GitLab. Some experienced people can get it right, but most of the time you will produce syntax errors. Also, Lokalize has much more features that a plain text editor: 1. Interactive merging and reviewing of changes from other .po translation files. I use it all the time to review and commit translations from people without SVN accounts. 2. Translation memory. Boost productivity, improves consistency of translations. 3. Other features that improve productivity (insertion of XML/HTML tags, source string diffs, ...) -- Alexander Potashev
Re: Sysadmin Load Reduction: Subversion Infrastructure
вс, 10 нояб. 2019 г. в 04:10, Ben Cooksley :
>
> On Sun, Nov 10, 2019 at 11:19 AM Albert Astals Cid wrote:
> >
> > El dissabte, 9 de novembre de 2019, a les 21:22:16 CET, Ben Cooksley va
> > escriure:
> > > On Sun, Nov 10, 2019 at 8:37 AM Albert Astals Cid wrote:
> > > >
> > > > El dissabte, 9 de novembre de 2019, a les 19:27:07 CET, Ben Cooksley va
> > > > escriure:
> > > > > On Sun, Nov 10, 2019 at 7:18 AM Alexander Potashev
> > > > > wrote:
> > > > > >
> > > > > > сб, 9 нояб. 2019 г. в 03:20, Ben Cooksley :
> > > > > > > This would include the shutdown of WebSVN in particular, which
> > > > > > > when
> > > > > > > coupled with the shutdown of our two CGit instances would also
> > > > > > > allow
> > > > > > > for us to eliminate an entire virtual machine from our systems.
> > > > > >
> > > > > > Will there be any web interface for SVN after shutdown of WebSVN?
> > > > > >
> > > > > > Can we assume https://phabricator.kde.org/source/svn/ remains
> > > > > > available during the next 10 years?
> > > > > >
> > > > >
> > > > > Phabricator's browser will be retired as part of the shutdown of
> > > > > Phabricator, which will take place once Gitlab has assumed
> > > > > responsibility for code hosting and review, and the tasks have been
> > > > > migrated from Phabricator.
> > > > >
> > > > > Should WebSVN be shutdown as well, then there would be no web
> > > > > interface to our SVN repository.
> > > >
> > > > That's not acceptable.
> > >
> > > Mind explaining why?
> >
> > Because we use it in l10n.kde.org to link to po files.
>
> Mind detailing what those links are used for?
A common workflow suggested for translators without SVN account
(and/or those who find it hard to use SVN) is as folllows:
1. Go to https://l10n.kde.org/stats/gui/trunk-kf5/team/ru/ ("ru" for
Russian) and pick a .po translation file that needs update - e.g.
incomplete translation or one containing mistakes.
2. Click on the .po file at l10n.kde.org to downloaded. WebSVN is
used for this.
3. Edit the downloaded .po file, send for review, etc.
WebSVN is even mentioned in KDE's primary translation how-to:
https://l10n.kde.org/docs/translation-howto/gui-translation.html
--
Alexander Potashev
Re: Sysadmin Load Reduction: Code Related Services
сб, 9 нояб. 2019 г. в 02:51, Ben Cooksley : > In the category of no longer in use, we have the compatibility > generator for the kde_projects.xml file. This was introduced when we > shutdown Redmine/Chiliproject and migrated to Phabricator, as a way of > keeping services that needed to discover a list of KDE Projects > functional. > > As we've since migrated to using YAML files within the > sysadmin/repo-metadata repository for both the CI System and > kdesrc-build (and with LXR using kdesrc-build to do it's code > checkouts) there shouldn't to my knowledge be anything still relying > on this (aside from perhaps scripty). > > I'd therefore like to shut this generator down as well, along with the > compaibility redirector running at projects.kde.org (given that it has > been some time since we were using that site, and many projects have > moved around in the virtual structure since then, making the redirects > it is able to offer useless) Hi Ben, I am developing a new version of the "opensrc" plugin for Lokalize [1] and it currently depends on kde_projects.xml. Of course I can add new code to scan the Git repo instead of just fetching kde_projects.xml, however it would be more complicated. Is there any good reason for killing kde_projects.xml? Would that really reduce the workload on Sysadmin team? I can't suspect any "moving parts" in the generator that may require maintenance. [1] https://cgit.kde.org/scratch/aspotashev/lokalize-opensrc-py.git/ -- Alexander Potashev
Re: General Infrastructure Maintainability: API and EBN
сб, 9 нояб. 2019 г. в 21:50, Ben Cooksley : > > > Over the past number of years one of the tasks the Sysadmin team has > > > worked on has been improving the overall maintainability of our > > > systems, with a significant number of specialised cronjobs, exceptions > > > and hidden linkages being eliminated. > > > > > > That is with one great exception: api.kde.org and ebn.kde.org. > > > > > > Both of these are suffering from an extreme amount of digital bitrot > > > and special casing and in general are now in a condition where I > > > cannot say for certain whether it would be possible to replicate the > > > setup on a new system without us experiencing some degree of breakage > > > (some of which we may not discover until weeks/months afterwards). > > > > > > In addition, the current setup relies on an old-fashioned overnight > > > reprocessing of all repositories, which is inefficient and resource > > > expensive. A more modern approach would have the various projects api > > > documentation generated on a delayed cycle from relevant branches as > > > part of something like a CI job (but not part of the actual CI > > > workflow itself). Hi Ben, I can't discuss this topic before we understand what exactly is wrong with api.kde.org and ebn.kde.org and why they are hard to manage. Could you please describe the current situation (where to find source code, how many servers, etc) in new Phabricator tasks like you did for identity.kde.org in https://phabricator.kde.org/T8449 ? P.S. Complicated legacy systems can be easy to replicate once you automate their deployment by using Docker containers and/or configuration management software like Ansible. -- Alexander Potashev
Re: Sysadmin Load Reduction: Subversion Infrastructure
сб, 9 нояб. 2019 г. в 03:20, Ben Cooksley : > This would include the shutdown of WebSVN in particular, which when > coupled with the shutdown of our two CGit instances would also allow > for us to eliminate an entire virtual machine from our systems. Will there be any web interface for SVN after shutdown of WebSVN? Can we assume https://phabricator.kde.org/source/svn/ remains available during the next 10 years? I'm not sure what use case Luigi has in mind, but among Russian l10n team we often use WebSVN to refer to specific SVN revisions, for example: https://websvn.kde.org/?view=revision=1555342 -- Alexander Potashev
Re: vote invitation sent out for goal voting
Thank you Lydia! What is the deadline for the "ballot" to be considered/counted? On Thu, Aug 22, 2019, 22:42 Lydia Pintscher wrote: > Hey folks, > > I have just sent out the emails with links to this year's goal survey. > All the final proposals are here: > https://phabricator.kde.org/tag/goal_setting_2019/ > The invitation went out to everyone subscribed to this mailinglist as > well as everyone with a developer account. If you did not receive it > but are an active contributor to KDE please send me an email off-list > to sort it out. > I'm really sorry that it has taken me longer than I wanted. I ran into > a few obstacles setting everything up during a conference. > > > Cheers > Lydia > > -- > Lydia Pintscher - http://about.me/lydia.pintscher > KDE e.V. Board of Directors > http://kde.org - http://open-advice.org >
Re: Updated Apps Website
Hi Jonathan, How would you handle the apps being developed (thus, not "unmaintained") that have a Git repository, but not released yet? ср, 5 июн. 2019 г. в 14:08, Jonathan Riddell : > > The new KDE Applications website is now up > > https://kde.org/applications/ > > The old one was a manual task of keeping the metadata up to date while this > one scans builds from build.kde.org and git in search of appstream > appdata.xml files and converts them into the required info. > > Technical info at > https://community.kde.org/KDE.org/applications > > If you see mistakes, go and fix them by updating the appstream files. These > files are also used in distro packages and appstores and new container > packages so a fix there goes a long way. > > https://community.kde.org/Guidelines_and_HOWTOs/AppStream > > Icons come from Breeze. If you see an issue with an icon I'm sure the Breeze > folks would be happy for a fix > https://bugs.kde.org/show_bug.cgi?id=407527 > > Future work is to make the content more pretty and relevant. Adding in non > app projects in some way. Adding in version numbers and release notes and > other features supported by appstream. Workboard at > https://phabricator.kde.org/project/board/196/ > > KDE needs to up its game for the support it provides for our applications, > here's to a great future for them :) > > Jonathan > -- Alexander Potashev
Re: Closing NEEDSINFO bugs after 30 days
пт, 16 нояб. 2018 г. в 16:35, Boudewijn Rempt : > > On vrijdag 16 november 2018 14:31:39 CET Alexander Potashev wrote: > > > You only considered to case when human sets NEEDSINFO. If NEEDSINFO is > > set by a script, we may have the same problem, would you suggest > > implementing the same behaviour? > > We don't have the script setting NEEDSINFO, do we? At least, I didn't see it > in Harald's list of options. Hopefully we don't. I noticed such change in some bug reports, however all of them are attributed to Andrew himself, not the "bug janitor" account. Sorry for the noise. -- Alexander Potashev
Re: Closing NEEDSINFO bugs after 30 days
пт, 16 нояб. 2018 г. в 16:22, Harald Sitter : > > On Fri, Nov 16, 2018 at 2:16 PM Boudewijn Rempt wrote: > > > > On vrijdag 16 november 2018 14:11:29 CET Harald Sitter wrote: > > > > > - human sets needsinfo > > > - 15 days pass: bot posts reminder > > > - reporter comments > > > - N days pass: bug gets automatically dropped back to whatever the > > > previous state was? > > > > Yes, that would be perfect! As far as I'm concerned, N can be 0 or 1. > > Cool. Should be easy to do. > > Any disagreements from the rest of the community? > > TLDR: if the original reporter comments on a needsinfo bug it gets > automatically switched back to whatever the state before needsinfo was Hi Harald, You only considered to case when human sets NEEDSINFO. If NEEDSINFO is set by a script, we may have the same problem, would you suggest implementing the same behaviour? -- Alexander Potashev
Re: Akademy 2018 Visa Invitations Batch #3
Hi Stefan, I don't understand how this invitation helps in the visa process. 1. If this invitation is from an enterprise and it does not cover your flights/accomodation, then your are required to book that before applying for the business visa, right? 2. If this invitation is from a citizen and it does not say that the guest stays in his/her home, then the same. Sounds like a regular tourist's visa requires the same amount of paperwork. 2018-06-08 18:32 GMT+03:00 Stefan Derkits : > Hello, > > as we just finished processing Batch #2 of the Visa Invitation Letters, > we wanted to give you all a deadline for Batch #3. > > So if you still need a Visa Invitation and want to get it before end of > June, please send us all the needed data until: > Tuesday, 19.06. 12:00 pm CEST (Berlin/Vienna Time) > > How to request a Visa Invitation Letter: > * Send your request for an invitation to akademy-team at kde.org, Subject: > "Visa Invitation Request" > * In the request, we need the following data: > ** Full Name > ** Full Address > ** Country of Origin > ** Passport Number > ** Date of Birth > ** wether you are a sponsored attendee or not > ** Arrival & Departure Date > > See you in Vienna, > Stefan > -- Alexander Potashev
Re: Kubuntu and other KDE distribution's use of KDE infrastructure
2017-01-16 20:51 GMT+03:00 Ken Vermette <verme...@gmail.com>: > KDE applications. In this case Canonical could use KDE infra for Kubuntu > In this case, Canonical is a patron, so Kubuntu, under Canonical, would fall > under this this umbrella. Kubuntu is not under Canonical since 2012. -- Alexander Potashev
Re: Bugzilla upgraded
2016-10-31 9:28 GMT+03:00 Ben Cooksley <bcooks...@kde.org>: > On Sun, Oct 30, 2016 at 9:48 AM, Alexander Potashev > <aspotas...@gmail.com> wrote: >> 2016-10-29 23:06 GMT+03:00 Ben Cooksley <bcooks...@kde.org>: >>> On Sun, Oct 30, 2016 at 4:59 AM, Alexander Potashev >>> <aspotas...@gmail.com> wrote: >>>> 2016-10-25 23:18 GMT+03:00 Ben Cooksley <bcooks...@kde.org>: >>>>> Hi all, >>>>> >>>>> The production instance of bugs.kde.org has now been upgraded with the >>>>> latest Bugzilla. >>>>> Thanks to everyone who tested the instance at bugstest.kde.org. >>>>> >>>>> If there are any issues, please let one of us know. >>>> >>>> Hi Ben, >>> >>> Hi Alexander, >>> >>>> >>>> When submitting a bug report recently, I noticed that the "Platform" >>>> combobox now has only 4 options: Other, PC, Macintosh, All. Before the >>>> update you could select from a large list of Linux distros. Even >>>> worse: if you select "Platform: PC", the bug report is rejected >>>> because of invalid platform. >>> >>> This is because you are using the Guided format, which is an >>> uncustomised upstream template - mainly intended for use on Mozilla's >>> Bugzilla. >>> I can't see this linked anywhere on bugs.kde.org itself though so i've >>> no idea how you got there. >> >> I clicked "Help -> Report Bug -> Launch Bug Report Wizard" in an application. >> >> See KBugReportPrivate::_k_updateUrl() in >> >> https://quickgit.kde.org/?p=kxmlgui.git=blob=7b18f8ad119759b1696916fbc2e9c6b54941cc8b=538a66fdab8194e860b98f0276f2b4e257e60507=src%2Fkbugreport.cpp > > I've now made adjustments to Bugzilla to ensure the different "guided" > wizard won't be used anymore when reporting bugs. Looks good. Thanks! -- Alexander Potashev
Re: Bugzilla upgraded
2016-10-29 23:06 GMT+03:00 Ben Cooksley <bcooks...@kde.org>: > On Sun, Oct 30, 2016 at 4:59 AM, Alexander Potashev > <aspotas...@gmail.com> wrote: >> 2016-10-25 23:18 GMT+03:00 Ben Cooksley <bcooks...@kde.org>: >>> Hi all, >>> >>> The production instance of bugs.kde.org has now been upgraded with the >>> latest Bugzilla. >>> Thanks to everyone who tested the instance at bugstest.kde.org. >>> >>> If there are any issues, please let one of us know. >> >> Hi Ben, > > Hi Alexander, > >> >> When submitting a bug report recently, I noticed that the "Platform" >> combobox now has only 4 options: Other, PC, Macintosh, All. Before the >> update you could select from a large list of Linux distros. Even >> worse: if you select "Platform: PC", the bug report is rejected >> because of invalid platform. > > This is because you are using the Guided format, which is an > uncustomised upstream template - mainly intended for use on Mozilla's > Bugzilla. > I can't see this linked anywhere on bugs.kde.org itself though so i've > no idea how you got there. I clicked "Help -> Report Bug -> Launch Bug Report Wizard" in an application. See KBugReportPrivate::_k_updateUrl() in https://quickgit.kde.org/?p=kxmlgui.git=blob=7b18f8ad119759b1696916fbc2e9c6b54941cc8b=538a66fdab8194e860b98f0276f2b4e257e60507=src%2Fkbugreport.cpp -- Alexander Potashev
Re: Bugzilla upgraded
2016-10-25 23:18 GMT+03:00 Ben Cooksley <bcooks...@kde.org>: > Hi all, > > The production instance of bugs.kde.org has now been upgraded with the > latest Bugzilla. > Thanks to everyone who tested the instance at bugstest.kde.org. > > If there are any issues, please let one of us know. Hi Ben, When submitting a bug report recently, I noticed that the "Platform" combobox now has only 4 options: Other, PC, Macintosh, All. Before the update you could select from a large list of Linux distros. Even worse: if you select "Platform: PC", the bug report is rejected because of invalid platform. -- Alexander Potashev
