Re: Pre-approved Languages
On Tuesday 29 April 2008, Allen Winter wrote: > kdesupport -> kdelibs -> kdepimlibs -> kdebase -> kdebindings -> everything kdesupport kdelibs kdebase-workspace kdepimlibs kdebindings kdebase-runtime kdebase everything else so just kdebase-workspace is the bad place to put. I also don't think it belongs there, it is more an app (like kdebase/apps) or an admin/utility. Greetings, Dirk ___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
Re: [Kde-bindings] Pre-approved Languages
On Wednesday 30 April 2008, Richard Dale wrote: > > On Wednesday 30 April 2008, Allen Winter wrote: > > > On Tuesday 29 April 2008 18:34:29 Aaron J. Seigo wrote: > > > > of course, if bindings ever get made for another module we're going > > > > to be in this same boat again aren't we? i wonder if later on it > > > > might make sense to split up kdebindings into modules that reflect > > > > the KDE/ modules ... so kdebindings-libs, kdebindings-base, > > > > kdebindings-pim ... > > > > > > > > i assume this would be a major pain for the bindings teams, but would > > > > it be feasible? if so, when would be a realistic time frame for such > > > > a modification? > > > > > > Or, maybe each current module can have a bindings subdir? > > > i.e. kdelibs/bindings, kdebase/bindings, kdepimlibs/bindings, ...? > > The second suggestion seems sensible to me, with subdirs for each language > like kdelibs/bindings/python etc. Having a whole new set of modules in > parallel with the existing libs just seems to complicate things. But I > don't know enough about this discussion to know what problem we're trying > to solve. The problem is circular dependencies. A python applet was introduced in kdebase, which means kdebase depends on kdebindings while kdebindings depends on kdebase. The issue was solved by moving the python applet to kdeutils, but the problem might happen again in the future. -- Cyrille Berger ___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
Re: [Kde-bindings] Pre-approved Languages
On Wednesday 30 April 2008 08:42:31 Cyrille Berger wrote: > Forwarding to kde-bindings, since they are the people who know better about > this. > > On Wednesday 30 April 2008, Allen Winter wrote: > > On Tuesday 29 April 2008 18:34:29 Aaron J. Seigo wrote: > > > of course, if bindings ever get made for another module we're going to > > > be in this same boat again aren't we? i wonder if later on it might > > > make sense to split up kdebindings into modules that reflect the KDE/ > > > modules ... so kdebindings-libs, kdebindings-base, kdebindings-pim ... > > > > > > i assume this would be a major pain for the bindings teams, but would > > > it be feasible? if so, when would be a realistic time frame for such a > > > modification? > > > > Or, maybe each current module can have a bindings subdir? > > i.e. kdelibs/bindings, kdebase/bindings, kdepimlibs/bindings, ...? The second suggestion seems sensible to me, with subdirs for each language like kdelibs/bindings/python etc. Having a whole new set of modules in parallel with the existing libs just seems to complicate things. But I don't know enough about this discussion to know what problem we're trying to solve. -- Richard ___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
Re: Pre-approved Languages
On Wednesday 30 April 2008 02:46:24 Allen Winter wrote: > Or, maybe each current module can have a bindings subdir? > i.e. kdelibs/bindings, kdebase/bindings, kdepimlibs/bindings, ...? I don't like too much as it would bloat the modules, but if it is the best solution for the binding team and the packagers, I accept it. Andras -- Quanta Plus developer - http://quanta.kdewebdev.org K Desktop Environment - http://www.kde.org ___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
Re: Pre-approved Languages
Forwarding to kde-bindings, since they are the people who know better about this. On Wednesday 30 April 2008, Allen Winter wrote: > On Tuesday 29 April 2008 18:34:29 Aaron J. Seigo wrote: > > of course, if bindings ever get made for another module we're going to be > > in this same boat again aren't we? i wonder if later on it might make > > sense to split up kdebindings into modules that reflect the KDE/ modules > > ... so kdebindings-libs, kdebindings-base, kdebindings-pim ... > > > > i assume this would be a major pain for the bindings teams, but would it > > be feasible? if so, when would be a realistic time frame for such a > > modification? > > Or, maybe each current module can have a bindings subdir? > i.e. kdelibs/bindings, kdebase/bindings, kdepimlibs/bindings, ...? -- Cyrille Berger ___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
Re: Pre-approved Languages
On Tuesday 29 April 2008 18:34:29 Aaron J. Seigo wrote: > On Tuesday 29 April 2008, Cyrille Berger wrote: > > On Tuesday 29 April 2008, Allen Winter wrote: > > > > It's not something I noticed until after I put it in. It's in > > > > kdebase because that's where the old one was and in /workspace > > > > because that's the X11 specific stuff. I added a cmake variable that > > > > can be set to stop it needing pykde at build time. But it can be > > > > moved to kdeutils if people prefer. > > > > > > Ah, I didn't know that kdebindings had to be built after > > > kdebase/workspace. > > > > > > So, the build order is > > > kdesupport -> kdelibs -> kdepimlibs -> kdebase -> kdebindings -> > > > everything else?? > > > > > > If the above is true, then yes, we definitely need to move > > > printer-applet to either kdeutils or kdeadmin. Either one seems ok > > > with me.. > > > > Well currently kdebindings depends on kdebase, for the plasma ruby > > bindings... So indeed there is a problem :/ > > i'd vote for kdeadmin personally, since it seems to be more of an admin > sort of thing? > > of course, if bindings ever get made for another module we're going to be > in this same boat again aren't we? i wonder if later on it might make sense > to split up kdebindings into modules that reflect the KDE/ modules ... so > kdebindings-libs, kdebindings-base, kdebindings-pim ... > > i assume this would be a major pain for the bindings teams, but would it be > feasible? if so, when would be a realistic time frame for such a > modification? Or, maybe each current module can have a bindings subdir? i.e. kdelibs/bindings, kdebase/bindings, kdepimlibs/bindings, ...? ___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
Re: Pre-approved Languages
On Tuesday 29 April 2008, Cyrille Berger wrote: > On Tuesday 29 April 2008, Allen Winter wrote: > > > It's not something I noticed until after I put it in. It's in > > > kdebase because that's where the old one was and in /workspace because > > > that's the X11 specific stuff. I added a cmake variable that can be > > > set to stop it needing pykde at build time. But it can be moved to > > > kdeutils if people prefer. > > > > Ah, I didn't know that kdebindings had to be built after > > kdebase/workspace. > > > > So, the build order is > > kdesupport -> kdelibs -> kdepimlibs -> kdebase -> kdebindings -> > > everything else?? > > > > If the above is true, then yes, we definitely need to move printer-applet > > to either kdeutils or kdeadmin. Either one seems ok with me.. > > Well currently kdebindings depends on kdebase, for the plasma ruby > bindings... So indeed there is a problem :/ i'd vote for kdeadmin personally, since it seems to be more of an admin sort of thing? of course, if bindings ever get made for another module we're going to be in this same boat again aren't we? i wonder if later on it might make sense to split up kdebindings into modules that reflect the KDE/ modules ... so kdebindings-libs, kdebindings-base, kdebindings-pim ... i assume this would be a major pain for the bindings teams, but would it be feasible? if so, when would be a realistic time frame for such a modification? -- Aaron J. Seigo humru othro a kohnu se GPG Fingerprint: 8B8B 2209 0C6F 7C47 B1EA EE75 D6B7 2EB1 A7F1 DB43 KDE core developer sponsored by Trolltech 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: Pre-approved Languages
On Tuesday 29 April 2008, Allen Winter wrote: > > It's not something I noticed until after I put it in. It's in > > kdebase because that's where the old one was and in /workspace because > > that's the X11 specific stuff. I added a cmake variable that can be > > set to stop it needing pykde at build time. But it can be moved to > > kdeutils if people prefer. > > Ah, I didn't know that kdebindings had to be built after kdebase/workspace. > > So, the build order is > kdesupport -> kdelibs -> kdepimlibs -> kdebase -> kdebindings -> everything > else?? > > If the above is true, then yes, we definitely need to move printer-applet > to either kdeutils or kdeadmin. Either one seems ok with me.. Well currently kdebindings depends on kdebase, for the plasma ruby bindings... So indeed there is a problem :/ -- Cyrille Berger ___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
Re: Pre-approved Languages
On Tuesday 29 April 2008 13:08:43 Jonathan Riddell wrote: > On Tue, Apr 29, 2008 at 06:48:01PM +0200, Dirk Mueller wrote: > > On Sunday 30 March 2008, Allen Winter wrote: > > > So we seem to have reached consensus on a policy (enclosed below). > > > > was the dependency issue discussed anywhere? I'm 17700 mails behind, so > > sorry about beating a dead horse, but I've just seen a python kde app > > appearing in kdebase/workspace, which is a dependency of kdebindings > > (where python kde is built). I don't think thats a great thing to do. > > Dirk said on kde-commits: > > this is a dependency loop (kdebase/workspace needed before > > kdebindings, kdebindings needed before printer-applet). any reason > > this cannot be in an addon module, like kdeutils? or kdeadmin? > > It's not something I noticed until after I put it in. It's in > kdebase because that's where the old one was and in /workspace because > that's the X11 specific stuff. I added a cmake variable that can be > set to stop it needing pykde at build time. But it can be moved to > kdeutils if people prefer. > Ah, I didn't know that kdebindings had to be built after kdebase/workspace. So, the build order is kdesupport -> kdelibs -> kdepimlibs -> kdebase -> kdebindings -> everything else?? If the above is true, then yes, we definitely need to move printer-applet to either kdeutils or kdeadmin. Either one seems ok with me.. -Allen ___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
Re: Pre-approved Languages
On Tue, Apr 29, 2008 at 06:48:01PM +0200, Dirk Mueller wrote: > On Sunday 30 March 2008, Allen Winter wrote: > > > So we seem to have reached consensus on a policy (enclosed below). > > was the dependency issue discussed anywhere? I'm 17700 mails behind, so sorry > about beating a dead horse, but I've just seen a python kde app appearing in > kdebase/workspace, which is a dependency of kdebindings (where python kde is > built). I don't think thats a great thing to do. Dirk said on kde-commits: > this is a dependency loop (kdebase/workspace needed before > kdebindings, kdebindings needed before printer-applet). any reason > this cannot be in an addon module, like kdeutils? or kdeadmin? It's not something I noticed until after I put it in. It's in kdebase because that's where the old one was and in /workspace because that's the X11 specific stuff. I added a cmake variable that can be set to stop it needing pykde at build time. But it can be moved to kdeutils if people prefer. Jonathan ___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
Re: Pre-approved Languages
On Tuesday 29 April 2008, Dirk Mueller wrote: > appearing in kdebase/workspace, which is a dependency of kdebindings (where > python kde is built). I don't think thats a great thing to do. please provide the reasons why you don't think that's a great thing to do, so that your points can either be addressed or be noted as blocking concerns. extra points for reasons that have not already been discussed in the language threads, of course, as restarting conversations ad nauseum isn't productive. -- Aaron J. Seigo humru othro a kohnu se GPG Fingerprint: 8B8B 2209 0C6F 7C47 B1EA EE75 D6B7 2EB1 A7F1 DB43 KDE core developer sponsored by Trolltech 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: Pre-approved Languages
On Sunday 30 March 2008, Allen Winter wrote: > So we seem to have reached consensus on a policy (enclosed below). was the dependency issue discussed anywhere? I'm 17700 mails behind, so sorry about beating a dead horse, but I've just seen a python kde app appearing in kdebase/workspace, which is a dependency of kdebindings (where python kde is built). I don't think thats a great thing to do. Thanks, Dirk ___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
Re: Pre-approved Languages
On Monday 31 March 2008 19:56:00 Riccardo Iaconelli wrote: > On Monday 31 March 2008 13:03:20 Stephan Kulow wrote: > > The corporate world should have applications in the core of KDE? > > I don't think so. > > Maybe not corporate world, but corporate programmers for sure. =) Yep, corporate world of programmers :) Paulo ___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
Re: Pre-approved Languages
On Monday 31 March 2008 13:03:20 Stephan Kulow wrote: > The corporate world should have applications in the core of KDE? > I don't think so. Maybe not corporate world, but corporate programmers for sure. =) AFAIK Java has good bindings, too... and I don't see it harming KDE in any ways. So here goes my +1 for python, ruby and java. -Riccardo -- GPG key: 3D0F6376 When encrypting, please encrypt also for this subkey: 9EBD7FE1 - Pace Peace Paix Paz Frieden Pax Pokój Friður Fred Béke 和平 Hasiti Lapé Hetep Malu Mир Wolakota Santiphap Irini Peoch Shanti Vrede Baris Rój Mír Taika Rongo Sulh Mir Py'guapy 평화 ___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
Re: Pre-approved Languages
Am Montag 31 März 2008 schrieb Paulo Moura Guedes: > On Sunday 30 March 2008 20:11:55 Aaron J. Seigo wrote: > > On Sunday 30 March 2008, Andreas Pakulat wrote: > > > But even though both bindings are in quite good shape - AFAIK and both > > > languages should be pre-approved. > > > > +1 for python and ruby. > > +1 for python and ruby and Java (don't forget corporate world) The corporate world should have applications in the core of KDE? I don't think so. -1 for perl, java and C# +1 for python and ruby Greetings, Stephan ___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
Re: Pre-approved Languages
On Sunday 30 March 2008 20:11:55 Aaron J. Seigo wrote: > On Sunday 30 March 2008, Andreas Pakulat wrote: > > But even though both bindings are in quite good shape - AFAIK and both > > languages should be pre-approved. > > +1 for python and ruby. +1 for python and ruby and Java (don't forget corporate world) ___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
Re: Pre-approved Languages
+1 for PHP ... h in fact no ;-) But agree with Python and Ruby, and why not Perl (no experience on it) On Sun, Mar 30, 2008 at 11:11 PM, Allen Winter <[EMAIL PROTECTED]> wrote: > On Sunday 30 March 2008 15:11:55 Aaron J. Seigo wrote: > > On Sunday 30 March 2008, Andreas Pakulat wrote: > > > But even though both bindings are in quite good shape - AFAIK and both > > > languages should be pre-approved. > > > > +1 for python and ruby. > > > > +1 for python and ruby > > +1 for perl, when the bindings come along > > > > > > > ___ > release-team mailing list > release-team@kde.org > https://mail.kde.org/mailman/listinfo/release-team > ___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
Re: Pre-approved Languages
On Sunday 30 March 2008 15:11:55 Aaron J. Seigo wrote: > On Sunday 30 March 2008, Andreas Pakulat wrote: > > But even though both bindings are in quite good shape - AFAIK and both > > languages should be pre-approved. > > +1 for python and ruby. > +1 for python and ruby +1 for perl, when the bindings come along ___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
Re: Pre-approved Languages
On Sunday 30 March 2008, Aaron J. Seigo wrote: > the fact that they've been around for some years now Yes... It's been (looks up his first bit of PyKDE code...) nine years now since PyKDE was good enough to do Real Stuff with. -- Boudewijn Rempt http://www.valdyas.org/fading/index.cgi ___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
Re: Pre-approved Languages
On Sunday 30 March 2008, Andreas Pakulat wrote: > But even though both bindings are in quite good shape - AFAIK and both > languages should be pre-approved. +1 for python and ruby. the fact that they've been around for some years now and apps built with them work well gives me enough confidence to have included-with-KDE-releases apps rely on them. i agree with Andreas that there is room for improvement on both sets of bindings. i think these improvement will happen quicker if they actually get used more, just like how our libs improve much more rapidly and in useful directions when they get real world use. -- Aaron J. Seigo humru othro a kohnu se GPG Fingerprint: 8B8B 2209 0C6F 7C47 B1EA EE75 D6B7 2EB1 A7F1 DB43 KDE core developer sponsored by Trolltech 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: 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: Pre-approved Languages
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). 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. 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]. PyQt and PyKDE have been around for bit a long time already and are highly mature. [1] "bus factor" is defined as the number of developers which need to be hit by a bus in order to completely derail a project. cheers, -- Simon Edwards | KDE-NL, Guidance tools, Guarddog Firewall [EMAIL PROTECTED] | http://www.simonzone.com/software/ Nijmegen, The Netherlands | "ZooTV? You made the right choice." ___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
Re: 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
Pre-approved Languages
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? We really need input from the kdebindings folks in order to judge how well the nominated language meets requirement #3. -- KDE Programming Languages Policy -- 1) must be an open, free language that meets our licensing requirements 2) must be a mature, high quality language with a large, vibrant support community and a long expected lifespan. 3) must have mature, high quality KDE bindings available 4) must be mature and operational on all our target platforms 5) must be able to provide full translations and internationalizations ___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
