Re: Suggestion to Remove KFloppy and hold back K3b
Am 2017-02-22 23:20, schrieb Wolfgang Bauer: Am Mittwoch, 22. Februar 2017, 22:01:01 schrieb Martin Gräßlin: The attack surface is exactly the same as any other X application. It's X itself which will make this exploitable. Yes, obviously, and that's clear to me too. I won't comment on the rest, because it's not specific to kfloppy as you write yourself. Just this: I answered nevertheless, because I think it's important for all devs to understand that connecting to X11 as root means a risk to their users and that there is nothing their application can do to protect against it. Ok, fine with me that you wrote that again. And important too, I agree. Although, I have to say that I somehow felt a bit like being "witch-hunted" for even thinking about that. But let's stop here, I'll try to forget that... ;-) Kind Regards, Wolfgang
Re: Suggestion to Remove KFloppy and hold back K3b
Am 2017-02-22 20:18, schrieb Wolfgang Bauer: Am Dienstag, 21. Februar 2017, 18:55:00 schrieb Nicolás Alvarez: > On Feb 15, 2017, at 17:58, Wolfgang Bauer wrote: > > Am Mittwoch, 15. Februar 2017, 22:21:19 schrieb Martin Gräßlin: >> Please do not consider starting a GUI application as root a possibility. > > Ok, but partitionmanager does exactly that. It restarts itself as root if > run as user. > So that instantly would rule out partionmanager as a proposed replacement, > I suppose. > > But KFloppy is quite a simple application. > There should not really be a special risk involved running it as root, but > I might be mistaken there. Sounds like you're challenging Martin to write a take-over-machine exploit via root KFloppy, and I would bet money that he would succeed ;) No, I don't. I just meant to say that the attack surface is smaller that for (certain) other applications. The attack surface is exactly the same as any other X application. It's X itself which will make this exploitable. You definitely cannot open a root konsole and run arbitrary commands as root by just sending fake key presses to kfloppy... ;) That was just the trivial case and not even an exploit. It was all pure X protocol. An exploit would be to use a string parsing bug in Qt/xcb to trigger a crash in KFloppy. And all I need for that is: * a fuzzer * a window opening as root We just need to accept that opening a root window means we are owned. Yes, sounds bad. Yes, no known exploits in the wild. Yes, I'm sure it's not just a theoretical threat. I got hundreds of bug reports (#361236) the last year of KWin crashing in Qt's string handling most likely from a window property. So to me it's a definite truth that there are exploitable window property to string vulnerabilities when run as root. That's also why KWin/Wayland is not root, but user. But please. I already wrote that restarting the application as root was just one idea to work around permission problems. (I even mentioned using kauth as option too in my first mail, and that's what I'll try to implement...) And to repeat: I already dropped that idea completely. So I don't see a point in continuing the discussion about this here. I answered nevertheless, because I think it's important for all devs to understand that connecting to X11 as root means a risk to their users and that there is nothing their application can do to protect against it. Cheers Martin
Re: Suggestion to Remove KFloppy and hold back K3b
Am 15. Februar 2017 23:58:50 MEZ schrieb Wolfgang Bauer : >Am Mittwoch, 15. Februar 2017, 22:21:19 schrieb Martin Gräßlin: >> Please do not consider starting a GUI application as root a >possibility. > >Ok, but partitionmanager does exactly that. It restarts itself as root >if run >as user. >So that instantly would rule out partionmanager as a proposed >replacement, I >suppose. Yes partition manager should not do that. They are aware of the issue. > >But KFloppy is quite a simple application. >There should not really be a special risk involved running it as root, >but I >might be mistaken there. You are. The danger is Qt and all the other libraries it depends on. Even xlib and xcb hardly protect against a malicious X server. And we just cannot assume any more that X is running as root. Cheers Martin
Re: Suggestion to Remove KFloppy and hold back K3b
Am 2017-02-15 19:50, schrieb Wolfgang Bauer: On 11 February 2017 at 13:44, Jonathan Riddell wrote: I recommend KFloppy be removed from Applications releases. It couldn't find my floppy drive and when I hacked the code to tell it where to look it depended on an external tool fdformat which didn't work anyway. KFloppy and fdformat work fine here in openSUSE, I do use it regularly (with an internal floppy drive). And as the current maintainer, I'd prefer to (try to) fix problems instead of having it dropped. I'm a bit surprised that in the test the floppy drive showed up as /dev/sdc though, mine always have been and still are at /dev/fd0... I suppose that was an external one? Not sure how to fix that then, it supposedly can be a random /dev/sdX... There is a (somewhat "hidden") feature though to use any device you want: just enter it into the text field (this is mentioned in the documentation, it's a rather old feature already and intended to be able to format USB sticks too, or other unpartitioned devices). It would definitely be possible to list all /dev/sdX devices in the chooser too, but that may be dangerous and cause data loss without any further check that it is really a floppy drive (or USB stick). I have to think about that one. I am aware of one particular problem related to permissions though: Normally the device can only be accessed by members of the group "disk" (or "floppy"), but modern distributions tend to not add users to these groups any more. You'd have to add the user to the appropriate group manually to make KFloppy and fdformat work, or run KFloppy as root. Not great, I agree. Actually I was thinking about this problem recently though. The error message could definitely be improved. And one "solution" would probably be to make KFloppy offer to restart itself as root (if it detects insufficient permissions) like partitionmanager does it. Please do not consider starting a GUI application as root a possibility. Starting a root process which connects to X server means a possible instant owning! This is the easiest way to get a root exploit. I wrote one against dolphin running as root last year, you can find it in my scratch repo on git.kde.org If users actually run KFloppy as root, please make sure that it is not possible! Please add a check prior (!) to the creation of Q(Gui)Application and terminate if it is run as root. It's important to do the check prior to creating Q(Gui)Application as the ctor performs the connection to XServer and afterwards it might be too late. The only viable solution is using KAuth. If this doesn't work for KFloppy, then I would agree that for security reasons we need to declare it as eol. I consider this as highly important! We need to get away from running GUI applications as root. It's insecure, it's dangerous and broken (yes, a root app has problems to connect to a user Display server, such as rootless-X11 or Wayland). We as a community need to stop recommending this. We need to make sure that applications which users might run as root just exit with a warning. Cheers Martin, the broken "you shall not run X11 apps as root"-record
Re: CI Requirements - Lessons Not Learnt?
Am 2017-01-06 05:57, schrieb Ben Cooksley: On Fri, Jan 6, 2017 at 12:38 AM, Martin Gräßlin wrote: Am 2017-01-05 11:20, schrieb Ben Cooksley: On Thu, Jan 5, 2017 at 10:28 PM, Martin Gräßlin wrote: Am 2017-01-05 09:44, schrieb Ben Cooksley: Hi all, It seems that my previous vocal complaints about system level / serious impact dependency bumps on the CI system have gone completely unnoticed by (some) members of our Community. This was demonstrated earlier this week when components of Plasma bumped their version requirements for XKBCommon and Appstream-Qt - without even a thought about notifying Sysadmin or checking which version the CI had, until their builds broke. Neither of these is easy to fix at this stage, as the system base is now too old to receive updates such as these. Base upgrades require a full rebuild of everything on the CI system, and usually involve significant additional churn and is a process that must be done roughly twice a year, depending on dependency bump demands. Does anyone have any suggestions as to how we may avoid this in the future? I have a few questions here: 1) Where is this requirement to check with sysadmins codified? So far I was only aware of dependency freeze. It's been codified since the PIM Qt 5.6 / WebEngine debacle, where Sysadmin had to rush delivery of Qt 5.6 to the CI system because the whole of PIM broke when they started using QtWebEngine. That was around March/April 2016, my mail archives can't seem to find the exact thread though. I'm sorry Ben, but I fear "sending out a mail about an issue with PIM" doesn't qualify as codifying it. Given what we have it looks like this did not reach the target audience. And neither will this thread. Uhm, it was far more than a single email. It was quite the thread, and if memory serves was on at least one of the mailing lists this thread was on. One of the key things that came out of that thread was to ask for things to be bumped well in advance if a newer version is needed. I'm disappointed that you think that email threads have insufficient reach given it's one of our communities principal means of communication. Email threads don't work to codify such requirements. What we need is something like an "announce new dependency to sysadmin freeze" prior to the dependency freeze in the release schedule. That's what I mean with codifying it. We need to have it in a way where devs actually check. It needs to be part of the process. An old email thread cannot be part of the process. This needs to change the process, the way KDE develops software. It needs to be listed in the release schedule (is not, I checked), maybe reviews need to be acked by release managers, etc. It seems to be part of the process for many others already, so not sure what needs to change. The gpgme transition went quite well for PIM, and other applications developers have reached out and asked about version upgrades to various libraries which were in their area of interest which we have sorted out easily enough. See above. Part of release schedule. 2) How can we easily check what build.kde.org has? Looking at cmake output is not a sufficient way as it gives me wrong information If CMake is outputting wrong information, then your CMakeLists.txt can't make the appropriate decisions as to whether the available version is suitable, so i'd say you've got bigger problems here that need to be addressed first. Cmake feature summary says: "required version >= 0.5" and that's for all found depeendencies. Unfortunately no information at all in the feature summary about the actual version. Quoting the KWin CMake log... 15:08:41 -- Found Wayland_Client: /usr/lib/x86_64-linux-gnu/libwayland-client.so (found version "1.12.90") 15:08:41 -- Found Wayland_Cursor: /usr/lib/x86_64-linux-gnu/libwayland-cursor.so (found version "1.12.90") 15:08:42 -- Found Wayland_Egl: /usr/lib/x86_64-linux-gnu/libwayland-egl.so (found version "11.0.2") 15:08:42 -- Found Wayland: /usr/lib/x86_64-linux-gnu/libwayland-client.so;/usr/lib/x86_64-linux-gnu/libwayland-cursor.so;/usr/lib/x86_64-linux-gnu/libwayland-egl.so (found suitable version "1.12.90", minimum required is "1.2") found components: Cursor Egl 15:08:42 -- Could NOT find XKB: Found unsuitable version "0.5.0", but required is at least "0.7.0" (found /usr/lib/x86_64-linux-gnu/libxkbcommon.so) 15:08:42 -- Found Libinput: /usr/lib/x86_64-linux-gnu/libinput.so (found suitable version "1.5.2", minimum required is "1.5") 15:08:42 -- Found UDev: /usr/include 15:08:42 -- Found Libdrm: /usr/lib/x86_64-linux-gnu/libdrm.so (found suitable version "2.4.64", minimum required is "2.4.62") 15:08:42 -- Found gbm: /usr/lib/x86_64-linux-gnu/libgbm.so (found version "11.0
Re: CI Requirements - Lessons Not Learnt?
Am 2017-01-05 09:44, schrieb Ben Cooksley: Hi all, It seems that my previous vocal complaints about system level / serious impact dependency bumps on the CI system have gone completely unnoticed by (some) members of our Community. This was demonstrated earlier this week when components of Plasma bumped their version requirements for XKBCommon and Appstream-Qt - without even a thought about notifying Sysadmin or checking which version the CI had, until their builds broke. Neither of these is easy to fix at this stage, as the system base is now too old to receive updates such as these. Base upgrades require a full rebuild of everything on the CI system, and usually involve significant additional churn and is a process that must be done roughly twice a year, depending on dependency bump demands. Does anyone have any suggestions as to how we may avoid this in the future? I have a few questions here: 1) Where is this requirement to check with sysadmins codified? So far I was only aware of dependency freeze. 2) How can we easily check what build.kde.org has? Looking at cmake output is not a sufficient way as it gives me wrong information 3) What should we do when build.kde.org does not have the requirement? It should be rather obvious that we don't introduce new dependencies because we like to. There is a very important software reason to it. That's the case for the xkbcommon dependency increase. Should I have let the code broken as it was, expecting half a year of bug reports till build.kde.org has the base upgraded to Ubuntu 16.04? If I have to degrade the quality of the product for serving the CI, I and all users have a problem. And this is currently the only alternative. The quality of our product is highly at risk as our changes are no longer compile tested. This is a huge problem for the release of Plasma 5.9. On the other hand I cannot revert the dependency change as that would break tests or introduce the broken code again. So actually we are caught between a hard and a rock place. When I increased the dependency I had the dependency freeze of Plasma 5.9 in mind. That's the one target I have to hit from release process currently. Also I had to consider a social aspect here. I asked xkbcommon devs to do the release. I would have feeled ashamed if we asked for the release and then don't use it. For me it was from a social point of view a very high requirement to ship with the dependency in the next release after xkbcommon release. If we have to wait an arbitrary time till build.kde.org has upgraded the base, maybe the choice of the base is not sufficient. E.g. I asked openSUSE about this dependency weeks ago. Actually a few days after xkbcommon had the release and it was already shipped in tumbleweed. Similar for Mesa 13 which I'm also eagerly waiting for build.kde.org to fetch it. Cheers Martin
Re: CI Requirements - Lessons Not Learnt?
Am 2017-01-05 11:20, schrieb Ben Cooksley: On Thu, Jan 5, 2017 at 10:28 PM, Martin Gräßlin wrote: Am 2017-01-05 09:44, schrieb Ben Cooksley: Hi all, It seems that my previous vocal complaints about system level / serious impact dependency bumps on the CI system have gone completely unnoticed by (some) members of our Community. This was demonstrated earlier this week when components of Plasma bumped their version requirements for XKBCommon and Appstream-Qt - without even a thought about notifying Sysadmin or checking which version the CI had, until their builds broke. Neither of these is easy to fix at this stage, as the system base is now too old to receive updates such as these. Base upgrades require a full rebuild of everything on the CI system, and usually involve significant additional churn and is a process that must be done roughly twice a year, depending on dependency bump demands. Does anyone have any suggestions as to how we may avoid this in the future? I have a few questions here: 1) Where is this requirement to check with sysadmins codified? So far I was only aware of dependency freeze. It's been codified since the PIM Qt 5.6 / WebEngine debacle, where Sysadmin had to rush delivery of Qt 5.6 to the CI system because the whole of PIM broke when they started using QtWebEngine. That was around March/April 2016, my mail archives can't seem to find the exact thread though. I'm sorry Ben, but I fear "sending out a mail about an issue with PIM" doesn't qualify as codifying it. Given what we have it looks like this did not reach the target audience. And neither will this thread. This needs to change the process, the way KDE develops software. It needs to be listed in the release schedule (is not, I checked), maybe reviews need to be acked by release managers, etc. 2) How can we easily check what build.kde.org has? Looking at cmake output is not a sufficient way as it gives me wrong information If CMake is outputting wrong information, then your CMakeLists.txt can't make the appropriate decisions as to whether the available version is suitable, so i'd say you've got bigger problems here that need to be addressed first. Cmake feature summary says: "required version >= 0.5" and that's for all found depeendencies. Unfortunately no information at all in the feature summary about the actual version. In any case, you can see the Docker log of the container being generated at https://build.kde.org/job/create_ubuntu_slave-ange/ and where do I find this information if I would not have asked in a mail? This is very related to properly codifying and documenting such requirements. You cannot tell people "don't introduce new dependencies", without telling them how to check. 3) What should we do when build.kde.org does not have the requirement? You have to file a Sysadmin ticket, also tagging the project 'build.kde.org' at the same time. And then? What's the process then? How long do we have to expect this to go? Would it allow to block a finished feature or an important bug fix? Would we be forced to write ifdef hackery? Sorry, but I'm not thrilled by this process. What matters to me is getting out good software to our users. And for that I have a hard requirement I have to hit: dependency freeze. It should be rather obvious that we don't introduce new dependencies because we like to. There is a very important software reason to it. That's the case for the xkbcommon dependency increase. Should I have let the code broken as it was, expecting half a year of bug reports till build.kde.org has the base upgraded to Ubuntu 16.04? That's what #ifdef is for... I see you volunteer to: 1. write the ifdef 2. adjust the unit test to skip 3. Inform distros that the reported minimum version is wrong, that in truth it requires a newer version than reported 4. handle all the bug reports related to it If not, please don't suggest ifdef. We all know that it comes with a huge cost. A cost I decided is too high in this case. After all I had many people complain about it and you can imagine how annoyed I am about the broken build. If it were as simple as an ifdef, we would have done it, wouldn't we? If I have to degrade the quality of the product for serving the CI, I and all users have a problem. And this is currently the only alternative. The quality of our product is highly at risk as our changes are no longer compile tested. This is a huge problem for the release of Plasma 5.9. On the other hand I cannot revert the dependency change as that would break tests or introduce the broken code again. So actually we are caught between a hard and a rock place. When I increased the dependency I had the dependency freeze of Plasma 5.9 in mind. That's the one target I have to hit from release process currently. Als
Re: CI Requirements - Lessons Not Learnt?
Sorry picked wrong from address Am 2017-01-05 10:28, schrieb Martin Gräßlin: Am 2017-01-05 09:44, schrieb Ben Cooksley: Hi all, It seems that my previous vocal complaints about system level / serious impact dependency bumps on the CI system have gone completely unnoticed by (some) members of our Community. This was demonstrated earlier this week when components of Plasma bumped their version requirements for XKBCommon and Appstream-Qt - without even a thought about notifying Sysadmin or checking which version the CI had, until their builds broke. Neither of these is easy to fix at this stage, as the system base is now too old to receive updates such as these. Base upgrades require a full rebuild of everything on the CI system, and usually involve significant additional churn and is a process that must be done roughly twice a year, depending on dependency bump demands. Does anyone have any suggestions as to how we may avoid this in the future? I have a few questions here: 1) Where is this requirement to check with sysadmins codified? So far I was only aware of dependency freeze. 2) How can we easily check what build.kde.org has? Looking at cmake output is not a sufficient way as it gives me wrong information 3) What should we do when build.kde.org does not have the requirement? It should be rather obvious that we don't introduce new dependencies because we like to. There is a very important software reason to it. That's the case for the xkbcommon dependency increase. Should I have let the code broken as it was, expecting half a year of bug reports till build.kde.org has the base upgraded to Ubuntu 16.04? If I have to degrade the quality of the product for serving the CI, I and all users have a problem. And this is currently the only alternative. The quality of our product is highly at risk as our changes are no longer compile tested. This is a huge problem for the release of Plasma 5.9. On the other hand I cannot revert the dependency change as that would break tests or introduce the broken code again. So actually we are caught between a hard and a rock place. When I increased the dependency I had the dependency freeze of Plasma 5.9 in mind. That's the one target I have to hit from release process currently. Also I had to consider a social aspect here. I asked xkbcommon devs to do the release. I would have feeled ashamed if we asked for the release and then don't use it. For me it was from a social point of view a very high requirement to ship with the dependency in the next release after xkbcommon release. If we have to wait an arbitrary time till build.kde.org has upgraded the base, maybe the choice of the base is not sufficient. E.g. I asked openSUSE about this dependency weeks ago. Actually a few days after xkbcommon had the release and it was already shipped in tumbleweed. Similar for Mesa 13 which I'm also eagerly waiting for build.kde.org to fetch it. Cheers Martin
Re: KDE Frameworks 5.29.0
Am 2016-12-05 09:20, schrieb David Faure: On dimanche 4 décembre 2016 23:42:44 CET šumski wrote: On nedjelja, 4. prosinca 2016. 00:37:52 CET David Faure wrote: > Dear packagers, > > KDE Frameworks 5.29.0 has been uploaded to the usual place. > > New framework: prison > > Public release next Saturday. > > Thanks for the packaging work! kconfig (r129382) breaks compilation of kdevplatform: http://paste.opensuse.org/82016854 Indeed (but it's not the change from RR 129382, it's commit cd4e650 from https://phabricator.kde.org/D3386 Seems to come from Inherits=BaseClass while BaseClass doesn't use arg="true". Here's a testcase for the kconfig unittests. Martin, can you take a look? The earliest I can have a look is probably on Friday, I'm sorry. My suggestion is to revert my two commits and I'll redo for next frameworks. Cheers Martin
Re: [Kde-pim] Unannounced dependency bump?
Am 2016-06-29 13:30, schrieb Daniel Vrátil: It's not only CI that has issues with PIM buildability as well - other KDE developers have issues with it as well often being the sole source of failures in their kdesrc-build runs. I do "kdesrc-build kde-pimlibs kde-pim" quite often without any issues. If the devs don't contact us, we can hardly fix something I hit the messagelib issue today, looked into build.kde.org, saw that the last three builds failed. Now I just run kdesrc-build again and kdepim doesn't build: [ 85%] Linking CXX shared module kcm_knote.so akregator/src/CMakeFiles/akregatorprivate.dir/build.make:206: recipe for target 'akregator/src/CMakeFiles/akregatorprivate.dir/articleviewer-ng/webengine/articleviewerwebengine.cpp.o' failed make[2]: *** [akregator/src/CMakeFiles/akregatorprivate.dir/articleviewer-ng/webengine/articleviewerwebengine.cpp.o] Error 1 CMakeFiles/Makefile2:8178: recipe for target 'akregator/src/CMakeFiles/akregatorprivate.dir/all' failed make[1]: *** [akregator/src/CMakeFiles/akregatorprivate.dir/all] Error 2 make[1]: *** Waiting for unfinished jobs I have reported to kde-pim mailing list before that I constantly have problems building it. I run everything through kdesrc-build, that's about 270 modules and only kdepim is the only one which I need to run again and again. Sometimes a --reconfigure is sufficient, sometimes I need to do --refresh-build. It's annoying to be honest. Typing this mail in my roundecube instance as kmail which I have right now, doesn't show mails. Cheers Martin ___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
Re: Plasma 5.5 alpha
Am 2015-11-08 01:30, schrieb Nicolas Lécureuil: Le 2015-11-06 13:28, Jonathan Riddell a écrit : It was suggested to celebrate repo freeze I make alpha tars of Plasma 5.5 just to check we know what's being released so here's some tars, please check it includes all the tars you expect and if you're incharge of a new tar then check it contains the right stuff. No release is planned, beta is due in 2 weeks. https://www.kde.org/info/source-plasma-5.4.90.inc http://embra.edinburghlinux.co.uk/~jr/tmp/unstable/plasma/5.4.90/ Does it compile with KF5 5.15.0 or does it need next 5.16.0 ? because here it does not compile : It most likely depends on 5.16. Our freezes are not yet in place so master depends on master. Only with the feature freeze we depend on a specific frameworks release. Sorry, that this caused trouble in building. We didn't plan for an alpha, it was a spontaneous idea to list the repos we have. Cheers Martin ___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
Re: More Plasma bug fix releases
Am 2015-10-28 21:11, schrieb Sandro Knauß: But there is also debian stable (also kubuntu LTS,...), that most users are using. And debian stable is time based, and no updates are allowd by default. Debian stable should not be affected by the proposal. I doubt it will ever ship a .0 or a .1 release. In fact it's more likely that it will ship a version we already consider EOL. For me the patch tracker is nothing, because I do not trust you as mantainer of KWin. I see it more as meta informations about patches, to be able to use it as argument for pushing things more easily futher down to the user. As sebas notes: we have these information in the BUG field of git. Although there are commits without a BUG field, just because we didn't report an internal bug for it. If this is a requirement for you distros, then we can of course create a bug report for each one. Otherwise I hope that you trust that we only fix bugs in our stable branch. Also one note: On debian side it is like that, every diff against debian stable is reviewed by the release team, so the diff must close serious bugs and should be as minimal as possible (but this should a stable fix anyhow :) So I understand correctly, that someone having no clue about the source code, having no clue about the domain and having no clue how sever the bug is, is going to decide whether it's a serious issue. I don't think I have to explain to you how broken that is on multiple levels. This is just ridiculous. Sorry I have no other words for it. Cheers Martin Regards, sandro -- Am Mittwoch, 28. Oktober 2015, 00:52:34 schrieb Albert Astals Cid: El Tuesday 27 October 2015, a les 15:31:45, Eric Hameleers va escriure: > On Tue, 27 Oct 2015, Albert Astals Cid wrote: > > El Tuesday 27 October 2015, a les 14:39:15, Eric Hameleers va escriure: > >> On Tue, 27 Oct 2015, Albert Astals Cid wrote: > >>> El Tuesday 27 October 2015, a les 14:18:01, Eric Hameleers va escriure: > On Tue, 27 Oct 2015, Sebastian Kügler wrote: > > On Tuesday, October 27, 2015 06:25:42 AM Eric Hameleers wrote: > >> I like the idea of getting more visibility for bugfixes that will > >> give > >> the enduser a better Plasma experience. Ideal for me would be a > >> patch > >> tracker (not the same as a bug tracker) where intermediate patches > >> are > >> made available that are scheduled for inclusion in the next > >> release. > >> That allows me as a package builder to assimilate those patches if > >> I > >> think they can not wait until the next release. > > > > That sounds like you just want the latest stable git branch, in this > > example Plasma/5.5? > > No, of course not. I consider the git branch to be in eternal flux. > The git HEAD may contain valuable usability patches but also other > meh > stuff that can wait until the next major release. I do not want to > dig > through hashes and commits to find out whether you solved some > blocking issue. > A patch tracker, containing patches you (the developers) consider > critical and which should find their way to the user ASAP, that is a > place where I would look. > >>> > >>> Yes, of course yes. > >>> > >>> Every single patch commited to a stable branch is a bugfix and thus > >>> the > >>> developer considers critical and should be released as soon as > >>> possible > >>> to > >>> users, otherwise instead of to the stable branch the developer would > >>> commited the patch to the development branch. > >>> > >>> Cheers, > >>> > >>> Albert > >> > >> You developers are so funny, my false teeth fell out from shaking. > > > > I did a serious reply to your comment and all i got back was sarcasm, > > please let's try to be constructive, otherwise what's the point of > > having > > this discussions? > > > > Do you really think we commit things that are not bugfixes to stable > > branches? > > > > Can you name some "meh stuff" that was commited to a stable branch and > > in > > your opinion should have waited for the next major release? > > Says the master of sarcasm. The fact that i may have been not well behaved at some points in the past does not give anyone carte blanche to be badly behaved, two bads don't make one good. > I was being constructive. Please put on > your release management hat. > > But you are indeed correct, I should adjust one of my statements, by > s/major/minor/ ; patches should not have to wait for the next > *major* release. That's why we have stable releases, no? > However, I id not interpret your reply as anywhere near serious. If > your view of distro packaging is that the packager should follow the > git commits from day to day, minute to minute then you need to adjust > your view of distro development. It is OK for *developers* to sit on > top of the git commits since that is what they do. A packager on the > other hand needs proper releases, because that makes
Re: More Plasma bug fix releases
Am 2015-10-28 19:27, schrieb Sandro Knauß: Hey, While l10n might not seem to be that important to you, it might be the difference between an unusable system and a useable system. So let's not start downplaying the importance of translations ;-) The point with translations is, if you change i18n strings in stable patches, than you also need to update all translations. I think that is the main disussion, if it is allowed to change i18n strings in stable branch or not. And than on the other hand you may have updates in the translations in between two point releases and than we also have the question, how to release these updates. You know quite well that we have string freezes and we are extremely serious about them. The comment was for shipping updated translations. Cheers Martin ___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
Re: More Plasma bug fix releases
Am 2015-10-28 13:34, schrieb Maximiliano Curia: On 27/10/15 13:51, Martin Graesslin wrote: I was thinking about the problem of how we can get bug fixes quicker to our user. With a three month release cycle a one-month bug fix cycle sounds too long to me. Fair enough. So I thought we should make bug fix releases faster and more often. In 5.4 we already went for this partially by having the first bug fix earlier. I wanted to know how much work this would mean for our distributions. If we ship out way more bug fix releases, would you be able to work with it? Would it block you? Would you have to skip releases? Or is it just pressing a button to run automatic scripts which upload your packages? We can keep up with bug fixes, in most cases the bugs will affect our users anyway and having the bug fixes released would reduce the time spent dealing with bugs, but it would be a waste of time and resources to package things that only contain a version bump. understood. Maybe we can do some scripting to only create tarballs if there were changes. Jonathan? So my suggestion would be to publish a 5.5 version and use the dot releases to publish bug fixes without a fixed schedule. Sorry I don't understand what you mean with that. Do you want a new bug fix release for each commit to stable branch? That certainly wouldn't scale. The next discussion would be what should be considered a bug fix to trigger a release, as much as I like to have l10n support, the automatic: l10n daemon script commit hardly qualify. While l10n might not seem to be that important to you, it might be the difference between an unusable system and a useable system. So let's not start downplaying the importance of translations ;-) What had I been thinking about? I was thinking about a Fibonacci based release schedule. This gives us quick bug fix releases directly after the release with slowly larger intervals. Of course it would mean tag and release happens on same day. Agreed on the release and tag on the same day. Can it be enforced that all the tests need to pass to consider the part for the release Please start a dedicated discussion for this point. Also, if possible, could you use signed tags for the releases? (on the Debian side of things we are considering using the upstream signed git tags as a replacement of tarballs and signatures/sums) Please also start a dedicated discussion for this point. Cheers Martin ___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
Re: Review Request 124895: delete the quit process, not UserActionsMenu
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/124895/#review84244 --- Ship it! Ship It! - Martin Gräßlin On Aug. 23, 2015, 9:01 p.m., Thomas Lübking wrote: > > --- > This is an automatically generated e-mail. To reply, visit: > https://git.reviewboard.kde.org/r/124895/ > --- > > (Updated Aug. 23, 2015, 9:01 p.m.) > > > Review request for kwin, Release Team and Martin Gräßlin. > > > Bugs: 351643 > https://bugs.kde.org/show_bug.cgi?id=351643 > > > Repository: kwin > > > Description > --- > > summarized > > > @release team, the bug will make kwin crash when showing the Alt+F3 menu > after having called the settings from there. > > => Can we still pick it for 5.4.0? > > > Diffs > - > > useractions.cpp 9714a6e > > Diff: https://git.reviewboard.kde.org/r/124895/diff/ > > > Testing > --- > > > Thanks, > > Thomas Lübking > > ___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
Distros: please package new plugins in Frameworks
Hi distro packagers, with the latest framework releases a few frameworks (e.g. KWindowSystem, KIdleTime, KGlobalAccel) were changed to a plugin infrastructure. If those plugins are missing things break (e.g. a Plasma panel is no longer a panel). I'm aware of at least two distributions where the plugins are no longer installed. Please ensure that you install the plugins to the correct location in your packages! Thanks Martin Graesslin signature.asc Description: This is a digitally signed message part. ___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
Re: [Kde-pim] What's up with kdepim*?
Also you have unreleased dependencies, at least prison and akonadi. Akonadi is as the others kdepim package it's the last one. Ok Dan could you told us which is the last package please ? Prison... I never used it it's optional so it's not a problem. The unreleased prison is also an optional dependency to plasma-workspace without creating problems :-) @Sune: could we get a release of prison? Cheers Martin ___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
Re: Request to make Wayland hard build dependency in KWin starting with Plasma 5.5
Am 2015-07-16 15:22, schrieb Eric Hameleers: On Thu, 16 Jul 2015, Martin Gräßlin wrote: On Thursday 16 July 2015 02:54:17 Eric Hameleers wrote: An xkbcommon package would have to be added to my repository as a new dependency but that is not an issue for me. So, no objections from me for the hard build requirements. A small note on xkbcommon: Qt/xcb also requires it. Please make sure that Qt is built with a system xkbcommon, otherwise it picks the one bundled in 3rd- party and that has resulted in crashes in KWin in the past if KWin is build with a system xkbcommon. My Qt5 so far has been built using the 3rdparty source which is part of the qt tarball. Once I add xkbcommon as a system package I will have to recompile Qt5, is what you are telling? yes Is this a Qt5 bug that has not been addressed yet? I'm not sure whether it counts as a bug (I have not reported one about it). It would certainly be nice if Qt would tell us in the build system that it pulled it in from 3rd-party so that we can error out in CMake. Apart from that there is probably not much to do. I always thought that it doesn't matter as distros don't like 3rd-party and will just build Qt against the system library ;-) Cheers Martin ___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
Re: Request to make Wayland hard build dependency in KWin starting with Plasma 5.5
On Thursday 16 July 2015 02:54:17 Eric Hameleers wrote: An xkbcommon package would have to be added to my repository as a new dependency but that is not an issue for me. So, no objections from me for the hard build requirements. A small note on xkbcommon: Qt/xcb also requires it. Please make sure that Qt is built with a system xkbcommon, otherwise it picks the one bundled in 3rd- party and that has resulted in crashes in KWin in the past if KWin is build with a system xkbcommon. > The following Wayland specific dependencies would be kept optional: > * X11_XCB > * libhybris > * Libinput > * udev Thanks for that, I am not prepared to add libinput since according to your erlier posts it would require logind (which we don't and won't include) or a logind-shim (implementations of which do not exist at present). Please note that libinput support in KWin does not introduce any build-time dependency on logind or logind-shm. It only imposes a runtime dependency. The same runtime dependency is also required by the drm backend. So this runtime dependency should not hinder anyone to build dep on libinput. The logind integration is build unconditionally and also run unconditionally on both x11 and wayland. Cheers Martin ___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
Request to make Wayland hard build dependency in KWin starting with Plasma 5.5
Hi KDE distro packagers, we are currently (Plasma 5.4) in the awkward situation that plasma-workspace has a hard Wayland dependency and KWin has only an optional build dependency. After the release of Plasma 5.4 I want to change this and turn some optional build dependencies into hard dependencies in KWin. Reasoning: over the Plasma 5.4 cycle I have pretty much only worked on Wayland support and that has resulted in more than 100 #if HAVE_WAYLAND ... #endif As our CI system and most distributions only compile with Wayland support the risk of accidental breakage increases each day. Even more it means that running builds without this build dependency is pretty much untested. While it's unlikely to affect kwin_x11, it is possible, nevertheless. Given that I want to turn the following list of dependencies from optional to required in the next development cycle: * KF5Wayland * Wayland::Cursor * Wayland::Egl * xkbcommon * libdrm * gbm The following Wayland specific dependencies would be kept optional: * X11_XCB * libhybris * Libinput * udev I would like to ask you to try to compile kwin (as of master/5.4 branch) and verify that you can provide the listed required packages. If your distribution is not able to provide one please inform me ASAP about it, so that I can evaluate how much impact it has to keep the dependency optional. Please note that libinput and udev are only kept optional as to my knowledge BSDs cannot provide them. Unfortunately it means that the drm backend in KWin is not functional (doesn't support input) without this dependency. Thank you for your collaboration. Best Regards Martin Gräßlin Head of KDE Wayland porting team signature.asc Description: This is a digitally signed message part. ___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
Re: Re: [kglobalaccel/kglobalaccel-master] /: Add missing licenses
On Friday 10 July 2015 15:46:08 Maximiliano Curia wrote: > Hi Martin, > > On 10/07/15 14:44, Martin Gräßlin wrote: > > On Friday 10 July 2015 12:26:23 Maximiliano Curia wrote: > >> Add missing licenses > > > > as the kglobalaccel maintainer I'm very surprised by your change. The > > framework MUST be LGPL, because it's a framework. How come that you > > decided > > that it is GPL? What is wrong? What needs fixing? I'm especially surprised > > by the language. There are no po files in this repository - how can it > > change the license? > > The po/bg files are distributed with the kglobalaccel's tarballs and are > under the GPL license, adding a copy of this license is only a formality > required by most licenses, but changes nothing to the licensing state of > the > library/framework. As that might also be an issue for other frameworks/applications: I think if the license of a PO file is different the COPYING needs to be distributed together with the PO file and not be part of the framework (where it is incorrect). > > > I'm surprised that you didn't raise any concerns on the mailing list or > > contacted me as the maintainer. Given that it is a framework it should > > have > > been obvious that there is a mistake somewhere and that changing to GPLv2 > > clearly cannot be the solution. > > Sorry, it was not my intention to step out of the line. The licensing issue > was found by the Debian ftpmasters and I've prepared a patch to make > kglobalaccel acceptable for Debian and I've posted the reviewboard to get > some feedback. > > I think that we are giving different values to the COPYING.* files found in > the root directory, for me, they are only legalese that go together with the > real licensing done in the files, but I'm not a lawyer. In that point I disagree. As frameworks are intended to be LGPL, having a GPL Copying file is highly confusing to the developers and even more to users of the framework. I would even go to the point of saying it's frightening for users as it looks like using kglobalaccel turns your maybe non-free software into having to comply to GPL and that's clearly not our intention. > Another option could be to drop the GPL translations and ask for new > translations, with a better licensing. For the time being I would say the non-LGPL compliant po files should no longer be distributed. So yes that goes in the direction of dropping them. Btw. thanks to look into the license problem in this framework. This is of course appreciated. Cheers Martin signature.asc Description: This is a digitally signed message part. ___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
Re: [kglobalaccel/kglobalaccel-master] /: Add missing licenses
On Friday 10 July 2015 12:26:23 Maximiliano Curia wrote: > Git commit cd503fed45a937c5d7eae22502304c16ba5e8fea by Maximiliano Curia. > Committed on 10/07/2015 at 12:13. > Pushed by maximilianocuria into branch 'kglobalaccel-master'. > > Add missing licenses > > The distributed tarballs include GPL-2 po files (po/bg), and the > src/runtime/main.cpp file is under LGPL-2 only, thus the included LGPL-2.1 > won't cover it. Hi Maxy, as the kglobalaccel maintainer I'm very surprised by your change. The framework MUST be LGPL, because it's a framework. How come that you decided that it is GPL? What is wrong? What needs fixing? I'm especially surprised by the language. There are no po files in this repository - how can it change the license? I'm surprised that you didn't raise any concerns on the mailing list or contacted me as the maintainer. Given that it is a framework it should have been obvious that there is a mistake somewhere and that changing to GPLv2 clearly cannot be the solution. Can we look into solving the root issue here? Cheers Martin > > A +339 -0COPYING.GPL-2 > A +481 -0COPYING.LGPL-2 > > http://commits.kde.org/kglobalaccel/cd503fed45a937c5d7eae22502304c16ba5e8fea > > diff --git a/COPYING.GPL-2 b/COPYING.GPL-2 > new file mode 100644 > index 000..d159169 > --- /dev/null > +++ b/COPYING.GPL-2 > @@ -0,0 +1,339 @@ > +GNU GENERAL PUBLIC LICENSE > + Version 2, June 1991 > + > + Copyright (C) 1989, 1991 Free Software Foundation, Inc., > + 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301 USA > + Everyone is permitted to copy and distribute verbatim copies > + of this license document, but changing it is not allowed. > + > +Preamble > + > + The licenses for most software are designed to take away your > +freedom to share and change it. By contrast, the GNU General Public > +License is intended to guarantee your freedom to share and change free > +software--to make sure the software is free for all its users. This > +General Public License applies to most of the Free Software > +Foundation's software and to any other program whose authors commit to > +using it. (Some other Free Software Foundation software is covered by > +the GNU Lesser General Public License instead.) You can apply it to > +your programs, too. > + > + When we speak of free software, we are referring to freedom, not > +price. Our General Public Licenses are designed to make sure that you > +have the freedom to distribute copies of free software (and charge for > +this service if you wish), that you receive source code or can get it > +if you want it, that you can change the software or use pieces of it > +in new free programs; and that you know you can do these things. > + > + To protect your rights, we need to make restrictions that forbid > +anyone to deny you these rights or to ask you to surrender the rights. > +These restrictions translate to certain responsibilities for you if you > +distribute copies of the software, or if you modify it. > + > + For example, if you distribute copies of such a program, whether > +gratis or for a fee, you must give the recipients all the rights that > +you have. You must make sure that they, too, receive or can get the > +source code. And you must show them these terms so they know their > +rights. > + > + We protect your rights with two steps: (1) copyright the software, and > +(2) offer you this license which gives you legal permission to copy, > +distribute and/or modify the software. > + > + Also, for each author's protection and ours, we want to make certain > +that everyone understands that there is no warranty for this free > +software. If the software is modified by someone else and passed on, we > +want its recipients to know that what they have is not the original, so > +that any problems introduced by others will not reflect on the original > +authors' reputations. > + > + Finally, any free program is threatened constantly by software > +patents. We wish to avoid the danger that redistributors of a free > +program will individually obtain patent licenses, in effect making the > +program proprietary. To prevent this, we have made it clear that any > +patent must be licensed for everyone's free use or not licensed at all. > + > + The precise terms and conditions for copying, distribution and > +modification follow. > + > +GNU GENERAL PUBLIC LICENSE > + TERMS AND CONDITIONS FOR COPYING, DISTRIBUTION AND MODIFICATION > + > + 0. This License applies to any program or other work which contains > +a notice placed by the copyright holder saying it may be distributed > +under the terms of this General Public License. The "Program", below, > +refers to any such program or work, and a "work based on the Program" > +means either the Program or any derivative work under copyright law: > +that is to say, a work containing the Program or a portion of it, >
Re: kde/workspace git module rename
On Tuesday 30 June 2015 12:01:47 Jonathan Riddell wrote: > projects.kde.org has a module called kde/workspace that's used for > Plasma bits. The name term "workspace" is obsolete and it's confusing > having it under "kde" where all the applications modules are. I'd > like to rename it to "plasma". I guess this will break kde-srcbuild > and maybe other build scripts. Is the tidying up worth the hassle? It will not just break kdesrc-build but also the local src code and build trees on our developer's systems. E.g. I have the structure setup with kdesrc- build and imported the projects into kdevelop using the src, build and install structure generated by kdesrc-build. This change would mean dropping all projects from kdevelop and reimport them, having to deal with branches not being moved to the new git structure, etc. etc. I expect that this would cost me several hours of work on each system (I have a build tree on three to four devices). Assuming that other plasma devs have similar setups we waste several person days just with shuffling repositories around. So given that I think this is not worth the hassle. Cheers Martin signature.asc Description: This is a digitally signed message part. ___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
Re: Re: Re: QPA plugin like functionality in frameworks?
On Wednesday 24 June 2015 23:20:21 Aleix Pol wrote: > On Wed, Jun 24, 2015 at 9:51 AM, Martin Gräßlin wrote: > > On Tuesday 23 June 2015 19:35:48 Aleix Pol wrote: > >> On Tue, Jun 23, 2015 at 9:42 AM, Martin Gräßlin wrote: > >> > Hi framework-developers and packagers, > >> > > >> > with two frameworks I'm currently in the need to have something like > >> > QPA. > >> > I > >> > want to make it possible to provide windowing-system specific plugins > >> > for > >> > frameworks using a private API. The need arises first of all in > >> > kwindowsystem to support wayland [1]. To implement it we need a > >> > dependency to KWayland, which is currently part of kde-workspace and > >> > not > >> > yet up to the quality and stability levels needed to make it a > >> > framework. > >> > The second framework where I need such functionality is kglobalaccel > >> > where kwin needs to take over a large part of the functionality of the > >> > runtime to make it work on wayland at all. > >> > > >> > I see the following possibilities to solve the problem: > >> > 1.Make it a private API without any ABI guarantee > >> > 2. Make it a public stable API with ABI guarantee > >> > 3. Make it a private API with so-version changes whenever the ABI > >> > changes > >> > > >> > Option 1 is closest to what Qt's QPA does, but I think this would be a > >> > nightmare for packagers. > >> > > >> > Option 2 could result in a nightmare for developers especially in the > >> > plugin infrastructure itself. With releases every month that could > >> > quickly end in classes like KWindowSystemPrivate32 and result in an > >> > unmanageable runtime check system. > >> > > >> > Personally I think Option 3 is the cleanest solution. Would this be > >> > acceptable for everyone? If yes are there any suggestions for where to > >> > install headers to, for naming the libraries, etc? > >> > > >> > Looking forward for your input, > >> > > >> > Cheers > >> > Martin > >> > > >> > [1] And obviously also other windowing systems if distributions/OSes > >> > want > >> > to add support for it. > >> > ___ > >> > Kde-frameworks-devel mailing list > >> > kde-frameworks-de...@kde.org > >> > https://mail.kde.org/mailman/listinfo/kde-frameworks-devel > >> > >> Hi Martin, > >> We already have something similar with frameworksintegration, maybe it > >> would make sense to integrate what you need there? > > > > Frameworksintegration doesn't really help as it's still part of frameworks > > and thus cannot depend on workspace libraries like kwayland. Also it's > > absolutely no solution for the problem of kglobalaccel (that feature > > must(!) be provided by kwin, there is no other way). > > > >> The biggest problem I see is that you want it in kde-workspace and > >> it's really complex to use a changing library within 2 different > >> release cycles. It will make things break on one side or another. > >> > >> What you can do is a stable plugin API and then provide the Wayland > >> plugins from Plasma releases. X11 and others can remain within > >> frameworks. > > > > That's option 2 from above. As said above I fear that this will be > > problematic due to the very short release cycle of frameworks and will > > create many subclasses just to keep it ABI stable. Of course it's doable, > > but well... > Well, these aren't completely new abstractions I guess, they're just > not public interfaces yet. If you start with wayland and X11 backends > (and ideally win/mac too), it should be a solid-enough interface > already so it doesn't need to change on the very next iteration. This assumes the API is done and is no longer extended. That's not the case, the API got extended at a constant pace over the last few months. Each addition to the API will need an addition to the "private" API in measure of adding a new virtual method. Cheers Martin signature.asc Description: This is a digitally signed message part. ___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
Re: Re: QPA plugin like functionality in frameworks?
On Tuesday 23 June 2015 19:35:48 Aleix Pol wrote: > On Tue, Jun 23, 2015 at 9:42 AM, Martin Gräßlin wrote: > > Hi framework-developers and packagers, > > > > with two frameworks I'm currently in the need to have something like QPA. > > I > > want to make it possible to provide windowing-system specific plugins for > > frameworks using a private API. The need arises first of all in > > kwindowsystem to support wayland [1]. To implement it we need a > > dependency to KWayland, which is currently part of kde-workspace and not > > yet up to the quality and stability levels needed to make it a framework. > > The second framework where I need such functionality is kglobalaccel > > where kwin needs to take over a large part of the functionality of the > > runtime to make it work on wayland at all. > > > > I see the following possibilities to solve the problem: > > 1.Make it a private API without any ABI guarantee > > 2. Make it a public stable API with ABI guarantee > > 3. Make it a private API with so-version changes whenever the ABI changes > > > > Option 1 is closest to what Qt's QPA does, but I think this would be a > > nightmare for packagers. > > > > Option 2 could result in a nightmare for developers especially in the > > plugin infrastructure itself. With releases every month that could > > quickly end in classes like KWindowSystemPrivate32 and result in an > > unmanageable runtime check system. > > > > Personally I think Option 3 is the cleanest solution. Would this be > > acceptable for everyone? If yes are there any suggestions for where to > > install headers to, for naming the libraries, etc? > > > > Looking forward for your input, > > > > Cheers > > Martin > > > > [1] And obviously also other windowing systems if distributions/OSes want > > to add support for it. > > ___ > > Kde-frameworks-devel mailing list > > kde-frameworks-de...@kde.org > > https://mail.kde.org/mailman/listinfo/kde-frameworks-devel > > Hi Martin, > We already have something similar with frameworksintegration, maybe it > would make sense to integrate what you need there? Frameworksintegration doesn't really help as it's still part of frameworks and thus cannot depend on workspace libraries like kwayland. Also it's absolutely no solution for the problem of kglobalaccel (that feature must(!) be provided by kwin, there is no other way). > The biggest problem I see is that you want it in kde-workspace and > it's really complex to use a changing library within 2 different > release cycles. It will make things break on one side or another. > > What you can do is a stable plugin API and then provide the Wayland > plugins from Plasma releases. X11 and others can remain within > frameworks. That's option 2 from above. As said above I fear that this will be problematic due to the very short release cycle of frameworks and will create many subclasses just to keep it ABI stable. Of course it's doable, but well... Cheers Martin signature.asc Description: This is a digitally signed message part. ___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
QPA plugin like functionality in frameworks?
Hi framework-developers and packagers, with two frameworks I'm currently in the need to have something like QPA. I want to make it possible to provide windowing-system specific plugins for frameworks using a private API. The need arises first of all in kwindowsystem to support wayland [1]. To implement it we need a dependency to KWayland, which is currently part of kde-workspace and not yet up to the quality and stability levels needed to make it a framework. The second framework where I need such functionality is kglobalaccel where kwin needs to take over a large part of the functionality of the runtime to make it work on wayland at all. I see the following possibilities to solve the problem: 1.Make it a private API without any ABI guarantee 2. Make it a public stable API with ABI guarantee 3. Make it a private API with so-version changes whenever the ABI changes Option 1 is closest to what Qt's QPA does, but I think this would be a nightmare for packagers. Option 2 could result in a nightmare for developers especially in the plugin infrastructure itself. With releases every month that could quickly end in classes like KWindowSystemPrivate32 and result in an unmanageable runtime check system. Personally I think Option 3 is the cleanest solution. Would this be acceptable for everyone? If yes are there any suggestions for where to install headers to, for naming the libraries, etc? Looking forward for your input, Cheers Martin [1] And obviously also other windowing systems if distributions/OSes want to add support for it. signature.asc Description: This is a digitally signed message part. ___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
KWin dependency heads-up
Hi packagers, I just wanted to inform you about new required dependencies for KWin 5.3. Due to outdated packages on our current CI system they are marked as optional (if the new CI is rolled out prior to the release they will change to being marked as required). * XCB minimum version 1.10: with an older version you won't have synced resizing. * xcb/util-cursor [1]: replaces XCursor library. Without you won't have e.g. resize/move cursors or cursors in effects like Present Windows. In addition we found and fixed [2] an issue in the xcb/util-cursor library which could result in no cursor [3] if the used theme does not contain the elements KDE/Qt expects (this mostly affects default cursor themes changed by distros). I recommend to pull the patch [2] or update to the new release [4] for KWin 5.3. As the release is brand new I will wait till 5.4 to make it the minimum required version to give you guys enough time to package. Sorry for any inconvenience this causes in your release process. Best Regards Martin Gräßlin [1] http://cgit.freedesktop.org/xcb/util-cursor [2] http://cgit.freedesktop.org/xcb/util-cursor/commit/?id=cf26479ece9ab9e04616bc10ba674d88a284e5b0 [3] https://bugs.kde.org/show_bug.cgi?id=344006 [4] http://cgit.freedesktop.org/xcb/util-cursor/tag/?id=0.1.2 signature.asc Description: This is a digitally signed message part. ___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
Re: Plasma 5.2.2 candidate tars
On Thursday 19 March 2015 17:52:15 Jonathan Riddell wrote: > 5.2.2 tars are up on depot, happy packaging > > These tars add documentation translations, looks like the Brazilians have > been hard at work. > > Please check over info and announcement pages and let me know of any > improvements or changes > > https://www.kde.org/info/plasma-5.2.2.php > https://www.kde.org/announcements/plasma-5.2.2.php > > Martin G said a fix for KWin was needed, I'm not sure if that got in or > not, so we may need to update that tar. No the fix is not yet in and I advice packagers to *NOT* package kwin till the new tarballs are up. I consider the issue in question a release blocker, please consider it the same. Cheers Martin signature.asc Description: This is a digitally signed message part. ___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
Re: Handling master/stable package differences on CI
On Wednesday 04 March 2015 09:16:39 Andreas Cord-Landwehr wrote: > Hey, currently we have different sets of packages available for master and > for stable branch groups on build.kde.org. Most prominent among them, only > master branches can build against Qt5.4, but not stable ones (only > providing Qt5.3). As a more or less result of this, after the branching of > Applications 15.04, the new stable branch of Rocs started to fail building > as it requires Qt5.4. > > I am writing this mail mostly as I am unsure how to proceed here, in > particular with the 15.04 Beta-1 release being close in front of us. > > What I currently see: > * Rocs has a hard dependency to Qt5.4 for a reason (since it uses the > QtQuick Statemachine) and would require considerable code changes to make > it work with Qt5.3 (well, a "hack" to get it building on build.k.o is > possible with only requiring Qt5.3, since building and unit tests should > pass, yet IMO that sends a very wrong message to packagers as the > application would fail starting when built against Qt5.3) Suggestion: ifdef properly for usage with Qt 5.3 so that it builds on the CI. But bind it to a CMake variable which gets passed to the build on the CI system. Something like -DIKNOWTHATITWILLBREAKWITHQT53 The same problem will btw hit Plasma once we branch. KWin is hard depending on Qt 5.4 and I think Eike introduced some hard 5.4 dependencies in other areas, too. Cheers Martin signature.asc Description: This is a digitally signed message part. ___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
Re: Re: 15.04 feature freeze exception for dolphin and dolphin-plugins
On Friday 27 February 2015 02:16:26 Albert Astals Cid wrote: > El Dijous, 26 de febrer de 2015, a les 19:53:30, Emmanuel Pescosta va > > escriure: > > Dear release team, > > > > Please consider a 15.04 feature freeze exception for dolphin [1] and > > dolphin-plugins [2]. > > None of those repos seem to have their KF5 branches in CI, how many people > have built them? Are we sure their dependencies are properly released? > detected by cmake? > > Has anyone sanitized the history of those repos? > I will answer myself, no, it has no branches, I don't think that's > acceptable to be honest. > > > Both are theoretically ready to be shipped as part of 15.04 as the first > > frameworks > > based release. > > Has anyone actually been using this release. Is it as good as the kdelibs4- > based one? I have been using Dolphin (Qt5) for months in my "normal" usage of Dolphin. As it comes with kdesrc-build I expect many others to have used it in the same way. So far I have not reported a bug report against the version, well simply because I didn't hit any. Cheers Martin signature.asc Description: This is a digitally signed message part. ___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
Re: Re: Re: 5.2.1 tars for packagers
On Tuesday 24 February 2015 00:58:15 Eric Hameleers wrote: > On Tue, 24 Feb 2015, Martin Gräßlin wrote: > > sorry, but it happens that I have a Weekend and cannot follow up > > everything > > which someone writes on Google+. It just happens that such comments get > > lost when I access Google+ on the phone. And guess what: I don't care, I > > am not a bugtracker gate keeper and don't handle bugs which are brought > > to me by: * IRC > > * mail > > * mailinglist > > * Google+ > > * private talk > > * whatever > > > > if you want to report a bug report, report it on bugs.kde.org. That's way > > better than assuming that I put people on ignore. > > With such an answer, can't you see why I think you put me on ignore? > After I asked you my question on G+ you have added multiple posts > about your own development on KWin, so I would have assumed that you > had read my question unless you were deliberately ignoring me. Do you want to have access to my inbox to see that it might happen that I forget about it? Read it on the smartphone, didn't answer on it (because I hate typing on the smartphone), notification discarded by Google+ and I forgot about it on Monday. Exactly that's why I don't accept bug reports on any other medium than bugs.kde.org to not forget about it. Sorry that I did not point out that it's better to report on bko than to me on Google+ because I was only on smartphone and didn't type. If you want to assume ill will by it, fine with me. Being pragmatic about it that I'm just human and buried in the load of incoming communications might be fairer, though. > > Judging from your G+ posts, you find it very important to communicate > with your users about your product Well you can also see that I didn't post on the Weekend on Google+, might be it was weekend after all ;-) Cheers Martin signature.asc Description: This is a digitally signed message part. ___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
Re: Re: kwin/kcmkwin/kwindecoration/kcm.cpp:399:17: error: ‘class QQuickWidget’ has no member named ‘setClearColor’
On Sunday 25 January 2015 12:58:27 Thomas Lübking wrote: > On Sonntag, 25. Januar 2015 12:41:42 CEST, David Faure wrote: > > It seems ce2fa727e886a8d47536748d95ca51faf1cb5d75 broke compilation with > > Qt 5.3 ? > Seems indeed. > > I'll bail out by having inherited it from review 122027 and excuse Martin > (and myself) because the version dependency is not mentioned in the 5.4 API > doc ;-) > > @Release Team > Will it be ok and sufficient to simply push a fix (#if QT_VERSION >= > 0x050400) into the Plasma/5.2 branch or is there an extra tag to operate > on? I pushed this as a fix: http://commits.kde.org/kwin/52793c5e5b7439c98106dd7ebc02707547025cca @Jonathan: please respin the kwin tarball with the commit. Sorry for the inconvenience. Martin > > Sorry for the trouble. > Thomas > ___ > release-team mailing list > release-team@kde.org > https://mail.kde.org/mailman/listinfo/release-team signature.asc Description: This is a digitally signed message part. ___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
Re: Re: Plasma 5.2 Beta Tars are up for packaging
On Thursday 08 January 2015 17:26:10 Jonathan Riddell wrote: > Also new is polkit-kde-agent-1 and kdecoration Cheers Martin signature.asc Description: This is a digitally signed message part. ___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
Re: Re: Fwd: Plasma Framework problems
On Sunday 12 October 2014 20:48:36 David Edmundson wrote: > On 12 Oct 2014 18:04, "šumski" wrote: > > On Sunday 12 of October 2014 11:58:44 David Edmundson wrote: > > > > I'll report back when I've confirmed this and then we can work out > > how we > > > > > proceed. > > > > > > > > Reverting a3932843386a29faa3c62bf2934a173a3781d56c does indeed make > > > > > > everything work. > > > > > > Assuming we don't have a time machine our options are: > > > - revert this commit and release plasma-framework 5.3.1 really quickly > > > > Please go with this option... How will this affect Plasma 5.1? Given the review it looks like it was moved into workspace - is it a problem to have the code twice? Anyway if you revert, please deprecate the code, add a TODO KF6 and a comment on why it cannot be removed. I find it kind of scary that a change in the private implementation detail breaks the released software. Cheers Martin signature.asc Description: This is a digitally signed message part. ___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
Re: Re: Whoopsie in KF5::WindowSystem 5.3.0
On Friday 10 October 2014 17:37:02 Rolf Eike Beer wrote: > Am Freitag, 10. Oktober 2014, 17:14:41 schrieb Martin Graesslin: > > Hi all, > > > > unfortunately we have an embarrassing bug [1] in KWindowSystem 5.3.0 > > which can crash any application making use of KWindowSystem on the X11 > > Platform. This is fixed with commit [2]. I recommend to either do a 5.3.1 > > release for KWindowSystem with just that commit added or at least that > > distros ship the patch in their packages. > > > > Sorry about that. I still don't understand how it could pass through the > > CI > > system without failing. > > > > Cheers > > Martin > > > > [1] Apparently I'm not able to count to four, see BUG 339771 > > Why not make the static array static in the file instead of the functions > and then simply do "netAtomCount = sizeof(array)/sizeof(array[0]) - 1;"? > That way you never have to count again ;) My intention was to fix the regression first in the most obvious way that I'm only fixing the regression. A change to make the code better should only go into 5.4 IMHO. Cheers Martin signature.asc Description: This is a digitally signed message part. ___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
Re: Re: Plasma 5.1 beta tars
On Friday 26 September 2014 19:46:27 Albert Astals Cid wrote: > El Divendres, 26 de setembre de 2014, a les 19:33:47, Martin Gräßlin va > > escriure: > > On Friday 26 September 2014 19:26:20 Albert Astals Cid wrote: > > > El Divendres, 26 de setembre de 2014, a les 11:50:16, Jonathan Riddell > > > va > > > > > > escriure: > > > > On Thu, Sep 25, 2014 at 11:06:08PM -0400, Anke Boersma wrote: > > > > >Seems most build ok with frameworks 5.2.0, kwin though needs > > > > >5.3.0: > > > > >http://quickgit.kde.org/?p=kwin.git&a=commitdiff&h=58adbe4d805f5f > > > > >b7 > > > > >33 > > > > >30 > > > > >4b994caa07ba77e2faab Is this beta not intended to be build on > > > > >frameworks released tars, it is intended to use git builds of > > > > >frameworks for it? > > > > > > > > Yes I'm afraid so, KF5 5.3 will be out before the final Plasma 5.2. > > > > > > So we have released unbuildable tars? Doesn't seem like the bests of the > > > ideas. > > > > I think there was a typo: KF5 5.3 will be released before the final Plasma > > 5.1, not 2. > > Still, at the moment, we have put out some tarballs that are uncompilable. > > What's the point? > > Cheers, > Albert > > P.S: Sure i know I can compile them using some git version somewhere, but > that's not how one is supposed to do releases. ok, I see the problem. As it was me who introduced the hard dependency on new 5.3 API, let me say sorry for that. I was not aware that it will create problems. Given that the release schedule was prepared in a way that we can depend on KF5.3 I didn't expect that depending on 5.3 would create packaging problems. I could easily revert the commits, but it would only fix half of the problem as also code in plasma depends on plasma-framework - even if it doesn't use new API. For the next release cycle we should be aware of that problem and ensure that we do not depend on unreleased frameworks. Cheers Martin signature.asc Description: This is a digitally signed message part. ___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
Re: Re: Plasma 5.1 beta tars
On Friday 26 September 2014 19:26:20 Albert Astals Cid wrote: > El Divendres, 26 de setembre de 2014, a les 11:50:16, Jonathan Riddell va > > escriure: > > On Thu, Sep 25, 2014 at 11:06:08PM -0400, Anke Boersma wrote: > > >Seems most build ok with frameworks 5.2.0, kwin though needs 5.3.0: > > >http://quickgit.kde.org/?p=kwin.git&a=commitdiff&h=58adbe4d805f5fb733 > > >30 > > >4b994caa07ba77e2faab Is this beta not intended to be build on > > >frameworks released tars, it is intended to use git builds of > > >frameworks for it? > > > > Yes I'm afraid so, KF5 5.3 will be out before the final Plasma 5.2. > > So we have released unbuildable tars? Doesn't seem like the bests of the > ideas. I think there was a typo: KF5 5.3 will be released before the final Plasma 5.1, not 2. Cheers Martin signature.asc Description: This is a digitally signed message part. ___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
Re: Re: Plasma 5.1 beta tars
On Thursday 25 September 2014 23:06:08 Anke Boersma wrote: > Seems most build ok with frameworks 5.2.0, kwin though needs 5.3.0: > http://quickgit.kde.org/?p=kwin.git&a=commitdiff&h=58adbe4d805f5fb733304b994 > caa07ba77e2faab > > Is this beta not intended to be build on frameworks released tars, it is > intended to use git builds of frameworks for it? yes KWin requires frameworks 5.3. I wanted to indicate the required version in CMakeLists.txt but we don't have any version check there yet, so I stepped away from it out of fear to break CMake. Cheers Martin > > Anke > > On Thu, Sep 25, 2014 at 6:28 PM, Jonathan Riddell wrote: > > Plasma 5.1 Beta tars are up at > > > > http://starsky.19inch.net/~jr/tmp/plasma-5.0.95/ > > > > and coming soon to depot.kde.org > > > > New in this release.. > > - standard version number 5.0.95 for all > > - the return of kdeplasma-addons > > - kwayland shows us the future of windowing systems > > > > Let me know of any problems > > > > Public release due Tuesday > > > > Jonathan > > ___ > > Kde-packager mailing list > > kde-packa...@kde.org > > https://mail.kde.org/mailman/listinfo/kde-packager signature.asc Description: This is a digitally signed message part. ___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
Re: Re: The name of Applications 4.14 + 1
On Thursday 17 July 2014 08:49:47 Andreas Cord-Landwehr wrote: > On Thursday 17 July 2014 08:13:59 Shantanu Tushar Jha wrote: > > Looking from a user's perspective who has been using KDE for some > > time now, > > > this sounds confusing. The reason is that Plasma is 5 and then > > applications > > > will be called 2014.mm, its just too much of a difference. And I'm not > > just > > guessing, I've answered questions from such users on #kde while trying > > not > > > to confuse them and it was difficult. > > Hi, I must admit that I see it rather the opposite way :) > > For me (when looking back at my user-but-not-developer time), I was > always slightly confused why KDE SC release numbers were different to the > application versions. Using a naming scheme that only carries the date of > the release would solve this. > > One could argue that this is the same with KF5/Plasma as they also consist > of several apps/libs with their own version numbers. But from my point of > view, KF5/Plasma are something that is "more consistent" in providing a > foundation for development or a consistent user experience, which an > applications release hardly can do. > > If using naming schemes like .MM, what would be the style for minor > releases? Appending days is probably not a good solution ;) Yet increasing > the month counter would not make it clear if the release is a major or a > minor/bugfix release. In the Plasma team we considered the .MM scheme. We thought about .MM.x with x being 0, 1, 2... for the bugfix releases. So the initial release would be 2014.12.0 while the January bugfix release would be 2014.12.1. Cheers Martin signature.asc Description: This is a digitally signed message part. ___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
Re: Re: Fwd: KDE Frameworks Release Cycle
On Tuesday 20 May 2014 07:19:59 Scott Kitterman wrote: > On May 20, 2014 4:19:26 AM EDT, Jos Poortvliet wrote: > >On Tuesday 20 May 2014 19:07:41 Ben Cooksley wrote: > >> On Tue, May 20, 2014 at 6:04 PM, Kevin Ottens wrote: > > > > > >> > Now, I think we'll have to agree to disagree on something. You > > > >believe > > > >> > there's some rule written in stone somewhere which will make the > >> > "everyone will pile up backports only" the new status quo forever, > > > >I say > > > >> > let's try and find out. > >> > >> In the meantime, everyone but the developers will suffer. > > > >Yes, and saying no to every proposal won't change that. > > > >I believe that the only advantage of the current situation (slow > >release > >cycle with a period of 'bugfixes' that go untested) seems to be that it > >is a > >known evil: we're lying about them being stable bugfix releases but the > > They are almost completely bugfix. Every now and then something slips > through, but those are mistakes. > > We (packagers) know exactly how much testing gets done upstream, so we test > them before releasing to our users. I already mentioned this once in this thread: such testing has to be done upstream. It is a waste of all distro's time if every distro tests independently the same things, and a bad experience if you miss to test something due to lack of knowledge [1]. I'm quite convince that there is a middle ground which will help the developers and the packagers way. We only have to accept that there will be changes and start to move a little bit. I see here so much possibilities to improve the workflows, but so far all I saw from distro side is "change is bad". Let's try a little bit harder to improve the situation :-) Cheers Martin [1] We had pretty bad regressions in KWin once which no distro spotted. From 0 to 10 with 10 being the worst imaginable bug, it scored an 11. signature.asc Description: This is a digitally signed message part. ___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
Re: Re: Fwd: KDE Frameworks Release Cycle
On Wednesday 30 April 2014 15:08:55 Raymond Wooninck wrote: > On Wednesday 30 April 2014 14:39:31 Martin Gräßlin wrote: > > I know that this is a change from how it is right now: but wouldn't it be > > better if those who are interested do these branches? Let's face it > > whatever we do upstream cannot suite all of our downstreams at the same > > time. > If I take your words literally here, then upstream is not interested in how > the distros is packaging KDE. The only point of interest of upstream is to > deliver new releases. This is kind of dumping everything to the distros > and let them sort things out. I really wonder if this is the release > methodology that Frameworks want to apply ? I fail to see how you could have read this into my mail especially considering the other mails where I explained that the new approach is a measure to increase the quality. > > > And please remember: this is only about frameworks, not about the > > applications or the workspace. > > But the proposed release cycle for Frameworks could set an example for the > others. If this is the way frameworks will follow, what would stop the > others from doing exactly the same. Nothing. In the same way nothing would stop them to do that without frameworks doing that. I already shared my plans for a rapid release cycle for KWin during the Wayland port with fellow developers months ago before this discussion for frameworks started. At the same time we decided that for Plasma as the desktop shell it's not suited. Different projects need different release cycles and I'm quite sure that every application will pick the approach which is suited best for them and the stakeholders. We live in a git world and rapid release cycles help to increase the quality. Following this thread I sometimes think people still think in svn. It's quite simple: master is always stable. Period. Code which doesn't have the quality cannot get merged in. Code that doesn't have test coverage cannot get in. We are not switching to a model where everything is lost and distros will have a hard time because the quality sucks and they need to fetch patches from everywhere. We are moving to a model where it should not happen that there are bugfixes needed (yes of course bugs will always happen, but if we fail to get at a point where it doesn't matter for distros, the approach will be wrong). Cheers Martin signature.asc Description: This is a digitally signed message part. ___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
Re: Re: Fwd: KDE Frameworks Release Cycle
On Wednesday 30 April 2014 08:24:43 Scott Kitterman wrote: > On Wednesday, April 30, 2014 11:35:54 Àlex Fiestas wrote: > > On Tuesday 29 April 2014 19:23:07 Scott Kitterman wrote: > > > For non-rolling distros, at some point you have to stop and release. A > > > mix > > > of new features and bug fixes aren't going to be allowed in. > > > > > > We (Kubuntu) have been delivering KDE SC point releases as post-release > > > updates to our users for most (maybe all) KDE4 releases. That's over > > > with > > > KF5. > > > > > > We'll, I guess, have to settle for cherry picking fixes and doing our > > > best. > > > > You might not know this but most developers don't do proper testing in the > > stable branches because the cost of having master and stable environments > > and doing testing in both branches for each fix is too much, we simply > > don't have the manpower for that. > > > > History has shown this mny times, we have done point releases that > > were > > horrible quality-wise because nobody was testing them. The stable branches > > have virtually no users. > > > > I have been told by you (at UDS) and by many others packagers that our > > point releases suck, that we introduce huge regressions etc. The above > > paragraph explains the reason. > > > > We have to be realistic here, upstream does NOT have the manpower to > > maintain more than one release. > > > > So, I honestly think that if we work together you can do a better work > > cherry- picking than we can. Also we should develop tools to make your > > life > > easier. > > We test the point releases before we ship them to end users. Sometimes we > find regressions. It happens. I'm pretty sure I didn't say the suck. > I've invested a lot of hours of my free time both getting approval to ship > them post release and packaging them as well. I wouldn't have done that if > I thought they sucked. > > I'm well aware of the amount of testing the stable branches get. That's why > we do the testing we do before we ship them. I can't recall the last time > we had end user complaints of a regression after a stable update has been > released to end users. > > I think the best tool to make our life easier would be maintenance branches. > If you only want to have one every 3 - 6 KF5 releases, fine. I know that this is a change from how it is right now: but wouldn't it be better if those who are interested do these branches? Let's face it whatever we do upstream cannot suite all of our downstreams at the same time. And please remember: this is only about frameworks, not about the applications or the workspace. Cheers Martin signature.asc Description: This is a digitally signed message part. ___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
Re: Re: Fwd: KDE Frameworks Release Cycle
On Wednesday 30 April 2014 12:33:06 Àlex Fiestas wrote: > We are all on the same situation and we have to make the best of it. We > believe that e can do best if we focus on master and make sure master rocks, > it has no regressions etc. Obviously, if we are able to increase the quality of overall frameworks by a more suited development model, the number of bugs goes down and the number of fixes which need to be backported will go down. Which might end this discussion as a non-issue. At least for the frameworks I maintain, I do hope that we will never have to do bug fixes. And that's kind of the case right now already - kwindowsystem 4.x last saw a bug fix in 2012. Cheers Martin signature.asc Description: This is a digitally signed message part. ___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
Re: Re: Fwd: KDE Frameworks Release Cycle
On Wednesday 30 April 2014 11:35:54 Àlex Fiestas wrote: > On Tuesday 29 April 2014 19:23:07 Scott Kitterman wrote: > > For non-rolling distros, at some point you have to stop and release. A mix > > of new features and bug fixes aren't going to be allowed in. > > > > We (Kubuntu) have been delivering KDE SC point releases as post-release > > updates to our users for most (maybe all) KDE4 releases. That's over with > > KF5. > > > > We'll, I guess, have to settle for cherry picking fixes and doing our > > best. > > You might not know this but most developers don't do proper testing in the > stable branches because the cost of having master and stable environments > and doing testing in both branches for each fix is too much, we simply > don't have the manpower for that. > > History has shown this mny times, we have done point releases that were > horrible quality-wise because nobody was testing them. The stable branches > have virtually no users. Just a note: consider watching David's, Vishesh's and my Akademy talk from last year. I discuss the problem with stable releases in detail and the mess we created in the past. > So, I honestly think that if we work together you can do a better work > cherry- picking than we can. Also we should develop tools to make your life > easier. Actually I think there is nothing wrong with having something like an "LTS" release which is maintained by the distros. I recently read that Ubuntu picked up maintenance of the Linux Kernel they are using. I think that the same could be done here, just that it might need tighter integration from the distros. E.g. thinking about which version would work well for the next openSUSE and Kubuntu release. Personally from an upstream position I would love to see stronger collaboration between our stakeholders. Also what should be quite obvious: asking the maintainers whether the fixes are backportable should always be possible. Cheers Martin signature.asc Description: This is a digitally signed message part. ___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
Re: Plasma Next alpha release engineering bits
On Wednesday 05 March 2014 13:10:12 Sebastian Kügler wrote: > Hi, > > As we're planning to release the first alpha of Plasma Next next week, I'd > like to go over some details that need discussing. > > - promo preparations > - tagging / tarballing: can happen anytime on Thursday next week > - smoke-testing of packages > - rolling out packages on Monday, or sooner depending on testing? > > We'll need someone to roll the tarballs and put them on the download site. > Who is willing to help here? > > Affected repositories: > > - plasma-framework > - kde-workspace > - kde-runtime > - kwin-compositing-kcm we will also need - kwindowsystem - frameworkintegration kwindowsystem because there will be SC changes and we need to adjust kde- workspace and I want to get those in as early as possible because of upcoming freeze in frameworks. frameworkintegration for the QSystemTrayIcon - statusnotifier mapping Cheers Martin signature.asc Description: This is a digitally signed message part. ___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
Re: Re: [dot] KF5 alpha 1
On Sunday 02 March 2014 19:55:46 Jos Poortvliet wrote: > On Sat, Mar 1, 2014 at 10:35 AM, David Faure wrote: > > On Friday 14 February 2014 17:10:15 Jos Poortvliet wrote: > >> On Tuesday 11 February 2014 23:18:51 David Faure wrote: > >> > KF5 alpha 1 is out > >> > > >> > (I changed permissions on the dir and pushed the tags into git). > >> > > >> > If anyone wants to write a release announcement, now is the time :) > >> > >> Back from holiday, writing something. Will give it today as release date > >> and push it out asap. Too bad nobody else found time to pick it up... > >> > >> Some info on what's in there would be appreciated. Will ping on IRC. > > > > New month, new KF5 release: I'm about to package up KF5 beta1 now. > > > > Official release on Tuesday, or do packagers and/or dot editors want more > > time? > > Alpha two? Should not be a huge deal, let's just get it out on > Tuesday. Any updates on what is new or changed would be appreciated, > something that can replace this part from alpha 1: > -- > Improvements in this release include the addition of .pri files which > make it easy for qmake based projects to use individual frameworks and > two new frameworks: kactivities and plasma-framework. There has also > been significant progress in getting frameworks to work on the > Microsoft Windows platform. > -- You could mention that our frameworks got fixed to run on Wayland [1]. Feel free to take one of my screenshots for it. Relevant blog post: http://blog.martin-graesslin.com/blog/2014/02/running-frameworks-powered-applications-on-wayland/ Cheers [1] kinit, kdesu and khtml are not yet fixed Martin signature.asc Description: This is a digitally signed message part. ___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
Re: Review Request 115519: Do not use KDE_VERSION_STRING for workspace applications
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/115519/ --- (Updated Feb. 7, 2014, 11:33 a.m.) Status -- This change has been marked as submitted. Review request for kde-workspace and Release Team. Repository: kde-workspace Description --- Workspace is no longer synced with kdelibs releases. Thus if compiled against e.g. 4.12 we want our workspace apps to still be 4.11. Diffs - kwin/clients/oxygen/demo/main.cpp 83d9d83 kwrited/kwrited.cpp cab2d6b plasma/desktop/shell/main.cpp ea3d43d startkde.cmake 30d5ab5 statusnotifierwatcher/statusnotifierwatcher.cpp 97ae164 systemsettings/app/main.cpp 78109e0 kstyles/oxygen/config/main.cpp 5a5286e kstyles/oxygen/demo/main.cpp 005395b ksysguard/gui/ksysguard.cpp 2ad34f2 config-workspace.h.cmake b3ba37d khotkeys/kcm_hotkeys/kcm_hotkeys.cpp 389a361 kinfocenter/main.cpp c28f7cf krunner/main.cpp 6eac316 kscreensaver/kblank_screensaver/blankscrn.cpp 99ef649 kscreensaver/krandom_screensaver/random.cpp 4047184 Diff: https://git.reviewboard.kde.org/r/115519/diff/ Testing --- compiled with 4.12.60 kdelibs and looked at e.g. startkde and systemsettings which have now 4.11.6. Thanks, Martin Gräßlin ___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
Review Request 115519: Do not use KDE_VERSION_STRING for workspace applications
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/115519/ --- Review request for kde-workspace and Release Team. Repository: kde-workspace Description --- Workspace is no longer synced with kdelibs releases. Thus if compiled against e.g. 4.12 we want our workspace apps to still be 4.11. Diffs - kwin/clients/oxygen/demo/main.cpp 83d9d83 kwrited/kwrited.cpp cab2d6b plasma/desktop/shell/main.cpp ea3d43d startkde.cmake 30d5ab5 statusnotifierwatcher/statusnotifierwatcher.cpp 97ae164 systemsettings/app/main.cpp 78109e0 kstyles/oxygen/config/main.cpp 5a5286e kstyles/oxygen/demo/main.cpp 005395b ksysguard/gui/ksysguard.cpp 2ad34f2 config-workspace.h.cmake b3ba37d khotkeys/kcm_hotkeys/kcm_hotkeys.cpp 389a361 kinfocenter/main.cpp c28f7cf krunner/main.cpp 6eac316 kscreensaver/kblank_screensaver/blankscrn.cpp 99ef649 kscreensaver/krandom_screensaver/random.cpp 4047184 Diff: https://git.reviewboard.kde.org/r/115519/diff/ Testing --- compiled with 4.12.60 kdelibs and looked at e.g. startkde and systemsettings which have now 4.11.6. Thanks, Martin Gräßlin ___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
Re: Re: Automatic creation of version information on bugs.kde.org
On Wednesday 05 February 2014 12:59:12 you wrote: > > I noticed that somehow the versions in bugzilla get updated once we had an > > SC release. I don't know who does it, but I assume that someone on the > > list knows who does it :-) > > > > So a small request: please exclude the kde-workspace products for the > > 4.12.x releases. Even better: change it to generate a 4.11.x version ;-) > > Open systemsettings, go into menu, "About systemsetting". The dialog window > displays "Version 4.12.0, under KDE 4.12.1" (seems like I havent finished > some update, me bad). Ah well, that's a bug in systemsettings. We had the same one in KWin and fixed it in 4.11.6. The problem is that the version number for historic reasons is taken from kdelibs. But we have the proper version number available - and need to change that in master anyway. > Please, dont. It'll generate even more confusion with users. In this case > IMHO the additional work burden is on your side. if you want to fiddle > around with the versioning system, you'll have to bear with the bug reports > and the information you provided in your applications. Yes there is confusion if versions information is incorrect. In case of KWin we fixed it and I'm happy to fix other applications. Cheers Martin signature.asc Description: This is a digitally signed message part. ___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
Re: Re: Automatic creation of version information on bugs.kde.org
On Wednesday 05 February 2014 13:07:37 Andreas K. Huettel wrote: > Am Mittwoch, 5. Februar 2014, 12:59:12 schrieb Andreas K. Huettel: > > Open systemsettings, go into menu, "About systemsetting". The dialog > > window > > displays "Version 4.12.0, under KDE 4.12.1" (seems like I havent finished > > some update, me bad). > > err, suspicion, could the displayed systemsettings version number be the > version of kdelibs that the app was built against? yes that's most likely the case. At least it was for KWin (that's what we fixed in 4.11.6) Cheers Martin signature.asc Description: This is a digitally signed message part. ___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
Re: Re: Automatic creation of version information on bugs.kde.org
On Wednesday 05 February 2014 11:02:04 Frank Reininghaus wrote: > Hi Martin, > > 2014-02-05 Martin Gräßlin: > > Hi all, > > > > I noticed that somehow the versions in bugzilla get updated once we had an > > SC release. I don't know who does it, but I assume that someone on the > > list knows who does it :-) > > > > So a small request: please exclude the kde-workspace products for the > > 4.12.x releases. Even better: change it to generate a 4.11.x version ;-) > > Jekyll Wu has the script that creates new versions automatically (just > one of the many things he does to make bugs.kde.org a better place - > thanks for that!). It's probably easy to exclude the kde-workspace > products from the script? Awesome work Jekyll! So would it be possible to pull the kde-workspace products out of the script and into another one for adding the 4.11.x releases? If you don't have the time for it, just tell me the git repo where the script lives and I'll adjust it myself :-) Cheers Martin signature.asc Description: This is a digitally signed message part. ___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
Automatic creation of version information on bugs.kde.org
Hi all, I noticed that somehow the versions in bugzilla get updated once we had an SC release. I don't know who does it, but I assume that someone on the list knows who does it :-) So a small request: please exclude the kde-workspace products for the 4.12.x releases. Even better: change it to generate a 4.11.x version ;-) Thanks a lot Cheers Martin signature.asc Description: This is a digitally signed message part. ___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
Re: Disable by default KRandR in 4.11
On Thursday 04 July 2013 01:06:27 Àlex Fiestas wrote: > Hi there > > I want to propose to disable by default KRandR from kde-workspace release > for 4.11. +1 > Ideally I would like to remove the source code completely, but I guess we > are too late into 4.11 to do such thing. why not? You could replace it with a readme to inform people still building from source or packagers not having kscreen yet, that it's time to switch. Cheers Martin signature.asc Description: This is a digitally signed message part. ___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
Re: Re: KDE SC 4.10.1 tarballs
On Sunday 03 March 2013 00:21:55 Albert Astals Cid wrote: > El Divendres, 1 de març de 2013, a les 20:54:04, Torgny Nyblom va escriure: > > Hi, > > > > The tarballs for the 4.10.1 release are now available in the usual > > location. > > > > I've not compiled them so please report any issues you find. > > The kde-workspace package failed to compile here > > /home/kdepackages/kde-workspace-4.10.1/kwin/layers.cpp:219:5: error: ISO C++ > forbids comparison between pointer and integer [-fpermissive] > > I needed to change > assert(newWindowStack.at(0) == (Window*)supportWindow->winId()); > to > assert(newWindowStack.at(0) == (Window)supportWindow->winId()); adding kwin to CC for more qualified answer than from me :-) I'd say you can remove the cast completely and I would say that it's no need to respin kde-workspace as it's only in an assert and compiles fine in release mode. -- Martin Gräßlin signature.asc Description: This is a digitally signed message part. ___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
Re: Re: Better testing of tagged tars
On Wednesday 13 February 2013 01:00:13 Albert Astals Cid wrote: > El Dimarts, 12 de febrer de 2013, a les 22:05:00, Martin Gräßlin va escriure: > > On Tuesday 12 February 2013 15:28:35 Anke Boersma wrote: > > > This whole thread was about stable tars, not RC or Beta. > > > > Sorry at least to me that was not obvious. (thread started on 31. of > > January, doesn't mention minor releases, so I assumed it meant the > > upcoming > > release of 4.10) - all I wrote so far was explicitly for the case of a > > 4.x.0 release. > > > > > What was found > > > and reported often, is regressions from say, 4.x.2 to 4.x.3. > > > Reported not in bug reports, but more a discussion on IRC, see if anyone > > > was aware, sometimes ml, again, just checking if it was a known/accepted > > > regression. > > > > status quo is that currently the branches are basically untested. > > That is *your* thinking, i.e. you don't test them, but i think it is a bit > off a stretch to present that as the reality. Although i agree more users > of the stable branch would help. do you know any developer running branch instead of master? I don't -- Martin Gräßlin signature.asc Description: This is a digitally signed message part. ___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
Re: Re: Re: Re: Re: Better testing of tagged tars
On Tuesday 12 February 2013 15:28:35 Anke Boersma wrote: > This whole thread was about stable tars, not RC or Beta. Sorry at least to me that was not obvious. (thread started on 31. of January, doesn't mention minor releases, so I assumed it meant the upcoming release of 4.10) - all I wrote so far was explicitly for the case of a 4.x.0 release. > What was found > and reported often, is regressions from say, 4.x.2 to 4.x.3. > Reported not in bug reports, but more a discussion on IRC, see if anyone > was aware, sometimes ml, again, just checking if it was a known/accepted > regression. status quo is that currently the branches are basically untested. Here personally I would love to get more testing as I never like pushing to branch (let's push to master, if nobody screams in two weeks, let's backport). For this situation I would suggest to coordinate with the quality team (e.g. Myriam). -- Martin Gräßlin signature.asc Description: This is a digitally signed message part. ___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
Re: Re: Re: Re: Better testing of tagged tars
On Tuesday 12 February 2013 14:37:22 Anke Boersma wrote: > any bugs found in the early tars (not build related) should > be kept quiet, until the tars are officially announced. It is better to > have final tars that have bugs that were known for a few days, than > reporting. What kind of bugs are you expecting to find: 1) Regressions from the last RC -> escalate 2) Bugs already present in the RC and reported 3) Bugs already present in the RC and not reported >From experience of our users and their usage with bugzilla. 90 % is category 2 (that obviously includes experienced users). Given that we release with known bugs (bug free software is impossible) it hardly matters whether there are a few more or less and it wouldn't change anything because we are post final tagging (except it's a showstopper -> escalate). That said: I keep to what I wrote. For me as a heavy bugzilla user (just look at commit-digest) getting bug reports for an unreleased version would cause more work and confusion. My first comment would be "this version is not yet released, where do you have it from? Are you sure you are running exactly that version?" - if I don't know the user and that he is an experienced Chakra user having access to pre-released packages, I have to assume he entered junk which happens more often than you would expect. For everything else of your mail: sorry, I'm not qualified to answer/comment on that :-) -- Martin Gräßlin signature.asc Description: This is a digitally signed message part. ___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
Re: Re: Re: Better testing of tagged tars
On Tuesday 12 February 2013 19:25:46 Myriam Schweingruber wrote: > Hi Anke, > > On Tue, Feb 12, 2013 at 7:07 PM, Anke Boersma > > wrote: > > But this is the exact point I'm trying to make. Educate early testers to > > report any issues they find within the distro. We have done that for 3 > > years, and is well known and accepted by our testers (this includes > > testing > > all beta and rc builds for Chakra). > > I think the point is: we don't have enough testers for the Beta and RC > release, if these people would join the Quality Team during testing > this would be far more valuable than only for the final tarball. So > far we are only a handful, and maybe you have testers that do test but > they don't report upstream, nor do they coordinate with us. The KDE > Quality team would welcome a few more hands for that, for the final > tarball it's just a bit late IMHO. +1000 - that's exactly the point. We don't need the testers when the final tarballs are already done, we need them months before. And if you have many testers for your beta packages you also get most of the distro issues early. -- Martin Gräßlin signature.asc Description: This is a digitally signed message part. ___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
Re: Re: Re: Better testing of tagged tars
On Tuesday 12 February 2013 10:43:37 Ian Monroe wrote: > On Tue, Feb 12, 2013 at 9:32 AM, Martin Gräßlin wrote: > > Would a solution like introducing dedicated versions help here: maybe. It > > would require each developer working with such issues to track the release > > team mailing list to get the notification of a respin, the new version > > number and the matching git hash. Tricky and again with lots of work. > > Also problematic once the final version is created because the version > > information must be exactly the same otherwise Dr.Konqui magic doesn't > > work. > > Wouldn't much of the problem be solved if the git sha was directly > appended to the version number? It wouldn't even need to be all that > many digits - like 3 or 4 - since it would just need to differentiate > between commits around the time of the release. Traceability would be > for free. You wouldn't be able to tell which tarball of the same > version but different sha was the newest, but you can't tell that > currently anyways. If DrKonqui can handle that (perform proper version matching) it would be in general a very good thing to have. But I don't know whether that can work at all that it really points to the right sha given the way how git works. One would need to know the hash of the commit being created by inserting the hash into the version information in CMakeLists.txt. -- Martin Gräßlin signature.asc Description: This is a digitally signed message part. ___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
Re: Re: Better testing of tagged tars
On Tuesday 12 February 2013 19:27:49 Ralf Jung wrote: > * add git tags and bugzilla versions at the same time as tarballs are > created gues who creates the bugzilla versions and no I don't think it would scale to burden that to the release team. -- Martin Gräßlin signature.asc Description: This is a digitally signed message part. ___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
Re: Re: Better testing of tagged tars
On Tuesday 12 February 2013 11:57:21 Anke Boersma wrote: > As to point 2, having a much clearer set policy, that any distro can convey > to their testers must surely result in less badly placed bug reports. > Testers who have to read documentation just to be able to use a certain > repo, are far more likely to also read about reporting issues correctly. > Any users that builds KDE from git, those don't result in often misplaced > bug-reports? Or any user who really has no idea what version they are > running, just choose one for a bug report, isn't that more likely to happen > then an educated testers filing an incorrect bug report? The problem here is DrKonqui and the automatic version matching. For someone running master it does not matter. Most products have a version field called "git master" and while DrKonqui is not able to match it, the users normally tell so. Now let's assume we would have the packages out in the wild for 4.11 prior to release. The version information reported by DrKonqui is 4.11.0 - no matter which tarball is currently running. At the same time there's still an RC out (4.10.98). Which means we cannot yet enable the version field 4.11.0 as that could result in incorrect data from bug reporters (we all know our users, it would end up in you have to ask each time whether it's really, really 4.11.0). No 4.11.0 in the versions means that the DrKonqui version matching magic doesn't work and the bug ends up as unspecified, but says in the initial comment 4.11.0. That creates additional work as all bugs reported like that needs to be re-triaged once 4.11.0 is released. Now the problem of re-spin tarballs. Let's assume we have a crash in KWin (driver related) not present in the RC, but in the final tars. We fix it (based on general assumptions on what might have caused the crash - yeah driver bugs for which you don't have the hardware tend to end up like that) and cause the release team to do a respin. But we still get the crash reports. What does it mean now? Issue not fixed? User not yet updated the package? Looking at backtrace doesn't help - if it is driver related they look all different for each distribution. Would a solution like introducing dedicated versions help here: maybe. It would require each developer working with such issues to track the release team mailing list to get the notification of a respin, the new version number and the matching git hash. Tricky and again with lots of work. Also problematic once the final version is created because the version information must be exactly the same otherwise Dr.Konqui magic doesn't work. For me as the product maintainer at the point between last RC and final release it's extremely important to get correct information as if there is a crash introduced after last RC, I would have to run to the release team to call stop. I can understand the need for distros to put out the packages for greater usage early. But from my developer perspective I must say that I would not want bugreports for this intermediate state. I also don't think that it in general would help much to have bug reports for this special stage. It should be only to find showstoppers and for that I doubt our bugzilla is suited at the moment anyway (c.f. the Plasma/Qt/Gentoo issue which went unnoticed on this list). That said: it would be much more help if users would test the betas and RCs more - I think from our perspective that's more help. -- Martin Gräßlin signature.asc Description: This is a digitally signed message part. ___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
Re: Re: Better testing of tagged tars
On Saturday 09 February 2013 23:08:50 Albert Astals Cid wrote: > Of course another option is lifting the requirement for the pre-packages not > being publicly available, after all the packages will most likely be the > real thing, so if everyone agrees it is better lifting this requirement, we > can do it, the fact that *I* personally like it the way it is doesn't mean > it's the better way. With my bugzilla user hat on I'm afraid of that. It would mean we get bug reports for an unreleased version. That's bound to create confusion - we would not be able to trust the version field any more. In case of a re-spin it will get just worse - different tar balls with the same version information. -- Martin Gräßlin signature.asc Description: This is a digitally signed message part. ___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
Re: Re: Re: Re: KDE SC 4.11 Release Schedule
On Sunday 20 January 2013 11:55:00 David Edmundson wrote: > > So I did that - result is attached and it doesn't tell me anything except > > that in the 4.10 cycle significantly less bugs have been created than in > > the other cycles. > > Have you taken into account that the CONFIRMED status changed to NEW, > and should be added together? Doesn't matter for the query I created and the NEW status changed to CONFIRMED. As shown in the description on how the data is gathered, the status is not considered at all. It's just what bugzilla returns, I was actually only interested in the sum of all reported bugs (that's why this row is bold), but included the data, as it was provided. -- Martin Gräßlin signature.asc Description: This is a digitally signed message part. ___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
Re: Re: Re: KDE SC 4.11 Release Schedule
On Saturday 19 January 2013 19:21:27 Martin Gräßlin wrote: > > > I think that the 4.11 cycle was not optimal, but I think it is because > > > it > > > overlapps with Christmas and New Year. > > > > Why was that suboptimal? We've been having that since all the 4.x.odd > > releases > > I have the feeling that we are drifting more and more into February and to > be honest I have never considered the betas/RCs around Christmas to be a > good idea. It's bad for all those devs doing paid KDE development, it's bad > for students (at least in Germany it overlapps with exam time, also in the > US the term ends before Christmas). I will try to play with bugzilla to see > whether there is a difference in number bugs reported in beta phase .odd vs > .even. So I did that - result is attached and it doesn't tell me anything except that in the 4.10 cycle significantly less bugs have been created than in the other cycles. How is the data generated? It uses bugzilla Reports -> Tabular Reports feature. Select "Status" in "Horizontal Axis" dropdown. Unselect everything in the upper area (most important unselect everything in the status list), open the "Search by Change History" area, select "[Bug creation]" in "where ANY of the fields:" and enter the date of the beta 1 release in the from date field and the final tagging date in the to date field. Then click generate report. Do that for each of the release cycles. -- Martin Gräßlin kde-reported-bugs-per-test-cycle.ods Description: application/vnd.oasis.opendocument.spreadsheet signature.asc Description: This is a digitally signed message part. ___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
Re: Re: KDE SC 4.11 Release Schedule
On Saturday 19 January 2013 18:25:20 Albert Astals Cid wrote: > El Divendres, 18 de gener de 2013, a les 19:37:52, Martin Gräßlin va escriure: > > On Tuesday 15 January 2013 23:27:53 Albert Astals Cid wrote: > > > El Dimarts, 15 de gener de 2013, a les 16:30:50, Allen Winter va escriure: > > > > Howdy, > > > > > > > > A proposed KDE SC 4.11 Release schedule is now available at > > > > http://techbase.kde.org/Schedules/KDE4/4.11_Release_Schedule > > > > > > > > (created using toma's really useful releaseschedule program) > > > > > > > > Please review and report back any obvious problems, for example > > > > conflicts with conferences (i.e. Akademy). > > > > > > I'd like to propose some changes for 4.11, i'd like everyone to comment > > > > > > 1) Drop Betas to 1 > > > > > > It doesn't seem "to me" that having extra betas gives us much more > > > quality, > > > > > > so my suggestion is to drop Beta 2 and move Beta 1 to happen in Beta 2 > > > time > > > (moving also Hard Freeze) which gives us 2 more weeks for feature > > > development > > > > > > 2) Drop RCs to 1 > > > > > > Same thing, it did not feel to me as that it gave us much, drop RC2 and > > > RC1 > > > > > > one week into the future > > > > I don't think that the number of Betas and RCs are too much and I think > > that more Betas and more RCs help improving the quality. Reducing the > > number of Betas and RCs means removing the chance to properly test stuff. > > In KWin we had more than once that we pushed a patch to a beta to see if > > it fixes a problem with the option to still revert it in the next beta. > > We need to do that in case of driver related issues which the devs cannot > > reproduce due to lack of hardware. If there are no betas which would > > allow us to do such "experiments" we would not do it as the risk is too > > high, but that also means that a large user group would lack an important > > improvement. We never push such changes in the minor releases as they are > > not tested at all prior to the release. > > I see your point, wouldn't the "less Beta/RC but more weekly 'unofficial' > releases" suggestion help you even more? That depends on whether distributions will package it, release it and users will upgrade to it. From what I see users seem to think that if it has an "RC" flag, it's stable enough to be testable. So I am not sure whether they would pick an "unofficial" release. > > > I think that the 4.11 cycle was not optimal, but I think it is because it > > overlapps with Christmas and New Year. > > Why was that suboptimal? We've been having that since all the 4.x.odd > releases I have the feeling that we are drifting more and more into February and to be honest I have never considered the betas/RCs around Christmas to be a good idea. It's bad for all those devs doing paid KDE development, it's bad for students (at least in Germany it overlapps with exam time, also in the US the term ends before Christmas). I will try to play with bugzilla to see whether there is a difference in number bugs reported in beta phase .odd vs .even. -- Martin Gräßlin signature.asc Description: This is a digitally signed message part. ___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
Re: Re: KDE SC 4.11 Release Schedule
On Saturday 19 January 2013 18:19:03 Albert Astals Cid wrote: > El Divendres, 18 de gener de 2013, a les 18:58:07, Martin Gräßlin va escriure: > > On Tuesday 15 January 2013 23:27:53 Albert Astals Cid wrote: > > > 4) Don't release if any if the tests are failing in builds.kde.org > > > > > > If we have tests, they have to work > > > > I have mixed feelings about that. Personally I agree completely, but I > > fear > > that this will end in less unit tests than in more. If you have unit tests > > and they have been broken for a long time you get punished, > > Right, but why would you have a broken unit test? The only reason i can > think of is that you know your code is broken but don't have time, etc to > fix it yet. If that's the case i'd suggest using QEXPECT_FAIL maybe? my code works :-) I actually had a look into two of the three failing tests and wanted to fix them. But did not understand the foreign code base good enough to investigate it properly. So I don't know whether this is an expected fail (given the commit message which introduced the tests which are failing I doubt it) or not. Those two are at least failing since I started looking at build.kde.org. Probably nobody cares :-( For the third test I informed the maintainer that it started to fail. -- Martin Gräßlin signature.asc Description: This is a digitally signed message part. ___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
Re: Re: KDE SC 4.11 Release Schedule
On Tuesday 15 January 2013 23:27:53 Albert Astals Cid wrote: > El Dimarts, 15 de gener de 2013, a les 16:30:50, Allen Winter va escriure: > > Howdy, > > > > A proposed KDE SC 4.11 Release schedule is now available at > > http://techbase.kde.org/Schedules/KDE4/4.11_Release_Schedule > > > > (created using toma's really useful releaseschedule program) > > > > Please review and report back any obvious problems, for example > > conflicts with conferences (i.e. Akademy). > > I'd like to propose some changes for 4.11, i'd like everyone to comment > > 1) Drop Betas to 1 > It doesn't seem "to me" that having extra betas gives us much more > quality, > so my suggestion is to drop Beta 2 and move Beta 1 to happen in Beta 2 time > (moving also Hard Freeze) which gives us 2 more weeks for feature > development > > 2) Drop RCs to 1 > Same thing, it did not feel to me as that it gave us much, drop RC2 and > RC1 > one week into the future I don't think that the number of Betas and RCs are too much and I think that more Betas and more RCs help improving the quality. Reducing the number of Betas and RCs means removing the chance to properly test stuff. In KWin we had more than once that we pushed a patch to a beta to see if it fixes a problem with the option to still revert it in the next beta. We need to do that in case of driver related issues which the devs cannot reproduce due to lack of hardware. If there are no betas which would allow us to do such "experiments" we would not do it as the risk is too high, but that also means that a large user group would lack an important improvement. We never push such changes in the minor releases as they are not tested at all prior to the release. I think that the 4.11 cycle was not optimal, but I think it is because it overlapps with Christmas and New Year. Reducing the number of betas is therefore fixing the wrong part of the schedule. Cheers Martin signature.asc Description: This is a digitally signed message part. ___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
Re: Re: KDE SC 4.11 Release Schedule
On Tuesday 15 January 2013 23:27:53 Albert Astals Cid wrote: > 4) Don't release if any if the tests are failing in builds.kde.org > If we have tests, they have to work I have mixed feelings about that. Personally I agree completely, but I fear that this will end in less unit tests than in more. If you have unit tests and they have been broken for a long time you get punished, if you don't have tests, your code is accepted without any problems. So it kind of encourages to have bad code (no unit tests). Before we go this way I would suggest to first get a cleanup on the unit tests and enable nag mails when a test starts to break [1]. If we see that this works well, we could go the full thing in 4.12. Also I would like to see some way to encourage more unit testing. Cheers Martin [1] I would love to get those, as I cannot use the build.kde.org build status for kde-workspace due to three tests not in KWin failing all the time signature.asc Description: This is a digitally signed message part. ___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
Re: Re: Another RC?, was: Re: Akonadi-Nepomuk Feeder Improvements
On Sunday 30 December 2012 20:55:22 Scott Kitterman wrote: > On Monday, December 31, 2012 12:24:18 AM Sebastian Kügler wrote: > > On Sunday, December 30, 2012 02:41:43 Scott Kitterman wrote: > > > Assuming 4.10.1 and 4.10.2 slip similarly, that would result in the next > > > Kubuntu release having 4.10.1 instead of 4.10.2. We might also have to > > > make some adjustments to our internal testing milestone schedule. > > > > > > 4.10.2 would come out a day or two before Kubuntu 13.04 (far to late for > > > pre- release updates) so we'd get to release without the current KDE > > > SC. We do ship the point releases as post-release updates, so they > > > would > > > get to users eventually, but post-release QA is a lot more work for us. > > > > > > This isn't precisely a problem, but changing the release cycle now is > > > not > > > idea for us. As long as 4.11 drops back into the usual time slot (and > > > doesn't also slip), then the impact would not be major. > > > > Would adding in two instead of three weeks work for you? > > No. Looking at the schedule, it would need to be only a week later than the > current schedule to make it. If the 4.10.0 -> 4.10.1 and 4.10.1 -> 4.10.2 > intervals were slightly reduced, maybe we could get there? what about Kubuntu uses stable from branch as of freeze day? That would be very close to 4.10.2. Or maybe tag 4.10.2 at the Kubuntu freeze day, but otherwise keep the schedule shifted? > > Scott K > ___ > release-team mailing list > release-team@kde.org > https://mail.kde.org/mailman/listinfo/release-team signature.asc Description: This is a digitally signed message part. ___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
Re: Re: Application version numbers, SC version numbers and FIXED-IN
On Thursday 27 December 2012 23:42:15 Albert Astals Cid wrote: > El Dijous, 27 de desembre de 2012, a les 16:16:55, Allen Winter va escriure: > > On Thursday 27 December 2012 11:57:28 AM Aurélien Gâteau wrote: > > > Hi, > > > > > > Gwenview version number is 2.x.y, where x.y follows KDE SC 4.x.y > > > (meaning > > > KDE SC 4.9.5 ships Gwenview 2.9.5). > > > > > > Until now we have been using Gwenview version numbers for Bugzilla > > > FIXED-IN > > > fields but it has been brought to my attention that doing so means > > > Gwenview > > > fixes do not get listed in the Bugzilla link. > > > > > > We could get rid of the notion of Gwenview version numbers and just use > > > KDE SC version numbers, but I don't think this would work for example > > > for > > > KMail. > > > > For the record, most kdepim apps use the same version number as KDE SC. > > Including KMail2, KOrganizer, Akregator, KAddressbook... > > > > > Is there an established policy for this? > > > > Not to my knowledge. > > > > > Should we use KDE SC version numbers in the FIXED-IN field? > > > > Good question. > > > > The definition of "Version Fixed In" is "A custom Free Text field in this > > installation of KDE Bugtracking System." Therefore, you could put the KDE > > SC version *and* the Gwenview version both. > > The problem with this is that then the bugzilla query we use to create "the > changelog" won't work, e.g > https://bugs.kde.org/buglist.cgi?query_format�vanced&short_desc_type=allwo > rdssubstr&short_desc=&long_desc_type=substring&long_desc=&bug_file_loc_type> > allwordssubstr&bug_file_loc=&keywords_type=allwords&keywords=&bug_status=RES > OLVED&bug_status=VERIFIED&bug_status=CLOSED&emailtype1=substring&email1=&ema > ilassigned_to2=1&emailreporter2=1&emailcc2=1&emailtype2=substring&email2=&bu > gidtype=include&bug_id=&votes=&chfieldfrom 11-06-01&chfieldto=Now&chfield> > cf_versionfixedin&chfieldvalue=4.9.4&cmdtype=doit&order=Bug+Number&field0-0- > 0=noop&type0-0-0=noop&value0-0-0> > > You could argue that this is the fault of the query not being good enough, > and i'd agree, but not sure how we can improve this situation. I don't think that this query could be further improved - maybe with target milestones, but they need to be set manually and would still require an app to use the SC version numbers. Back at Akademy Jeroen showed some MediaWiki magic to automize the changelog. Maybe we could transit to something like that, then the maintainers just need to provide a kind of pattern for their version numbers? Cheers Martin signature.asc Description: This is a digitally signed message part. ___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
Re: Re: Exception for Dolphin - KFileMetadataWidget
On Sunday 23 December 2012 14:24:58 Sebastian Kügler wrote: > Hi Vishesh, > > On Saturday, December 22, 2012 15:26:10 Vishesh Handa wrote: > > On Sat, Dec 22, 2012 at 3:07 PM, Frank Reininghaus > > wrote: If many people thought that the benefits > > of the new widget outweigh the risks, I would say "let's merge it" - I > > don't want to be blamed by future users of KDE 4.10 for holding back > > useful > > things if there is no good reason for it. But at the moment, it seems that > > there are more people who are worried about the risks, so I feel that it > > should > > better wait until KDE 4.11. > > > > From what I have noticed most people just don't respond, and that is taken > > as a sign of acceptance. So one cannot really infer that there are more > > people who are worried about the risks. Just that 2 people who disagree > > have raised their voice. > > > > Is there something I can do to reduce these risks? > > > > From what I see there are 3 use cases - > > > > 1. Using it when Nepomuk enabled > > 2.1. Using it when Nepomuk is disabled > > 2.2. Using it when Nepomuk is enabled but the file has no meta-data > > > > So, the concern of using the widget in unknown ways doesn't really come > > into play. > > > > I hope I'm not being rude. I just really really want to get this widget > > into 4.10. Otherwise I'm going to have to spend 2-3 days (maybe even > > more?) fixing up the old deprecated Nepomuk code and the > > KFileMetadataWidget. I rather focus on other things. > > Understandable, and in principle I agree. The user in me even wants this to > go in, but my experience as release manager says otherwise. We're more than > a month past feature freeze, and we have those freezes for a good reason: > stability, being able to test code and iterate a few times over them. > > Also, we have been bitten by this kind of last minute changes in the past, > repeatedly, and especially by Nepomuk (though not exclusively). > > That's why I'm so hesitant about this change. Ultimately, I'd leave the > decision to Frank, but seeing he's also not convinced, I think we should > just postpone this merge to 4.11, as sour as this might be. Even if my opinion doesn't really matter here, I want to say that I agree with sebas. You basically remove all the chances for user testing as it's too late in the cycle and given how late it is, it is not even tested by kde-developers running master and Christmas and New Year doesn't make it better. Personally I'm extremely careful with any changes after the feature freeze and after RC I would not allow any code to enter which even has the slightest chance for regressions if it would affect the user experience (e.g. the OpenGL compositor). And nepomuk is in that regard similarly important as KWin. If it breaks KDE gets really bad press and disappointed users. Don't risk it. Go with the old code even if it has known issues. Cheers Martin signature.asc Description: This is a digitally signed message part. ___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
Re: Re: okteta binary compatibility
On Thursday 22 November 2012 18:18:33 Friedrich W. H. Kossebau wrote: > Is there an easy way/tool to check ABI changes myself as developer, so > packagers can be saved from the need to report such things upstream? there's the abi-compliance-checker [1] Cheers Martin [1] http://ispras.linuxbase.org/index.php/ABI_compliance_checker signature.asc Description: This is a digitally signed message part. ___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
Re: Feature Freeze and Review Board
Am 19.10.2012 19:35, schrieb Albert Astals Cid: El Divendres, 19 d'octubre de 2012, a les 10:47:30, Martin Gräßlin va escriure: Hi all, I was wondering about the relation of feature freeze and Review Board. Right now we have quite some open review request for e.g. KWin or also Plasma. To me everything what is currently open as a review request is a "planned" feature. Now given our feature freeze policy none of these requests may be merged after the soft freeze if they are not also listed in the planned feature wiki page. This means I have now to tell everyone to edit the wiki if they want to get the feature in. I consider editing MediaWiki tables as a PITA and I consider manual work for something which already is in a computer system as quite stupid and I think the time is better spent on the code then on editing the Wiki document. Therefore I would like to request the following change in our release schedule: "Trunk is frozen for feature commits that are not listed in the planned feature document." to "Trunk is frozen for feature commits that are not listed in the planned feature document or opened as a review request prior to the feature freeze." Opinions? It makes sense *but* having the wiki up to date with all the features is good not only for the feature freeze scenario, it also helps promo, QA, and other people to know what is new and what has to be talked about, tested, etc. fair enough, but what about all those features which happened between July and October and which nobody added, because people only add things to the feature plan to get two more weeks of hacking? Also why enforce to change the wiki document now, when it is not required right *now*. This has nothing to do with my request, but the feature plan we currently have does not list the features we ship. It might be that developers add it after promo asked for the third time that if it's not listed it will not be in the release announcement. Currently from a developer perspective the feature plan is only used to get the two more weeks for hacking which ends up with many, many todo items to just get everything in one might work on and in the end it looks like we have nothing done at all. All I want is to overcome this for at least the things which are already in progress by being on review board. We make here the life of the developers more difficult than it has to be. So personally i'd like that you guys still add the stuff to the feature plan. And when we are at it: could we change "trunk" to whatever is better fitting? Can we just be smart people and accept that "trunk" is just a word and that the rest of the people is smart enough too and understand that for git it means "master"? Because what other word are you suggesting instead of "trunk"? maybe "release branch"? Cheers Martin Cheers, Albert Kind Regards Martin Gräßlin ___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team ___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team ___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
Feature Freeze and Review Board
Hi all, I was wondering about the relation of feature freeze and Review Board. Right now we have quite some open review request for e.g. KWin or also Plasma. To me everything what is currently open as a review request is a "planned" feature. Now given our feature freeze policy none of these requests may be merged after the soft freeze if they are not also listed in the planned feature wiki page. This means I have now to tell everyone to edit the wiki if they want to get the feature in. I consider editing MediaWiki tables as a PITA and I consider manual work for something which already is in a computer system as quite stupid and I think the time is better spent on the code then on editing the Wiki document. Therefore I would like to request the following change in our release schedule: "Trunk is frozen for feature commits that are not listed in the planned feature document." to "Trunk is frozen for feature commits that are not listed in the planned feature document or opened as a review request prior to the feature freeze." Opinions? And when we are at it: could we change "trunk" to whatever is better fitting? Kind Regards Martin Gräßlin ___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
Re: Re: Regression causing Freeze in KWin 4.9.1
On Wednesday 05 September 2012 21:45:59 Albert Astals Cid wrote: > El Dimecres, 5 de setembre de 2012, a les 21:06:55, Martin Graesslin va > > escriure: > > On Tuesday 04 September 2012 22:41:10 Martin Gräßlin wrote: > > > Hi KDE Packagers, > > > > > > unfortunately we have introduced a nasty regression while fixing a bug > > > in > > > KWin for 4.9.1 [1]. With the "wrong" settings and the wrong set of open > > > windows distributed over multiple desktops this can result in a freeze. > > > > > > A freeze in KWin means that the compositor stops, that is the user has > > > no > > > chance to recover from this state unless he knows how to switch to a > > > tty. > > > > > > In case you have not yet pushed out updates for kde-workspace I would > > > kindly ask you to hold them off till we have a working and regression > > > free fix. A patch is already attached to the bug, but I want to give it > > > more time for testing tomorrow. > > > > > > As an alternative you could also revert git commit > > > 567f8cc50082ce5307aa7163fdf3176446a1df5a which introduced the > > > > regression. > > > > > I will keep you informed when the patch has been committed to the > > > branch. > > > > I just pushed the fix to KDE/4.9 branch of kde-workspace repository as > > 8452e6c[1]. > > > > Sorry again for introducing this issue. > > So do we want a 4.9.1a tarball for kde-workspace or we trust packagers will > just pick up the patch? I guess it's less work to put out a new tarball and provide it to the distros than all distros having to download the patch and include it in their package, right? signature.asc Description: This is a digitally signed message part. ___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
Re: Re: Regression causing Freeze in KWin 4.9.1
On Tuesday 04 September 2012 22:53:11 Albert Astals Cid wrote: > El Dimarts, 4 de setembre de 2012, a les 22:41:10, Martin Gräßlin va escriure: > > Hi KDE Packagers, > > > > unfortunately we have introduced a nasty regression while fixing a bug in > > KWin for 4.9.1 [1]. With the "wrong" settings and the wrong set of open > > windows distributed over multiple desktops this can result in a freeze. > > > > A freeze in KWin means that the compositor stops, that is the user has no > > chance to recover from this state unless he knows how to switch to a tty. > > > > In case you have not yet pushed out updates for kde-workspace I would > > kindly ask you to hold them off till we have a working and regression > > free fix. A patch is already attached to the bug, but I want to give it > > more time for testing tomorrow. > > > > As an alternative you could also revert git commit > > 567f8cc50082ce5307aa7163fdf3176446a1df5a which introduced the regression. > > > > I will keep you informed when the patch has been committed to the branch. > > Martin do you want me to add a note to > http://www.kde.org/info/4.9.1.php#bugs ? Yes, that would make sense. signature.asc Description: This is a digitally signed message part. ___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
Regression causing Freeze in KWin 4.9.1
Hi KDE Packagers, unfortunately we have introduced a nasty regression while fixing a bug in KWin for 4.9.1 [1]. With the "wrong" settings and the wrong set of open windows distributed over multiple desktops this can result in a freeze. A freeze in KWin means that the compositor stops, that is the user has no chance to recover from this state unless he knows how to switch to a tty. In case you have not yet pushed out updates for kde-workspace I would kindly ask you to hold them off till we have a working and regression free fix. A patch is already attached to the bug, but I want to give it more time for testing tomorrow. As an alternative you could also revert git commit 567f8cc50082ce5307aa7163fdf3176446a1df5a which introduced the regression. I will keep you informed when the patch has been committed to the branch. Sorry for the inconvenience. Kind Regards Martin Gräßlin [1] https://bugs.kde.org/show_bug.cgi?id06260 signature.asc Description: This is a digitally signed message part. ___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
Re: Re: Killing announcements/changelogs/changelog*.php
On Wednesday 15 August 2012 14:12:53 Albert Astals Cid wrote: > El Dimecres, 15 d'agost de 2012, a les 13:55:59, Martin Gräßlin va escriure: > > Am 15.08.2012 12:44, schrieb Albert Astals Cid: > > > What do you guys think? > > > > clear +1, but maybe use target milestone instead of version fixed in > > (or at least in addition). > > You can't set the milestone in a git/svn commit (AFAIK) so no, let's use > what we told everybody to use, i.e. the FIXED-IN: keyword in commits. this would only need to adjust the hook to update in additon the target milestone. I just checked the docs [1] and target_milestone can be set through the API. The problem is most likely that most bugzilla products do not use the target_milestone so setting it would fail. Which is probably a reason why the kludge with the custom free-text field got introduced. Maybe Jeroen could comment on this and whether it would be possible to easily create the target milestones for all KDE SC products? Best Regards Martin [1] http://www.bugzilla.org/docs/4.2/en/html/api/Bugzilla/WebService/Bug.html#update signature.asc Description: This is a digitally signed message part. ___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
Re: Killing announcements/changelogs/changelog*.php
Am 15.08.2012 12:44, schrieb Albert Astals Cid: What do you guys think? clear +1, but maybe use target milestone instead of version fixed in (or at least in addition). Cheers Martin ___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
Re: Review Request: Manage m_preview->deco pointer around plugin juggling
> On July 25, 2012, 2:30 p.m., Martin Gräßlin wrote: > > I would appreciate if this would go into 4.9.0. > > > > Short summary for the release team: > > * third party decorations (namely QtCurve and keramik) implemented an > > internal and unstable API for window decorations > > * this API is called KDecoration*Unstable* to prevent anyone having the > > awesome idea to implement it > > * we ensured that KWin and Systemsettings do not crash when an incompatible > > deco is found > > * for Systemsettings there was a small bug which might lead to a crash (see > > referenced bug) > > * I would like to not ship with a known crasher > > * I hope I correctly summarized it :-) > > Thomas Lübking wrote: > No worry, i'm back in civilization and will have usable access to my > system in time ;-) > Also, despite what Ben said, 4.9 is not yet frozen - so we *should* still > be permitted to just push?! > > About the crasher fixed here - API safety is not related. Was the > general "make it snappier" commit. > > I introduced it by attempting to stop (long time present) leaking plugins > (and unloading them as well) > Ultimately this (and similar usage) was very likey the source of the GHNS > crashes as well, the preview/plugin link is not robust in this regard. > > Albert Astals Cid wrote: > Yes, 4.9 is still not frozen, freeze starts at 23:59 UTC today (in around > 9 hours) Let me just point out that the freezes are confusing. I re-read the mail before writing it and completely mixed up the date. Can we please work on that for 4.10 and yes I volunteer to write any git hooks to properly freeze the branches (though I would prefer someone competent working on that). - Martin --- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/105721/#review16378 --- On July 25, 2012, 2:30 p.m., Thomas Lübking wrote: > > --- > This is an automatically generated e-mail. To reply, visit: > http://git.reviewboard.kde.org/r/105721/ > --- > > (Updated July 25, 2012, 2:30 p.m.) > > > Review request for kwin, Release Team and Martin Gräßlin. > > > Description > --- > > it is mandatory to manage loadPlugin() and destroyPreviousPlugin() using > disablePreview() > loadPlugin() moves the present factory pointer to "old_fact" which is then > deleted by the succeeding destroyPreviousPlugin() > > I also left a warning into the sources for our heirs ;-) > > > This addresses bug 304026. > http://bugs.kde.org/show_bug.cgi?id=304026 > > > Diffs > - > > kwin/kcmkwin/kwindecoration/decorationmodel.cpp 3d3bb86 > kwin/kcmkwin/kwindecoration/preview.h 20ee869 > kwin/kcmkwin/kwindecoration/preview.cpp fe802c7 > > Diff: http://git.reviewboard.kde.org/r/105721/diff/ > > > Testing > --- > > Yes, quite some. > I'm pretty sure this is it and that a sanitation on recreate is not necessary > for commented reasons. > The actual troublemaker was the BorderSizesRole implementation > > > /me wonders whether we can now also shortcut if (lib->loaded()) - gonna try > that tonight. > > I *may* be not be back in time (but i doubt so), so iff i've not acted on > call until 22:00 CEST just push this and the other one or two reviews in a > row before the freeze on my behalf. Thanks. > > > Thanks, > > Thomas Lübking > > ___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
Re: Review Request: Manage m_preview->deco pointer around plugin juggling
--- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/105721/#review16378 --- Ship it! I would appreciate if this would go into 4.9.0. Short summary for the release team: * third party decorations (namely QtCurve and keramik) implemented an internal and unstable API for window decorations * this API is called KDecoration*Unstable* to prevent anyone having the awesome idea to implement it * we ensured that KWin and Systemsettings do not crash when an incompatible deco is found * for Systemsettings there was a small bug which might lead to a crash (see referenced bug) * I would like to not ship with a known crasher * I hope I correctly summarized it :-) - Martin Gräßlin On July 25, 2012, 2:30 p.m., Thomas Lübking wrote: > > --- > This is an automatically generated e-mail. To reply, visit: > http://git.reviewboard.kde.org/r/105721/ > --- > > (Updated July 25, 2012, 2:30 p.m.) > > > Review request for kwin, Release Team and Martin Gräßlin. > > > Description > --- > > it is mandatory to manage loadPlugin() and destroyPreviousPlugin() using > disablePreview() > loadPlugin() moves the present factory pointer to "old_fact" which is then > deleted by the succeeding destroyPreviousPlugin() > > I also left a warning into the sources for our heirs ;-) > > > This addresses bug 304026. > http://bugs.kde.org/show_bug.cgi?id=304026 > > > Diffs > - > > kwin/kcmkwin/kwindecoration/decorationmodel.cpp 3d3bb86 > kwin/kcmkwin/kwindecoration/preview.h 20ee869 > kwin/kcmkwin/kwindecoration/preview.cpp fe802c7 > > Diff: http://git.reviewboard.kde.org/r/105721/diff/ > > > Testing > --- > > Yes, quite some. > I'm pretty sure this is it and that a sanitation on recreate is not necessary > for commented reasons. > The actual troublemaker was the BorderSizesRole implementation > > > /me wonders whether we can now also shortcut if (lib->loaded()) - gonna try > that tonight. > > I *may* be not be back in time (but i doubt so), so iff i've not acted on > call until 22:00 CEST just push this and the other one or two reviews in a > row before the freeze on my behalf. Thanks. > > > Thanks, > > Thomas Lübking > > ___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
Re: Review Request: Manage m_preview->deco pointer around plugin juggling
--- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/105721/ --- (Updated July 25, 2012, 2:30 p.m.) Review request for kwin, Release Team and Martin Gräßlin. Changes --- adding release team for breaking the tagging freeze Description --- it is mandatory to manage loadPlugin() and destroyPreviousPlugin() using disablePreview() loadPlugin() moves the present factory pointer to "old_fact" which is then deleted by the succeeding destroyPreviousPlugin() I also left a warning into the sources for our heirs ;-) This addresses bug 304026. http://bugs.kde.org/show_bug.cgi?id=304026 Diffs - kwin/kcmkwin/kwindecoration/decorationmodel.cpp 3d3bb86 kwin/kcmkwin/kwindecoration/preview.h 20ee869 kwin/kcmkwin/kwindecoration/preview.cpp fe802c7 Diff: http://git.reviewboard.kde.org/r/105721/diff/ Testing --- Yes, quite some. I'm pretty sure this is it and that a sanitation on recreate is not necessary for commented reasons. The actual troublemaker was the BorderSizesRole implementation /me wonders whether we can now also shortcut if (lib->loaded()) - gonna try that tonight. I *may* be not be back in time (but i doubt so), so iff i've not acted on call until 22:00 CEST just push this and the other one or two reviews in a row before the freeze on my behalf. Thanks. Thanks, Thomas Lübking ___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
Re: Re: Release Team BoF Summary
On Friday 13 July 2012 14:31:35 Aurélien Gâteau wrote:
> To address this we proposed the following numbering scheme:
>
> 4.N.7{1,2,3} => N+1 alpha 1, 2, 3
> 4.N.8{1,2,3} => N+1 beta 1, 2, 3
> 4.N.9{1,2,3} => N+1 rc 1, 2, 3
>
> With this scheme, 4.10 alpha 1 would be 4.9.71, 4.10 beta 2 would be 4.9.82
I like the idea, I had real issues setting up the version numbers in bugzilla
because I failed to understand what the next RC will have as a version number.
With that scheme it's easy to setup and easy to add another beta or rc if
needed.
Cheers
Martin
signature.asc
Description: This is a digitally signed message part.
___
release-team mailing list
release-team@kde.org
https://mail.kde.org/mailman/listinfo/release-team
Re: Re: Re: Release Team BoF Summary
On Friday 13 July 2012 12:37:19 Torgny Nyblom wrote: > On 13.07.2012 08:14, Martin Gräßlin wrote: > > On Thursday 12 July 2012 23:23:39 Albert Astals Cid wrote: > >> El Dijous, 12 de juliol de 2012, a les 17:06:12, Allen Winter va > >> > >> escriure: > >> > On Thursday, July 12, 2012 08:43:12 PM Albert Astals Cid wrote: > >> > > == Note 2 => >> > > There is a suggestion that every feature commit > >> > > should have an > >> > > associated > >> > > bug number so it can be better tracked. Someone suggests trying > >> > >> with > >> > >> > > frameworks when its more ready > >> > > >> > I wonder if we could make special Big Feature "Bugs" on bugzilla > >> > >> and then > >> > >> > create the feature list web page from a query of those "bugs"?? > >> > > >> > Each of these big features would have a milestone release number. > >> > > >> > yes.. I sorta like this idea. > >> > > >> > Thoughts? > >> > >> The idea is cool, problem is always forcing people to follow it :D > > > > random ideas to get devs motivated: > [...] > > > * once soft freeze is in place use git-hook to enforce that commits > > need a bug > > number (either it's a bugfix or it's a feature which needs to be > > listed in > > bugzilla) > > -1 for this last part. As I see it this will only decrease the > motivation for fixing bugs as you find them since you will need to > either find the report in bugzilla or create a new report just to close > it a minute later. Concerning the first point I hope that till we would start with that once our bugtracker is cleaned up, so the developer would a) know what is in there b) has an interest to actually close the bug report as otherwise it would just start to get useless again. Second concern is of course really important as it would look like bureaucracy to a dev. But if a developer finds a bug himself in the freeze state there is something wrong. I hope that till then we have a quality team which finds the issues early. Btw. I create bug reports when I find a bug which I fix myself. So yeah something like this can only be done once the bugtracker is in a useable state and till there I agree on the -1. Cheers Martin Gräßlin signature.asc Description: This is a digitally signed message part. ___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
Re: Re: Release Team BoF Summary
On Thursday 12 July 2012 23:23:39 Albert Astals Cid wrote: > El Dijous, 12 de juliol de 2012, a les 17:06:12, Allen Winter va escriure: > > On Thursday, July 12, 2012 08:43:12 PM Albert Astals Cid wrote: > > > == Note 2 == > > > There is a suggestion that every feature commit should have an > > > associated > > > bug number so it can be better tracked. Someone suggests trying with > > > frameworks when its more ready > > > > I wonder if we could make special Big Feature "Bugs" on bugzilla and then > > create the feature list web page from a query of those "bugs"?? > > > > Each of these big features would have a milestone release number. > > > > yes.. I sorta like this idea. > > > > Thoughts? > > The idea is cool, problem is always forcing people to follow it :D random ideas to get devs motivated: * don't mention features not listed in the release announcments * don't list them in commit-digest * don't include them in quality team checks and make that team rock so that devs see the advantage to have them test their new features * once soft freeze is in place use git-hook to enforce that commits need a bug number (either it's a bugfix or it's a feature which needs to be listed in bugzilla) Some of these could be done already in 4.10, but for e.g. git hooks we should give the devs at least one cycle to adjust to the new way. Cheers Martin signature.asc Description: This is a digitally signed message part. ___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
Re: [RFC] Bugzilla "Feature" Severity
On Thursday 12 July 2012 19:15:10 Allen Winter wrote: > We would do away with the wiki-based feature plans currently on techbase: > replacing with a bugzilla query. > > For example, the query for all wishes planned for 4.10 are: > https://bugs.kde.org/buglist.cgi?bug_severity=wishlist&target_milestone=4.10 > > but I am proposing: > https://bugs.kde.org/buglist.cgi?bug_severity=feature&target_milestone=4.10 > > Comments? +1 would love it, especially the feature plan through bugzilla query. Cheers Martin signature.asc Description: This is a digitally signed message part. ___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
Re: Re: Release Script (KF5)
On Thursday 12 July 2012 13:36:18 Rex Dieter wrote: > On 07/12/2012 01:25 PM, Martin Gräßlin wrote: > > But apart from that: could we start dreaming? Dreaming of a KDE where > > every > > application clearly defines what dependencies it has and exactly in a way > > that packagers can set up the dependencies in an automatic and correct > > way? Can we consider going forward with leaving all hacks behind us and > > not stop the fixing with the hacks being the reasons? > > Yes, please. My dream includes: > > start the work to define this wonderfully well-specified set of > dependencies *first*, *then* consider dropping all the old assumptions > and hacks (not before). I think we are currently in the process of doing just that. Currently no hacks are dropped yet and we plan for the future. What I got from this thread is that we as KDE developers have to define more clearly our dependencies. So in this process of evaluating what we need for the future, the current hacks have to be irrelevant as that will just mean we will never have a bright future in that regard. Of course we have to keep the hacks as a plan B in case plan A (getting it right) does not work out :-) Cheers Martin signature.asc Description: This is a digitally signed message part. ___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
Re: Re: Release Script (KF5)
On Thursday 12 July 2012 13:01:47 Rex Dieter wrote: > On 07/12/2012 12:43 PM, Martin Gräßlin wrote: > >> Now, I'd have a much lesser concern if modules that are part of the 'kde > >> development platform' at least are never skipped. > > > > Could you explain why? > > So, right now I can do a very simple runtime dependency for kde apps: > > KDE_DEV_VERSION=$(kde4-config --kde-version | cut -d' ' -f1) > > Requires: kde-runtime >= $KDE_DEV_VERSION My understanding is that there won't be a kde-runtime once there is frameworks. But apart from that: could we start dreaming? Dreaming of a KDE where every application clearly defines what dependencies it has and exactly in a way that packagers can set up the dependencies in an automatic and correct way? Can we consider going forward with leaving all hacks behind us and not stop the fixing with the hacks being the reasons? For me as a developer it would be much nicer if I could say that my app requires only version 5.x of framework bar and 5.y of framework foobar. And not having a generic dependency set by the packager to 5.z. Would that change your point of view? Would it still be more difficult or in fact easier? Kind Regards Martin Gräßlin signature.asc Description: This is a digitally signed message part. ___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
Re: Re: Re: Release Script (KF5)
On Thursday 12 July 2012 19:43:54 Martin Gräßlin wrote: > So you will have a one-time task to set up the distribution build system to > create these packages. What I do not understand is why having particular > frameworks skip a release would make your work easier. logic error: s/easier/more difficult/g signature.asc Description: This is a digitally signed message part. ___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
Re: Re: Release Script (KF5)
On Thursday 12 July 2012 12:36:05 Rex Dieter wrote: > On 07/12/2012 12:29 PM, Michael Jansen wrote: > > I will implement the ability to skip release for unchanged modules > > (fully automated) and would ask everyone here to really think twice > > before asking the release team to keep the current practice of releasing > > everything. Because there is no reason. > > Not exactly no reason. There's the case that it can be used to simplify > versioning on pkg interdependencies. > > Now, I'd have a much lesser concern if modules that are part of the 'kde > development platform' at least are never skipped. Could you explain why? As far as I understand moving to frameworks 5 will mean for packagers that what used to be one package (kdelibs) will be turned into something like 20 individual packages (I hope no distribution will continue to bundle all frameworks in one package as that would kind of destroy the idea of frameworks). So you will have a one-time task to set up the distribution build system to create these packages. What I do not understand is why having particular frameworks skip a release would make your work easier. I would imagine that you have some script magic going on to automate the package building once a release is done and that script should easily be able to detect that there has not been a new release for a given framework. Yes, No? Kind Regards Martin Gräßlin Who will probably have to maintain a small framework which will perhaps be updated once a years. signature.asc Description: This is a digitally signed message part. ___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
Re: 4.9 SC RC1 tarballs are up
Am 27.06.2012 03:24, schrieb Anke Boersma: Just in case someone else can reproduce, before announcing KDE 4.8.95, build fail for kde-workspace: http://paste.chakra-project.org/2102/ linux 3.4.3 Qt 4.8.2 soprano 2.7.57 akonadi 1.7.90 shared-desktop-ontology 1.10.0 libkgapi 0.4.1 Settings used: -DWITH_OpenGLES=ON \ -DKWIN_BUILD_WITH_OPENGLES=ON I'll have a look at it once I am at home. As far as I remember all my builds on my jenkins are ok. So it has to be related to your build options. Without checking I would say: drop them, not required any more since 4.8. Cheers Martin ___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
Re: Re: Proposed adjustments to our release cycles
On Monday 18 June 2012 19:08:33 Albert Astals Cid wrote: > El Dilluns, 18 de juny de 2012, a les 06:36:33, Martin Gräßlin va escriure: > > On Monday 18 June 2012 00:26:13 Albert Astals Cid wrote: > > > My concerns: > > > * Need more people to do the tarball packaging/releasing (since if you > > > > > > propose to release that often you can't expect the same person to be > > > doing > > > packages almost weekly or byweekly given the release dates won't > > > probably > > > align) > > > > I would say we need proper Jenkins support for that. It must be as simple > > as clicking one button to have the tarball fall out of the CI system and > > already know whether it compiles or not. > > This is cool, i totally support that, just don't see it there, do we have > any volunteer for the work? if nobody takes care about it, I'm happy to help, though I don't see any time for it till August > > > > * Uncertainity on the "current release state". We have people that > > > don't > > > > > > know the current state of the release and commit new features or new > > > strings when we are frozen, and that's with just one release schedule, i > > > can imagine the mess with N different release schedules > > > > "Always summer in trunk". As long as releases are not created from the > > master branch it should be fine. On the other hand nobody should commit > > without a review anyway, so just commit and push without proper > > communication with the core developer group is so wrong in the first place > > That's news to me, I've been commiting for 10 years to KDE cvs/svn/git and > the code i have pre-review is clearly under 5%, if mandatory pre-reviews > are part of the plan, please clearly state so. Let me add that I meant "known code base". I am quite sure that you won't need a review request for Okular (though personally I would advise you nevertheless ;-), but if you want to commit to e.g. kdepim it might be an idea to check with the core development team first. > > > > * The difficulty of coding for N releases. Since the releases an not > > > > > > aligned anymore, you have to maintain code and #ifdefs for new features > > > that depend on new versions of parts X of the stack that may or might > > > not > > > be used by people compiling the application. We've have some bad > > > experiences with "expected versions on the stack" so i hope you're > > > understanding this is not a theoretical scenario. > > > > Also here: proper Jenkins support. CI needs to scream at you if you commit > > something which does not compile. > > Compiling is not enough, let me remind you of the 4.8.4 kdelibs crashes > misteriously if not un against the "proper" soprano problem. True, which shows again how important it is to have unit tests as already pointed out in this thread. (Let's just assume that those problems would have been spotted with a unit test). Cheers Martin signature.asc Description: This is a digitally signed message part. ___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
Re: Re: Proposed adjustments to our release cycles
On Monday 18 June 2012 00:26:13 Albert Astals Cid wrote: > My concerns: > > * Need more people to do the tarball packaging/releasing (since if you > propose to release that often you can't expect the same person to be doing > packages almost weekly or byweekly given the release dates won't probably > align) I would say we need proper Jenkins support for that. It must be as simple as clicking one button to have the tarball fall out of the CI system and already know whether it compiles or not. > > * Uncertainity on the "current release state". We have people that don't > know the current state of the release and commit new features or new > strings when we are frozen, and that's with just one release schedule, i > can imagine the mess with N different release schedules "Always summer in trunk". As long as releases are not created from the master branch it should be fine. On the other hand nobody should commit without a review anyway, so just commit and push without proper communication with the core developer group is so wrong in the first place > > * The difficulty of coding for N releases. Since the releases an not > aligned anymore, you have to maintain code and #ifdefs for new features > that depend on new versions of parts X of the stack that may or might not > be used by people compiling the application. We've have some bad > experiences with "expected versions on the stack" so i hope you're > understanding this is not a theoretical scenario. Also here: proper Jenkins support. CI needs to scream at you if you commit something which does not compile. Cheers Martin signature.asc Description: This is a digitally signed message part. ___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
Re: Re: ALERT: KDElibs (at least) 4.8.4 is actually 4.8.80+
On Sunday 10 June 2012 20:49:51 Wulf C. Krueger wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA1 > > On 10.06.2012 20:33, Albert Astals Cid wrote: > > Feel free to wait until the packages are released publicly. That > > way you'll have packages that work > > [...] > > > There is not a single untested tarball in any semipublic site. > > There are untested tarballs in a private site. > > I think these two answers summarize nicely albeit with a very sad > outcome what QA means to KDE. I'm quite surprised to hear that from a downstream. I think as a downstream you should be aware of the steps currently undertaken by the KDE community to improve the situation. And many of these steps have been discussed also on this mailinglist - e.g. using Jenkins to generate and build the tarballs. I'm quite sure our sysadmins would appreciate help from an experienced downstream developer :-) Given the current efforts on QA, I find your comment not helpful - neither for KDE, nor for you as a downstream. As Albert already pointed out this is a "we" and we should work together and not against each other. Cheers Martin Gräßlin signature.asc Description: This is a digitally signed message part. ___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
Re: Re: Request for delaying 4.8.4 request
Am 04.06.2012 23:57, schrieb Kevin Kofler: On Monday 04 June 2012, Alex Fiestas wrote: Not including this patch will mean not having fstab support until 4.9 (since we won't have 4.8.5). Why aren't we doing .5 releases anymore? Those .5 releases have always been welcome when they were done (which went back and forth). I also don't see a good reason for skipping them: With a monthly release cycle, why leave 2 months between the .4 and .0 releases? I think the .5 releases really need to come back! What do you expect to be in the .5 release? I as a developer already deleted my local KDE/4.8 branch as the release schedule said there won't be any 4.8 release any more. I expect that also other developers are able to read the schedule and do their planning according to it. Even if I had the local branch around, I would probably no longer push any changes to 4.8. From a bugfixing perspective we are concentrating on 4.9 and it becomes more and more difficult to test anything on 4.8, especially once 4.9 is branched. The time spend backporting to 4.8 is quite high compared to the benefits of the bugfix to go into that release. Cheers Martin ___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
Re: Re: Why are 4.8.80 packages already out in the wild?
On Monday 04 June 2012 18:34:40 Friedrich W. H. Kossebau wrote: > This issue is even a bigger problem if your fellow developers compile your > code from scratch and then file a bug by version "Compiled from sources". > Should happen much more often, no? :) quite the opposite. Most users who actually compile from source give either directly the shasum of the git commit or the date when they pulled. Personally those are my most favorite bug reporters as they are most capable of providing useful information and we know that they can compile code and could test a patch :-) Cheers Martin signature.asc Description: This is a digitally signed message part. ___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
Re: Re: Why are 4.8.80 packages already out in the wild?
On Monday 04 June 2012 15:18:11 Kevin Kofler wrote: > On Monday 04 June 2012, Sebastian Kügler wrote: > > That means that people report bugs against different incarnations of the > > same packages, which makes bugs hard to find -- it doesn't work as we > > can't verify the exact state of the code a bug is filed against. > > That almost never makes a difference in practice, and when it does, the > developers are (or should be) aware of the respin and ask to make sure. (If > the reporter is the packager, he/she'll definitely know whether the package > already uses a respun tarball, if not, he/she can provide the exact version > of the distro package and the distro packager can tell you what tarball was > used. And in any case, we always issue a new build with the respun tarball > as soon as possible.) I must admit that I find your answer strange. Given that the whole thread had been started by a developer because he sees a problem in exactly that thing, it's quite strange that I get told that there is no problem at all. Please note that working as a developer is quite different to working as a distro packager. Yes your distro packages have very precise versions, yes our versions, too - once they are released. And that's the difference to the distro packages, before the release it is not known what the version is. (Btw. shipping patches upstream does not know about is as bad - even in development versions nobody should use). Now what appears to be no problem is a problem. It is causing work for developers when the version information is wrong. It is causing work if we have to ask again for the version information. Furthermore it is not said that a developer knows about a respin tarball. Please note that unlike you, I as a developer have no access to the tarball before release and the developers don't get a mail in their inbox telling them that the tarball has been recreated. Developers have to actively monitor the release team mailinglist and I'm quite sure that not everybody is subsribed to this list. The whole thing becomes even more complex if we consider the perfect case of bug triaging. How should a triager know that the developers fixed a bug which caused a respin of the package? I hope you understand that what you describe as a non-issue, is issue enough that I started the thread. So yeah either I have no clue about what I do, or maybe, maybe it is an issue in fact. Cheers Martin signature.asc Description: This is a digitally signed message part. ___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
Re: Re: Why are 4.8.80 packages already out in the wild?
On Monday 04 June 2012 10:52:13 you wrote: > On Sunday, June 03, 2012 20:46:56 Martin Gräßlin wrote: > > I don't want to blame anyone (that's why I did not name the distros). > > Well, it's a specific distro pushing out packages too early to its users > (and in this case, a group that doesn't understand that these are not > 4.8.80 packages until we announce them). > > Which distro did you experience this with? I can talk to them to be a bit > more patient. For the record the distro information is in the linked bug reports. The two bugs reported were one by Arch and one by Fedora. Cheers Martin signature.asc Description: This is a digitally signed message part. ___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
Re: Re: Why are 4.8.80 packages already out in the wild?
On Monday 04 June 2012 01:26:01 Kevin Kofler wrote: > On Monday 04 June 2012, Albert Astals Cid wrote: > > It's not about hurting or not (that it does, see how Martin got confused > > and probably lost time wondering how something like that could be > > happening). > > Oh, and what Martin actually got confused by is a failure of processes on > the KDE end: The Bugzilla entry for the new (pre)release should be created > no later than the first "try" of tarballs. How else are we, the packagers, > supposed to report bugs we find in the tarballs, if they're not of release- > blocking importance? When you create the tarballs, the component should > already be in place. No, sorry, that doesn't make any sense. Why? * the number of bugs reported by distro people compared to users is extremely low (less than 1 %) * I cannot remember a bug reported by distro people between tagging and releasing * for me it is important to be able to reference a git hash with a release. The git tags are only pushed *after* the release. In the state between tagging and release I am normally not aware what has been tagged, with the exception of 4.8.80 thanks to Albert publishing the shasums on the mailing list So no, also in future I will create the version tag in bugzilla once there is a release and not when the release process got started. Cheers Martin signature.asc Description: This is a digitally signed message part. ___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
Re: Re: Why are 4.8.80 packages already out in the wild?
On Sunday 03 June 2012 20:34:55 Andrea Scarpino wrote: > Well...In Arch I released the packages some hour before Tom's thread about > calling off beta1. You guys decided to delay it only, so I kept the > packages in the unstable repo to let our devs test them, but I didn't > announce them. > I guess the "Install KDE 4.9" wiki page on techbase did the rest. > > Anyway, if you want to blame someone I guess you should blame users not us. I don't want to blame anyone (that's why I did not name the distros). I want to know what we can do that versions which should not go to the users end up on the users's system. And somehow I think it's also in the interest of the distributions to ensure that packages which should not be used do not get installed. Just imagine Albert would have called off the release due to severe data loss issues... If mistakes happen, we have to identify them and ensure that they don't happen in future :-) Cheers Martin signature.asc Description: This is a digitally signed message part. ___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
