Re: Release Script
Hi, On Thu, Jun 21, 2012 at 7:58 PM, Michael Jansen i...@michael-jansen.bizwrote: ** On Wednesday, June 20, 2012 11:56:51 PM Andreas Pakulat wrote: Hi, On Wed, Jun 20, 2012 at 9:30 PM, Michael Jansen i...@michael-jansen.biz wrote: 2. Make the necessary build-system changes to use this version information for the .SO names. IMHO this is wrong, the numbers tagged to the end of a shared-object thats used as a shared library really have nothing to do with the release version number. The number is only used to distinguish compatibility of different release of the same library. I do not disagree. But this is how it is currently done unless i am mistaken. Which is certainly possible. So unless someone comes up with a better solution or explains why and how i am wrong i will keep that because i am pretty sure requiring people to manually update the soname for each release is a recipe to disaster and a way to annoy our packagers. But if you have a solution or idea for that? Keep it coming. We could define the soversion too in that configuration file. But how and when to increase? On each major and minor release increase it automatically too? Btw. kdelibs/cmake/modules/KDE4Defaults.cmake:22 ++ And you cannot really go back to 4.2.0 now that 4.9.0 is going to be released. The only option would be to move forward to 5.2.0. So still no exact match between release-version and soname. I don't want to go back. kdepim4.x will always use the kdelibs versions for its soname and not its own version. Unless we rerelease it i can't and don't want to change that. So the sonames we are talking of are 4.1x or 5.0 depending on the versions we put the changes live. Hmm, I may have to retract here, it seems my mail was led by false assumptions based on the shared libs I have here. So, I now think that generating the second and third digit of the version from a file automatically, so it matches the minor and bugfix version of the project that the shared library belongs to is just fine. As far as I can see from http://tldp.org/HOWTO/Program-Library-HOWTO/shared-libraries.html the soversion and the first digit of the three-digit version number need to match. Since you don't want to update the soversion automatically as it has far-reaching consequences to do that, that part should not be auto-generated for the VERSION property. So read out minor and bugfix version and append that to the SOVERSION property to create a value for VERSION in cmake. Andreas ___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
Re: Release Script
Hi, On Thu, Jun 21, 2012 at 8:57 PM, Michael Jansen i...@michael-jansen.bizwrote: ** On Thursday, June 21, 2012 08:44:09 PM Andreas Pakulat wrote: Hi, On Thu, Jun 21, 2012 at 7:58 PM, Michael Jansen i...@michael-jansen.biz wrote: ** On Wednesday, June 20, 2012 11:56:51 PM Andreas Pakulat wrote: Hi, On Wed, Jun 20, 2012 at 9:30 PM, Michael Jansen i...@michael-jansen.biz wrote: 2. Make the necessary build-system changes to use this version information for the .SO names. IMHO this is wrong, the numbers tagged to the end of a shared-object thats used as a shared library really have nothing to do with the release version number. The number is only used to distinguish compatibility of different release of the same library. I do not disagree. But this is how it is currently done unless i am mistaken. Which is certainly possible. So unless someone comes up with a better solution or explains why and how i am wrong i will keep that because i am pretty sure requiring people to manually update the soname for each release is a recipe to disaster and a way to annoy our packagers. But if you have a solution or idea for that? Keep it coming. We could define the soversion too in that configuration file. But how and when to increase? On each major and minor release increase it automatically too? Btw. kdelibs/cmake/modules/KDE4Defaults.cmake:22 ++ And you cannot really go back to 4.2.0 now that 4.9.0 is going to be released. The only option would be to move forward to 5.2.0. So still no exact match between release-version and soname. I don't want to go back. kdepim4.x will always use the kdelibs versions for its soname and not its own version. Unless we rerelease it i can't and don't want to change that. So the sonames we are talking of are 4.1x or 5.0 depending on the versions we put the changes live. Hmm, I may have to retract here, it seems my mail was led by false assumptions based on the shared libs I have here. So, I now think that generating the second and third digit of the version from a file automatically, so it matches the minor and bugfix version of the project that the shared library belongs to is just fine. As far as I can see from http://tldp.org/HOWTO/Program-Library-HOWTO/shared-libraries.html the soversion and the first digit of the three-digit version number need to match. Since you don't want to update the soversion automatically as it has far-reaching consequences to do that, that part should not be auto-generated for the VERSION property. So read out minor and bugfix version and append that to the SOVERSION property to create a value for VERSION in cmake. And i am a bit confused too. As svuorela pointed out: objdump -x /kde4/kde/lib64/libkdepim-copy.so.4.8.0 | grep SONAME SONAME libkdepim-copy.so.4 The tldp link I included has a rather easy to understand explanation close to the top about this. lrwxrwxrwx 1 mjansen users 19 May 23 19:31 /kde4/kde/lib64/libkdepim-copy.so - libkdepim-copy.so.4 lrwxrwxrwx 1 mjansen users 23 May 23 19:31 /kde4/kde/lib64/libkdepim-copy.so.4 - libkdepim-copy.so.4.8.0 -rwxr-xr-x 1 mjansen users 883382 Jun 16 22:32 /kde4/kde/lib64/libkdepim-copy.so.4.8.0 So i am not so sure about that stuff anymore. Or better i wasn't to start with. As I said, right now most libs are at BC-version 4 (some kdelibs libs like kdecore are already at BC version 5) and so far the minor version and a .0 was simply added to get the 'realname' (as tldp puts it). Anyway i don't want to change anything there. I just wanted to point out that reusing the number from kde4defaults.cmake should not be done for our packages. Each package should have each needed version information itself. Because only that makes it possible to skip releases and release independently. Yes, if releasing projects indepentenly from one another is the goal, then each needs to maintain its own SOVERSION and VERSION. FWIW some projects already do this, kdevplatform for example is at SOVERSION 6 now in master and kdegames also had two BC breakages since 2.0 I believe so it should also be at 6 (didn't actually check and am not 100% sure). Andreas ___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
Re: Release Script
Hi, On Wed, Jun 20, 2012 at 9:30 PM, Michael Jansen i...@michael-jansen.bizwrote: 2. Make the necessary build-system changes to use this version information for the .SO names. IMHO this is wrong, the numbers tagged to the end of a shared-object thats used as a shared library really have nothing to do with the release version number. The number is only used to distinguish compatibility of different release of the same library. And you cannot really go back to 4.2.0 now that 4.9.0 is going to be released. The only option would be to move forward to 5.2.0. So still no exact match between release-version and soname. Andreas ___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
Re: kde-runtime does not finds kactivites
Hi, On Sun, Jun 10, 2012 at 1:05 AM, Manuel Tortosa manutort...@gmail.comwrote: ** El Diumenge, 10 de juny de 2012, a les 00:52:28, Andreas Pakulat va escriure: Ok, great, then please let the kactivities team know about this. The release-team cannot really do anything about it (other than trying to reach the kactivities team). Basically the same goes to all the rest of your mails, if things don't build, the first person to speak to is the corresponding development team/maintainer so such problems get fixed asap. Actually as been fixed already by Allen in git. I don't know what do you have against sending mails for warning about the issues i am finding on compiling the tarballs, i just try to be constructive helping to fix a release before actually making the tarballs public and preventing some bigger problems. I don't have a problem with reporting broken tarballs or the fact that there are build-problems to the release-team. But I think the way you're doing it right now is not very efficient for the release-team, its harder to keep track of the overall state when the information is spead across multiple mail threads. If this is the release-team mailing list the release team should be updated about the problems about the upcomming release, really i don't understand you at all. I think it would be more efficient to send the build-problems to the corresponding module-dev-lists immediately and assemble a list of things over the time of a day or two and send the assembled list to the release-team. I think that would make it easier to follow up on the states once they're fixed. Feel free to create a filter in your mail program to ignore my messages, you are a kde coder, i am a kde translator, we both are part of kde and we both should ensure the quiality of the release. Not much of a coder these days unfortunately :) Sorry, didn't want to stop your efforts or diminish them, I'll be a bit clearer next time I raise concerns. Andreas ___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
Re: kde-runtime does not finds kactivites
Hi, On Sat, Jun 9, 2012 at 4:11 PM, Manuel Tortosa manutort...@gmail.comwrote: Another issue in the beta2 tarballs, after compiling and installing kactivities, kde-runtime does not finds it: Martin Graesslin recently had a nice blog post about some basic information that needs to be provided when reporting any kind of problem. Your post lacks all information, with this not even an educated guess is possible. For a start, a trace-run output from cmake would be useful. In addition provide where KActivities is installed to, i.e. where do you expect it to find, is it fully, properly installed - in particular is cmake's config file (I assume kactivities installs one) present and if so where exactly? That should hopefully give us a clue why it doesn't find KActivities. Andreas ___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
Re: Shared Desktop Ontologies
Hi, On Sat, Jun 9, 2012 at 3:56 PM, Manuel Tortosa manutort...@gmail.comwrote: Again about SDO The akonadi-nepomuk feeder needs some commits from a SDO not yet released, there is a 0.9.5 tagged and also a 0.9.51 but nothing packaged and even more the needed commits are after the 0.9.51 tagging So, theorically somebody should tag a newer version and release the package for SDO before kde 49 or will not work correctly. I am not an expert so probably somebody more involved in nepomuk can confirm the issue I'd suggest to contact the SDO maintainer (probably Sebastian Trueg) about this, SDO is not part of KDE SC and not released by our release-team. Andreas ___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
Re: kde-runtime does not finds kactivites
Hi, On Sat, Jun 9, 2012 at 7:50 PM, Manuel Tortosa manutort...@gmail.comwrote: ** El Dissabte, 9 de juny de 2012, a les 19:31:51, Andreas Pakulat va escriure: Martin Graesslin recently had a nice blog post about some basic information that needs to be provided when reporting any kind of problem. Your post lacks all information, with this not even an educated guess is possible. For a start, a trace-run output from cmake would be useful. In addition provide where KActivities is installed to, i.e. where do you expect it to find, is it fully, properly installed - in particular is cmake's config file (I assume kactivities installs one) present and if so where exactly? That should hopefully give us a clue why it doesn't find KActivities. Ok sorry, will try to be a bit more specific: KActivitiesConfig.cmake does not set KACTIVITIES_FOUND and that's why the message about not finding KActiviities is shown when compiling kde-runtime. Ok, great, then please let the kactivities team know about this. The release-team cannot really do anything about it (other than trying to reach the kactivities team). Basically the same goes to all the rest of your mails, if things don't build, the first person to speak to is the corresponding development team/maintainer so such problems get fixed asap. Andreas ___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
Re: KDE 4.8 RC1 (4.7.95) tarballs uploaded (try#1)
On 23.12.11 02:54:00, Kevin Kofler wrote: 2. The released version of KDevelop doesn't build against the new okteta headers. Not sure whether that's intentional, but it breaks things in any case. If the incompatibility is intentional, we need an updated KDevelop. Yes, okteta changed its API and the released KDevelop does not build against that. KDevelop master does build against current okteta afaik (didn't try myself). I don't quite see what that has to do with KDE 4.8, KDevelop is not released as part of the SC and has its own schedule. There's a new KDevelop release planned in the not-too-distant future, but no fixed dates yet (its in feature freeze now though). If everything went correctly with the okteta libs then they should have update SONAMES and hence should be co-installable with the old versions keeping both the released kdevelop and new okteta running. Andreas ___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
Re: KDE 4.8 RC1 (4.7.95) tarballs uploaded (try#1)
On 23.12.11 10:55:42, Sebastian Kügler wrote: On Friday, December 23, 2011 02:54:00 Kevin Kofler wrote: 2. The released version of KDevelop doesn't build against the new okteta headers. Not sure whether that's intentional, but it breaks things in any case. If the incompatibility is intentional, we need an updated KDevelop. Please make sure Okteta and KDevelop authors know about this. They are, in fact Friedrich already fixed. And differently than I said before, its also in the 4.2 branch. So distro's can easily pull the patch: http://barney.cs.uni-potsdam.de/pipermail/kdevelop-devel/2011-December/041913.html There's not going to be another 4.2.x release afaik. Andreas ___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
Re: KDE 4.8 RC1 (4.7.95) tarballs uploaded (try#1)
On 23.12.11 10:49:11, Andreas Pakulat wrote: On 23.12.11 02:54:00, Kevin Kofler wrote: 2. The released version of KDevelop doesn't build against the new okteta headers. Not sure whether that's intentional, but it breaks things in any case. If the incompatibility is intentional, we need an updated KDevelop. Yes, okteta changed its API and the released KDevelop does not build against that. KDevelop master does build against current okteta afaik (didn't try myself). I don't quite see what that has to do with KDE 4.8, KDevelop is not released as part of the SC and has its own schedule. There's a new KDevelop release planned in the not-too-distant future, but no fixed dates yet (its in feature freeze now though). Need to correct myself: The 4.2 branch of KDevelop was also changed by Friedrich, so distributions can take the patch from the branch: http://barney.cs.uni-potsdam.de/pipermail/kdevelop-devel/2011-December/041913.html AFAIK there's not going to be another 4.2.x release of KDevelop, the developers concentrate on 4.3 already. Andreas ___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
Re: KDE 4.7.2 (try#1) uploaded
On 10.10.11 00:33:17, Jonathan Callen wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA512 On 10/08/2011 06:21 PM, Andreas Pakulat wrote: On 08.10.11 15:24:57, Nicolas Alvarez wrote: Andreas Pakulat wrote: On 08.10.11 01:10:50, Nicolas Alvarez wrote: Andras Mantia wrote: On Sunday, October 02, 2011 17:04:42 Dirk Mueller wrote: Hi, I just finished uploading KDE 4.7.2 tarballs. Unlike previous tarballs, these have been consistently taken from KDE/4.7 branch in git. What does this mean, no 4.7.2 tag was created in git? I don't see anything like that with git tag in kdepim and would like to check if some bugfix made into 4.7.2 or not. dc60f1116dad12fbdd443a964d58eec7e5ed09fc (kdepim-runtime) 84edd007f903763b61296a84768e2f4c9f98113a (kdepimlibs) Tags are created *after* the tarballs. If packagers find problems in a non-final tarball, Dirk can release a new one, but tags are immutable, so they should be created only once we're sure everything is okay. Sorry thats wrong: git tag -a 4.7.2 edit source file git commit -a -m Blah git tag -f -a 4.7.2 works just fine and you can push the result without needing the force-parameter as long as the commit the tag points to now is a successor of the one it pointed to before. As far as I know, that's not the case for annotated tags. If a tag points at a commit A, it can be updated to commit B if A is an ancestor of B. But if the tag points at an annotated tag object which in turn points at commit A, you can't update it at all. There is nothing that can be a successor of the tag object. Did you actually try it out? I've done this twice in the last 4 weeks at work and did not run into any problems. And neither did I when I tried right now :) Andreas That works very well *until the tag is pushed*. Once the tag has been pushed, if you try and push a changed tag, anyone that pulled the repo with the old tag *will not see the tag change*. This behavior is by design, the following excerpt from git-tag(1) explains why: Indeed, though unlike the documentation suggests a simple git fetch --targs will do the job without the necessity to first delete the old tag. Andreas ___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
Re: KDE 4.7.2 (try#1) uploaded
On 08.10.11 01:10:50, Nicolas Alvarez wrote: Andras Mantia wrote: On Sunday, October 02, 2011 17:04:42 Dirk Mueller wrote: Hi, I just finished uploading KDE 4.7.2 tarballs. Unlike previous tarballs, these have been consistently taken from KDE/4.7 branch in git. What does this mean, no 4.7.2 tag was created in git? I don't see anything like that with git tag in kdepim and would like to check if some bugfix made into 4.7.2 or not. dc60f1116dad12fbdd443a964d58eec7e5ed09fc (kdepim-runtime) 84edd007f903763b61296a84768e2f4c9f98113a (kdepimlibs) Tags are created *after* the tarballs. If packagers find problems in a non-final tarball, Dirk can release a new one, but tags are immutable, so they should be created only once we're sure everything is okay. Sorry thats wrong: git tag -a 4.7.2 edit source file git commit -a -m Blah git tag -f -a 4.7.2 works just fine and you can push the result without needing the force-parameter as long as the commit the tag points to now is a successor of the one it pointed to before. Andreas ___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
Re: KDE 4.7.2 (try#1) uploaded
On 08.10.11 15:24:57, Nicolas Alvarez wrote: Andreas Pakulat wrote: On 08.10.11 01:10:50, Nicolas Alvarez wrote: Andras Mantia wrote: On Sunday, October 02, 2011 17:04:42 Dirk Mueller wrote: Hi, I just finished uploading KDE 4.7.2 tarballs. Unlike previous tarballs, these have been consistently taken from KDE/4.7 branch in git. What does this mean, no 4.7.2 tag was created in git? I don't see anything like that with git tag in kdepim and would like to check if some bugfix made into 4.7.2 or not. dc60f1116dad12fbdd443a964d58eec7e5ed09fc (kdepim-runtime) 84edd007f903763b61296a84768e2f4c9f98113a (kdepimlibs) Tags are created *after* the tarballs. If packagers find problems in a non-final tarball, Dirk can release a new one, but tags are immutable, so they should be created only once we're sure everything is okay. Sorry thats wrong: git tag -a 4.7.2 edit source file git commit -a -m Blah git tag -f -a 4.7.2 works just fine and you can push the result without needing the force-parameter as long as the commit the tag points to now is a successor of the one it pointed to before. As far as I know, that's not the case for annotated tags. If a tag points at a commit A, it can be updated to commit B if A is an ancestor of B. But if the tag points at an annotated tag object which in turn points at commit A, you can't update it at all. There is nothing that can be a successor of the tag object. Did you actually try it out? I've done this twice in the last 4 weeks at work and did not run into any problems. And neither did I when I tried right now :) Andreas ___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
Re: [Kde-graphics-devel] libkmap and libkface moved to kdereview
On 25.11.10 08:40:05, Gilles Caulier wrote: 2010/11/24 Albert Astals Cid aa...@kde.org: A Dimecres, 24 de novembre de 2010, Gilles Caulier va escriure: 2010/11/24 Albert Astals Cid aa...@kde.org: A Dilluns, 22 de novembre de 2010, Gilles Caulier va escriure: Hi KDE teams, This summer, digiKam team has work on 2 new features : face detection and reverse geo-coding. These features have been implemented during Google Summer of code 2010. You can see more information at these pages : http://techbase.kde.org/Projects/Digikam/CodingSprint2010 For Face detection we have implemented a shared library named libkface http://websvn.kde.org/trunk/kdereview/libkface/ For Reverse-Geocoding we have implemented another shared library named libkmap http://websvn.kde.org/trunk/kdereview/libkmap/ Both libraries have been hosted in a dedicated branch from KDE subversion repository. Following Albert Astals Cid tips from review-team mailing list, i moved this code to trunk/kdereview for 2 weeks. Code is open for review by KDE developers. The plan is to include libkmap and libkface to kdegraphics/libs with KDE 4.7. These libraries are shared between digiKam/kipi-plugins, and of course with others part of KDE applications. As you can see, in digiKam and kipi-plugins 2.0 release plan targeted for may 2011, but this can be delayed if problem occurs : http://www.digikam.org/drupal/about/releaseplan Remember that digiKam team already maintain 3 shared libraries named libkipi, libkexiv2, and libkdcraw into kdegraphics/libs. if all is fine, somebody can plan to patch KDE 4.7 plan to include this libraries in TODO list ? libkmap seems to have a hard dependency on marble, in the past we didn't want those, nor sure if that rule is still there. But if it is not, can you turn that hard dependency into a soft one, please? digiKam already have an hard depency to marble, about geolocation feature, since 1.0.0 release. there is no problem with that... Well, yes it is, as it is now, moving it to kdegraphics will make kdegraphics not compile if you don't have kdeedu installed, and that is totally unacceptable. Do you mean that it will be more logic to host libkmap with KDEEDU or better, into marble as well ? No the point is that there must be no interdependencies between two modules. So if two modules need a shared library it needs to go into kdelibs (or kdepimlibs for pim-libraries) or it needs to be a completely external dependencies outside of any of the KDE modules. Andreas -- Ships are safe in harbor, but they were never meant to stay there. ___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
Re: Keeping binary compatibility
On 01.10.10 15:32:41, Lubos Lunak wrote: - WTH does e.g. ksysguard install libraries .so and .h files for something that looks a lot like its internal libraries? In case this is about libprocess/libprocessui they are not internal. They're useful for apps that want to present a widget with a list of processes in a nice way. KDevelop uses that to select a process to attach gdb to it. They were supposed to move to kdelibs at some point, but that didn't happen yet unfortunately. Having said that, I generally agree that there's too little information and awareness (among developers) about BC. In particular there's no place that clearly says for each module which libs should keep BC and which don't. Its apparently also pretty unknown to developers that when BC is broken the soname needs to be changed. So part of the problem is more of informational than a technical one (maybe even social) to make developers aware of their responsibility when installing shared libs. Andreas -- A long-forgotten loved one will appear soon. Buy the negatives at any price. ___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
Re: BIC in libkonq
On 04.08.10 11:16:01, Modestas Vainius wrote: On antradienis 03 Rugpjūtis 2010 22:52:36 Dirk Mueller wrote: libkonq is an edge case, it is used in quite some other modules, on the other side, due to the anything that depends on *workspace* must require the exact version anyway, making an exception for libkonq doesn't make that much sense to me. Yes, probably most of libraries are local to kdebase-workspace. But if they are local, they should not install headers to the world. But they all do (why?). A few libraries in kdebase-workspace are definitely public, for example libsolidcontrol (afaik, it broke BC in 4.5 without bumping soname) and libtaskmanager [1] (it broke ABI in 4.4 in comparison with 4.3). The libs from ksysguard (libprocess and libprocessui) are also used outside of workspace. The recent example on top of all that workspace stuff: libsolidinterfaces was moved to kdelibs 4.4 with completely reworked API and without any soname bump. Looks like KDE violates soname concept for the sake of what? Because a single change in CMakeLists.txt is too hard? Or SOVERSION 4 is such a good looking number that there is a strict policy not to touch it? I'm sorry but I don't know how else I could explain this. You overestimate how many people actually have a clue about sonames. Most developers do not know what that number means or when it should be increased. They simply use the variable set by FindKDE4Internal and are done with it. Anyway, at this point I see this as completely lost battle. I guess we will need to start adding distro patches (sad) for bumping sonames of those public libraries because you do not seem to have much interest in following well defined practises in the unix world which are supported by libc/ldconfig/ld.so.conf. As Lubos said, you're barking up the wrong tree, the release team can do 0 about this. The developers actually can, but most of them don't read this list. Andreas -- You are a very redundant person, that's what kind of person you are. ___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
Re: BIC in libkonq
On 04.08.10 19:01:27, Modestas Vainius wrote: It's probably that the topic is not important or considered as not worth the extra effort by majority of developers, so I don't expect situation to improve greatly despite conclusion on k-c-d. As I already said, the problem is not that developers don't care, they simply don't know that a soname change is necessary (or they don't know/understand when its necessary). You need to tell them (each and every one) somehow, for example by putting something on techbase and directing the developers in question (via their mailinglist) to the place. They won't notice soname-problems themselves as they only have 1 version of the library installed which all apps link against. It's not me, you or release-team who can fix all cases each release. What's more, I'm also afraid that when pushing too hard people might start doing otherwise for the sake of extra safety - bump soname in advance as soon as trunk opens without checking if changes are BC or not. Tracking BC is not an easy task. Right, tracking all BiC changes by reading commit logs is _extremely_ hard, especially in active projects. So IMHO its a valid way to simply bump soname after a release. If you can't guarantee that your library is BC between two releases (for whatever reason, including that its too much work to track BiC changes, especially since there's no automated way to do it), then the best you can do is bump the soname as soon as a new development cycle starts. Andreas -- Your love life will be... interesting. ___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
Re: Request to bump Qt version requirements to 4.6.3 for KDE SC 4.5 (and above)
On 08.07.10 17:36:09, Maciej Mrozowski wrote: Hello From what I understand, Plasma in KDE4 Workspace 4.5 relies on notifications provided by libdbusmenu-qt to control what to draw in system tray. And apparently Qt = Qt-4.6.2 contains known bug that causes 'close application' notifications not to be delivered - as a result causing system tray regressions - application icons not disappearing. https://bugs.kde.org/show_bug.cgi?id=232915 https://bugs.kde.org/show_bug.cgi?id=195998 https://bugs.kde.org/show_bug.cgi?id=241248 and similar reports. Because it's quite visually exposed and obvious bug (confirmed to be solved with mentioned Qt upgrade), I propose bumping Qt requirements to 4.6.3 for 4.5 branch and trunk for whole KDE SC release (currently it requires Qt 4.6.0). This has already been discussed and as a compile-time requirement doesn't make a runtime-requirement its been dis-approved (in fact this exact bump was made, discussed afterwards and reverted again (see r1135987 and r1136437 in kdelibs). IIRC the discussion was on kde-core-devel. Andreas -- You will wish you hadn't. ___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
Re: Request to bump Qt version requirements to 4.6.3 for KDE SC 4.5 (and above)
On 08.07.10 20:14:47, Maciej Mrozowski wrote: On Thursday 08 of July 2010 19:28:01 Thiago Macieira wrote: On Thursday 8. July 2010 18.42.36 Maciej Mrozowski wrote: The question is: who cares whether Qt minor releases are interchangeable or not so that we can just specify minimal required dependencies to ensure only that stuff compiles? the build-time dependency should only be a minor release of Qt - is this policy written anywhere? Why is it more important that code compiles than providing better user experience? I think it's fundamental question. The build-time requirement doesn't influence the run-time requirement of Qt. You can compile against 4.6.3 and then run against 4.6.0. So requiring 4.6.3 to compile will NOT get your bug solved. I disagree but let me explain. Someone fetches KDE tarballs. Tries to build them - then encounters build error stating that Qt dependencies are not met. Person in question upgrades Qt, then builds KDE and problem has been solved by avoiding it. If person in question is distro packager, he does the same, but he also ensures that runtime dependencies of packages he's preparing are matching build time dependencies. So problem has been avoided as well (note that KDE SC 4.5.0 is not out yet and number of bug reported already is significant). If said person purposely hacks buildsystem to allow older Qt version - he should be ready to grab the pieces. The only case when bug is not solved. And right-fully so, the packagers need to take care about this and upgrade their Qt packages. Thats their job and only theirs. Thats not KDE's business'. You need to convince your distro to upgrade. And all KDE has to do is to say that distros should upgrade. And that should go without saying that distros should always upgrade. And they do. So what are you complaining about? Bug reported - ceck Bug fixed - check Distros upgrading - check Right. But those users who will go through this exact same procedure over and over AGAIN. Because: - they weren't told Qt-4.6.2 is broken in this regard (why would they? they just grab packages and build from source against whatever Qt version they happen to have) People building from sources are expected to be able to follow upstream updates for _everything_ they build themselves. $random_user doesn't build stuff from sources (except very few things), they use packages at which point packagers come into the game: or - packager who prepared packages for them was not told Qt-4.6.2 is broken in this regard. Then he shouldn't be a packager. Packagers are _expected_ to follow the upstream of whatever they package and update the packages as soon as an update is released (at least for bugfix releases). If they're not able to do that they shouldn't create packages in the first place. So the only reliable way for them to find out is to personally experience bug, fill it (or seach bugzilla first), then be told to go away and complain elsewhere (usually distro). Uhm, packagers are distro-people in most of the cases. So in case they do ship KDE 4.5.x packages with Qt4.6.2 (or earlier) they'll get bugreports and rightfully so. At that point its their job to find out whats wrong, this may include filing a KDE bug and getting told this is an upstream problem, please report to Qt. And all of this could have been avoided if dependencies were raised in first place. The compile time dependency is nonsense, KDE 4.5.x doesn't _need_ 4.6.3 to compile, it needs 4.6.x (x=0). The problem is a pure _runtime_ problem and hence needs to be fixed at runtime. If KDE had a way of requiring a certain Qt version during runtime, that requirement should be changed. But changing a build-time requirement because of 1 bug that occurs during runtime is just plain wrong. (and some people say it's distros that work like it compiles - release) So? Thats broken distro's and broken packagers, we shouldn't need to care about people not taking their job seriously. Andreas -- Of course you have a purpose -- to find a purpose. ___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
Where to put a new app release on the download server
Hi, I'm pondering where to best put the source tarball for a stable release for a new app (kdevelop-pg-qt)? Its going to be a stable release, but I'm unsure about the right place, apps/KDE4.x/utils/ might be a candiate, but then those subdirs seem to be rarely used.. Where are extragear apps usually put? (I see konversation and amarok in stable/ directly) Andreas -- You can do very well in speculation where land or anything to do with dirt is concerned. ___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
How to release an extragear app?
Hi, KDevelop4 is approaching its first stable release from extragear and I'm not fully sure how the procedure is for an extragear app for this. In particular how does the whole translation-stuff work? Should we have a kdevelop-i18n.tar.gz or should it be inside the normal kdevelop.tar.gz? Where and how do I get the translations and how to build them? I didn't find any pointers to this on techbase, but would be happy to contribute them once I know the details. Besides tagging, tarballing, branching, notifying packagers and writing a dot-announcement is there anything else I need to take care of? Andreas -- Think twice before speaking, but don't say think think click click. ___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
Where to branch from extragear?
Hi, I just wrote up the release schedule for KDevelop4.0 and wanted to include to where we'll branch the release. Unfortunately I can't quite find the right spot in branches/. So where should a extragear app put its stable branches? Andreas -- You will be reincarnated as a toad; and you will be much happier. ___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
Re: Where to branch from extragear?
On 25.02.10 20:50:06, Albert Astals Cid wrote: A Dijous, 25 de febrer de 2010, Andreas Pakulat va escriure: Hi, I just wrote up the release schedule for KDevelop4.0 and wanted to include to where we'll branch the release. Unfortunately I can't quite find the right spot in branches/. So where should a extragear app put its stable branches? http://websvn.kde.org/branches/stable/extragear-kde4/ Thanks. Andreas -- Today is National Existential Ennui Awareness Day. ___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
KDevelop4 Release Schedule finalized
Hi, for those interest, we've settled on a final schedule for the 4.0 release of KDevelop4: http://www.kdevelop.org/mediawiki/index.php/KDevelop_4/4.0_Release_Schedule Andreas -- Stay away from hurricanes for a while. ___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
Re: Tagging Release delayed for KDE SC 4.4-beta1
On 29.11.09 22:41:44, Tom Albers wrote: Op Sunday 29 November 2009 21:48 schreef u: I will have no way of fixing any bugs at all in KOrganizer 4.4 until this is dealt with. Basically, we'd be throwing KOrganizer out there and just hoping for the best. I can't do that as maintainer of this application, nor as the kdepim module coordinator. Why haven't you reported this earlier, for example tuesday, when Dirk asked for showstoppers? Without the delay we would hav had tarballs out to the packagers already. Reporting this on the eve before tagging gives us zero opertunity to fix this. I guess disabling kdepim is the only possible solution now. I don't think we should insert another beta already, let's see how it goes and decide later. Who is our current qt contact? Can someone contact him/her to see if we can get a fix asap? Did anybody care to look at the bugreport? Thiago kinda promised to either get it fixed properly for 4.6.0 final or put in a workaround (most probably the revert of the problematic commit) for the release and fix it for 4.6.1. Having said that, I don't see why an upstream bug should have an influence of what and when we do the beta. We might hold off rc's or finals, but a beta is there exactly to find such things. Distro's will for sure pick up the patch easily, especially if we tell the packagers via the kde-packagers maillist. As far as I can see the revert is relatively unproblematic, except printing out warnings in dbus apps. Andreas -- You will be surprised by a loud noise. ___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
Re: The shared-desktop-ontologies mess
On 26.11.09 14:53:03, Sebastian Trueg wrote: I want to apologize for the mess I made in kdelibs yesterday evening. I can understand that you are frustrated especially with the beta1 tagging. Let me explain the whole idea of the shared-desktop-ontologies package: In Nepomuk as in projects like Tracker and Strigi we need the ontologies to describe our data and to create user interfaces. This only makes sense if we use the same ontologies so that the data we create is compatible. We have been struggling to create this package for a long time. Putting it off even longer increases the possibility of ontology forking and incompatible data even more. On a more practical note without this package we need copies of the ontologies in several modules like kdebase or kdepim for example. Now if the big part of you think this was too bold a move and should be reverted - I can understand that. In that case we have two possibilites: 1. put the ontologies in kdelibs (maybe even as a fallback in case the shared-desktop-ontologies are not installed) That would mean creating some CMake API that needs to be working and maintained until the end of KDE4 (I'm assuming the ontologies are needed during the build of those modules). So this would best be what is needed anyway, and kdelibs just installs those files the same as the ontologies-project would do. However, if you think it was bold and not very community but what's done is done then I will try my best to get the cmake issues fixed (once I am told what they are ;) Well, given that apparently at least kdepim already adjusted to the new ontologies-stuff and already uses the (half-baked) new cmake module I think its best to move forward instead of backward. Distributions should be notified asap to package the new dependency and more importantly we need to let the release team( cc'ed on this mail) know that right now there are unresolved build-issues with trunk and that tagging and release need to be delayed (as far as I understood they want to do that anyway as the kde 4.3.4 release is scheduled for the same time). I'll try to have a look at the cmake module tonight to see what exactly is problematic in there and will post the results. -- A long-forgotten loved one will appear soon. Buy the negatives at any price. ___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
Re: KDevelop 4.0 release
On 30.10.09 22:03:04, Sebastian Kügler wrote: On Friday 30 October 2009 19:14:15 Andreas Pakulat wrote: Hi, I just wanted to clarify that we (the KDevelop team) would like to be part of the KDE 4.4 release. That is we're going to follow the release schedule as planned on techbase and we'd like to be included in the tarball'ing being done for the beta's and rc's. I'll be making sure to update the version numbers in kdevelop and kdevplatform before the tagging and I'm going to push out another last beta (6) on our own this weekend. Very cool. Would you like to prepare a webpage with a couple of screenshots and a general introduction for the release PR around KDE 4.4? As we do have our own website which already has a screenshots, news etc. section I think that should be doable - if our webmaster has enough time to put the data online :) David has shown cool stuff quite often on his blog, maybe something like that? The amount of new stuff in KDE 4.4 is overwhelming, and we'll have more than enough trouble covering it. :) I'll try to prepare the KDevelop4.0 PR material as much as I can (screenshots, introduction, initial steps as we still lack a proper manual unfortunately). Andreas -- You will have a long and boring life. ___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
KDevelop 4.0 release
Hi, I just wanted to clarify that we (the KDevelop team) would like to be part of the KDE 4.4 release. That is we're going to follow the release schedule as planned on techbase and we'd like to be included in the tarball'ing being done for the beta's and rc's. I'll be making sure to update the version numbers in kdevelop and kdevplatform before the tagging and I'm going to push out another last beta (6) on our own this weekend. Andreas -- Your temporary financial embarrassment will be relieved in a surprising manner. ___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
Re: Possible 4.3.0 blocker in the Konsole KPart?
On 03.08.09 02:32:50, Eike Hein wrote: Aaron J. Seigo wrote: it's not a data loss bug, just not a very pretty thing. it also only seems to affect the top-left of the scrolled viewport. this is something that would be very good to fix in 4.3.1 for sure, but i don't think it's a release blocker? Dunno, that's what I'm wondering :). IMHO its not a release blocker, its not pretty but in most cases of embedding the kpart it'll only cause a broken display of the prompt. It also means the Scrollback sub-menu has disappeared from the context menu, though, so it's also a feature regression. But it won't eat anyone's children, I guess. You may call it a feature regression, the author of konsole might call it a conscious decision. Looking at the context menu of the kpart and the real app, they are having the same options. So I guess this might have been done on purpose. Andreas -- You are as I am with You. ___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
Re: kdevelop and kdevplatform tagged in branches/KDE/4.3
On 27.06.09 16:25:39, Albert Astals Cid wrote: I wonder if they really belong there, can someone clarify? No they don't. Andreas -- Today's weirdness is tomorrow's reason why. -- Hunter S. Thompson ___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
Re: kdevelop and kdevplatform tagged in branches/KDE/4.3
On 28.06.09 12:39:39, Andreas Pakulat wrote: On 27.06.09 16:25:39, Albert Astals Cid wrote: I wonder if they really belong there, can someone clarify? No they don't. Was about to say that I've removed them, but apparently that requires a bit more privileges than I have. Dirk, can you remove kdevelop and kdevplatform from branches/KDE/4.3 and also the tags? Andreas -- You'll feel much better once you've given up hope. ___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
KDevelop beta3 release mess
Hi, it seems that some friendly helpful soul uploaded 0.9.93 tarballs that I put on upload.kde.org last weekend. At that time they weren't in the right place and Stephan Binner said I should move them to the pub/unstable/kdevelop/version place as soon as I got permission for that. Unfortunately I don't have permission yet (I sent my ssh keys to Dirk on wednesday, but haven't heard back from him). In the meantime it seems someone picked the tarballs and moved them instead of me. As I didn't know about that move, we've meanwhile retagged and wanted to merge two more crash fixes into the beta3 tag in svn. So now we have the tarballs on the ftp mirrors and they don't match the tag that has been created. Question is: Whats the best way to solve this - change the tag back and release a beta4 with a new tag once I have upload privileges? Or should I just replace the tarballs once I have upload privileges and notify kde-packagers, additionally to a dot-announcement, blog and news-item on our website? Andreas -- You'll never be the man your mother was! ___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
Re: KDE 4.2.2 tarballs (try #1) uploaded
On 27.03.09 10:00:53, Pierre Schmitz wrote: Am Freitag, 27. März 2009 09:26:02 schrieb Dirk Mueller: The significant change is that oxygen-icons was split out of kdebase-runtime and is a seperate tarball now. you have to make sure that you build and install that in addition. The kdebase-runtime packages still has the oxygen icons in kdebase/runtime/pics/oxygen/. This will result in a file conflict between oxygen-icons and kdebase-runtime. So, I made a diff (filenames only) between oxygen-icons and kdebase/runtime/pics/oxygen. While there a lot of new files in oxygen-icons (which is not a problem) there are also some missing or were renamed. For example system-restart.png is called system-reboot.png now. I attached the diff; the problematic lines are those with a leading +; those files are in kdebase-runtime but not in oxygen-icons. I don't know if those icons are used at all, but I think kdebase/runtime/pics/oxygen should be merged into oxygen-icons and the first should be removed then to remove any confusion or file conflicts. Well, trunk/kdesupport is not what you should use for the 4.2 releases. kdesupport for 4.2 is in /tags/kdesupport-for-4.2/kdesupport and there's no oxygen-icons there. Hence there should be no problem. Andreas -- Are you making all this up as you go along? ___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
Re: KDE 4.2.2 tarballs (try #1) uploaded
On 27.03.09 11:07:50, Pierre Schmitz wrote: Am Freitag, 27. März 2009 10:52:59 schrieb Andreas Pakulat: Well, trunk/kdesupport is not what you should use for the 4.2 releases. kdesupport for 4.2 is in /tags/kdesupport-for-4.2/kdesupport and there's no oxygen-icons there. Hence there should be no problem. And what is this about: /tags/KDE/4.2.2/oxygen-icons/ Somebody screwed up tagging as far as I can see, that module doesn't belong there if the original is in trunk/KDE/kdesupport (which it is). So either someone copies trunk/KDE/kdesupport/oxygen-icons to branches/kdesupport-for-4.2 and removes oxygen icons from kdebase and re-tags or kdebase ships with oxygen icons and that directory you mentioned gets removed. If this shouldn't be used with 4.2.2 it's fine, but all this is still confusing. Yeah, apparently someone did not know about the kdesupport-for-4.2 branch. Why is there a oxygen-icons-4.2.2.tar.bz2 anyway if its not meant to be used with KDE 4.2.2? Because it was in the tag I guess. Andreas -- You will gain money by a speculation or lottery. ___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
Re: KDE 4.2.2 tarballs (try #1) uploaded
On 27.03.09 08:16:01, Helio Chissini de Castro wrote: On Sexta-feira 27 Março 2009, Pierre Schmitz wrote: Am Freitag, 27. März 2009 10:52:59 schrieb Andreas Pakulat: Well, trunk/kdesupport is not what you should use for the 4.2 releases. kdesupport for 4.2 is in /tags/kdesupport-for-4.2/kdesupport and there's no oxygen-icons there. Hence there should be no problem. And what is this about: /tags/KDE/4.2.2/oxygen-icons/ If this shouldn't be used with 4.2.2 it's fine, but all this is still confusing. Why is there a oxygen-icons-4.2.2.tar.bz2 anyway if its not meant to be used with KDE 4.2.2? Pierre is right, kdebase-runtime tarball is wrong, icons still there. Well, then move oxygen-icons from tags/KDE/4.2.2 to branches/kdesupport-for-4.2 as it belongs there and then remove kdebase/runtime/icons/oxygen from branches/KDE/4.2 and retag kdebase. Andreas -- You will hear good news from one you thought unfriendly to you. ___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
Re: KDE 4.2.2 tarballs (try #1) uploaded
On 27.03.09 12:20:38, Jonathan Riddell wrote: On Fri, Mar 27, 2009 at 01:10:30PM +0100, Andreas Pakulat wrote: Pierre is right, kdebase-runtime tarball is wrong, icons still there. Well, then move oxygen-icons from tags/KDE/4.2.2 to branches/kdesupport-for-4.2 as it belongs there and then remove kdebase/runtime/icons/oxygen from branches/KDE/4.2 and retag kdebase. This is a bugfix release, there should not be any new tarballs or moving around or sources. +1 on that fact. Andreas -- Today is the tomorrow you worried about yesterday. ___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
Re: KDE 4.2.2 tarballs (try #1) uploaded
On 27.03.09 14:07:16, Tom Albers wrote: At Friday 27 March 2009 14:02, you wrote: Many of the issues would not exists if they communicate with packagers and dirk *before* take the decision. Actually, they did. See the archives of the r-t list. But nobody told Dirk where to get the icons for KDE 4.2.2, so the option he was left with was copying from trunk, which apparently doesn't work with kdebase-runtime 4.2.2. So someone needs to step up and fix this mess and IMHO the right way to do that is have the icons in kdebase for the lifetime of KDE 4.2 as that doesn't break anything. Andreas -- Your object is to save the world, while still leading a pleasant life. ___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
Re: oxygen icons moved
On 27.03.09 10:05:11, Riccardo Iaconelli wrote: On Thursday 26 March 2009 16:00:22 Dirk Mueller wrote: On Thursday 19 March 2009, Cyrille Berger wrote: I talked with Casper (over irc) on what would be needed for releasing oxygen icons. Unless I missed something, it's tag, export and upload (mail kde- packager ?), and he seemed ready to do it himself. I'm willing to do the packaging myself, but I need the information where to find the oxygen icons for KDE 4.2.2. You're not really telling me that I should use the trunk version of oxygen icons, right? What is the version number of the oxygen icons? where can I find the version that matches KDE 4.2 branch? Ok, I didn't talk with Casper or Nuno here, so take my word with a grain of salt here, but... why not? Because you're sometimes changing names of icons and that breaks existing code - unless you backport the code-changes before the release. Andreas -- Try to get all of your posthumous medals in advance. ___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
Re: oxygen icons moved
On 28.03.09 01:47:23, Maciej Mrozowski wrote: A Friday 27 March 2009 23:49:32, Sebastian Kügler escreveu: Some applications still ship some icons on their own (I could give some examples, like digikam, and used to - koffice). The possible reasons are: - some application developers don't know whether some icon is shipped already with KDE4 Then they should start to look at the icons in kdebase/runtime (or now oxygen-icons in kdesupport). An app developer should at least coordinate these things somewhat with the artists, unless they want to ship their own iconset. - some application developers don't want to assume that KDE4 shipping those newly added application icons is installed on user machine, so just in any case they ship icons themselves. Thats a moot point, any KDE app has kdebase/runtime as runtime dependency so oxygen icons are _always_ there. Andreas -- You may worry about your hair-do today, but tomorrow much peanut butter will be sold. ___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
Re: oxygen icons moved
On 28.03.09 01:55:32, Sebastian Kügler wrote: On Saturday 28 March 2009 01:27:58 Nuno Pinheiro wrote: Well my issue is another as nothing to do with the issues so far. its about control, we are creating a new kde3.x mess couse aplications are creating their hown versions of the same icons, and not teling any one they do so, couse well they dont have 2. I see. I don't see another solution than to make it easy to ship all icons from one canonical source. Maybe we should have a mechanism to download missing icons automatically, so Oxygen is shipped as webservice. Or at least educating application developers better. Realistically, there will always be the problem of people not passing their modifications up, it's just too easy to change the name and ship it, while passing it back upstream is hard. Another reason to ship icons with an application is that there's only a limited amount of artists available and they have only limited time. In KDevelop we have currently two icons copied from an oxygen icon (and one coming from KDE3) that we ship, simply because the artists didn't yet get around to work on the list of icons posted in the wiki for KDevelop. I'm trying to keep such things out of kdevelop and thats why there are no icons in the menus for some of the most-used actions, but in some cases having text is simply not an option (toolbars in dockwidgets for example). Am I assuming correctly that the only regressions caused by icons is when an icon gets a different name and needs to be moved? Yes in that case we'd either need a copy of the old name still around or make sure all apps using the icon are updated. this is a solution to that issue, no one came up with a beter one.. Let's try to find a better one then :) I don't see in how far putting icons into kdesupport would solve that problem? Yeah, I think the problem is rather that a) app devs don't know that kdebase/runtime is a dependency for _every_ kde app and they might also not know they should pick icons from there or request them from the oxygen tema b) what I said above about limited resources for creating icons Or is the problem the size of Oxygen? I can imagine that you don't want to ship every single special application icon in the world in the kdebase tarball. In that case, it would make sense to ship it separately. I don't really see how shipping a huge tarball that all kde apps depend on outside of kdebase is better than shipping it inside. But I don't have a good idea how to fix the size of the oxygen dir (in terms of files) without starting to scatter around app-specific icons to the applications - which might again lead to duplication and confusion as Nuno pointed out. Andreas -- You're ugly and your mother dresses you funny. ___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
Re: oxygen icons moved
On 28.03.09 01:26:26, Nuno Pinheiro wrote: A Saturday 28 March 2009 00:55:32, Sebastian Kügler escreveu: In that case, it would make sense to ship it separately. This change (which is the point of this discussion) is made already. Still, that's not something we should change in a bug fix update as Andreas pointed out as well. Realy im fine with anything as long as it works, by working i meen having some way of geting a complete overview of the intire icon set, with i dont right now, and nor do developers, I can only speak for myself, but I as a developer always use kdebase/runtime/oxygen to get an overview over icons that I should use and to find one when I have a certain action. a developer serching for an specific icon for his app as no place to go and look for all of them unless he instales every single app out there that ships oxygen icons, and heven if he does he cant be sure its realy an oxygen icon or a icon some application developer found some ware and put it in his install oxygen directory... Hmm, I'm not a guru in the icon-spec, but shouldn't apps install their custom icons not into the oxygen directory but rather into the fallback hicolor or what it is called? At least thats what KDevelop does with the three custom icons it has and that gives other developers a clear hint that these icons are not part of the oxygen iconset. (I just see that we're creating quite some mess actually in kdevelop/pics, I'll try to fix that tomorrow). I have no perfect anser for this but I can complain about it I have spoken about this to the other icon designers we all agrea that a centralized place for all icons is beter... I don't see why that centralized place cannot be kdebase/runtime as that is already a hard runtime requirement for all kde apps. I do understand that you could more easily produce releases yourself from a kdesupport/oxygen-icons module, so I'm not saying you should go back to kdebase/runtime if the separate releases are an important factor. Apart from that I mostly see education problems and the problem of people copying existing apps to start their own (and existing apps doing it wrong). And you can't fix those problems with throwing software or hardware at them, btw. anybody knows what the tutorials on techbase tell people about icons? Andreas -- Beauty and harmony are as necessary to you as the very breath of life. ___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
Re: BC problem in kdepimlibs/kcal/calendarresources.cpp
On 21.03.09 18:16:31, Tom Albers wrote:
Op Friday 20 March 2009 13:19 schreef u:
Hi,
In commit 926668 to trunk/KDE/kdepimlibs/kcal/calendarresources.cpp I
accidentally broke binary compatibility.
This commit was back ported to branch 4.2 and is present in KDE4.2.1.
Now I fixed it so it's BC with 4.0, 4.1, 4.2.{0, 2, ...}, 4.3 ... just not
4.2.1 :(
Commits which broke BC are:
trunk - 926668
branch4.2 - 926671
Commits which fixed BC are:
trunk - 941693
branch4.2 - 941695
I apologize for any inconvenience.
Hi,
Those things happen.
But although the damage has been repaired, it leaves us with a 4.2.2 which
will be BIC against 4.2.1. So I think we *must* bump the so-version now.
Qt Software didn't bump their soversion in the 4.4.1 release, so I'm not
sure thats needed. Also bumping soversion would not quite correct, since
4.2.2 is still BiC to 4.2.0 and earlier versions.
Andreas
--
Stay away from hurricanes for a while.
___
release-team mailing list
release-team@kde.org
https://mail.kde.org/mailman/listinfo/release-team
Re: Help with release announcement
On 28.01.09 01:28:15, Tom Albers wrote: Op Wednesday 28 January 2009 01:11 schreef u: Hi, as hopefully some of the dot-people read here, or somebody at least knows where I should turn to: I'd like to have a dot article out with KDevelop's beta release, but so far were unable to reach the authors to coordinate the whole thing. The old dot had an email address (dot at kdenews org) to post messages to (which I did), but the new site doesn't have any email adress available at all - not even for the webmaster. It also doesn't seem to have any way to post an article as the old site had. So can somebody please let me know who/which adress I should write to to coordinate an annoucement on the dot. Andreas Hi, I just poked them, and they seem to be aware of it - at least now ;-). :) Thanks. In the meanwhile, you can email them on the email address you mentioned. It should not have changed. Ok, maybe with the switch they just need a bit more time to answer (or the mail got lost somewhere). I'll resend it later and eventually ping riddell. Andreas -- Beware of a dark-haired man with a loud tie. ___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
Kdevelop Beta
Hi, seems like our tagged and tarballe'd beta is not going to work very well on multi-core/multi-processor machines due to parts of kdelibs being non-threadsafe. We're working on a fix for that. My problem is: The beta (3.9.90) has already been tagged and tarballe'd and I'm not sure wether I should a) merge the fix into the tag and ask dirk to replace the existing 3.9.90 tarballs b) create a new 3.9.90.1 tag and get tarballs for that c) create a 3.9.91 tag+tarballs. Any suggestions? Ideally I'd do a), but as the tarballs are already on ftp.kde.org I fear that people might already use them and not notice the change when they're replaced. There's not been an announcement yet for the beta, but that might still be a case. Andreas -- After your lover has gone you will still have PEANUT BUTTER! ___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
Help with release announcement
Hi, as hopefully some of the dot-people read here, or somebody at least knows where I should turn to: I'd like to have a dot article out with KDevelop's beta release, but so far were unable to reach the authors to coordinate the whole thing. The old dot had an email address (dot at kdenews org) to post messages to (which I did), but the new site doesn't have any email adress available at all - not even for the webmaster. It also doesn't seem to have any way to post an article as the old site had. So can somebody please let me know who/which adress I should write to to coordinate an annoucement on the dot. Andreas -- Time to be aggressive. Go after a tattooed Virgo. ___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
Re: KDE 4.2 RC1 (4.1.96) try#1
On 09.01.09 13:17:50, Nicolas Lécureuil wrote: On Wed, Jan 7, 2009 at 5:11 PM, Dirk Mueller muel...@kde.org wrote: Hi, I just finished uploading the first set of tarballs for RC1 under unstable/ Please let me know if you find any issues, I've not yet started testing them. Release is 2 days after 4.1.4 (so next week thursday tentatively). Greetings, Dirk i have some pbs with latest sources on my rpms kdebase-workspace need /usr/lib/libkdeui.so /usr/lib/libplasma.so /usr/lib/libkdecore.so which wasn't needed for Beta2. In + kdepimlibs and kdebase-workspace can't be found and this is needed : See the kde-buildsystem list, this is because you've built kdelibs with a cmake 2.6.3 pre-release that doesn't yet know about the new search location for the cmake config-files. You need to either downgrade to a 2.6.2 release of CMake or use a more recent rc of 2.6.3 (or update your checkout). Andreas -- Be free and open and breezy! Enjoy! Things won't get any better so get used to it. ___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
Re: KDE 4.2 RC1 (4.1.96) try#1
On 09.01.09 17:40:55, Nicolas Lécureuil wrote: On Fri, Jan 9, 2009 at 5:34 PM, Andreas Pakulat ap...@gmx.de wrote: On 09.01.09 23:48:24, Funda Wang wrote: 2009/1/9 Andreas Pakulat ap...@gmx.de: On 09.01.09 13:17:50, Nicolas Lécureuil wrote: On Wed, Jan 7, 2009 at 5:11 PM, Dirk Mueller muel...@kde.org wrote: Hi, I just finished uploading the first set of tarballs for RC1 under unstable/ Please let me know if you find any issues, I've not yet started testing them. Release is 2 days after 4.1.4 (so next week thursday tentatively). Greetings, Dirk i have some pbs with latest sources on my rpms kdebase-workspace need /usr/lib/libkdeui.so /usr/lib/libplasma.so /usr/lib/libkdecore.so which wasn't needed for Beta2. In + kdepimlibs and kdebase-workspace can't be found and this is needed : See the kde-buildsystem list, this is because you've built kdelibs with a cmake 2.6.3 pre-release that doesn't yet know about the new search location for the cmake config-files. You need to either downgrade to a 2.6.2 release of CMake or use a more recent rc of 2.6.3 (or update your checkout). You mean rc5 is not recent enough? I don't know when it was added, but I do know that rc4 doesn't contain the change (which is what I had at home) and currently cmake 2.6.3 is at rc7. The easy answer is: If kdepimlibs or kdebase cannot find the libraries from kdelibs and those are in libdir/cmake/kdelibs, then you're cmake needs to be updated. where can i found a tarball of rc7 ? http://www.cmake.org/files/v2.6/ I guess you'd have to fetch it from CVS the CMake-2.6. 2.6.3 is still in development and unreleased, maybe you should instead use 2.6.2. Andreas -- In the stairway of life, you'd best take the elevator. ___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
Re: kdevplatform/kdevelop branching?
On 07.01.09 17:09:13, Andreas Pakulat wrote: On 07.01.09 15:19:03, Dirk Mueller wrote: On Wednesday 07 January 2009, Andreas Pakulat wrote: Leaves one question: We wanted to release beta1 with KDE 4.2.0, how do we best go about this? Do it the same way as done with the beta's, i.e. you fetch trunk/kdevplatform+trunk/kdevelop into the rc tags and put tarballs into the unstable/ directory? Or should we do this ourselves now that 4.2 is in its own branch? Whatever you prefer, I'm fine with creating the tarballs together with KDE 4.2.0 based on your svn revision information, or you can do it yourself. I'll take option 1, i.e. you create the tarballs. Thanks in advance. Any preparational packages for beta1 before 4.2.0, e.g. something with RC1 this week? Yes, another alpha release with rc1 would be nice. I've created two new tags for kdevplatform and kdevelop just now with apropriate versions and requirements. Just found out that there's a startup bug in the code (an illegal instruction on QString::isEmpty()). So those tags are currently useless. I'll try to fix this, but can't say when it'll be fixed. I think KDE 4.2rc1 will just have to live without an alpha of kdevelop/kdevplatform. Its not such a big deal anyway as the time to the next release is pretty short. Andreas -- Don't look now, but the man in the moon is laughing at you. ___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
Re: Retag of KDevplatform 0.9.85
On 07.01.09 23:38:54, Amilcar do Carmo Lucas wrote: Hi, Sorry but I had to retag kdevplatform. Are the tar.bz2 files already done ? If yes, please redo them. I can not because I haven't kde4.2 installed. +1 from me, please ignore the there's a crash in the tag, so don't package it mail from me in the other thread. Thought it would take longer to fix. Andreas -- Today is National Existential Ennui Awareness Day. ___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
Re: Fwd: PolicyKit-KDE destiny
On 20.12.08 18:22:46, Kevin Ottens wrote: On Friday 19 December 2008 20:21:59 Andreas Pakulat wrote: Hmm, actually isn't this more something for workspace? As far as I understood the purpose of this is to replace a GTK/Gnome-equivalent if running a KDE desktop. Thats exactly what workspace is for. Rex is right, it's a runtime dependency for policykit enabled applications. It exposes a D-Bus interface you're supposed to call to allow the user to get credentials. Yes, there's a GTK+ based equivalent which exposes the same interface since said interface is shared... still, at runtime you expect *something* to expose this interface. So those apps won't work at all if the dbus interface is not there? That would make it a runtime dependency indeed. Andreas -- Beware of a tall blond man with one black shoe. ___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
Re: Fwd: PolicyKit-KDE destiny
On 19.12.08 10:43:24, Rex Dieter wrote: Andreas Pakulat wrote: On 19.12.08 15:19:54, Matt Williams wrote: On Friday 19 December 2008 14:41:42 Allen Winter wrote: Forwarding to the Release Team. My opinion on this was to defer to those who know the issues much better than I. IOW: I'm happy either way. -- Forwarded Message -- Subject: PolicyKit-KDE destiny Date: Friday 19 December 2008 From: Dario Freddi drf54...@gmail.com To: kde-core-de...@kde.org Hello everyone, After spending some time in KDEreview, I think it's time for taking a decision about the destiny of PolicyKit-KDE. Basically the decision, based on the proposals we had in the last discussion, is whether going for a freeze except, or place it in extragear to allow packaging for distros and throw it in trunk for KDE 4.3. I'd like to point again that this does not introduce new APIs or anything critical, it's just a client for using PolicyKit inside KDE without the need for the GNOME interface After some discussion I'll do whatever was decided. Cheers Dario Where exactly is this to end up? I guess kdebase but which part? runtime or apps? IMHO apps, as its not a runtime dependency for all kde apps. disagree, (as I understand it), policy-kde is not a standalone app, but a runtime component for policykit-using apps. Hmm, actually isn't this more something for workspace? As far as I understood the purpose of this is to replace a GTK/Gnome-equivalent if running a KDE desktop. Thats exactly what workspace is for. Andreas -- You've been leading a dog's life. Stay off the furniture. ___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
Re: Backporting to 4.1.80
On 02.12.08 17:27:45, Rafael Fernández López wrote: Hi, Why would you want to backport patches to a tag? It's either branch/ (4.1.x) or trunk (next release of that is beta2). Tags are not supposed to change after a release, which for 4.1.80 a.k.a beta1 has happened :). Because I want it to be on the 4.2 branch that will be created from the 4.1.80 tag. No ? I thought that was the way: we tag from trunk, we branch from the tag that were the betas. No, we tag from trunk for the betas, then we branch from trunk for 4.2.0 and tag 4.2.x (x0) from the branch. Andreas -- Domestic happiness and faithful friends. ___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
Re: Release Goals
On 02.11.08 08:29:23, Allen Winter wrote: Howdy, Here are the Release Goals for 4.2. Please send me an update on them: keep; remove; move to 4.3 Goals Also, please send me any 4.3 Goals that you have. * KDevelop and KDevplatform modules ^^ late, but will sorta be part of 4.2. right? To make it clear: Plan is to release beta1 with KDE 4.2.0, most probably a beta2 with 4.2.1 and if all goes well then 1 or 2 rc's and a final release somewhere around 4.2.3 or 4.2.4. Andreas -- You will meet an important person who will help you advance professionally. ___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
Re: Release Coordinator
On 09.09.08 12:38:25, Martin Schlander wrote: Tirsdag 09 september 2008 11:28:01 skrev Andreas Pakulat: On 09.09.08 11:12:08, Martin Schlander wrote: I would be happy if you would add keeping this page reasonably up to date, to your list of duties: http://techbase.kde.org/Schedules/Extragear I know technically kdevelop isn't extragear, but.. You mean I should remove KDevelop from that page? KDevelop lives in trunk/KDE not extragear. There's currently not even a place in extragear where maintained releasable plugins could live, so I don't see why KDevelop would be listed on that page. The point of the page is to have a somewhat centralised place where translators and others interested can keep track of upcoming releases without too much horsing around. Potentially it would also save release coordinators a little work regarding notifying kde-i18n-doc about releases and such I'd think. While KDevelop is not developed in extragear - it is in some sense extra gear for KDE. But if you think it's better to have techbase.kde.org/Schedules/KDevelop, or to not be listed under t.k.o/Schedules at all, that's of course up to you and your team. The point of having KDevelop under trunk/KDE is that it follows KDE's release cycle/schedule. Unfortunately we're only humans and pretty limited amount too, so we weren't able to provide something thats releaseable for 4.1 or 4.2. However that situation has changed now, I personally and also the rest of the team feels that with the re-re-visited (i.e. original) 4.2 schedule we are able to ship a C++ IDE together with the rest of KDE 4.2. So the general KDE 4.2 schedule applies to us. Andreas -- Expect a letter from a friend who will ask a favor of you. ___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
Release Coordinator
Hi, unfortunately Matt Rogers recently had to step down from the role of Maintainer/Release Coordinator for the kdevelop and kdevplatform module. So we (that is the KDevelop developer team) tried to find a new person for the job. As far as it looks by now (80% of the team acknowledged it) that will be me - as I basically already do 90% of the job :) I've checked the apropriate techbase page and just wanted to double-check wethere there's anything, besides being subscribed to this list and putting my name on the Release Team page on techbase, that I need to do to start :) Andreas -- You will be recognized and honored as a community leader. ___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
Re: KDE 4.1 Beta1 tarballs (try #1) uploaded
On 26.05.08 13:33:20, Dirk Mueller wrote: On Friday 23 May 2008, Robby Workman wrote: Well, unless I'm missing something obvious, kdevelop won't compile without kdevplatform. Cluestick, anyone? :) it is supposed to compile without kdevplatform, as only quanta depends on kdevplatform, the rest doesn't. The rest of kdewebdev to be precise. if you have a concrete compile error, then I'd like to have a look. I haven't managed to test kdewebdev without kdevplatform yet. I think was Robby meant is that the kdevelop-module also cannot be included as it also depends on kdevplatform. Andreas -- Generosity and perfection are your everlasting goals. ___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
Re: breaking BIC for new addon libs in minor releases (was: Re: Goals? How are we doing?)
On 06.05.08 17:56:11, Friedrich W. H. Kossebau wrote: Am Dienstag, 6. Mai 2008, um 17:17 Uhr, schrieb Andreas Pakulat: On 05.05.08 21:24:52, Andras Mantia wrote: Actually would be nice to see at least a KDevPlatform release. I know its hard, but maybe makes sense, just like kdelibs was released before the actual KDE 4.0.0. Well, we could probably do that, but without any guarantees regarding binary compatibility. Especially not for the interfaces, shell, project, sublime, language and vcs libraries. I have a similar problem. I know at least one person which would like to make use of the Okteta libraries (implementing a specialised ByteArrayModel) in a 3rd-party project after the 4.1 release. But I know for sure the API will change for 4.2 again, so I do not install any headers. Right now I had to tell him bad luck... I did not find an explicit rule for this on techbase.kde.org, just remember the general unwritten rule ensure binary interface compatibility in minor releases. Thats currently only a rule for kdelibs+kdepimlibs - AFAIK. Other modules in KDE/ need to decide on that themselves, for example kdegames broke BC in their libkdegames library between 4.0 and 4.1. The techbase page explicitly says that the guidelines are not mandatory. Andreas -- Tomorrow, you can be anywhere. ___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
Re: breaking BIC for new addon libs in minor releases (was: Re: Goals? How are we doing?)
On 06.05.08 18:22:09, Friedrich W. H. Kossebau wrote: Am Dienstag, 6. Mai 2008, um 18:15 Uhr, schrieb Andreas Pakulat: On 06.05.08 17:56:11, Friedrich W. H. Kossebau wrote: Am Dienstag, 6. Mai 2008, um 17:17 Uhr, schrieb Andreas Pakulat: On 05.05.08 21:24:52, Andras Mantia wrote: Actually would be nice to see at least a KDevPlatform release. I know its hard, but maybe makes sense, just like kdelibs was released before the actual KDE 4.0.0. Well, we could probably do that, but without any guarantees regarding binary compatibility. Especially not for the interfaces, shell, project, sublime, language and vcs libraries. I have a similar problem. I know at least one person which would like to make use of the Okteta libraries (implementing a specialised ByteArrayModel) in a 3rd-party project after the 4.1 release. But I know for sure the API will change for 4.2 again, so I do not install any headers. Right now I had to tell him bad luck... I did not find an explicit rule for this on techbase.kde.org, just remember the general unwritten rule ensure binary interface compatibility in minor releases. Thats currently only a rule for kdelibs+kdepimlibs - AFAIK. Other modules in KDE/ need to decide on that themselves, for example kdegames broke BC in their libkdegames library between 4.0 and 4.1. Was libkdegames public for 3rd-party development, i.e. have the headers been installed? AFAIK some apps in extragear and playground use it, AFAIK. The techbase page explicitly says that the guidelines are not mandatory. Which page is that? http://techbase.kde.org/index.php?title=Policies/Library_Code_Policy Right at the top. Andreas -- Life, loathe it or ignore it, you can't like it. -- Marvin, Hitchhiker's Guide to the Galaxy signature.asc Description: Digital signature ___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
Re: breaking BIC for new addon libs in minor releases (was: Re: Goals? How are we doing?)
On 06.05.08 19:01:15, Tom Albers wrote: Op dinsdag 06 mei 2008 18:46 schreef u: Am Dienstag, 6. Mai 2008, um 18:39 Uhr, schrieb Tom Albers: Op dinsdag 06 mei 2008 18:30 schreef u: I disagree. I think it is a must to be BC between minor releases. If you want to be bic public, go to extragear/libs untill you are ready... What would this change for 3rd-party developers? You can make a release whenever you like and bump the major so version of the lib as you like in each release. That would be me, but I asked for 3rd-party developers. Then, I know I would not make releases independent of the KDE ones, because I would develop the libs and the program together. So nothing would change for 3rd parties, just another location. The difference is that you have a proper versioning with library version numbers. 3rd party devels can check for that and adapt their code to those versions. What has library versioning to do with keeping BC? If a lib breaks BC it increases its so version and can also adjust its major version number. The library doesn't have to follow the global KDE version number at all, for example the kdevplatform libs don't do it for the plain reason that its not very honest to say they are version 4.x. That version would indicate a matureness the library simply doesn't have. I like to keep minor release from KDE BC and more importantly 3rd party devels should be able to rely on that. Right, people using a lib need to rely on that lib keeping BC within a major version, that doesn't mean a library can't change BC between releases, it just means it needs to increase its major version. And if the library devs want to release it with KDE and have it as KDE module thats fine too - IMHO. Andreas -- You are a fluke of the universe; you have no right to be here. signature.asc Description: Digital signature ___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
Re: Pre-approved Languages
On 30.03.08 08:19:33, Allen Winter wrote: Howdy, So we seem to have reached consensus on a policy (enclosed below). Now I think we should take on the task of pre-approving a couple of non-C++ languages, thereby giving the green light to anyone thinking about using one of them = Chicken Lays Egg. Nominations anyone? I'm not a kdebindings person, but I did try both korundum (ruby) and I know PyQt/PyKDE for quite some time. Both have one drawback: - PyQt/PyKDE are both mostly developed in private repositories of one person (well, one for each), which means that fixes sometimes take a bit longer and (especially PyQt4) don't follow our release cycles - Korundum4 lacks documentation and examples (the latter exist, but are still for KDE3 version) But even though both bindings are in quite good shape - AFAIK and both languages should be pre-approved. Andreas -- Blow it out your ear. signature.asc Description: Digital signature ___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
Re: Pre-approved Languages
On 30.03.08 17:35:54, Simon Edwards wrote: Andreas Pakulat wrote: On 30.03.08 08:19:33, Allen Winter wrote: I'm not a kdebindings person, but I did try both korundum (ruby) and I know PyQt/PyKDE for quite some time. Both have one drawback: - PyQt/PyKDE are both mostly developed in private repositories of one person (well, one for each), which means that fixes sometimes take a bit longer and (especially PyQt4) don't follow our release cycles But even though both bindings are in quite good shape - AFAIK and both languages should be pre-approved. That is not entirely accurate. PyQt is developed privately at Riverbank Computing and snapshots are regularly made available. (It looks like Phil is publishing nightly snapshots). Thats not something KDE can reliably depend on, because those are not added to distributions. When a new version of Qt is released, the updated PyQt release quickly follows in general. Usually long before the next release of KDE which requires the new Qt. Phil has always been responsive to bug reports in my experience. Maybe my memory is wrong, but I think the PyQt4.1 and PyQt4.2 versions came out quite some time after the relevant Qt release. And right now I can't try out PyQt4/PyKDE4 because there's no version that I can compile as I don't have space for a KDE 4.0 checkout on disk. PyKDE is split between Jim Bublitz and myself. Jim is the main PyKDE guy who does most of the big changes and tooling work for generating the bindings. Jim's time and bandwidth is limited which makes it hard for him to track SVN trunk. This is where I step in and manage PyKDE in kdebindings and integrating Jim's work into SVN. I also do maintenance work on PyKDE and update the bindings to track SVN (which I did leading up to 4.0). Jim has been sharing his knowledge with me to help increase PyKDE's bus factor[1]. Yes, but then Jim has to integrate those changes back into his private repo and thats going back and forth. Its as far as I can see not a big deal and yes both of you and also Phil are really responsive to bugreports on the mailinglists. Still its a small drawback when comparing that to the ruby bindings. OTOH you've got the better docs and examples I think ;) PyQt and PyKDE have been around for bit a long time already and are highly mature. No doubt about that. I never intended to say that python is not a good choice, however re-reading my last sentence I see that its quite a bit cryptic (probably due to me having learnt german as first language ;). Andreas -- Today's weirdness is tomorrow's reason why. -- Hunter S. Thompson ___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
Re: Non-C++ Apps in KDE Main Modules (Was: Guidance in KDE Admin)
On 28.03.08 09:41:28, Nicolas Ternisien wrote: Here is one of the main problems: those apps will work only if you have their bindings installed. But the bindings need to be generated whenever something changes in the libraries, so you might end up with a none- working app in a main module because the bindings were not yet updated. My other concern is speed and memory usage. If we start to have a mix of different scripting applications that you have to run in order to have a usable KDE... I have no problems having extensions or even full apps in those languages as long as I am not forced to run them. Why will your Python app will use something new in the KDE API before having the binding ready and updated ? Moreover, changes in the KDE API will only massively be done for major version (KDE 4 -5), and in this case, all KDE source code will be broken at once. Did you follow PyKDE3 releases? Its always been lagging behind KDE3.x changes quite a bit due to time constraints at the authors side. And its not just the big changes of major versions that need changes in the bindings, there's plenty of API that gets added between minor releases. Thats one of the reasons why PyQt bindings are only provided for rc's and releases (and sometimes beta's) of Qt. About the memory usage, we are currently talking about integrating *Python* scripting language only, not a mix of different scripting applications. As soon as you allow one scripting language in a main KDE module you'll basically have to allow all or try to fight all those naggers that file thousands of reports asking for their preferred language. I must admit that I was sceptical the first time I heard guidance was in Python, but in any machine I used it, it always start fast. Thats also what I've seen, except a few performance problems with model/view classes in erci4 - though that was more than 6 months ago. Andreas -- You will be a winner today. Pick a fight with a four-year-old. ___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
New Features list?
Hi, IIRC for KDE 3.5 there was an xml file to accumulate the various changes (specially features) that were done. Does something like that exist for KDE 4.1 too? I mean besides the feature planning page on techbase. Where do I find it if it exists? I'd like to add an entry for the Print Shortcuts feature I just comitted. Andreas -- You will be aided greatly by a person whom you thought to be unimportant. ___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
Re: kdesupport branch for 4.0.x
On 21.03.08 13:46:24, David Faure wrote: On Friday 21 March 2008, Andras Mantia wrote: without hunting on project pages for the latest release that works with a specific KDE version. Does this mean that those libs in kdesupport are making incompatible changes !?? Sorry, I didn't follow the kde-devel thread -- but if the latest version of the libs doesn't work then it means they are not keeping SC/BC... No, its not about the libraries keeping BC/SC. In this particular case soprano just switched to Qt4.4 as dependency due to using Qt4.4-only API. And this obviously leads to confusion, unless there's a complete 4.0-branch for kdesupport. Andreas -- You will obey or molten silver will be poured into your ears. signature.asc Description: Digital signature ___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
Re: kdesupport branch for 4.0.x
On 21.03.08 16:43:16, Albert Astals Cid wrote: A Divendres 21 Març 2008, Andreas Pakulat va escriure: On 21.03.08 13:46:24, David Faure wrote: On Friday 21 March 2008, Andras Mantia wrote: without hunting on project pages for the latest release that works with a specific KDE version. Does this mean that those libs in kdesupport are making incompatible changes !?? Sorry, I didn't follow the kde-devel thread -- but if the latest version of the libs doesn't work then it means they are not keeping SC/BC... No, its not about the libraries keeping BC/SC. In this particular case soprano just switched to Qt4.4 as dependency due to using Qt4.4-only API. And this obviously leads to confusion, unless there's a complete 4.0-branch for kdesupport. You can always use a released version like soprano 2.0, right? Sure. The real problem is that our build documentation isn't up to date wrt. to building from a branch vs. building from trunk. Andreas -- You will always get the greatest recognition for the job you least like. ___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
Re: Discussion about 4.1 timeframe (was Re: What to do about Kompare?)
On 14.12.07 15:49:24, Cyrille Berger wrote: On Friday 14 December 2007, Andreas Pakulat wrote: Are you sure about that? I don't know how SuSE or RedHat and others do their releases but I'd expect them to need at least 2 or rather 4 weeks after a KDE 4.1 release until its patched up/fixed for inclusion in the next release. So if the next release of a distro X is planned for mid-june a release in mid-may would be needed. Meaning we'd effectively have 1.5 months non-frozen trunk/ thats really very little time. I wouldn't plan software release in function of what distributions plans to do or plans no to do or might plan to do. There are distributions being relesed all the time. Anyway, most will offer backport of KDE4.1 for their current release. So I think you should focus on picking the best solution for KDE 4.1 to be the KDE 4 that kick KDE 3's ass (not that KDE 4.0 isn't good, but it's not better than KDE 3.5 in all area). While I do agree that 4.1 should be set at a fix date, I do think the schedule should ensure that application like KMail which were left aside for 4.0, are able to deliver in 4.1. I completely agree with you Cyrille and that is what I wanted to express - see my last sentence of a release in may meaning too little time for active development. Andreas -- You should emulate your heros, but don't carry it too far. Especially if they are dead. ___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
Re: What to do about Kompare?
On 13.12.07 07:10:20, Matt Rogers wrote: On Dec 13, 2007, at 5:53 AM, John Tapsell wrote: +1 vote for not including and having a 4.1 release within 3-4 months of 4.0. I think everyone can be satisfied with that. I'm not. :P You get basically two months to develop and add new features and that's quite crazy. If we do this, you once again leave out KDevelop and kdewebdev from the release because i don't think those are going to be ready in 3-4 months. You also leave out a significantly better version of Kopete since all the new stuff we want to do for that (which is currently planned for 4.1) won't get done either. I'm with Matt here, the same applies to kompare as I doubt everything thats needed can be done in just two months (also looking at the fact that I won't have much time for hacking myself until may). I think a 6 month timeframe is better for the 4.1 release. Andreas -- You will meet an important person who will help you advance professionally. ___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
Re: What to do about Kompare?
On 10.12.07 18:13:20, Allen Winter wrote: On Monday 10 December 2007 18:04:16 Kevin Kofler wrote: In Bug 153463 [1], Kevin Kofler provides some patches to make the current Kompare code in kdesk compile (and work, I guess). It definitely works here, at the very least. :-) Kevin, would you want to take over kdesdk/kompare and make it work for KDE4.0.0? Else, I guess we won't have kompare in KDE4.0. Yes, I'm willing to pick it up. Excellent. Great News! Is there already a dedicated list for kdesdk or even kompare? lists.kde.org didn't show anything and neither does mailman on mail.kde.org show anything. Reason I'm asking: I'm willing to help out with kompare and especially the 3-way branch. KDevelop4 will need a good diff-viewer and 3-way-merge tool and while I'm not up for maintainership due to time constraints I'm certainly willing to help out as time allows. Andreas -- A few hours grace before the madness begins again. ___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
Re: KCalc's Future
On 08.12.07 23:12:16, Christian Ehrlicher wrote:
_knumfloat::_knumfloat(QString const num)
{
mpf_init(_mpf);
mpf_set_str(_mpf, num.toAscii(), 10);
}
I already tried to pass 10,0 without success. Don't know if nan and
inf is correctly interpreted.
Does gmp create a deep copy of the char*? If not that might be the
reason, toAscii() returns a QByteArray and that will be implicitly
converted to char*. However that returns the QByteArray internal buffer
and thus its gone after the call to mpf_set_str. So either gmp needs to
do a deep copy in set_str or you need to keep the QByteArray around
until its not needed anymore.
Andreas
--
Your boss is a few sandwiches short of a picnic.
___
release-team mailing list
release-team@kde.org
https://mail.kde.org/mailman/listinfo/release-team
Re: Delaying 4.0?
On 28.11.07 07:30:29, Rex Dieter wrote: Andras Mantia wrote: On Wednesday 28 November 2007, Rex Dieter wrote: If this is absolutely the last slip, sure. Otherwise, the release party scheduled for January 17 will look pretty silly. But doing a release just for the shake of the release party is equally silly. :) So, do *you* want to be the one to tell the event organizers that all their hard work and effort to pull the event together is now in jeopardy? Not I. Huh? Why is their effort wasted if the release happens on Feb. 4th or some such? They can still pull off a release party. Its not like the party is going to be months before the release. IMHO its going to be much worse to do a release before the party, regardless of the state of KDE4. Reviews will rip KDE4 apart if the release is done that way and the released KDE 4.0.0 is not in a state thats worth a release. Andreas -- You'll be sorry... ___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
Re: Delaying 4.0?
On 28.11.07 15:29:26, Sebastian Kügler wrote: [CC:ing ev-marketing anyway.] On Wednesday 28 November 2007 15:08:50 Andreas Pakulat wrote: On 28.11.07 07:30:29, Rex Dieter wrote: Andras Mantia wrote: On Wednesday 28 November 2007, Rex Dieter wrote: If this is absolutely the last slip, sure. Otherwise, the release party scheduled for January 17 will look pretty silly. But doing a release just for the shake of the release party is equally silly. :) So, do *you* want to be the one to tell the event organizers that all their hard work and effort to pull the event together is now in jeopardy? Not I. Huh? Why is their effort wasted if the release happens on Feb. 4th or some such? They can still pull off a release party. Its not like the party is going to be months before the release. IMHO its going to be much worse to do a release before the party, regardless of the state of KDE4. Reviews will rip KDE4 apart if the release is done that way and the released KDE 4.0.0 is not in a state thats worth a release. From a PR point of view, and for the sake of the release party, KDE is in a state where we'd be able to present it at such an event. I explicitly tried to not talk about the actual current state of KDE4, because I simply don't know. I'm not using KDE4 on a regular basis, so I can't comment on the state - except a few bugs I encountered. I don't share your opinion on what's worse, party before release or party after release. You really want to have the release out when you're showing it to the public (which is what the event is all about, Industry, Press and Community). Telling them that it's not released and thus still very much vapourware would be quite unfortunate (read sucks). Hmm, indeed. I obviously didn't dive into the content of that party as it seems. I agree that having a release party that shows off the release to all the 3rd party people without actual release might be a bit worse than having more problems in the release than we'd like to have. And btw, jduging from what I read on various sites (dot, planetkde, irc) I do think a 4.0 release in early january is realistic. Andreas -- You're currently going through a difficult transition period called Life. ___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
new showstopper in kdegames
Hi, I'd like to add a new showstopper to the 4.0 release goals. lskat from kdegames is completely unusable since revision 731909. The graphics drawing code was changed to center the cards, but the code that finds the right positions for clicks is still the old. Also the drawing of the covered cards is not done anymore. Bugreport: https://bugs.kde.org/show_bug.cgi?id=153072 I wasn't sure wether I should just add it to the wiki or ask here first. Andreas -- It was all so different before everything changed. ___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
Re: new showstopper in kdegames
On 28.11.07 18:56:57, Thomas Zander wrote: On Wednesday 28. November 2007 18:37:13 Andreas Pakulat wrote: I'd like to add a new showstopper to the 4.0 release goals. lskat from kdegames is completely unusable since revision 731909. Can you revert the bad change? I could, but I'm not the maintainer of that app and I'm in no way involved with kdegames (I just happen to play them). So I'd rather wait for a few days to see if its being fixed, lets say until the weekend? And btw, the second issue I reported (the hidden-cards not visible) is a separate bug, introduced a few revisions earlier. And that one has quite some unrelated changes with it, so I'd like to not just revert that whole commit. (Bugreport: http://bugs.kde.org/show_bug.cgi?id=153076) Andreas -- Tomorrow, you can be anywhere. ___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
Re: new showstopper in kdegames
On 28.11.07 12:56:32, Rex Dieter wrote: Andreas Pakulat wrote: On 28.11.07 12:13:44, Rex Dieter wrote: Andreas Pakulat wrote: I'd like to add a new showstopper to the 4.0 release goals. lskat from kdegames is completely unusable since revision 731909. Maybe I'm dense or naive or missing something, but an unusable *game* being a release showstopper? Hmm, I guess it could as well just be disabled. But an application that can't be used, but is installed by default is a showstopper IMHO. Fair enough. I was just uncertain whether disabling individual broken apps was something that the release-team even needed to be involved with (unless module maintainers/developers are tardy/absent). Hmm, right. Sorry seems I was a bit hasty to post this here, should've gone to the games-list first. Andreas -- Tomorrow, you can be anywhere. ___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
Re: kwin status
On 16.11.07 15:28:46, Thomas Zander wrote: Hi, I have been running KDE4 as my main desktop for the last couple of days and plasma is shaping up nicely; lots of thingies missing but I sure people are aware of that. What I have not seen any emails about is that status of kwin. I really got scared of the amount of problems in kwin. From focussing problems (loads of em) to missing support for xinerama. What exact problems? Last I tried kwin properly placed new windows on the screen that has the mouse. Is there anything else kwin has to do wrt. xinerama setups? Andreas -- It is so very hard to be an on-your-own-take-care-of-yourself-because-there-is-no-one-else-to-do-it-for-you grown-up. ___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
Re: Next Tagging
On 13.11.07 17:59:09, Aaron J. Seigo wrote: On Tuesday 13 November 2007, Allen Winter wrote: On Tuesday 13 November 2007 12:33:45 pm Tom Albers wrote: Op Tuesday 13 November 2007 16:52 schreef u: Reading back on the beta5 or rc1 thread it seems like most people are for keeping to this schedule; i.e. no beta5. Just for the record, I don't agree to it. We've set up beta goals so we have a global idea about when we are ready for a rc. From the beta goals we have only reached one absolute go (Dolphin), the rest is still a showstopper or something in between. Guys, I can't even log into a KDE4 desktop today after a complete rebuild. i suppose the question is: why? I guess the reason for something like that would be kdeinit4 not working anymore. Reading kde-commits suggests that Dirk wanted to fix something and accidentally picked QFileInfo.path() where he meant QFileInfo.filePath()... (the function was findExe IIRC, probably in KStandardDirs or some such) Andreas -- Try the Moo Shu Pork. It is especially good today. ___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
Re: beta5 or rc1
On 12.11.07 12:22:11, Thomas Zander wrote: Hi Torsten, On Monday 12. November 2007 08:25:18 Torsten Rahn wrote: while we do have some pretty minor showstoppers. Well, last time I checked the default style didn't support QToolBox yet. This basically rendered Marble unusable as people are not able to make use of the interface. Did we make oxygen (the style) a showstopper? I thought we'd look at the quality when nearing a release and just ship with plastique as default if oxygen was not good enough. In the meantime oxygen was made the default in kdelibs, appparently #oxygen agreed that would be a good idea. Maybe that should be changed back... Next to that; you should add your found bugs (or, missing feature ;) to http://techbase.kde.org/Projects/Oxygen/StyleWinDec I think the known problems are already there, the problem is getting them fixed ;) Andreas -- Slow day. Practice crawling. ___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
Re: beta5 or rc1
On 12.11.07 13:48:19, Sebastian Kügler wrote: On Monday 12 November 2007 13:01:42 Andreas Pakulat wrote: Did we make oxygen (the style) a showstopper? I thought we'd look at the quality when nearing a release and just ship with plastique as default if oxygen was not good enough. In the meantime oxygen was made the default in kdelibs, appparently #oxygen agreed that would be a good idea. Maybe that should be changed back... Next to that; you should add your found bugs (or, missing feature ;) to http://techbase.kde.org/Projects/Oxygen/StyleWinDec I think the known problems are already there, the problem is getting them fixed To me it looks like all problems have been taken care of, but this one. Check the page, in the known bugs section - one showstopper attributed to Qt (I think a patch is already in qt-copy), - one showstopper issue pending review of a patch by the KHTML team - one issue is a pending review of color roles compliance - one is the QToolBox issue That's really 'only' two showstoppers left, I call this great progress. It'd be stupid if we switched back to plastique. Oxygen is making excellent progress, and it already feels much better than plastik in day-to-day usage. You're overlooking that there are quite some incoming bugs that have no yet been categorized. Also I'd call vertical tabs and vertical titles in dockwidgets a showstopper as well. The first means you don't know where one tab starts and another ends. The second makes it impossible to read the dockwidget title. Apart from that the oxygen windeco (AFAIK) doesn't adhere to the kde color scheme completely (it ignores the titlebar color that is set). There's a bugreport for that, but I can't find it right now. And it hasn't been the default style in any of the betas KDE released, which means less testing. Oxygen should be in a releasable state right now, simply because its part of the KDE platform and as far as I can see its not. Andreas PS: The work that the two or three people working on Oxygen (especially the KStyle) managed to do in the last 3 months is amazing. I'm not saying they didn't do enough, I'm saying the time wasn't enough for the complete rewrite that had to happen. -- Everything will be just tickety-boo today. ___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
Re: beta5 or rc1
On 12.11.07 14:28:42, Sebastian Kügler wrote: On Monday 12 November 2007 14:08:17 Thomas Zander wrote: On Monday 12. November 2007 13:48:19 Sebastian Kügler wrote: That's really 'only' two showstoppers left, I think the point is that Torsten noted that QToolBox is not supported. Besides that tabbed panes seem to not be supported (according to the page). I'm sure you agree that those are show stoppers. I only see west and east not being supported. Or I am getting you wrong. I have to re-check when I'm home but last time I had a look (already 3 weeks or so ago) the south tabs where drawn upside-down, i.e. looked like north-tabs that were just moved below the tabwidget... Andreas -- You will contract a rare disease. ___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
Re: KDE 3.5.8
On 01.10.07 09:40:57, Tom Albers wrote: At Monday 01 October 2007 02:17, you wrote: We recently moved to a branch (please no flames anymore, got enough of that already) and some of us developers would like to merge that branch back into KDE/3.5 before this release. The thing is, that I don't want want to flame as you request, but could you consider moving kdevelop to extragear-sdk? In that case you can determine for each release if you want to be part of it. We will just tag what is in there at that moment so you can swap around whatever you see fit. Again, just an idea, please don't kill me. Thats exactly what I want as well, for KDevelop4. KDevelop3 development might get an occasional change here or there but is also considered abdandoned. This recent move out/change scripty was caused by two things: a) a lot of changes that we had lying on our harddisks but couldn't share with the community due to full freeze b) the release team not answering our request for freeze exception Anyway, as Stephan said he doesn't care about keeping the full freeze I will merge back today. Andreas -- You will triumph over your enemy. ___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
Re: Questions About the New Schedule
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. Andreas -- Chicken Little only has to be right once. ___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
Re: KDE 3.5.8
On 21.09.07 10:02:43, Stephan Kulow wrote: Hi! It's been a while since KDE 3.5.7 (released may 22nd) and a lot has changed in the 3.5 branch since then, so I would like to release another service pack. As the translators requested some clean up time, I suggest we go with October 7th as tagging date and release on 15th. Any objections? If not, I let everyone know :) About KDevelop :) We recently moved to a branch (please no flames anymore, got enough of that already) and some of us developers would like to merge that branch back into KDE/3.5 before this release. The thing is, that a) that branch has new strings (I already changed scripty to update from the branch instead of KDE/3.5 a few weeks ago) b) it has new features I know 3.5 is in full freeze, thats why I'm asking wether we are allowed to move back at all. If not, please don't release the kdevelop module from KDE/3.5 when releasing KDE 3.5.8. We will do a release of KDevelop 3.5.0 at the time of the KDE release ourselves in that case. (Should kdevelop 3.4.1 be removed from KDE/3.5 in that case?) Andreas -- You will give someone a piece of your mind, which you can ill afford. ___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
Re: Another item to add to your list perhaps?
On 23.09.07 18:19:40, Matt Rogers wrote: On Sunday 23 September 2007 15:12:20 Andreas Pakulat wrote: On 23.09.07 14:26:04, Troy Unrau wrote: Hey guys, perhaps this should go on your list at http://techbase.kde.org/Schedules/KDE4/4.0_Release_Beta_Goals KWin Composite has performance issues (big ones) on hardware where other 3D compositing programs run perfectly smoothly. Perhaps we just need to optimize for some hardware or something, and it's not a showstopper (since composite can be disabled), but it will ruin a lot of first impressions of KWin 4 in it's current state. Speaking about kwin: Not necessarily for the beta-goals, but for the final release somebody should sit down and fix the xinerama issues in kwin as well. I'm rather astonished that xinerama is basically completely broken, because I was under the impression that the standard kwin code didn't change that much (i.e. the non-compositing stuff)... How do you propose we do that when few, if any, of the kwin developers use xinerama? This belongs to a kwin list really, but they should have at least a remote idea what they changed that completely broke xinerama - I'm not only talking about windows not being on the screen where I want them. I'm talking about menus always popping up on the first screen, no matter where the application window is and about KWin not even knowing there are more than 1 screens attached. Andreas, who will now subscribe to yet another ML just to get a usable KDE4.0 -- Your business will go through a period of considerable expansion. ___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
Re: Another item to add to your list perhaps?
On 23.09.07 14:26:04, Troy Unrau wrote: Hey guys, perhaps this should go on your list at http://techbase.kde.org/Schedules/KDE4/4.0_Release_Beta_Goals KWin Composite has performance issues (big ones) on hardware where other 3D compositing programs run perfectly smoothly. Perhaps we just need to optimize for some hardware or something, and it's not a showstopper (since composite can be disabled), but it will ruin a lot of first impressions of KWin 4 in it's current state. Speaking about kwin: Not necessarily for the beta-goals, but for the final release somebody should sit down and fix the xinerama issues in kwin as well. I'm rather astonished that xinerama is basically completely broken, because I was under the impression that the standard kwin code didn't change that much (i.e. the non-compositing stuff)... Andreas -- It's lucky you're going so slowly, because you're going in the wrong direction. ___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
branches/stable/l10n/scripts
SVN commit 713402 by apaku: Change the path for stable kdevelop, its now in a separate branch to allow ongoing development for the kdevelop3 series. CCMAIL:[EMAIL PROTECTED] CCMAIL:release-team@kde.org CCMAIL:[EMAIL PROTECTED] M +4 -1 get_paths --- branches/stable/l10n/scripts/get_paths #713401:713402 @@ -15,7 +15,7 @@ kdelibs|kdebase|kdegames|kdesdk|kdegraphics|kdeutils|kdenetwork|kdeedu|kdeaccessibility) echo branches/KDE/3.5/$1 ;; - kdemultimedia|kdeadmin|kdetoys|kdevelop|kdepim|kdeaddons|kdeartwork|kdewebdev) + kdemultimedia|kdeadmin|kdetoys|kdepim|kdeaddons|kdeartwork|kdewebdev) echo branches/KDE/3.5/$1 ;; koffice) @@ -27,6 +27,9 @@ extragear-*) echo branches/stable/extragear/`echo $1 | sed -e s,extragear-,,` ;; +kdevelop) + echo branches/kdevelop/3.5 + ;; *) echo ERROR: unknown module $1 12 exit 1 ___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
Re: Release dates/nomenclature
On 02.09.07 17:44:25, Helio Chissini de Castro wrote: On Sunday 02 September 2007, Allen Winter wrote: Ok, I turned the Krazy web site off. I can't really do anything about the command line tool except tell folks not to use it. -Allen Please, no. I was planning to use it in a next week presentation in a major conference here an one of the important things introduced during our evolution. Despite this, turn off Krazy is just a way to make more people talking about what's happening. Sorry, but by blaming Krazy for the fact that we're lack of resources or for try force people to do something is almost the same to cut off the liberty of developers decide by thenselves what they want to do. Probably i'm not the first one to say that, but the current issues have NOTHING TO DO with tools like krazy, but to lack of we do better management of project and failing in to explain to out developers what we need to do right now. Seriously, shutting down krazy is more signal of weakness and confusion than a really help to project. PLease, get it online again. I completely agree and there may be krazy issues that should be fixed _before_ the release - for example dpointerness and maybe some others. I also don't think this helps getting developers into fixing bugs, those that were looking at the ebn and fixing krazy issues might as well just use the commandline tool. IMHO there's a reason these people don't work on real bugs but krazy stuff (in my case the factor is time, if I only have some 30 minutes I rather fix a bunch of krazies instead of starting something which I can't finish). Andreas -- Chess tonight. ___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
Re: 10 Days Until Next Milestone
On 22.05.07 19:15:20, Tom Albers wrote: Op di 22 mei 2007 17:57 schreef u: Other point, it was said that the agressive 4.0 release schedule was also to allow devs to developp and port applications for 4.x. What is the purpose without kdevelop and win/osx port? I would love a win/osx port and the people working on that seem to do a great job as far as i can see. Well, its still a far way until the win32 port is publicly usable, even though the installer already works relatively well. The point about kdevelop I dont understand. You can develop with kdevelop from kde3, non? Right and thats exactly what we kdevelop developers do. Its working pretty well and even if the 4.0 schedule would be move 2 months KDevelop probably wouldn't make it, its just too much work to do still and too few developers - as is the case for the rest of KDE :) (I wonder what will happen with KDE5 if KDE doesn't acquire tons of new developers) Andreas -- You have a deep appreciation of the arts and music. ___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
