Re: KDE 3.5.8
Am Montag 01 Oktober 2007 schrieb Andreas Pakulat: On 26.09.07 13:50:51, Andreas Pakulat wrote: 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?) Would somebody please give us (the kdevelop team) at least any response? (no I will not do the move unless it is approved, but still its kinda rude to get no answer whatsoever) Oops, I overlooked the mail somehow. I was aware of the issue though. So the thing is: if you already changed scripty, then merging back is the safer variant. Otherwise 3.5.8's kde-i18n might create a more untranslated kdevelop than with the branch. I wonder why you guys don't ask forehand. Now all I could do is remove kdevelop from kde-i18n and 3.5.8 completely ;( But backmerge, I don't care. The idea in freezing KDE 3.5 was to keep people on KDE4 development, if it doesn't work for kdevelop and the development team is using dirty tricks to circumvent the freeze, I can't help. Greetings, Stephan ___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
Re: KDE 3.5.8
On Monday 01 October 2007, Tom Albers wrote: 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. There is no need to move it anywhere, it just about deciding if KDevelop should or not be released together with a certain version of KDE. If the KDevelop developers tell in *advance* that we added new string, features, please don't include the current kdevelop module in KDE 3.5.8, I don't think anybody will complain. The same the other way around, if they say that the only changes compared to the last released version are bugfixes, it can be included in the upcoming KDE pack. Andras -- Quanta Plus developer - http://quanta.kdewebdev.org K Desktop Environment - http://www.kde.org signature.asc Description: This is a digitally signed message part. ___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
Re: KDE 3.5.8
Am Montag 01 Oktober 2007 schrieb Andras Mantia: On Monday 01 October 2007, Tom Albers wrote: 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. There is no need to move it anywhere, it just about deciding if KDevelop should or not be released together with a certain version of KDE. If the KDevelop developers tell in *advance* that we added new string, features, please don't include the current kdevelop module in KDE 3.5.8, I don't think anybody will complain. The same the other way around, if they say that the only changes compared to the last released version are bugfixes, it can be included in the upcoming KDE pack. No. There _is_ a problem. And that is that KDE module's translations are packaged in kde-i18n. So you can't simply translate kdevelop 7.0 in KDE 3.5's kde-i18n and then expect a working 3.5.8 to be released Greetings, Stephan ___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
Re: KDE 3.5.8
At Monday 01 October 2007 10:09, you wrote: On Monday 01 October 2007, Tom Albers wrote: 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. There is no need to move it anywhere, it just about deciding if KDevelop should or not be released together with a certain version of KDE. If the KDevelop developers tell in *advance* that we added new string, features, please don't include the current kdevelop module in KDE 3.5.8, I don't think anybody will complain. The same the other way around, if they say that the only changes compared to the last released version are bugfixes, it can be included in the upcoming KDE pack. For the next release we will make releases of extragear application at the same time the other modules are released. So your workflow fits way better in extragear (release on reqest at the same time as KDE) then a main module (always release). Toma -- http://www.mailody.net___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
Re: KDE 3.5.8
On Monday 01 October 2007, Stephan Kulow wrote: Am Montag 01 Oktober 2007 schrieb Andras Mantia: On Monday 01 October 2007, Tom Albers wrote: 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. There is no need to move it anywhere, it just about deciding if KDevelop should or not be released together with a certain version of KDE. If the KDevelop developers tell in *advance* that we added new string, features, please don't include the current kdevelop module in KDE 3.5.8, I don't think anybody will complain. The same the other way around, if they say that the only changes compared to the last released version are bugfixes, it can be included in the upcoming KDE pack. No. There _is_ a problem. And that is that KDE module's translations are packaged in kde-i18n. So you can't simply translate kdevelop 7.0 in KDE 3.5's kde-i18n and then expect a working 3.5.8 to be released So this would mean a need in scripty script each time a module (be it kdevelop, koffice or whatever) is packaged together or separately? Can't the kde-i18n packages be created per module? So let's say KDE 4.0 has kdelibs, kdepimlibs, kdebase and kdegames. There will be kde-i18n-kdelibs, kde-i18n-kdepimlibs and so on. If KDE 4.1 has one more module, the corresponding kde-i18n-* is also released. If a module is not released together with 4.2, the i18n module for that is not released. And to avoid chaos: those module maintainers whose modules will be added/removed from the next release should inform (and ask permission) the release team and translation teams well in advance. If this was discussed on kde-i18n list, I just shut up now. :) Andras -- Quanta Plus developer - http://quanta.kdewebdev.org K Desktop Environment - http://www.kde.org signature.asc Description: This is a digitally signed message part. ___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
Re: KDE 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
Am Montag 01 Oktober 2007 schrieb Andras Mantia: So this would mean a need in scripty script each time a module (be it kdevelop, koffice or whatever) is packaged together or separately? Can't the kde-i18n packages be created per module? So let's say KDE 4.0 has kdelibs, kdepimlibs, kdebase and kdegames. There will be kde-i18n-kdelibs, kde-i18n-kdepimlibs and so on. If KDE 4.1 has one more module, the corresponding kde-i18n-* is also released. If a module is not released together with 4.2, the i18n module for that is not released. And to avoid chaos: those module maintainers whose modules will be added/removed from the next release should inform (and ask permission) the release team and translation teams well in advance. This might work for kdevelop perhaps. But e.g. not for the kopete case, that jumps back in and out. The way we package translations is a compromise and the condition is that we move into one direction, otherwise we create a mess. If this is should be more flexible for KDE 4, we need to do the split a massive one and package applications including _all_ translations (as GNOME basically does). Greetings, Stephan ___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
To help the release management
Hi, To see what need to be done, communicate our work and see our own objectives, we are currently using buzilla (which is hard to use), and many wiki page, which are often becoming out to date... On kdegames, we'd like to fix that (in fact, we WANT to fix that). And we are thinking using a more modern management projet tool like Trac, to have an much easier to use tool, communicate, to help each developper to see what task it must do, and especially to have a common and up to date release view (example from the Videolan project): https://trac.videolan.org/vlc/roadmap I just saw there are maybe a plan to which KDE to bugzilla 3, but bugzilla 3 doesn't seems to improve these criticals points... Could we think on a better KDE-wise tool and organisation? Should we (kdegames) build up your own tool to manage the module? ___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
Re: Questions About the New Schedule
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. I can confirm that the ruby part compile for me. Never tried csharp and/or python. And I have no special local change. Maybe if you can provide specifcs error message to [EMAIL PROTECTED] it would help the situation (even if it's not you who fix the issues in the end). -- Cyrille Berger ___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
Re: KDE 3.5.8
Actually my point was that it should matter if a module is in toplevel directory of KDE or under extragear, what it matters is what policy it follows. KDevelop is one, KOffice is another. Do you want to move KOffice under extragear as well? First, KOffice has allways had his own release schedule separated from KDE. I guess for historical reason it's located as a top svn directory, if it was started today it would probably end up in extragear/office. But that's not the problem. Second, as I understand, Tom's point is not about the exact location of KDevelop in svn, it's about wether a module (or an application) is _allways_ released at the same time than KDE or not. If it is, then it can be in the main module. If it's not the case, then it would be easier for the release team to have it in extragear. In KDE4 extragear module will allways be released with KDE4 but including a version tagged by their maintainers, which might or might not be the same tagging date as the one of KDE4. -- Cyrille Berger ___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
Re: Questions About the New Schedule
On Monday, 1. October 2007, Cyrille Berger wrote: According to that, it has not build in almost 2 and a half months. Hum right I have disabled plasma, maybe it should be disabled by default. CCing kde-bindings. I have it disabled as well. in fact I only try to build the smoke-qt bindings. but the qtguess configury (whatever it is good for) runs twice, and 2nd time it fails completely, aborting the build. I've mailed the log already to Richard Dale and I already disabled the smoke-kde bindings (which couldn't be build at all due to a desynchronized copy of qtguess.pl.in), but no result so far. Greetings, Dirk ___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
Re: Konqueror questions.
On Monday 01 October 2007 1:06:38 am Dirk Mueller wrote: On Tuesday, 25. September 2007, Albert Astals Cid wrote: And if that's still not clear, that can well be because doing complex sentences in english is not my strong point, i'll rephrase it. I have hope we can have them working for KDE 4.0 I still don't get it. KDEPim 4. was not declared a show stopper for 4.0 before. I agree that bugs in the libraries that are possibly exposed by kmail, but maybe also by other applications have to be fixed. but that is not the same level as saying kmail is a ship stopper. There is nobody working on KDE Pim for 4.0, and with nobody working on it, the amount of time needed for getting it ready is definitely unpredictable. BTW: last time I tried to use kmail from KDE 4.0, it deleted all my folders. I was not too happy about that. (but I've learned meanwhile that for kmail, its always good to have backups). Yes, we may have to remove KMail as a 4.0 showstopper. We may have to remove kdepim entirely from the 4.0 release. I don't know yet. I was told several months ago that kdepim was going to receive a large increase in manpower by now... not sure what happened. Probably better to have people to use a reliable kmail3 under the kde4 desktop than having people lose data with a buggy kmail4. other non-kmail apps in kdepim are looking pretty good, however. -Allen ___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
Re: [Kde-bindings] Questions About the New Schedule
On Monday 01 October 2007, Dirk Mueller wrote: On Monday, 1. October 2007, Cyrille Berger wrote: According to that, it has not build in almost 2 and a half months. Hum right I have disabled plasma, maybe it should be disabled by default. CCing kde-bindings. I have it disabled as well. in fact I only try to build the smoke-qt bindings. but the qtguess configury (whatever it is good for) runs twice, and 2nd time it fails completely, aborting the build. I've mailed the log already to Richard Dale and I already disabled the smoke-kde bindings (which couldn't be build at all due to a desynchronized copy of qtguess.pl.in), but no result so far. Well it all built for me until Dirk changed the smoke/kde/qtguess.pl.cmake file. I think the problem is that the FindQt4 cmake file used by the smoke/qt build sets up a macro called QT_LIBRARIES, but the version of FindQt4 in KDE doesn't set that up. So we do need different qtguess.pl.cmake files for smoke/qt, and for smoke/kde (and smoke/plasma). I find these perl scripts largely unmaintainable and they should all be removed and cmake-only tests used. The Qt build options for building KDE need to be pretty much complete, and we should only need to test for which we are on a Mac, Windows or Linux type build env for the window styles QT_ defines. -- Richard ___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
KDE/kdebindings/smoke
SVN commit 719655 by rdale: * Attempt to remove build errors from the smoke config script CCMAIL: [EMAIL PROTECTED] CCMAIL: release-team@kde.org M +2 -84 kde/qtguess.pl.cmake M +31 -112 plasma/qtguess.pl.cmake ___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
Re: [Kde-bindings] Questions About the New Schedule
Quoting Richard Dale [EMAIL PROTECTED]: On Monday 01 October 2007, Dirk Mueller wrote: On Monday, 1. October 2007, Cyrille Berger wrote: According to that, it has not build in almost 2 and a half months. Hum right I have disabled plasma, maybe it should be disabled by default. CCing kde-bindings. I have it disabled as well. in fact I only try to build the smoke-qt bindings. but the qtguess configury (whatever it is good for) runs twice, and 2nd time it fails completely, aborting the build. I've mailed the log already to Richard Dale and I already disabled the smoke-kde bindings (which couldn't be build at all due to a desynchronized copy of qtguess.pl.in), but no result so far. Well it all built for me until Dirk changed the smoke/kde/qtguess.pl.cmake file. I think the problem is that the FindQt4 cmake file used by the smoke/qt build sets up a macro called QT_LIBRARIES, but the version of FindQt4 in KDE doesn't set that up. So we do need different qtguess.pl.cmake files for smoke/qt, and for smoke/kde (and smoke/plasma). ^^^ Wouldn't it be easier to have a single FindQt4 cmake file instead of the *eight* different ones we have now? (http://lists.kde.org/?l=kde-core-develm=119116801902968w=2) I find these perl scripts largely unmaintainable and they should all be removed and cmake-only tests used. The Qt build options for building KDE need to be pretty much complete, and we should only need to test for which we are on a Mac, Windows or Linux type build env for the window styles QT_ defines. -- Richard ___ Kde-bindings mailing list [EMAIL PROTECTED] https://mail.kde.org/mailman/listinfo/kde-bindings -- Pau Garcia i Quiles http://www.elpauer.org (Due to my workload, I may need 10 days to answer) ___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
Re: [Kde-bindings] Questions About the New Schedule
On Monday 01 October 2007, Pau Garcia i Quiles wrote: I think the problem is that the FindQt4 cmake file used by the smoke/qt build sets up a macro called QT_LIBRARIES, but the version of FindQt4 in KDE doesn't set that up. So we do need different qtguess.pl.cmake files for smoke/qt, and for smoke/kde (and smoke/plasma). ^^^ Wouldn't it be easier to have a single FindQt4 cmake file instead of the *eight* different ones we have now? (http://lists.kde.org/?l=kde-core-develm=119116801902968w=2) What a nightmare! -- Richard ___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
Re: Questions About the New Schedule
Hello all, Sebastian Kügler wrote: On Monday 01 October 2007 10:37:06 Andreas Pakulat wrote: On 01.10.07 06:30:25, Dirk Mueller wrote: On Saturday, 8. September 2007, Albert Astals Cid wrote: 5) Should language bindings be part of the development platform? Richard Dale says Python and Ruby in good shape by late October, and possibly C# too. If Richard says he can do it, i say we can try it :-) Thats not enough. somebody has at least to be able to confirm that the bindings *compile*. right now, kdebindings does not compile, and after I spent an hour or so looking, I'm sure that it can not compile for anyone at all, given the fundamental bugs in the build system. it is my understanding that Richard uses a completely different build system to maintain the bindings, at least thats what he used to do in KDE3 times. There has to be at least somebody who maintains the official build system, and that person has to be != me. Same thing applies to the python bindings, but those are not buildable with cmake and I don't see why they should be. I understand that Simon Edwards is working on making them compile with cmake. Simon, can you give us an update about the python bindings? How stable are they? I don't remember telling anyone other than Jim Bublitz that I was looking at using cmake to build the bindings. But as a matter of fact, yes, yes I have been working on that for the last few days. 8-) (Am I that predictable?) Until that is in order, the configure.py script works ok. configure.py doesn't really handle installing things other than the binding themselves (e.g. example code, docs etc). Which is why I hope to be able to switch to cmake sometime as that will make it easier for other people to build and install it all, and I'll be able to recycle the cmake code which is already used in KDE. As far as the bindings themselves are concerned, the kdelibs stuff is in good shape except for one omission, Phonon. It is tricky module to wrap and Jim has been working on it, although we might require additions and fixes to SIP (bindings generator, produced and maintained by Phil Thompson at Riverbank computing). Jim is still quite confident to still have Phonon in KDE 4.0. The other modules in kdelibs are definitely complete enough and stable enough for people to develop on. Other things like docs, example code, test code, and other things which you would expect in a SDK, are still being developed and worked on. We expect to have it in order by 4.0. This might appear to be a lot of development late in the KDE 4 process, but it is unavoidable. We needed a relatively stable and workable kdelibs before the real bindings work could even start. That said, the bindings themselves are very solid. The tools which we are using and building on, SIP and PyQt, have been in production for at least 18 months now. On a technical level, what can I provide in the build system for the Python bindings which would simply the tarballing stage of release work? (directory layout? a special build target make dist??) cheers, -- Simon Edwards | KDE-NL, Guidance tools, Guarddog Firewall [EMAIL PROTECTED] | http://www.simonzone.com/software/ Nijmegen, The Netherlands | ZooTV? You made the right choice. ___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
