Re: splitting up kdebase in git
Alexander Neundorf wrote: > Maybe something has to be done in git ? > (basically all tools which get introduced to KDE have a fixing/feature > addition phase initially ;-) > > Alex Yes, this issue comes up on the git mailing list from time to time. http://thread.gmane.org/gmane.comp.version-control.git/165389
Re: splitting up kdebase in git
Tom Albers wrote: - Original Message - On Saturday, February 12, 2011 19:12:41 Tom Albers wrote: - Original Message - Hi, Our default wallpapers used to be part of kdebase/workspace, but during the git migration they've been removed from workspace due the size of that directory. Wallpapers can't be kept in a git repository because every time a git repository is cloned all the history (including old wallpapers) is cloned. So actually wallpapers are nowhere, should we move wallpapers back to trunk/KDE/kdebase/workspace? Maybe just a tarball somewhere? SVN won't stay around, so we need another solution i think. I thought we were keeping SVN around for translations? Or will they simply migrate after the rest of the modules have? I personally have no intention to maintain two revision control systems. I thought that translators won't move from SVN. So, why not simply use the best solution (SVN) for these binary data? Regards -- Luigi
Re: splitting up kdebase in git
On Saturday 12 February 2011, Tom Albers wrote: > - Original Message - > > > On Saturday, February 12, 2011 19:12:41 Tom Albers wrote: > > > - Original Message - > > > > > > > Hi, > > > > > > > > Our default wallpapers used to be part of kdebase/workspace, > > > > but during > > > > the git migration they've been removed from workspace due the > > > > size of > > > > that directory. > > > > Wallpapers can't be kept in a git repository because every time > > > > a git > > > > repository is cloned all the history (including old wallpapers) > > > > is cloned. So actually wallpapers are nowhere, should we move > > > > wallpapers > > > > back to trunk/KDE/kdebase/workspace? > > > > > > > > Bye, > > > > Davide Bettio. > > > > > > Maybe just a tarball somewhere? SVN won't stay around, so we need > > > another > > > solution i think. > > > > I thought we were keeping SVN around for translations? Or will they > > simply > > migrate after the rest of the modules have? > > I personally have no intention to maintain two revision control > systems. I understood that SVN would stay indefinitely (read-only) because the Git repos do not carry the full history. (Of course a read-only SVN won't really help with the wallpapers.) Regards, Ingo signature.asc Description: This is a digitally signed message part.
Re: splitting up kdebase in git
Hi, On 02/12/11 20:12, Tom Albers wrote: > Maybe just a tarball somewhere? SVN won't stay around, so we need another > solution i think. > So probably we have to move it to a wallpapers git repository, anyway until SVN is active we can continue to use it. Bye, Davide Bettio. signature.asc Description: OpenPGP digital signature
Re: splitting up kdebase in git
On Saturday 12 February 2011, Tom Albers wrote: > - Original Message - > > > On Saturday, February 12, 2011 19:12:41 Tom Albers wrote: > > > - Original Message - > > > > > > > Hi, > > > > > > > > Our default wallpapers used to be part of kdebase/workspace, but > > > > during > > > > the git migration they've been removed from workspace due the size > > > > of > > > > that directory. > > > > Wallpapers can't be kept in a git repository because every time a > > > > git > > > > repository is cloned all the history (including old wallpapers) is > > > > cloned. So actually wallpapers are nowhere, should we move > > > > wallpapers > > > > back to trunk/KDE/kdebase/workspace? > > > > > > > > Bye, > > > > Davide Bettio. > > > > > > Maybe just a tarball somewhere? SVN won't stay around, so we need > > > another > > > solution i think. > > > > I thought we were keeping SVN around for translations? Or will they > > simply > > migrate after the rest of the modules have? > > I personally have no intention to maintain two revision control systems. Maybe something has to be done in git ? (basically all tools which get introduced to KDE have a fixing/feature addition phase initially ;-) Alex
Re: splitting up kdebase in git
- Original Message - > On Saturday, February 12, 2011 19:12:41 Tom Albers wrote: > > - Original Message - > > > > > Hi, > > > > > > Our default wallpapers used to be part of kdebase/workspace, but > > > during > > > the git migration they've been removed from workspace due the size > > > of > > > that directory. > > > Wallpapers can't be kept in a git repository because every time a > > > git > > > repository is cloned all the history (including old wallpapers) is > > > cloned. So actually wallpapers are nowhere, should we move > > > wallpapers > > > back to trunk/KDE/kdebase/workspace? > > > > > > Bye, > > > Davide Bettio. > > > > Maybe just a tarball somewhere? SVN won't stay around, so we need > > another > > solution i think. > > I thought we were keeping SVN around for translations? Or will they > simply > migrate after the rest of the modules have? I personally have no intention to maintain two revision control systems. -- Tom Albers KDE Sysadmin
Re: splitting up kdebase in git
On Saturday, February 12, 2011 19:12:41 Tom Albers wrote: > - Original Message - > > > Hi, > > > > Our default wallpapers used to be part of kdebase/workspace, but > > during > > the git migration they've been removed from workspace due the size of > > that directory. > > Wallpapers can't be kept in a git repository because every time a git > > repository is cloned all the history (including old wallpapers) is > > cloned. So actually wallpapers are nowhere, should we move wallpapers > > back to trunk/KDE/kdebase/workspace? > > > > Bye, > > Davide Bettio. > > Maybe just a tarball somewhere? SVN won't stay around, so we need another > solution i think. I thought we were keeping SVN around for translations? Or will they simply migrate after the rest of the modules have? Regards, - Michael Pyne signature.asc Description: This is a digitally signed message part.
Re: splitting up kdebase in git
- Original Message - > Hi, > > Our default wallpapers used to be part of kdebase/workspace, but > during > the git migration they've been removed from workspace due the size of > that directory. > Wallpapers can't be kept in a git repository because every time a git > repository is cloned all the history (including old wallpapers) is > cloned. So actually wallpapers are nowhere, should we move wallpapers > back to trunk/KDE/kdebase/workspace? > > Bye, > Davide Bettio. Maybe just a tarball somewhere? SVN won't stay around, so we need another solution i think. Best, -- Tom Albers KDE Sysadmin
Re: splitting up kdebase in git
Hi, On 02/11/11 22:44, Ingo Klöcker wrote: >> Since that location in SVN is now a bit obscure, perhaps we should >> create a new SVN module called trunk/KDE/kdebase-wallpapers. > kde-wallpapers? Because ... > >> The context here is that: SVN is just better then Git at storing >> stuff like wallpapers, so I think we should consider it as the best >> longterm solution for big binary blobs. But wallpapers are required >> by kdebase-workspace. > ... because kdebase/workspace became kde-workspace in Git. I would like to underline that they are our default wallpapers (they used to be part of kdebase and they musn't be confused with extras wallpapers in kdeartwork). Anyway trunk/KDE/kde-wallpapers should be ok too. Bye, Davide Bettio. signature.asc Description: OpenPGP digital signature
Re: splitting up kdebase in git
2011/2/11 Ingo Klöcker : > On Friday 11 February 2011, Ian Monroe wrote: >> On Fri, Feb 11, 2011 at 14:06, Davide Bettio wrote: >> > Hi, >> > >> > Our default wallpapers used to be part of kdebase/workspace, but >> > during the git migration they've been removed from workspace due >> > the size of that directory. >> > Wallpapers can't be kept in a git repository because every time a >> > git repository is cloned all the history (including old >> > wallpapers) is cloned. So actually wallpapers are nowhere, should >> > we move wallpapers back to trunk/KDE/kdebase/workspace? >> >> Since that location in SVN is now a bit obscure, perhaps we should >> create a new SVN module called trunk/KDE/kdebase-wallpapers. > > kde-wallpapers? Because ... > > >> The context here is that: SVN is just better then Git at storing >> stuff like wallpapers, so I think we should consider it as the best >> longterm solution for big binary blobs. But wallpapers are required >> by kdebase-workspace. > > ... because kdebase/workspace became kde-workspace in Git. Well, so maybe kde-basewallpapers or kde-workspace-wallpapers then. Eg, PAINT IT GREEN!! :D Ian
Re: splitting up kdebase in git
On Friday 11 February 2011, Ian Monroe wrote: > On Fri, Feb 11, 2011 at 14:06, Davide Bettio wrote: > > Hi, > > > > Our default wallpapers used to be part of kdebase/workspace, but > > during the git migration they've been removed from workspace due > > the size of that directory. > > Wallpapers can't be kept in a git repository because every time a > > git repository is cloned all the history (including old > > wallpapers) is cloned. So actually wallpapers are nowhere, should > > we move wallpapers back to trunk/KDE/kdebase/workspace? > > Since that location in SVN is now a bit obscure, perhaps we should > create a new SVN module called trunk/KDE/kdebase-wallpapers. kde-wallpapers? Because ... > The context here is that: SVN is just better then Git at storing > stuff like wallpapers, so I think we should consider it as the best > longterm solution for big binary blobs. But wallpapers are required > by kdebase-workspace. ... because kdebase/workspace became kde-workspace in Git. Regards, Ingo signature.asc Description: This is a digitally signed message part.
Re: splitting up kdebase in git
On Fri, Feb 11, 2011 at 14:06, Davide Bettio wrote: > Hi, > > Our default wallpapers used to be part of kdebase/workspace, but during > the git migration they've been removed from workspace due the size of > that directory. > Wallpapers can't be kept in a git repository because every time a git > repository is cloned all the history (including old wallpapers) is > cloned. So actually wallpapers are nowhere, should we move wallpapers > back to trunk/KDE/kdebase/workspace? Since that location in SVN is now a bit obscure, perhaps we should create a new SVN module called trunk/KDE/kdebase-wallpapers. The context here is that: SVN is just better then Git at storing stuff like wallpapers, so I think we should consider it as the best longterm solution for big binary blobs. But wallpapers are required by kdebase-workspace. Ian
Re: splitting up kdebase in git
Hi, Our default wallpapers used to be part of kdebase/workspace, but during the git migration they've been removed from workspace due the size of that directory. Wallpapers can't be kept in a git repository because every time a git repository is cloned all the history (including old wallpapers) is cloned. So actually wallpapers are nowhere, should we move wallpapers back to trunk/KDE/kdebase/workspace? Bye, Davide Bettio. signature.asc Description: OpenPGP digital signature
Re: splitting up kdebase in git
On Sunday, January 23, 2011, Allen Winter wrote: > On Tuesday 18 January 2011 6:15:04 pm Aaron J. Seigo wrote: > > On Tuesday, January 18, 2011, Allen Winter wrote: > > > On Tuesday 18 January 2011 4:34:21 pm Aaron J. Seigo wrote: > > > > hi all ... > > > > > > > > when looking at migrating kdebase to git (thanks to Ian Monroe for > > > > his efforts there and for the support of KO Gmbh that helped make > > > > that happen), it was decided to split it up into chunks which are: > > > > > > > > * kdebase runtime (git -> kderuntime) > > > > * kdebase workspace (git -> kdeworkspace) > > > > > > could we do kde-runtime and kde-workspace instead? > > > only because it's traditional (and because we already have git > > > kdepim-runtime) > > > > oops, sorry, probably just my mistake for not including a dash in there > > .. yeah, that's fine :) > > > > > > * kdebase apps, minus konsole (git -> kdebase-apps) > > > > > > I guess kde-apps won't work. > > > maybe kde-baseapps? > > > > i like that better, yes.. > > Aaron, there is some confusion on the kdebase git rep names. > > We want kde-runtime, kde-workspace, kde-baseapps? > or do we want to keep the old names (kdebase-runtime, kdebase-workspace, > kdebase-apps)? we're dropping "base" from runtime and workspace as it no longer makes sense. it's just "kde runtime" and "kde workspace". with this split, "kdebase" doesn't make a lot of sense anymore. -- 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 Qt Development Frameworks signature.asc Description: This is a digitally signed message part.
Re: splitting up kdebase in git
On Tuesday 18 January 2011 6:15:04 pm Aaron J. Seigo wrote: > On Tuesday, January 18, 2011, Allen Winter wrote: > > On Tuesday 18 January 2011 4:34:21 pm Aaron J. Seigo wrote: > > > hi all ... > > > > > > when looking at migrating kdebase to git (thanks to Ian Monroe for his > > > efforts there and for the support of KO Gmbh that helped make that > > > happen), it was decided to split it up into chunks which are: > > > > > > * kdebase runtime (git -> kderuntime) > > > * kdebase workspace (git -> kdeworkspace) > > > > could we do kde-runtime and kde-workspace instead? > > only because it's traditional (and because we already have git > > kdepim-runtime) > > oops, sorry, probably just my mistake for not including a dash in there .. > yeah, that's fine :) > > > > * kdebase apps, minus konsole (git -> kdebase-apps) > > > > I guess kde-apps won't work. > > maybe kde-baseapps? > > i like that better, yes.. > Aaron, there is some confusion on the kdebase git rep names. We want kde-runtime, kde-workspace, kde-baseapps? or do we want to keep the old names (kdebase-runtime, kdebase-workspace, kdebase-apps)? Personally, I don't much care. But Ian definitely needs to know for sure. Please clarify. -Allen
Re: KDE git docs for dummies ? WAS: Re: splitting up kdebase in git
On Friday, January 21, 2011, Torgny Nyblom wrote: > On Friday 21 January 2011 22.44.49 Ben Cooksley wrote: > > This is completely unpalatable in terms of security and technical on > > KDE servers in my opinion as a sysadmin. Not sure what the others > > think of it however. > > We use it at work and my (somewhat clowdy after 6 months of paternety > leave) memory of it was that it was quite unintuiative to work with and > hard to understand what you were supposed to do when doing anything else > then the normal pull/push thing. thanks for the input from both of you; i'll guess i can now safely remove gerrit from my list for now :) cheers... -- 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 Qt Development Frameworks signature.asc Description: This is a digitally signed message part.
Re: KDE git docs for dummies ? WAS: Re: splitting up kdebase in git
On Friday 21 January 2011 22.44.49 Ben Cooksley wrote: > On Fri, Jan 21, 2011 at 11:17 AM, Aaron J. Seigo wrote: > > On Thursday, January 20, 2011, Ben Cooksley wrote: > >> Correct, it is Gerrit which is a more git based alternative to > >> Reviewboard. http://code.google.com/p/gerrit/ > > > > does it have benefits over reviewboard? having just toyed with a bit > > after lunch today, it seems like it's useful to drive the entire > > integration workflow and not just smaller or one-off patches? > > > > if that's true, would gerrit be a workable replacement for reviewboard > > once everything is moved over to git? would it be integratable with > > identify.kde.org? > > Whilst Gerrit can integrate with KDE Identity (identity.kde.org) it > has some pretty severe technical issues. > > Implementation wise, it runs it's own sshd implementation (written in > Java) on a non standard port. It uses this to allow you to to publish > review requests by pushing to it using a Git client. However, it > implements the git protocol itself as well, and uses it to lie about > the push being accepted by git, storing the changes in it's own > database. In terms of accessing the sshd implementation it provides, > it implements storage of SSH keys in it's own way as well, which means > information has to be duplicated. > > In addition, when trying to test it myself, it's installation > procedure failed using MySQL, I was only able to test it using it's > integrated H2 database. > > This is completely unpalatable in terms of security and technical on > KDE servers in my opinion as a sysadmin. Not sure what the others > think of it however. We use it at work and my (somewhat clowdy after 6 months of paternety leave) memory of it was that it was quite unintuiative to work with and hard to understand what you were supposed to do when doing anything else then the normal pull/push thing. /Regards Torgny
Re: KDE git docs for dummies ? WAS: Re: splitting up kdebase in git
On Fri, Jan 21, 2011 at 11:17 AM, Aaron J. Seigo wrote: > On Thursday, January 20, 2011, Ben Cooksley wrote: >> Correct, it is Gerrit which is a more git based alternative to Reviewboard. >> http://code.google.com/p/gerrit/ > > does it have benefits over reviewboard? having just toyed with a bit after > lunch today, it seems like it's useful to drive the entire integration > workflow and not just smaller or one-off patches? > > if that's true, would gerrit be a workable replacement for reviewboard once > everything is moved over to git? would it be integratable with > identify.kde.org? Whilst Gerrit can integrate with KDE Identity (identity.kde.org) it has some pretty severe technical issues. Implementation wise, it runs it's own sshd implementation (written in Java) on a non standard port. It uses this to allow you to to publish review requests by pushing to it using a Git client. However, it implements the git protocol itself as well, and uses it to lie about the push being accepted by git, storing the changes in it's own database. In terms of accessing the sshd implementation it provides, it implements storage of SSH keys in it's own way as well, which means information has to be duplicated. In addition, when trying to test it myself, it's installation procedure failed using MySQL, I was only able to test it using it's integrated H2 database. This is completely unpalatable in terms of security and technical on KDE servers in my opinion as a sysadmin. Not sure what the others think of it however. Regards, Ben > > i ask because if that was to become something that might eventually join our > toolchain, it might alter how we decide to plan the workflow and the timeline > for implementing it in full ... > > -- > 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 Qt Development Frameworks >
Re: KDE git docs for dummies ? WAS: Re: splitting up kdebase in git
On Thursday, January 20, 2011, Ben Cooksley wrote: > Correct, it is Gerrit which is a more git based alternative to Reviewboard. > http://code.google.com/p/gerrit/ does it have benefits over reviewboard? having just toyed with a bit after lunch today, it seems like it's useful to drive the entire integration workflow and not just smaller or one-off patches? if that's true, would gerrit be a workable replacement for reviewboard once everything is moved over to git? would it be integratable with identify.kde.org? i ask because if that was to become something that might eventually join our toolchain, it might alter how we decide to plan the workflow and the timeline for implementing it in full ... -- 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 Qt Development Frameworks signature.asc Description: This is a digitally signed message part.
Re: KDE git docs for dummies ? WAS: Re: splitting up kdebase in git
2011/1/21 Alexander Neundorf : > On Thursday 20 January 2011, Aaron J. Seigo wrote: >> On Wednesday, January 19, 2011, Alexander Neundorf wrote: >> > http://community.kde.org/Sysadmin/GitKdeOrgManual looks quite ok for >> > somebody who knows how to use git for KDE, but not for me. >> > Can somebody please add a simple step-by-step howto, what I have to do >> > with identity.kde.org, projects.kde.org and git.kde.org, how the git >> > push/merge/branching policy is for KDE, etc. If there are existing blog >> >> this is, at least to me, two related but separate topics: >> >> a) how do i get myself hooked up with all the tools? >> b) what is the development workflow once i have those tools? > > Yes. > And anybody who wants to commit needs to get both more or less right right > from the start. > >> as i understand it: >> >> identity.k.o, projects.k.o, reviewboard.k.o, etc. are things you set up >> once and mostly forget about afterwards. they are the new replacements to >> the "how do i get an svn account?", "how do get a new svn module?" and >> "what is the lifecycle of a kde app?" >> >> this is mostly about re-working existing documentation, such as: >> >> http://techbase.kde.org/Policies/SVN_Guidelines >> >> and it's probably a really good opportunity to try and put it into an order >> that's even more accessible than what we have right now. a "KDE >> contributor's primer" on techbase, which is what you seem to be looking for >> (and something i'd find useful myself as i learn all the new answers, too >> :) >> >> one thing that complicates this is that these tools are to some extent >> still in development. as needs are discovered and defined, sysadmin is >> adding capabilities to cover them. the recent addition of >> http://projects.kde.org/kde_projects.xml is a good example. so the "it's >> not finished yet, but it's already usable" status does mean it's a little >> more tricky. >> >> the other half of the question is development workflow. and that's even >> less well defined, as Ian noted. it would be very good, as Ossi noted, to >> have something that can create some consistency between KDE projects. >> personally, i think we'll end up with something like this: >> >> http://techbase.kde.org/Policies/Kdelibs_Coding_Style >> >> but for git workflow in kdelibs. hopefully then we can encourage as many of >> KDE projects to adopt it outright or as the core of their own workflow. >> kdelibs just hasn't had this done for it yet. it's part of the struggle >> with kdelibs given how distributed and loosely knit the group of people who >> work kdelibs are. >> >> in kde-workspace (and for the parts of kde-runtime we also maintain) we've >> been discussing how to do things. i love that you shared what CMake has >> done here as it's a great reference point. thanks for that :) so far, the >> workflow we've sketched together looks a -lot- like this: >> >> http://public.kitware.com/Wiki/Git/Workflow/Topic >> >> i'm fairly tempted to just steal .. er .. borrow, yeah, that's it .. >> borrow! that from cmake for our needs. > > Would be perfectly fine :-) > As long as there is no policy defined, I simply try to push/merge to the > respective master ? > I also think that really most/all new KDE git repositories should use a common > workflow. > >> perhaps we could even use it as a >> starting point for the kdelibs workflow as well. >> >> one of the things we haven't worked out yet is how to publish the status of >> topic/feature branches, which is what this seems to address for CMake: >> >> http://public.kitware.com/Wiki/Git/Workflow/Stage >> >> ? > > The git stage for cmake is a set of scripts written by Brad. Not sure it's > intended to be a long term solution. > They are thinking about using something else instead ... it has git in the > name and is a google project.. web thingy... was it gerrit ? Not sure. Correct, it is Gerrit which is a more git based alternative to Reviewboard. http://code.google.com/p/gerrit/ > > Alex > Regards, Ben
Re: KDE git docs for dummies ? WAS: Re: splitting up kdebase in git
On 20.01.11 19:47:22, Alexander Neundorf wrote: > On Thursday 20 January 2011, Tom Albers wrote: > > - Original Message - > > > > > On Wed, Jan 19, 2011 at 03:33:30PM -0600, Ian Monroe wrote: > > > > There is no push/merge/branching policy for KDE. Different projects > > > > will likely do their own thing. For the time being its just the > > > > SVN-style development translated to Git. > > > > > > words like "unwise", "stupid" and "utterly braindead" come to mind. > > > you > > > cannot refer to projects' sovereignty in an environment where > > > everybody > > > can push everywhere. and before you make excuses about sysadmin only > > > implementing and not making decisions: FAIL. at the very least you > > > should have facilitated the creation of such a policy, because this > > > very > > > much *is* part of "implementing git". > > > > We facilitate #kde-git and scm-interest mailinglist. > > What's the recommended place to ask git questions ? > (I'd prefer a mailing list over IRC) > scm-interest ? > > Like: how do I check whether my git clone uses the correct ssl-key, and if > not, how do I make it use the key ? A git clone has no idea about ssl keys and such. Git simply runs ssh to connect to the remote host (if you use the ssh:// protocol). So configure your ssh client correctly and then you're set. Andreas -- If you sow your wild oats, hope for a crop failure.
Re: KDE git docs for dummies ? WAS: Re: splitting up kdebase in git
2011/1/20 Alexander Neundorf: > As long as there is no policy defined, I simply try to push/merge to the > respective master ? > I also think that really most/all new KDE git repositories should use a common > workflow. I think this is a reasonable expectation for all repositories that are part of the Software Compilation. (If extragear apps and personal projects want to do things differently, I really think that's up to them.) I think "trunk" == "master" is pretty obvious, but when it comes to stabilisation branches I think will have to develop a policy to enforce consistency. For example, SC 4.x usually contains Konsole version 2.x, but I don't think it's reasonable to expect everyone to know this detail (for Konsole and for every other project) to be able to tell which is the current stable branch. Maybe stabilisation for SC 4.7 should always happen in a "SC4.7" branch, regardless of the project's current version number? Or maybe this has already been decided somewhere and I just missed it? Parker
Re: KDE git docs for dummies ? WAS: Re: splitting up kdebase in git
On Thursday 20 January 2011, Aaron J. Seigo wrote: > On Wednesday, January 19, 2011, Alexander Neundorf wrote: > > http://community.kde.org/Sysadmin/GitKdeOrgManual looks quite ok for > > somebody who knows how to use git for KDE, but not for me. > > Can somebody please add a simple step-by-step howto, what I have to do > > with identity.kde.org, projects.kde.org and git.kde.org, how the git > > push/merge/branching policy is for KDE, etc. If there are existing blog > > this is, at least to me, two related but separate topics: > > a) how do i get myself hooked up with all the tools? > b) what is the development workflow once i have those tools? Yes. And anybody who wants to commit needs to get both more or less right right from the start. > as i understand it: > > identity.k.o, projects.k.o, reviewboard.k.o, etc. are things you set up > once and mostly forget about afterwards. they are the new replacements to > the "how do i get an svn account?", "how do get a new svn module?" and > "what is the lifecycle of a kde app?" > > this is mostly about re-working existing documentation, such as: > > http://techbase.kde.org/Policies/SVN_Guidelines > > and it's probably a really good opportunity to try and put it into an order > that's even more accessible than what we have right now. a "KDE > contributor's primer" on techbase, which is what you seem to be looking for > (and something i'd find useful myself as i learn all the new answers, too > :) > > one thing that complicates this is that these tools are to some extent > still in development. as needs are discovered and defined, sysadmin is > adding capabilities to cover them. the recent addition of > http://projects.kde.org/kde_projects.xml is a good example. so the "it's > not finished yet, but it's already usable" status does mean it's a little > more tricky. > > the other half of the question is development workflow. and that's even > less well defined, as Ian noted. it would be very good, as Ossi noted, to > have something that can create some consistency between KDE projects. > personally, i think we'll end up with something like this: > > http://techbase.kde.org/Policies/Kdelibs_Coding_Style > > but for git workflow in kdelibs. hopefully then we can encourage as many of > KDE projects to adopt it outright or as the core of their own workflow. > kdelibs just hasn't had this done for it yet. it's part of the struggle > with kdelibs given how distributed and loosely knit the group of people who > work kdelibs are. > > in kde-workspace (and for the parts of kde-runtime we also maintain) we've > been discussing how to do things. i love that you shared what CMake has > done here as it's a great reference point. thanks for that :) so far, the > workflow we've sketched together looks a -lot- like this: > > http://public.kitware.com/Wiki/Git/Workflow/Topic > > i'm fairly tempted to just steal .. er .. borrow, yeah, that's it .. > borrow! that from cmake for our needs. Would be perfectly fine :-) As long as there is no policy defined, I simply try to push/merge to the respective master ? I also think that really most/all new KDE git repositories should use a common workflow. > perhaps we could even use it as a > starting point for the kdelibs workflow as well. > > one of the things we haven't worked out yet is how to publish the status of > topic/feature branches, which is what this seems to address for CMake: > > http://public.kitware.com/Wiki/Git/Workflow/Stage > > ? The git stage for cmake is a set of scripts written by Brad. Not sure it's intended to be a long term solution. They are thinking about using something else instead ... it has git in the name and is a google project.. web thingy... was it gerrit ? Not sure. Alex
Re: KDE git docs for dummies ? WAS: Re: splitting up kdebase in git
On Thursday 20 January 2011, Tom Albers wrote: > - Original Message - > > > On Wed, Jan 19, 2011 at 03:33:30PM -0600, Ian Monroe wrote: > > > There is no push/merge/branching policy for KDE. Different projects > > > will likely do their own thing. For the time being its just the > > > SVN-style development translated to Git. > > > > words like "unwise", "stupid" and "utterly braindead" come to mind. > > you > > cannot refer to projects' sovereignty in an environment where > > everybody > > can push everywhere. and before you make excuses about sysadmin only > > implementing and not making decisions: FAIL. at the very least you > > should have facilitated the creation of such a policy, because this > > very > > much *is* part of "implementing git". > > We facilitate #kde-git and scm-interest mailinglist. What's the recommended place to ask git questions ? (I'd prefer a mailing list over IRC) scm-interest ? Like: how do I check whether my git clone uses the correct ssl-key, and if not, how do I make it use the key ? Alex
Re: KDE git docs for dummies ? WAS: Re: splitting up kdebase in git
On Thursday, January 20, 2011, Aaron J. Seigo wrote: > On Wednesday, January 19, 2011, Alexander Neundorf wrote: > > http://community.kde.org/Sysadmin/GitKdeOrgManual looks quite ok for > > somebody who knows how to use git for KDE, but not for me. > > Can somebody please add a simple step-by-step howto, what I have to do > > with identity.kde.org, projects.kde.org and git.kde.org, how the git > > push/merge/branching policy is for KDE, etc. If there are existing blog > > this is, at least to me, two related but separate topics: > > a) how do i get myself hooked up with all the tools? > b) what is the development workflow once i have those tools? just occured to me that there is a third topic here, too: c) how to build KDE software from the new git repositories we'll need to replace the "getting started" tutorials currently on techbase with something that uses the new git stuff. it probably makes sense to make something much, much more simple this time around, even if it is less comprehensive and doesn't cover every possible use case in the main tutorial. once kdesrc-build and the projects.kde.org xml file are able to work together (and how i dream for a nice simple Qt GUI to sit on top of that :), i think it would make sense to drive people who want to build KDE software from our repositories in that direction. it's simple, straight-forward and should mask a lot of the possible complexity with the new git infrastructure. kdesrc-build is the kind of thing that people can use to get up and started within minutes with. building an individual module by "hand", important for starting to contribute to a given module, can be another small tutorial. from there readers could be directed to the CMake documentation as well for more in depth info. the relationships between the modules (qt -> support -> libs -> runtime, workspace, SC modules, extragear) could be another. still, the first "getting started building KDE software" tutorial should be kept dead simple. -- 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 Qt Development Frameworks signature.asc Description: This is a digitally signed message part.
Re: KDE git docs for dummies ? WAS: Re: splitting up kdebase in git
On Wednesday, January 19, 2011, Alexander Neundorf wrote: > http://community.kde.org/Sysadmin/GitKdeOrgManual looks quite ok for > somebody who knows how to use git for KDE, but not for me. > Can somebody please add a simple step-by-step howto, what I have to do with > identity.kde.org, projects.kde.org and git.kde.org, how the git > push/merge/branching policy is for KDE, etc. If there are existing blog this is, at least to me, two related but separate topics: a) how do i get myself hooked up with all the tools? b) what is the development workflow once i have those tools? as i understand it: identity.k.o, projects.k.o, reviewboard.k.o, etc. are things you set up once and mostly forget about afterwards. they are the new replacements to the "how do i get an svn account?", "how do get a new svn module?" and "what is the lifecycle of a kde app?" this is mostly about re-working existing documentation, such as: http://techbase.kde.org/Policies/SVN_Guidelines and it's probably a really good opportunity to try and put it into an order that's even more accessible than what we have right now. a "KDE contributor's primer" on techbase, which is what you seem to be looking for (and something i'd find useful myself as i learn all the new answers, too :) one thing that complicates this is that these tools are to some extent still in development. as needs are discovered and defined, sysadmin is adding capabilities to cover them. the recent addition of http://projects.kde.org/kde_projects.xml is a good example. so the "it's not finished yet, but it's already usable" status does mean it's a little more tricky. the other half of the question is development workflow. and that's even less well defined, as Ian noted. it would be very good, as Ossi noted, to have something that can create some consistency between KDE projects. personally, i think we'll end up with something like this: http://techbase.kde.org/Policies/Kdelibs_Coding_Style but for git workflow in kdelibs. hopefully then we can encourage as many of KDE projects to adopt it outright or as the core of their own workflow. kdelibs just hasn't had this done for it yet. it's part of the struggle with kdelibs given how distributed and loosely knit the group of people who work kdelibs are. in kde-workspace (and for the parts of kde-runtime we also maintain) we've been discussing how to do things. i love that you shared what CMake has done here as it's a great reference point. thanks for that :) so far, the workflow we've sketched together looks a -lot- like this: http://public.kitware.com/Wiki/Git/Workflow/Topic i'm fairly tempted to just steal .. er .. borrow, yeah, that's it .. borrow! that from cmake for our needs. perhaps we could even use it as a starting point for the kdelibs workflow as well. one of the things we haven't worked out yet is how to publish the status of topic/feature branches, which is what this seems to address for CMake: http://public.kitware.com/Wiki/Git/Workflow/Stage ? our documents should also probably cover how reviewboard and friends can work into that workflow as well. i'm also personally somewhat conflicted over how to handle bug fixes without getting too complex this is all separate from the tools (identity.k.o, etc.) though, and imho should probably be a second set of documents on techbase. the git.kde.org manual is a decent starting pont for source material for the tools, but we'll be starting from scratch for the workflow bits. which makes borrowing pre- existing work that fits closely with what we need tempting ;) i'm not sure i have the energy right now to do this (too many other things tugging at my sleeves right now), and i am doubly unsure i have enough git knowledge to really do a great job of it. i could probably help with the tools intro, though; and i wouldn't mind participating, though certainly not taking lead on, the workflow bits. it would be great if we could have a working document (as in: something we are actually using, or at least trying to use) for workflow by the time the Platform 11 sprint rolls around at the start of June where we could probably do some high-bandwidth hammering out of any remaining details, if any. in the meantime, as Ian notes, it's likely that kdelibs will start out on day 0 in a sort of "what we've always done with svn/cvs, only using git" workflow until we have something like this put together. > Sorry if such documentation already exists and I just didn't find it. i don't think it does yet or at least, i haven't found it either ;) > For CMake, which moved to git last spring, such a wiki page exists: > http://www.cmake.org/Wiki/CMake/Git , which was mostly good enough for git again, thanks for sharing this link ... another bit of useful git-ology added to my reading ... -- Aaron J. Seigo humru othro a kohnu se GPG Fingerprint: 8B8B 2209 0C6F 7C47 B1EA EE75 D6B7 2EB1 A7F1 DB43 KDE core de
Re: KDE git docs for dummies ? WAS: Re: splitting up kdebase in git
On Thursday, January 20, 2011, Oswald Buddenhagen wrote: > On Wed, Jan 19, 2011 at 03:33:30PM -0600, Ian Monroe wrote: > > There is no push/merge/branching policy for KDE. Different projects > > will likely do their own thing. For the time being its just the > > SVN-style development translated to Git. > > words like "unwise", "stupid" and "utterly braindead" come to mind. you dude, that was so not cool as a response. you can disagree and offer input, sure, but try to do it without insult. everyone'll listen closer and walk away happier. > cannot refer to projects' sovereignty in an environment where everybody > can push everywhere. i mostly agree with you; when it's an open-for-all-to-participate playground, then having some common guidelines and expectations is highly useful to ensuring that accidents don't happen and that people feel confident enough to contribute broadly. the ballancing issue is that different projects have different needs and even variations in how their development community is put together, and that is bound to translate to some variation. there is more than one way to do git, and KDE has more than one team in it these days. we can strive to bring commonality to this issue, but i don't think we will realistically achieve perfect uniformity. that said, i've been personally using this as a starting reference: http://community.kde.org/Sysadmin/GitKdeOrgManual the section on personal repositories in particular has some useful points, such as how to start with something in your scratch, how to move it to the new KDE playground, how to move that to kdereview and then out to a final location. there are some very basic guidelines on things like reviewboard there as well. i think it could be a good starting point from which further documentation can be built up. > and before you make excuses about sysadmin only > implementing and not making decisions: FAIL. at the very least you i think sysadmin has / had enough on their plate without also taking this on. honestly, knowing what resources they have along with the responsibilities they've taken on this far and the patience and commitment with which they've done so, it's probably ok that they didn't also take this on themselves. :) > should have facilitated the creation of such a policy, because this very > much *is* part of "implementing git". perhaps you could help with this part of implementing git and start crafting some mechanisms that we can consider adopting. we've been trying to do this for plasma leading up to the migration of libs, base and plasma-addons and we've had some success but i'm not sure i'm 100% happy yet. :) there's a lot to read about this on the 'net from others who have been using git in varoius ways for projects of various sizes, so there's a lot to digest. would you be able / willing to help out with this part of things? it strikes me as the kind of thing that you are usually pretty good at, in fact :) -- 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 Qt Development Frameworks signature.asc Description: This is a digitally signed message part.
Re: KDE git docs for dummies ? WAS: Re: splitting up kdebase in git
- Original Message - > On Wed, Jan 19, 2011 at 03:33:30PM -0600, Ian Monroe wrote: > > There is no push/merge/branching policy for KDE. Different projects > > will likely do their own thing. For the time being its just the > > SVN-style development translated to Git. > > > words like "unwise", "stupid" and "utterly braindead" come to mind. > you > cannot refer to projects' sovereignty in an environment where > everybody > can push everywhere. and before you make excuses about sysadmin only > implementing and not making decisions: FAIL. at the very least you > should have facilitated the creation of such a policy, because this > very > much *is* part of "implementing git". We facilitate #kde-git and scm-interest mailinglist. -- Tom Albers KDE Sysadmin
Re: KDE git docs for dummies ? WAS: Re: splitting up kdebase in git
On Wed, Jan 19, 2011 at 03:33:30PM -0600, Ian Monroe wrote: > There is no push/merge/branching policy for KDE. Different projects > will likely do their own thing. For the time being its just the > SVN-style development translated to Git. > words like "unwise", "stupid" and "utterly braindead" come to mind. you cannot refer to projects' sovereignty in an environment where everybody can push everywhere. and before you make excuses about sysadmin only implementing and not making decisions: FAIL. at the very least you should have facilitated the creation of such a policy, because this very much *is* part of "implementing git".
Re: KDE git docs for dummies ? WAS: Re: splitting up kdebase in git
2011/1/19 Alexander Neundorf : > Hi, > > now that it's getting serious, can somebody who is working on the git > migration, *please* take care and write proper documentation on > techbase.kde.org for git dummies ? > > http://techbase.kde.org/Development/Tutorials/Git , which is the first google > result, and looks like a gateway page, has a "Getting started" section, the > only link there which looks not outdated is the one to the git.kde.org > manual. > > http://community.kde.org/Sysadmin/GitKdeOrgManual looks quite ok for somebody > who knows how to use git for KDE, but not for me. Maybe try this out first, it looks straightforward and the topic list is comprehensive: http://gitimmersion.com > Can somebody please add a simple step-by-step howto, what I have to do with > identity.kde.org, projects.kde.org and git.kde.org, how the git > push/merge/branching policy is for KDE, etc. If there are existing blog > articles about this, please add links to them in a good visible place. There is no push/merge/branching policy for KDE. Different projects will likely do their own thing. For the time being its just the SVN-style development translated to Git. > Sorry if such documentation already exists and I just didn't find it. > > For CMake, which moved to git last spring, such a wiki page exists: > http://www.cmake.org/Wiki/CMake/Git , which was mostly good enough for git > dummies as me. I'd really like if somebody would write something similar for > KDE. I don't want to discourage anyone finishing the KDE-spin of the "intro to git" documentation, but there are tons of generic git docs out there and so far we don't have much KDE-specific advice to give. Like most of the cmake docs are actually about their workflow, not really git. Everyone should really pay attention to this though: http://community.kde.org/Sysadmin/GitKdeOrgManual#Let_Git_rewrite_URL_prefixes Will save you a lot of time. :) Ian
KDE git docs for dummies ? WAS: Re: splitting up kdebase in git
Hi, now that it's getting serious, can somebody who is working on the git migration, *please* take care and write proper documentation on techbase.kde.org for git dummies ? http://techbase.kde.org/Development/Tutorials/Git , which is the first google result, and looks like a gateway page, has a "Getting started" section, the only link there which looks not outdated is the one to the git.kde.org manual. http://community.kde.org/Sysadmin/GitKdeOrgManual looks quite ok for somebody who knows how to use git for KDE, but not for me. Can somebody please add a simple step-by-step howto, what I have to do with identity.kde.org, projects.kde.org and git.kde.org, how the git push/merge/branching policy is for KDE, etc. If there are existing blog articles about this, please add links to them in a good visible place. Sorry if such documentation already exists and I just didn't find it. For CMake, which moved to git last spring, such a wiki page exists: http://www.cmake.org/Wiki/CMake/Git , which was mostly good enough for git dummies as me. I'd really like if somebody would write something similar for KDE. Thanks Alex
Re: splitting up kdebase in git
On 18 January 2011 23:55, Aaron J. Seigo wrote: >> Oh, what happened to the idea of making kde-workspace-libs a >> standalone repo? Wouldn't that make sense? > > it could be done, but there was no use case for that. keeping the repos > together lets us not worry so much about binary compat, too. Ah. Just leave ksysguard where it is then. :-)
Re: splitting up kdebase in git
On Tuesday, January 18, 2011, John Tapsell wrote: > On 18 January 2011 23:13, Aaron J. Seigo wrote: > > the complication there is that krunner also relies on libksyguard, which > > lives in kdebase/workspace/libs/ksysguard. so we'd either end up with a > > really odd dependency in ksysguard on kde-workspace, or kde-workspace > > would end up depending on the ksysguard repository .. and then there's > > the matter of binary compatibility in the library due to that (a number > > of practical solutions there available to us, though). > > Oh, what happened to the idea of making kde-workspace-libs a > standalone repo? Wouldn't that make sense? it could be done, but there was no use case for that. keeping the repos together lets us not worry so much about binary compat, too. -- 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 Qt Development Frameworks signature.asc Description: This is a digitally signed message part.
Re: splitting up kdebase in git
On 18 January 2011 23:13, Aaron J. Seigo wrote: > the complication there is that krunner also relies on libksyguard, which lives > in kdebase/workspace/libs/ksysguard. so we'd either end up with a really odd > dependency in ksysguard on kde-workspace, or kde-workspace would end up > depending on the ksysguard repository .. and then there's the matter of binary > compatibility in the library due to that (a number of practical solutions > there available to us, though). Oh, what happened to the idea of making kde-workspace-libs a standalone repo? Wouldn't that make sense?
Re: splitting up kdebase in git
On Tuesday, January 18, 2011, Allen Winter wrote: > On Tuesday 18 January 2011 4:34:21 pm Aaron J. Seigo wrote: > > hi all ... > > > > when looking at migrating kdebase to git (thanks to Ian Monroe for his > > efforts there and for the support of KO Gmbh that helped make that > > happen), it was decided to split it up into chunks which are: > > > > * kdebase runtime (git -> kderuntime) > > * kdebase workspace (git -> kdeworkspace) > > could we do kde-runtime and kde-workspace instead? > only because it's traditional (and because we already have git > kdepim-runtime) oops, sorry, probably just my mistake for not including a dash in there .. yeah, that's fine :) > > * kdebase apps, minus konsole (git -> kdebase-apps) > > I guess kde-apps won't work. > maybe kde-baseapps? i like that better, yes.. > > also, please keep all relevant discussion on kde-core-devel rather than > > CC'ing all the lists; i just CC'd the lists so everyone there who may > > not be on k-c-d as well receives the information :) > > Having konsole, ksysguard, etc in their own git repo is fine. > But they still will reside logically inside kdebase-apps > > For example on api.kde.org the EBN and LXR. yes, that's cool :) -- 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 Qt Development Frameworks signature.asc Description: This is a digitally signed message part.
Re: splitting up kdebase in git
On Tuesday, January 18, 2011, John Tapsell wrote: > On 18 January 2011 21:34, Aaron J. Seigo wrote: > > konsole, however, is a significant application in its own right that > > doesn't actually share code with the rest of the apps in there (besides > > Qt, kdelibs and runtime, of course ;). so it is getting its own repo. > > > > if there are any questions / concerns / thoughts on this, please provide > > your feedback now as we'd like to make the move as soon as possible once > > 4.6.0 is released. > > apps/ksysguard could get its own repo as well. It's completely > standalone, and (a few?) people want to compile ksysguardd (the > daemon) by itself. the complication there is that krunner also relies on libksyguard, which lives in kdebase/workspace/libs/ksysguard. so we'd either end up with a really odd dependency in ksysguard on kde-workspace, or kde-workspace would end up depending on the ksysguard repository .. and then there's the matter of binary compatibility in the library due to that (a number of practical solutions there available to us, though). a process table and such seems a fairly important piece to the workspace, at least the desktop (can't imagine shipping without it, really?) ... possible options i can think of: * don't split out ksysguard * give libksysguard a binary compat strategy, make kde-workspace depend on it * make the process table a generic plugin of some sort that krunner tries to load at runtime, making ksysguard "only" a runtime dependency any other ideas? (administrivia bit: if we want it split out, we'll have to write some more git conversion rules) -- 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 Qt Development Frameworks signature.asc Description: This is a digitally signed message part.
Re: splitting up kdebase in git
On 18 January 2011 22:05, Allen Winter wrote: > Having konsole, ksysguard, etc in their own git repo is fine. > But they still will reside logically inside kdebase-apps > > For example on api.kde.org the EBN and LXR. That's sounds great. John
Re: splitting up kdebase in git
On Tuesday 18 January 2011 4:34:21 pm Aaron J. Seigo wrote: > hi all ... > > when looking at migrating kdebase to git (thanks to Ian Monroe for his > efforts > there and for the support of KO Gmbh that helped make that happen), it was > decided to split it up into chunks which are: > > * kdebase runtime (git -> kderuntime) > * kdebase workspace (git -> kdeworkspace) could we do kde-runtime and kde-workspace instead? only because it's traditional (and because we already have git kdepim-runtime) > * kdebase apps, minus konsole (git -> kdebase-apps) I guess kde-apps won't work. maybe kde-baseapps? > * konsole > > runtime / workspace / apps as divisions already reflects changes made > starting > with 4.0. even now in svn, code in one of those is not allowed to have a > compile time dependency on code in the other two. this is why, for instance, > folderview is in kdebase/apps/: it relies on libkonq which is also in there. > > kdebase-apps is being kept together because there is a lot of code sharing > between the projects there, particularly in the form of file management code > in libkonq. it was determined by the maintainers of each that there was > nothing but a loss of efficiency and increased pain to be gained from > splitting them up. > > konsole, however, is a significant application in its own right that doesn't > actually share code with the rest of the apps in there (besides Qt, kdelibs > and runtime, of course ;). so it is getting its own repo. > > if there are any questions / concerns / thoughts on this, please provide your > feedback now as we'd like to make the move as soon as possible once 4.6.0 is > released. > > also, please keep all relevant discussion on kde-core-devel rather than > CC'ing > all the lists; i just CC'd the lists so everyone there who may not be on > k-c-d > as well receives the information :) > Having konsole, ksysguard, etc in their own git repo is fine. But they still will reside logically inside kdebase-apps For example on api.kde.org the EBN and LXR.
Re: splitting up kdebase in git
On 18 January 2011 21:34, Aaron J. Seigo wrote: > konsole, however, is a significant application in its own right that doesn't > actually share code with the rest of the apps in there (besides Qt, kdelibs > and runtime, of course ;). so it is getting its own repo. > > if there are any questions / concerns / thoughts on this, please provide your > feedback now as we'd like to make the move as soon as possible once 4.6.0 is > released. apps/ksysguard could get its own repo as well. It's completely standalone, and (a few?) people want to compile ksysguardd (the daemon) by itself. John
splitting up kdebase in git
hi all ... when looking at migrating kdebase to git (thanks to Ian Monroe for his efforts there and for the support of KO Gmbh that helped make that happen), it was decided to split it up into chunks which are: * kdebase runtime (git -> kderuntime) * kdebase workspace (git -> kdeworkspace) * kdebase apps, minus konsole (git -> kdebase-apps) * konsole runtime / workspace / apps as divisions already reflects changes made starting with 4.0. even now in svn, code in one of those is not allowed to have a compile time dependency on code in the other two. this is why, for instance, folderview is in kdebase/apps/: it relies on libkonq which is also in there. kdebase-apps is being kept together because there is a lot of code sharing between the projects there, particularly in the form of file management code in libkonq. it was determined by the maintainers of each that there was nothing but a loss of efficiency and increased pain to be gained from splitting them up. konsole, however, is a significant application in its own right that doesn't actually share code with the rest of the apps in there (besides Qt, kdelibs and runtime, of course ;). so it is getting its own repo. if there are any questions / concerns / thoughts on this, please provide your feedback now as we'd like to make the move as soon as possible once 4.6.0 is released. also, please keep all relevant discussion on kde-core-devel rather than CC'ing all the lists; i just CC'd the lists so everyone there who may not be on k-c-d as well receives the information :) -- 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 Qt Development Frameworks signature.asc Description: This is a digitally signed message part.
