Re: Observations and personal conclusions on the KDE release process since 4.0
Hello, On 06/29/2010 09:52 PM, Wulf C. Krueger wrote: Having been a KDE packager for several years now, I've looked at the releases of KDE since 4.0.0. I felt that the overall KDE release quality has become noticeably worse than it was during the 3.x days (during which I was most active). Thanks for the input, and the summary. After the 4.4 release cycle which don't go so great, we tightened up the freeze schedule somewhat with regard to no-commits before tagging, clearer dependency freezes and better communication when changes to header files are done (i.e. mail kde-bindings@). So far my impression is that the release cycle which we are in right now has been running much smoother than in the past. I'm saying that with my bindings hat on. From my point of view there have been less last minute surprises. The main issues for this cycle, IMHO, have been: * unclear dependency requirements - i.e. exactly which versions of things are required by KDE. This info doesn't seem to be collected in one place. The problem is actually getting worse since KDE has more dependencies than in the past, and because components/subprojects have been migrating out of svn to git elsewhere. * branches - Things being branched off earlier than expected, or work branches being merged later in the process make it harder to keep track of what exactly is going to be in 4.5. I guess there is still work to do. cheers, -- Simon Edwards | KDE-NL, Guidance tools, Guarddog Firewall si...@simonzone.com | http://www.simonzone.com/software/ Nijmegen, The Netherlands | ZooTV? You made the right choice. ___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
Re: KDE SC 4.5 schedule
Morning all, Aaron J. Seigo wrote: Simon (and other bindings people): would that be enough time for you folks? I was think last night along the same lines as what just Toma said. CCMAIL, and tactical committing (i.e. not changing an API just before a tag/milestone, but at the start of a new phase) would probably go a long way to smoothing things out. We should try this. cheers, -- Simon Edwards | KDE-NL, Guidance tools, Guarddog Firewall si...@simonzone.com | http://www.simonzone.com/software/ Nijmegen, The Netherlands | ZooTV? You made the right choice. ___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
Re: KDE 4.4.2 tarballs (try #1) uploaded
Hello, Eric Hameleers wrote: On Fri, 26 Mar 2010, Dirk Mueller wrote: I just finished uploading the first set of KDE 4.4.2 tarballs. Please let me know of any issues that you might experience. Intended release date is next week Tuesday/Wednesday (I'm sorry that I'm a day late with tagging). The kdebindings tarball fails to build with this error: [ 91%] Building CXX object python/pykde4/CMakeFiles/python_module_PyKDE4_kutils.dir/sip/kutils/sipkutilspart7.o Linking CXX shared library ../../lib/pykde/kutils.so [ 91%] Built target python_module_PyKDE4_kutils [ 91%] Generating sip/nepomuk/sipnepomukpart0.cpp, sip/nepomuk/sipnepomukpart1.cpp, sip/nepomuk/sipnepomukpart2.cpp, sip/nepomuk/sipnepomukpart3.cpp, sip/nepomuk/sipnepomukpart4.cpp, sip/nepomuk/sipnepomukpart5.cpp, sip/nepomuk/sipnepomukpart6.cpp, sip/nepomuk/sipnepomukpart7.cpp sip: QDebug is undefined make[2]: *** [python/pykde4/sip/nepomuk/sipnepomukpart0.cpp] Error 1 make[1]: *** [python/pykde4/CMakeFiles/python_module_PyKDE4_nepomuk.dir/all] Error 2 make: *** [all] Error 2 I am building against sip 4.10.1 and kde-qt 4.6.2-patched I'm not seeing this error on my 4.4 svn branch build. Can you tell me which version of Python PyQt you are using? Is anyone else seeing this problem? cheers, -- Simon Edwards | KDE-NL, Guidance tools, Guarddog Firewall si...@simonzone.com | http://www.simonzone.com/software/ Nijmegen, The Netherlands | ZooTV? You made the right choice. ___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
Re: KDE 4.4 RC1 (4.3.90) tarballs uploaded
Hello, Dirk Mueller wrote: On Thursday 07 January 2010, Simon Edwards wrote: [python/pykde4/CMakeFiles/python_module_PyKDE4_plasma.dir/all] Error 2 make: *** [all] Error 2 It should work fine with a recent SIP and PyQt snapshot. A new stable release of PyQt is imminent, then can I up the version check in CMakeLists.txt. Sorry for the inconvenience guys. Is it possible to make the bindings only use released versions of sip/pyqt? A new SIP and PyQt stable are out and PyKDE now requires it and checks for it in CMakeLists. Although annoying, not using SIP/PyQt snapshots during the 4.4 dev cycle would have required dropping most of the new changes to Plasma which depend on new functionality in Qt 4.6. This is really one of the risks of KDE requiring a bleeding edge Qt functionality (4.6) which wasn't released until quite late in the KDE dev cycle. Other things like PyQt depend on Qt and don't get much time to react and be updated once a new Qt version is out. with RC2, there is a new problem: /usr/bin/cmake -E cmake_progress_report kdebindings-1077263/build/CMakeFiles What is the solution here? You'll have to ask Richard Dale since this error is in smoke and not PyKDE. A strict ban on header file changes during the RC phase would be a good way to help reduce these kinds of last minute problems. Even in these late stages the plasma team are still stuffing around with their (new) APIs. cheers, -- Simon Edwards | KDE-NL, Guidance tools, Guarddog Firewall si...@simonzone.com | http://www.simonzone.com/software/ Nijmegen, The Netherlands | ZooTV? You made the right choice. ___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
Re: KDE 4.4 RC1 (4.3.90) tarballs uploaded
Hello, Rex Dieter wrote: Simon Edwards wrote: Hi, kdebindings fails to build here: A new stable release of PyQt is imminent, then can I up the version check in CMakeLists.txt. Sorry for the inconvenience guys. As I just commented in kde-bindings, the newer sip release appears to be binary incompatible (ie, 4.9.x had SIP_API_MAJOR 6, and 4.10 has SIP_API_MAJOR 7), so requires a rebuild of all things using sip. :( (unless I'm missing something). Yes that is true. The SIP binary API changes quite often, and requires that PyQt PyKDE be recompiled against the new version. cheers, -- Simon Edwards | KDE-NL, Guidance tools, Guarddog Firewall si...@simonzone.com | http://www.simonzone.com/software/ Nijmegen, The Netherlands | ZooTV? You made the right choice. ___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
Versions of dependencies for coming releases (Re: phonon version required for bindings?)
[just bringing this topic out of private mail and onto the release team list.] Dirk Müller wrote: On Monday 01 June 2009, Simon Edwards wrote: Sure, no problem. I find the versioning of things in kdesupport -- which are needed to build KDE from SVN -- to be very unclear when it comes to approaching releases. During most of the dev cycle kdesupport is needed and works fine until around the end when all sorts of different versions of things from all over the KDE SVN repository are selected as being THE version. Where is this stuff documented? Google can't seem to find it. This is currently not really documented. for release branches we have tags/kdesupport-for-4.1/2 which contains the recommended versions. for /trunk this is currently in flux, so it depends on Matthias what the plans are. This is a problem for me at least and maybe others. The Python bindings includes bindings for a number of things from kdesupport such as phonon, akonadi and soprano. To get ready for release I need to know which branch/tag of these libraries will be the minimum requirement for the coming KDE release. IMHO, by soft freeze it should be pretty clear which versions/branches are in going to be in good enough shape to be a requirement for the next KDE release. The decision just needs to be made an documented on techbase. Can we have this stuff settled by soft freeze in the future? cheers, -- Simon Edwards | KDE-NL, Guidance tools, Guarddog Firewall si...@simonzone.com | http://www.simonzone.com/software/ Nijmegen, The Netherlands | ZooTV? You made the right choice. ___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
Re: [Kde-bindings] Status of the kdebindings module?
Richard Dale wrote: On Wednesday 09 July 2008 11:47:00 Simon Edwards wrote: Hello all, What is the status of the kdebindings modules? Do you guys know of any issues which are blocking for the 4.1 RC1 release? The release team wants to know. Time to speak up! I don't have any pykde4 blockers for RC1. (But I do have something which I want to fix before the 4.1 release proper.) The most serious bug I can think of in the Ruby and C# bindings is that you can't include slot/signal types outside the types that are in the qt smoke module. So that means the dataUpdated() slots in plasma apps crash. Also the marshaller for the Plasma Plasma::DataEngine::Data type hasn't been tested yet, and it may need fixing if it has any bugs. These things will certainly be fixed this weekend at the bindings meeting. Perhaps the most important thing is that the C# and Ruby bindings build ok, and as far as I know they do. Ok, I take that as meaning that there is no reason for the kdebindings modules not to be in RC1. @release-team, if the bindings don't build or whatever in RC1 then the issue should be taken up on the kde-bindings list ASAP. cheers, -- Simon Edwards | KDE-NL, Guidance tools, Guarddog Firewall [EMAIL PROTECTED] | http://www.simonzone.com/software/ Nijmegen, The Netherlands | ZooTV? You made the right choice. ___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
Re: Request for breaking hard feature freeze for an important Plasma feature ; )
Peter Penz wrote: On Tuesday, 1. July 2008 00:26:46 Aaron J. Seigo wrote: [...] it's really basic code without any real trickinesses to it and would help with the plasmalash. i'm ok with waiting for 4.2, but i'm not sure our users are. =P I'm sure most users see this as bug. +1 from my side for fixing this bug :-) Seriosly: Plasma is in really good shape in 4.1, but I fear this minor thing might open the door for (yet another) plasma bashing if it won't be fixed... I agree. If this feature is missing it likely to be experienced as a (biggish) bug by users. Provided there is low chance of this feature impacting stability or causing breakage etc etc, I would say that not having this feature is worse than having it but there being a few bugs left in it. I say put it in, and we'll take any bug risks. (It sounds pretty safe according to Aaron anyway). cheers, -- Simon Edwards | KDE-NL, Guidance tools, Guarddog Firewall [EMAIL PROTECTED] | http://www.simonzone.com/software/ Nijmegen, The Netherlands | ZooTV? You made the right choice. ___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
Re: Fwd: KDE/kdelibs/kdecore/config
David Faure wrote: On Wednesday 24 October 2007, Simon Edwards wrote: Dirk Mueller wrote: Hi, just the stuff that I want to see on the freaking deep freeze day! I guess I should go unbreak PyKDE again. dfaure also got me in KXMLGUIBuilder. I thought these kinds of changes were being announced in advance... I mailed kde-core-devel about it. Ok, I see it now. thanks. Maybe a [BIC] subject prefix is a good idea in the future. It makes it a bit easier to spot in between all of the other stuff being discussed. cheers, -- Simon Edwards | KDE-NL, Guidance tools, Guarddog Firewall [EMAIL PROTECTED] | http://www.simonzone.com/software/ Nijmegen, The Netherlands | ZooTV? You made the right choice. ___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
Re: Questions About the New Schedule
Hello all, Sebastian Kügler wrote: On Monday 01 October 2007 10:37:06 Andreas Pakulat wrote: On 01.10.07 06:30:25, Dirk Mueller wrote: On Saturday, 8. September 2007, Albert Astals Cid wrote: 5) Should language bindings be part of the development platform? Richard Dale says Python and Ruby in good shape by late October, and possibly C# too. If Richard says he can do it, i say we can try it :-) Thats not enough. somebody has at least to be able to confirm that the bindings *compile*. right now, kdebindings does not compile, and after I spent an hour or so looking, I'm sure that it can not compile for anyone at all, given the fundamental bugs in the build system. it is my understanding that Richard uses a completely different build system to maintain the bindings, at least thats what he used to do in KDE3 times. There has to be at least somebody who maintains the official build system, and that person has to be != me. Same thing applies to the python bindings, but those are not buildable with cmake and I don't see why they should be. I understand that Simon Edwards is working on making them compile with cmake. Simon, can you give us an update about the python bindings? How stable are they? I don't remember telling anyone other than Jim Bublitz that I was looking at using cmake to build the bindings. But as a matter of fact, yes, yes I have been working on that for the last few days. 8-) (Am I that predictable?) Until that is in order, the configure.py script works ok. configure.py doesn't really handle installing things other than the binding themselves (e.g. example code, docs etc). Which is why I hope to be able to switch to cmake sometime as that will make it easier for other people to build and install it all, and I'll be able to recycle the cmake code which is already used in KDE. As far as the bindings themselves are concerned, the kdelibs stuff is in good shape except for one omission, Phonon. It is tricky module to wrap and Jim has been working on it, although we might require additions and fixes to SIP (bindings generator, produced and maintained by Phil Thompson at Riverbank computing). Jim is still quite confident to still have Phonon in KDE 4.0. The other modules in kdelibs are definitely complete enough and stable enough for people to develop on. Other things like docs, example code, test code, and other things which you would expect in a SDK, are still being developed and worked on. We expect to have it in order by 4.0. This might appear to be a lot of development late in the KDE 4 process, but it is unavoidable. We needed a relatively stable and workable kdelibs before the real bindings work could even start. That said, the bindings themselves are very solid. The tools which we are using and building on, SIP and PyQt, have been in production for at least 18 months now. On a technical level, what can I provide in the build system for the Python bindings which would simply the tarballing stage of release work? (directory layout? a special build target make dist??) cheers, -- Simon Edwards | KDE-NL, Guidance tools, Guarddog Firewall [EMAIL PROTECTED] | http://www.simonzone.com/software/ Nijmegen, The Netherlands | ZooTV? You made the right choice. ___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
