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
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"... ;-)
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
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
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
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 wo
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
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
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,
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
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:
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 sel
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
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
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...
>
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
31 matches
Mail list logo
