A contributor has recently started translating KDE to Amharic.
They are looking for people to help since translating KDE is a lot of work.
Please join the kde-l10n-am mailing list and introduce yourself if you are interested in helping!
Showing posts with label kde. Show all posts
Showing posts with label kde. Show all posts
Monday, May 18, 2026
Friday, December 23, 2022
Donate to KDE with a 10% power up! (1-week-offer)
Hopefully by now, you know that in KDE we are running an End of Year Fundraising campaign.
If you didn't, now you know :)
The campaign has already raised around 16 thousand euros, but there's still a bit to go to the minimum goal of 20 thousand.
So let's spice things up a little, I will donate 10% of every donation you make, you donate 1€, I will donate 0.1€, you donate 100€ I will donate 10€, etc.
I'm placing my maximum total donation amount at (20000-16211.98)/11 = 344.37€, that is if you all donate 3443.7€ (or more), I will donate 344.37€ and we'll reach the 20K goal.
How is this going to work?
I will make my donation on the 31st of December (just one donation, to save up on fees).
For your donation to be included in my matching donation you need to send me an email to aacid@kde.org with your name/email and put in copy (CC) the KDE e.V. board kde-ev-board@kde.org so they can confirm your donation.
Only donations between now (23rd of December around 18:00 CET) and 31st of December will be considered.
Saturday, May 14, 2022
The KDE Qt5 Patch Collection has been rebased on top of Qt 5.15.4
Commit: https://invent.kde.org/qt/qt/qt5/-/commit/5c85338da3c272587c0ec804c7565db57729fd48
Commercial release announcement: https://www.qt.io/blog/commercial-lts-qt-5.15.4-released
I want to personally extend my gratitude to the Commercial users of Qt for beta testing Qt 5.15.4 for the rest of us.
The Commercial Qt 5.15.4 release introduced some bugs that have later been fixed. Thanks to that, our Patchset Collection has been able to incorporate the reverts for those two bugs that affected Android and Windows and the Free Software users will never be affected by those!
Friday, April 17, 2020
Should KDE fork CHMLib?
CHMLib is a library to handle CHM files.
It is used by Okular and other applications to show those files.
It hasn't had a release in 11 years.
It is packaged by all major distributions.
A few weeks ago I got annoyed because we need to carry a patch in Okular flathub because the code is not great and it defines it's own int types.
I tried contacting the upstream author, but unsurprisingly after 11 years he doesn't seem to care much and got no answer.
Then i looked saw that various distributions carry different random set of patches, not great.
So I said, OK, maybe we should just fork it, and emailed 14 people listed at repology as package maintainers for CHMLib saying how they would react to KDE forking CHMLib in an effort to do some basic maintenance, i.e. get it to compile without need for patches, make sure all the patches different distributions has are in the same place, etc.
1 packager answered saying "great"
1 packager answered "nah we want to follow upstream" (... which part of upstream is dead did they not understand?)
1 person answered saying "i haven't been packaging for $DISTRO for ages" (makes sense given how old the package is)
1 person answered saying "not a maintainer anymore but i think you should not break API/ABI of CHMLib" (which makes sense, never said that was planned)
And that's it, so only 4 out of 14 answers and only one of them encouraging.
So I'm asking *YOU*, should we push for a fork or I should stop this crazyness and do something more productive?
It is used by Okular and other applications to show those files.
It hasn't had a release in 11 years.
It is packaged by all major distributions.
A few weeks ago I got annoyed because we need to carry a patch in Okular flathub because the code is not great and it defines it's own int types.
I tried contacting the upstream author, but unsurprisingly after 11 years he doesn't seem to care much and got no answer.
Then i looked saw that various distributions carry different random set of patches, not great.
So I said, OK, maybe we should just fork it, and emailed 14 people listed at repology as package maintainers for CHMLib saying how they would react to KDE forking CHMLib in an effort to do some basic maintenance, i.e. get it to compile without need for patches, make sure all the patches different distributions has are in the same place, etc.
1 packager answered saying "great"
1 packager answered "nah we want to follow upstream" (... which part of upstream is dead did they not understand?)
1 person answered saying "i haven't been packaging for $DISTRO for ages" (makes sense given how old the package is)
1 person answered saying "not a maintainer anymore but i think you should not break API/ABI of CHMLib" (which makes sense, never said that was planned)
And that's it, so only 4 out of 14 answers and only one of them encouraging.
So I'm asking *YOU*, should we push for a fork or I should stop this crazyness and do something more productive?
Thursday, February 06, 2020
New help porting to Go >= 1.12
At KDE we have a GitHub mirror. One of the problems about having a mirror is that people routinely try to propose Pull Requests over there, but no one is watching, so they would go stale, which is not good for anyone.
What no one? Actually no, we have kdeclose, a bot that will go over all Pull Requests and gracefully close them suggesting people to move the patch over to KDE infrastructure where we are watching.
The problem is that I'm running that code on Google AppEngine and they are cutting support for the old Go version that it's using, so I would need someone help me port the code to a newer Go version.
Anyone can help me?
P.S: No, I'm not the original author of the code, it's a fork of something else, but that has not been updated either.
Update: This is now done, thanks to Daniele (see first comment). Mega fast, thanks community!
What no one? Actually no, we have kdeclose, a bot that will go over all Pull Requests and gracefully close them suggesting people to move the patch over to KDE infrastructure where we are watching.
The problem is that I'm running that code on Google AppEngine and they are cutting support for the old Go version that it's using, so I would need someone help me port the code to a newer Go version.
Anyone can help me?
P.S: No, I'm not the original author of the code, it's a fork of something else, but that has not been updated either.
Update: This is now done, thanks to Daniele (see first comment). Mega fast, thanks community!
Sunday, February 02, 2020
QCA cleanup spree
The last few weeks I've done quite a bit of QCA cleanup.
Bit of a summary:
* Moved to KDE's gitlab and enable clazy and clang-tidy continuous integration checks
* Fixed lots of crashes when copying some of the classes, it's not a normal use case, but it's supported by the API so make it work :)
* Fixed lots of crashes because we were assuming some of the backend libraries had more features than they actually do (e.g. we thought botan would support always support a given crypto algorithm, but some versions don't, now we check if the algorithm it's supported before saying it is)
* Made all the tests succeed :)
* Dropped Qt4 support
* Use override, nullptr (Laurent), various of the "sanity" QT_* defines, etc.
* botan backend now requires botan2
* Fixed most of the compile warnings
What I probably also did is maybe break the OSX and Windows builds, so if you're using QCA there you should start testing it and propose Merge Requests.
Note: My original idea was to actually kill QCA because i started looking at it and lot of the code looked a bit fishy, and no one wants crypto fishy code, but then i realized we use it in too many places in KDE and i'd rather have "fishy crypto code" in one place than in lots of different places, at least this way it's easier to eventually fix it.
Bit of a summary:
* Moved to KDE's gitlab and enable clazy and clang-tidy continuous integration checks
* Fixed lots of crashes when copying some of the classes, it's not a normal use case, but it's supported by the API so make it work :)
* Fixed lots of crashes because we were assuming some of the backend libraries had more features than they actually do (e.g. we thought botan would support always support a given crypto algorithm, but some versions don't, now we check if the algorithm it's supported before saying it is)
* Made all the tests succeed :)
* Dropped Qt4 support
* Use override, nullptr (Laurent), various of the "sanity" QT_* defines, etc.
* botan backend now requires botan2
* Fixed most of the compile warnings
What I probably also did is maybe break the OSX and Windows builds, so if you're using QCA there you should start testing it and propose Merge Requests.
Note: My original idea was to actually kill QCA because i started looking at it and lot of the code looked a bit fishy, and no one wants crypto fishy code, but then i realized we use it in too many places in KDE and i'd rather have "fishy crypto code" in one place than in lots of different places, at least this way it's easier to eventually fix it.
Tuesday, January 28, 2020
The Qt Company is stopping Qt LTS releases. We (KDE) are going to be fine :)
Obvious disclaimer, this is my opinion, not KDE's, not my employer's, not my parents', only mine ;)
Big news today is that Qt Long-term-supported (LTS) releases and the offline installer will become available to commercial licensees only.
Ignoring upcoming switch to Qt6 scenario for now, how bad is that for us?
Let's look at some numbers from our friends at repology.
At this point we have 2 Qt LTS going on, Qt 5.9 (5.9.9 since December) and Qt 5.12 (5.12.6 since November).
How many distros ship Qt 5.9.9? 0. (there's macports and slackbuilds but none of those seem to provide Plasma packages, so I'm ignoring them)
How many distros ship Qt 5.12.6? 5, Adélie Linux, Fedora 30, Mageia 7, OpenSuse Leap 15.2, PCLinux OS (ALT Linux and GNU Guix also do but they don't seem to ship Plasma). Those are some bigger names (I'd say specially Fedora and OpenSuse).
On the other hand Fedora 28 and 29 ship some 5.12.x version but have not updated to 5.12.6, Opensuse Leap 15.1 has a similar issue, it's stuck on 5.9.7 and did not update to 5.9.9 and so is Mageia 6 which is stuck on Qt 5.9.4
Ubuntu 19.04, 19.08 and 20.04 all ship some version of Qt 5.12 (LTS) but not the lastest version.
On the other a few of other "big" distros don't ship Qt LTS, Arch and Gentoo ship 5.14, our not-distro-distro Neon is on 5.13 and so is flatpak.
As I see it, the numbers say that while it's true that some distros are shipping the latest LTS release, it's not all of them by far, and it looks more like an opportunistic use, the LTS branch is followed for a while in the last release of the distro, but the previous ones get abandoned at some point, so the LTS doesn't really seem to be used to its fully potential.
What would happen if there was no Qt LTS?
Hard to say, but I think some of the "newer" distros would actually be shipping Qt 5.13 or 5.14, and in my book that's a good thing, moving users forward is always good.
The "already released" distros is different story, since they would obviously not be updating from Qt 5.9 to 5.14, but as we've seen it seems that most of the times they don't really follow the Qt LTS releases to its full extent either.
So all in all, I'm going to say not having Qt LTS releases is not that bad for KDE, we've lived for that for a long time (remember there has only been 4 Qt LTS, 4.8, 5.6, 5.9 and 5.12) so we'll do mostly fine.
Yes, this may actually be a problem, if all goes to plan Qt 5.15 will be released in May and Qt 6.0 in November, that means we will likely get up to Qt 5.15.2 or 5.15.3 and then that's it, we're moving to Qt 6.0
Obviously KDE will have to move to Qt 6 at some point, but that's going to take a while (as example Plasma 5 was released when Qt was at 5.3) so for let's say that for a year or two we will still be using Qt 5.15 without any bugfix releases.
That can be OK if Qt 5.15 ends being a good release or a problem if it's a bit buggy. If it's buggy, well then we'll have to figure out what to do, and it'll probably involve some kind of fork somewhere, be it by KDE (qt already had that for a while in ancient history with qt-copy) or by some other trusted source, but let's hope it doesn't get to that, since it would mean that there's two set of people fixing bugs in Qt 5.15, The Qt Company engineers and the rest of the world, and doing the same work twice is not smart.
Big news today is that Qt Long-term-supported (LTS) releases and the offline installer will become available to commercial licensees only.
Ignoring upcoming switch to Qt6 scenario for now, how bad is that for us?
Let's look at some numbers from our friends at repology.
At this point we have 2 Qt LTS going on, Qt 5.9 (5.9.9 since December) and Qt 5.12 (5.12.6 since November).
How many distros ship Qt 5.9.9? 0. (there's macports and slackbuilds but none of those seem to provide Plasma packages, so I'm ignoring them)
How many distros ship Qt 5.12.6? 5, Adélie Linux, Fedora 30, Mageia 7, OpenSuse Leap 15.2, PCLinux OS (ALT Linux and GNU Guix also do but they don't seem to ship Plasma). Those are some bigger names (I'd say specially Fedora and OpenSuse).
On the other hand Fedora 28 and 29 ship some 5.12.x version but have not updated to 5.12.6, Opensuse Leap 15.1 has a similar issue, it's stuck on 5.9.7 and did not update to 5.9.9 and so is Mageia 6 which is stuck on Qt 5.9.4
Ubuntu 19.04, 19.08 and 20.04 all ship some version of Qt 5.12 (LTS) but not the lastest version.
On the other a few of other "big" distros don't ship Qt LTS, Arch and Gentoo ship 5.14, our not-distro-distro Neon is on 5.13 and so is flatpak.
As I see it, the numbers say that while it's true that some distros are shipping the latest LTS release, it's not all of them by far, and it looks more like an opportunistic use, the LTS branch is followed for a while in the last release of the distro, but the previous ones get abandoned at some point, so the LTS doesn't really seem to be used to its fully potential.
What would happen if there was no Qt LTS?
Hard to say, but I think some of the "newer" distros would actually be shipping Qt 5.13 or 5.14, and in my book that's a good thing, moving users forward is always good.
The "already released" distros is different story, since they would obviously not be updating from Qt 5.9 to 5.14, but as we've seen it seems that most of the times they don't really follow the Qt LTS releases to its full extent either.
So all in all, I'm going to say not having Qt LTS releases is not that bad for KDE, we've lived for that for a long time (remember there has only been 4 Qt LTS, 4.8, 5.6, 5.9 and 5.12) so we'll do mostly fine.
But What about Qt 5.15 and Qt 6 you ask!
Yes, this may actually be a problem, if all goes to plan Qt 5.15 will be released in May and Qt 6.0 in November, that means we will likely get up to Qt 5.15.2 or 5.15.3 and then that's it, we're moving to Qt 6.0
Obviously KDE will have to move to Qt 6 at some point, but that's going to take a while (as example Plasma 5 was released when Qt was at 5.3) so for let's say that for a year or two we will still be using Qt 5.15 without any bugfix releases.
That can be OK if Qt 5.15 ends being a good release or a problem if it's a bit buggy. If it's buggy, well then we'll have to figure out what to do, and it'll probably involve some kind of fork somewhere, be it by KDE (qt already had that for a while in ancient history with qt-copy) or by some other trusted source, but let's hope it doesn't get to that, since it would mean that there's two set of people fixing bugs in Qt 5.15, The Qt Company engineers and the rest of the world, and doing the same work twice is not smart.
Monday, September 24, 2018
Libre Application Summit 2018
Earlier this month i attended Libre Application Summit 2018 in Denver.
Libre Application Summit wants to be a place for all people involved in doing Free Software applications to meet and share ideas, though being almost organized by GNOME it had a some skew towards GNOME/flatpak. There was a good presence of KDE, but personally I felt that we would have needed more people at least from LibreOffice, Firefox and someone from the Ubuntu/Canonical/Snap field (don't get annoyed at you if I failed to mention your group).
The Summit was kicked off by a motivational talk on how to make sure we ride the wave of "Open Source has won but people don't know it". I felt the content of the talk was nice but the speaker was hit by some issues (not being able to have the laptop in front of her due to the venue being a bit weirdly layouted) that sadly made her speech a bit too stumbly.
Then we had a bunch of flatpak related talks, ranging from the new freedesktop-sdk runtime, from very technical stuff about how ostree works and also including a talk by our own Aleix Pol on how KDE is planning to approach the release of flatpaks. Some of us ended the day having BBQ at the house the Codethink people were staying. Thanks for the good time!
I kicked off the next day talking about how we (lately mostly Christoph) are doing the KDE Applications releases. We got appreciation of the good work we're doing and some interesting follow up questions so I think people were engaged by it.
The morning continued with talks about how to engage the "non typical" free software people, designers, students, professors, etc.
After lunch we had a few talks by the Elementary people and another talk with Aleix focused on which apps will run on your Plasma devices (hint: all of them).
The day finished with a quizz sponsored by System 76, it was fun!
The last day of talks started again with me speaking, this time about how amazing Qt is and why you should use it to build your apps. There I had some questions about people worrying if QtWidgets was going to die, I told them not to worry, but it's clear The Qt Company needs to improve their messaging in that regard.
After that we had a talk about a Fedora project to create a distro based exclusively in flaptaks, which sounds really interesting. The last talks of LAS 2018 were about how to fight vandalism in crowdsourced data, the status of Librem 5 (it's still a bit far away) and a very interesting one about the status of Free Software in Research.
All in all i think the conference was interesting, still a bit small and too GNOME controlled to appeal to the general crowd, but it's the second time it has been organized, so it will improve.
I want to thank the KDE e.V. for sponsoring my flight and hosting to attend this conference. Please Donate! so we can continue attending conferences like this and spreading the good work of KDE :)
Check out the great group photo at #LASGNOME! Thank you for all the participant and speakers for posing for us :-) pic.twitter.com/v7pPmcCBV1
— LAS GNOME (@LASGNOME) 8 de setembre de 2018
Libre Application Summit wants to be a place for all people involved in doing Free Software applications to meet and share ideas, though being almost organized by GNOME it had a some skew towards GNOME/flatpak. There was a good presence of KDE, but personally I felt that we would have needed more people at least from LibreOffice, Firefox and someone from the Ubuntu/Canonical/Snap field (don't get annoyed at you if I failed to mention your group).
The Summit was kicked off by a motivational talk on how to make sure we ride the wave of "Open Source has won but people don't know it". I felt the content of the talk was nice but the speaker was hit by some issues (not being able to have the laptop in front of her due to the venue being a bit weirdly layouted) that sadly made her speech a bit too stumbly.
Then we had a bunch of flatpak related talks, ranging from the new freedesktop-sdk runtime, from very technical stuff about how ostree works and also including a talk by our own Aleix Pol on how KDE is planning to approach the release of flatpaks. Some of us ended the day having BBQ at the house the Codethink people were staying. Thanks for the good time!
Soon, @tsdgeos tells us all about KDE Applications releases in @LASGNOME. @kdecommunity pic.twitter.com/ODnxEZ77xv
— Aleix Pol (@AleixPol) 7 de setembre de 2018
I kicked off the next day talking about how we (lately mostly Christoph) are doing the KDE Applications releases. We got appreciation of the good work we're doing and some interesting follow up questions so I think people were engaged by it.
The morning continued with talks about how to engage the "non typical" free software people, designers, students, professors, etc.
The @kdecommunity and @Codethink people having interesting discussions over sushi at #LAS2018 pic.twitter.com/O5lH1hPTlk
— Albert Astals Cid (@tsdgeos) 7 de setembre de 2018
After lunch we had a few talks by the Elementary people and another talk with Aleix focused on which apps will run on your Plasma devices (hint: all of them).
The day finished with a quizz sponsored by System 76, it was fun!
The KDE spies team wasn't very successful at #LASGNOME trivial, but had lots of fun :) @tsdgeos @AleixPol @maru161803399 @albertvaka pic.twitter.com/k0172A3Vk1
— Albert Astals Cid (@tsdgeos) 8 de setembre de 2018
The last day of talks started again with me speaking, this time about how amazing Qt is and why you should use it to build your apps. There I had some questions about people worrying if QtWidgets was going to die, I told them not to worry, but it's clear The Qt Company needs to improve their messaging in that regard.
Learning about Qt in the @LASGNOME from @tsdgeos @qtproject pic.twitter.com/Vr5Raj10Su
— Aleix Pol (@AleixPol) 8 de setembre de 2018
After that we had a talk about a Fedora project to create a distro based exclusively in flaptaks, which sounds really interesting. The last talks of LAS 2018 were about how to fight vandalism in crowdsourced data, the status of Librem 5 (it's still a bit far away) and a very interesting one about the status of Free Software in Research.
All in all i think the conference was interesting, still a bit small and too GNOME controlled to appeal to the general crowd, but it's the second time it has been organized, so it will improve.
I want to thank the KDE e.V. for sponsoring my flight and hosting to attend this conference. Please Donate! so we can continue attending conferences like this and spreading the good work of KDE :)
Monday, September 03, 2018
Come meet KDE in Denver - September 6-9
This week, Aleix (KDE eV Vice Predisdent), Albert Vaca (KDE Connect maintainer) and me will be in Denver to attend the Libre Application Summit 2018.
Libre Application Summit is unfortunately not free to attend so even if i'd urge you to come and see the amazing talks we're going to give I can see why not everyone would want to come.
So I'm going to say that if you're in the Denver area and are a KDE fan, write a comment here and maybe we can meet for drinks or something :)
Libre Application Summit is unfortunately not free to attend so even if i'd urge you to come and see the amazing talks we're going to give I can see why not everyone would want to come.
So I'm going to say that if you're in the Denver area and are a KDE fan, write a comment here and maybe we can meet for drinks or something :)
Tuesday, November 15, 2016
Finding a valid build order for KDE repositories
KDE has been lately been growing quite a bit in repositories, and it's not always easy to tell what needs to be build before, do i build first kdepim-apps-libs or pimcommon?
A few days ago i was puzzled by the same question and realized we have the answer in the dependency-data-* files from the kde-build-metadata repository.
They define what depends on what so what we need to do is just build a graph with those dependencies and get a valid build order from it.
Thankfully python already has a module for graphs and stuff so build-order.py was not that hard to write.
So say you want to know a valid build order for the stable repositories based on kf5-qt5
Here it is
Note i've been saying *a* valid build order, not *the* valid build order, since there are various orders that are valid since not every repo depends other repos.
Now i wonder, does anyone else find this useful? And if so to which repository do you think i should commit such script?
A few days ago i was puzzled by the same question and realized we have the answer in the dependency-data-* files from the kde-build-metadata repository.
They define what depends on what so what we need to do is just build a graph with those dependencies and get a valid build order from it.
Thankfully python already has a module for graphs and stuff so build-order.py was not that hard to write.
So say you want to know a valid build order for the stable repositories based on kf5-qt5
Here it is
Note i've been saying *a* valid build order, not *the* valid build order, since there are various orders that are valid since not every repo depends other repos.
Now i wonder, does anyone else find this useful? And if so to which repository do you think i should commit such script?
Sunday, September 27, 2015
KDE dinner in Berlin - October 3
This weekend the KDE e.V. board is going to have an in-person board meeting in Berlin.
We would like you to join us for dinner on Saturday 3 around 19:00 (location still undecided, suggestions accepted).
If you are interested in talking about KDE, KDE e.V., Free Software, Open Source, today's elections in Catalonia or any other random talk and want to have a good time let me know that you're coming (latest by Wednesday night).
We would like you to join us for dinner on Saturday 3 around 19:00 (location still undecided, suggestions accepted).
If you are interested in talking about KDE, KDE e.V., Free Software, Open Source, today's elections in Catalonia or any other random talk and want to have a good time let me know that you're coming (latest by Wednesday night).
Saturday, September 26, 2015
September 26: SystemSettings and KCMs bug triaging day!
Today/Tomorrow September 26 is SystemSettings and KCMs bug triaging day.
As described by Jeremy in this post in the KDE Gardening mailing list the purpose is:
1. Triage all bugs in the systemsettings product (and maybe the kcm product too).
2. If a bug is reproducible still, comment on it and find someone that knows how to fix it and convince them to do so.
3. Find maintainers for as many of the kcms as we can.
This is something anyone with a relatively new Plasma installed can help with so join us on September 26 at the #kde-devel IRC channel!
Personally I'll be on from 10am Spanish time until around 4pm with some lunch time in between.
More info at the gardening wiki for SystemSettings
As described by Jeremy in this post in the KDE Gardening mailing list the purpose is:
1. Triage all bugs in the systemsettings product (and maybe the kcm product too).
2. If a bug is reproducible still, comment on it and find someone that knows how to fix it and convince them to do so.
3. Find maintainers for as many of the kcms as we can.
This is something anyone with a relatively new Plasma installed can help with so join us on September 26 at the #kde-devel IRC channel!
Personally I'll be on from 10am Spanish time until around 4pm with some lunch time in between.
More info at the gardening wiki for SystemSettings
Friday, May 15, 2015
KDE Applications 15.08 release schedule
We have just made official the release schedule for KDE Applications 15.08.
It's a bit simpler than in previous times, let's see if it works out.
Freeze is in 2 months
Full schedule at https://techbase.kde.org/Schedules/Applications/15.08_Release_Schedule
It's a bit simpler than in previous times, let's see if it works out.
Freeze is in 2 months
Full schedule at https://techbase.kde.org/Schedules/Applications/15.08_Release_Schedule
Sunday, March 22, 2015
Submit your talk to Akademy 2015!
The Call for Papers deadline for Akademy 2015 is just 10 days away. So you should submit a talk now, you know you have cool stuff to share, so do a small write up and tell the world that awesome new stuff you're working on.
And of course don't forget to register as always it's free but let's us know how many of you nice people are going to come over ;)
Ah and we also have the badges available, thanks to Alba Carro for the nice pictures :)
And of course don't forget to register as always it's free but let's us know how many of you nice people are going to come over ;)
Ah and we also have the badges available, thanks to Alba Carro for the nice pictures :)
Friday, March 20, 2015
KDE dinner in Berlin - April 11
In a few weeks (April 11-12) the KDE e.V. board is going to have an in-person board meeting in Berlin.
We board people have to eat from time to time and since we like talking to other people besides ourselves we’re organizing a dinner on Saturday 11 around 19:00 (location still undecided, suggestions accepted).
So if you are interested in talking about KDE, KDE e.V., Free Software, Open Source, or any other random talk and want to have a good time let me know that you're coming as soon as possible, space is limited.
We board people have to eat from time to time and since we like talking to other people besides ourselves we’re organizing a dinner on Saturday 11 around 19:00 (location still undecided, suggestions accepted).
So if you are interested in talking about KDE, KDE e.V., Free Software, Open Source, or any other random talk and want to have a good time let me know that you're coming as soon as possible, space is limited.
Wednesday, February 11, 2015
KDE Applications 15.04 Feature Freeze is in 2 weeks
As per our Release Schedule, the freeze for KDE Applications 15.04 is in two weeks (25 February).
Get yourselves ready!
Get yourselves ready!
Sunday, January 25, 2015
Help test KDE Bomber game
As Laurent mentioned we are moving some KDE games from kdelibs4-based to kf5-based for the next KDE Applications 15.04 relase.
Today we just switched libkdegames, libkmahjongg and bovo. Next target is bomber, so if you have some time grab the master branch of libkdegames and the frameworks one of bomber, give it a try and make sure we're not regressing somewhere we didn't realize.
Today we just switched libkdegames, libkmahjongg and bovo. Next target is bomber, so if you have some time grab the master branch of libkdegames and the frameworks one of bomber, give it a try and make sure we're not regressing somewhere we didn't realize.
Saturday, January 17, 2015
KDE End of Year 2014 Fundraiser is over
Yesterday was the last day of the KDE End of Year 2014 Fundraiser.
I want to thank publicly the 788 donors that helped us raise over 22000 euro.
You all rock and rule!
Thanks to this money we'll be able to keep sponsoring developers to attend conferences and sprints to improve the software we all love and use.
Of course there's never enough money so we still greatly appreciate your donations at http://kde.org/donate or even better you can become a KDE Supporting Member.
I want to thank publicly the 788 donors that helped us raise over 22000 euro.
You all rock and rule!
Thanks to this money we'll be able to keep sponsoring developers to attend conferences and sprints to improve the software we all love and use.
Of course there's never enough money so we still greatly appreciate your donations at http://kde.org/donate or even better you can become a KDE Supporting Member.
Wednesday, December 03, 2014
KDE End of Year Fundraising cards are being sent out!
We ordered some samples to make sure they looked good, and here they are here!
If you want some, we will send them to you as gift if you donate to the KDE End of Year 2014 Fundraising
P.S: If you made a donation that qualifies for a postcard gift before this monday and have not received an email from me asking which design and to which address you want the postcards sent please contact me at aacid@kde.org
If you want some, we will send them to you as gift if you donate to the KDE End of Year 2014 Fundraising
P.S: If you made a donation that qualifies for a postcard gift before this monday and have not received an email from me asking which design and to which address you want the postcards sent please contact me at aacid@kde.org
Monday, November 03, 2014
New postcard design added for the KDE End of Year 2014 Fundraising Campaign!
You probably know we're running a Fundraiser Campaign in KDE land. As a way to say thank you donors over 30€ get a postcard.
Today we've announced the second of three designs we are planning.
Donate and get a physical copy of it ;)
Today we've announced the second of three designs we are planning.
Donate and get a physical copy of it ;)
Subscribe to:
Posts (Atom)