Re: the next step on the desktop
On Tirsdag den 1. februar 2011, Aaron J. Seigo wrote: On Monday, January 31, 2011, Anders Lund wrote: Please do not make everything the desktop, as long as it is not keyboard accerssible! I avoid using plasma-notebook, since it is an interface for clickers. please do not make knee-jerk reactions. please create informed opinions, ask questions reasonably and i promise that you'll get informed, reasonable answers. Please do not be rude, you end up making me feel bad every time you answer any question or comment I make. If you can not handle that I do not always see things same way you do without being unnice, please ignore me. so ... SAL is keyboard navigable. keyboard shortcuts can get focus to any given widget. the thing i did notice that isn't keyboardable when testing right now is tab-ing out of the top shortcut strip. My experince with SAL so far is that I start it, look at it and do not know what to do except clicking in the entry field, which makes me immediately go back to the normal desktop. For SAL to work like that, the search entry should have focus when it is displayed, which is not currently the case. It it would do that, it would be usable, and in fact be what I have been looking for for long time: A SAL that is in the center and having space enough to make it really easy to pick the desired result. Of course there are other concerns: The current dashboard display is not working well, the background is too noisy behind it, and very much I actually have very valuable widgets on my desktop that I use often, and that I can display or hide hide with a single shortcut. Hey Plasma have very great value, thanks again for that :) So the message is not that I am against improvements or evolution, rather that I strive for them being usable for everyone, including keyboard users. The good keyboard support is one of my favorite KDE features! ad the intention is not to make everything the desktop :) Good :) -- Venlig hilsen, Anders
Re: the next step on the desktop
A Segunda, 31 de Janeiro de 2011 23:58:54 Anders Lund você escreveu: Please do not make everything the desktop, as long as it is not keyboard accerssible! I avoid using plasma-notebook, since it is an interface for clickers. Such interfaces may make sense for tablets and phones, NOT for anything with a keyboard! contrary to what some beleve the mouse does some jobs better than the keyboard :), plus major major plus the things a mouse does are very very difrent from what a touch based interface does... -- Nuno Pinheiro | nuno.pinhe...@kdab.com | UI Designer Klarälvdalens Datakonsult AB, a KDAB Group company KDAB - Qt Experts - Platform-independent software solutions
Re: Merge or Cherry-Pick?
On Tue, Feb 01, 2011 at 08:18:10AM +0100, Thiago Macieira wrote: On Tuesday, 1 de February de 2011 01:23:01 Oswald Buddenhagen wrote: just face it, git's merging concept makes most sense for longer-lived feature branches, but not so much for bugfix branches. not even linux itself uses a forward-merge strategy for bugfix branches. How does the kernel work then? As far as I know, everything is merged. not bugfix branches, e.g. what will become 2.6.37.1. it is in fact maintained by a different person and linus doesn't care much for it. it just works better if the stability of a patch is proven in someone higher up the hierarchy's master. fwiw, even in linux' history you'll find merged cherry-picks, but that's presumably because less critical bugfixes often take so long to propagate in the hierarchy. having said that, i do think a clean forward-merging strategy is worthwhile and feasible, given the proper infrastructure and mindsets - e.g. what i envision for qt's opengov. but this is so utterly incompatible with kde's resources and low quality standards^W^Wbarrier to entry culture.
Re: Merge or Cherry-Pick?
On Tue, Feb 01, 2011 at 01:43:17AM +0100, Andreas Pakulat wrote: I'm constantly doing the tag --contains and branch --contains thing to find out when a certain fix was done at work to double-check wether a reported bug is already contained in a released version. Or which branches are affected by a bug introduced by a specific commit. this could be implemented by a secondary merge tracking mechanism which works like svn's. git somewhat recently got the notes feature which allows attaching pretty much any textual metadata to commits without altering them. it's just that somebody would have to write that code ...
Re: Merge or Cherry-Pick?
On Mon, January 31, 2011 11:27 pm, Thiago Macieira wrote: On Monday, 31 de January de 2011 23:34:39 Arno Rehn wrote: I guess that won't quite work when there are commits specific to 4.6 in the 4.6 branch that shouldn't end up in master. And it clutters history with tons of merges. Then let's solve the problem by not having anything specific to 4.6. If it belongs in the stable release, it belongs in the next stable release too. That's not always true. Some changes *will* be specific to 4.6, because sections of code in master can get rewritten, features added or removed, so the changes won't be applicable there. -- David Jarvie. KDE developer. KAlarm author - http://www.astrojar.org.uk/kalarm
Re: proposal: remove KTextEditor interface from kdelibs repository
On 2011-02-01, Aaron J. Seigo ase...@kde.org wrote: --nextPart3865859.bpjpIik9D5 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable On Monday, January 31, 2011, Michael Pyne wrote: On Monday, January 31, 2011 17:42:56 Aaron J. Seigo wrote: potential caveats are that it makes it harder to build certain KDE apps because now you need not only kdelibs, but kate. this is already true f= or things that require libs in kde-support, kdepimlibs or kdegraphics, though. =20 This is more a package management concern, and while I do want to avoid indeed; i'm hoping one or more of the packagers will chime in at some point. I have commented on the kate developers plans more than once, but people just seems to bring it up over and over again. But no. Nothing has changed in my perception of things. So far, we as packagers have been told that applications can expect all plugins (kio slaves, kparts, ...) located in kdelibs and kdebase-runtime to be available, and segfault is a acceptable way of handling missing things. Application developers has made their *current* apps based on this, and stuff will break by moving e.g. katepart out of kdelibs. Now KTextEditor. KTextEditor is a public library in kdelibs. This means that people can actually expect KTextEditor to be there when they do find_package(KDE4 REQUIRED) It also means that people who builds from source can do svn up / git pull in kdelibs and install new requirements,make, make install and still have all apps working. I'm unsure why we wants to break the promises we made to the rest of the world about the stability of our libraries. (oh. and why should a kile/kdevelop/... user compile and install kate?) /Sune - who as a packager will have a hard time effectively undoing this work in order to *keep* the compatibility. As a packager, I actually trust KDE to live up to their promises.
Re: proposal: remove KTextEditor interface from kdelibs repository
On Tuesday, February 01, 2011 11:11:08 am Sune Vuorela wrote: On 2011-02-01, Aaron J. Seigo ase...@kde.org wrote: --nextPart3865859.bpjpIik9D5 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable On Monday, January 31, 2011, Michael Pyne wrote: On Monday, January 31, 2011 17:42:56 Aaron J. Seigo wrote: potential caveats are that it makes it harder to build certain KDE apps because now you need not only kdelibs, but kate. this is already true f= or things that require libs in kde-support, kdepimlibs or kdegraphics, though. =20 This is more a package management concern, and while I do want to avoid indeed; i'm hoping one or more of the packagers will chime in at some point. I have commented on the kate developers plans more than once, but people just seems to bring it up over and over again. But no. Nothing has changed in my perception of things. So far, we as packagers have been told that applications can expect all plugins (kio slaves, kparts, ...) located in kdelibs and kdebase-runtime to be available, and segfault is a acceptable way of handling missing things. I agree that this will lead to additional dependency to kate package for some modules, but is this that bad? Application developers has made their *current* apps based on this, and stuff will break by moving e.g. katepart out of kdelibs. Now KTextEditor. KTextEditor is a public library in kdelibs. This means that people can actually expect KTextEditor to be there when they do find_package(KDE4 REQUIRED) Yeah, and because of this requirement, which I can agree on, I didn't remove it from kdelibs, as its public API and I wanted to be SC + BC. And no, runtime components moving to other modules is not a SC/BC problem. It also means that people who builds from source can do svn up / git pull in kdelibs and install new requirements,make, make install and still have all apps working. They never can do that. Every now and then new dependencies come up. New versions of virtuoso needed, new lib*, whatever. You NEVER was able to rely that you can just up + recompile kdelibs and be fine. Normally it not even compiled... I'm unsure why we wants to break the promises we made to the rest of the world about the stability of our libraries. (oh. and why should a kile/kdevelop/... user compile and install kate?) Because it uses katepart? We could even split it up more, in more repos, like katepart, kate, kwrite, but given they interdepend a lot, that is even more hassle. Beside, kile users won't compile it, they will use the versions shipped with the distro. /Sune - who as a packager will have a hard time effectively undoing this work in order to *keep* the compatibility. As a packager, I actually trust KDE to live up to their promises. I still no get this problem. kdelibs adds more and more dependencies over the last years, same for other modules. Why is this dependency change different at all? It is not even a compile time dependency change... Beside: I am grateful for your work as packager and don't want to annoy you. But really, the whole git moving only makes sense, if stuff that is related is grouped. And no, beside using kdelibs stuff, katepart and co. is not really related. And working over 3 repositories is a hassle. (you need to clone all, thats slow on dialup, you need to send at most 3 patches, you need to fiddle with CMake to build only the kate parts, if you want only to have katepart and co. fresh and not all libs, ...) I can understand that new dependencies are work, but I don't see the problem in comparison to other dependencies which change the whole time. To get new contributors for Kate, it is essential, that working on it is EASY. And the current way is easy (http://kate-editor.org/get-it/), the old not. Greetings Christoph -- -- Christoph Cullmann - AbsInt Angewandte Informatik GmbH Email: cullm...@absint.com Science Park 1 Tel: +49-681-38360-22 66123 Saarbrücken Fax: +49-681-38360-20 GERMANYWWW: http://www.AbsInt.com Geschäftsführung: Dr.-Ing. Christian Ferdinand Eingetragen im Handelsregister des Amtsgerichts Saarbrücken, HRB 11234
Re: proposal: remove KTextEditor interface from kdelibs repository
On Tuesday, 2011-02-01, Christoph Cullmann wrote: On Tuesday, February 01, 2011 11:11:08 am Sune Vuorela wrote: So far, we as packagers have been told that applications can expect all plugins (kio slaves, kparts, ...) located in kdelibs and kdebase-runtime to be available, and segfault is a acceptable way of handling missing things. I agree that this will lead to additional dependency to kate package for some modules, but is this that bad? It would require a new kdelibs package (the new one will no longer satisfy the same needs) or require that the packagers extract the interface related things from kate and add them as a dependency for the kdelibs meta package. Application developers has made their *current* apps based on this, and stuff will break by moving e.g. katepart out of kdelibs. Now KTextEditor. KTextEditor is a public library in kdelibs. This means that people can actually expect KTextEditor to be there when they do find_package(KDE4 REQUIRED) Yeah, and because of this requirement, which I can agree on, I didn't remove it from kdelibs, as its public API and I wanted to be SC + BC. And no, runtime components moving to other modules is not a SC/BC problem. While it is SC/BC, it changes the contents of the kdelibs package. Either packagers put in extra effort of extracting the now missing parts from Kate and add them as dependencies to kdelibs or they create a new version of kdelibs which no longer satisfies the dependency rules of all applications packaged against the old one (or with even more effort adding the old kdelibs package as an alternative for all program packages that do not use the runtime dependency). It also means that people who builds from source can do svn up / git pull in kdelibs and install new requirements,make, make install and still have all apps working. They never can do that. Every now and then new dependencies come up. New versions of virtuoso needed, new lib*, whatever. You NEVER was able to rely that you can just up + recompile kdelibs and be fine. Normally it not even compiled... The difference is that new dependencies add things to kdelibs so they can only be used by applications built against that new version. Removing a dependency would mean you'd have to check all applications on whether they need the removed dependency and explicitly add it to their dependency list. Or do you mean kate would become an additional depencency of kdelibs (however that would work)? I still no get this problem. kdelibs adds more and more dependencies over the last years, same for other modules. Why is this dependency change different at all? It is not even a compile time dependency change... My guess is that there are different rules for removal of functionality than there are for adding. On source or binary level we can always add (non-virtual) functions but we cannot remove any. When we make kdelibs depend on something, we usually put quite some effort into our layer to make sure we can change dependencies without changing dependencies for apps built on kdelibs, e.g. make kdelibs depend on different libraries for new Solid backend implementations without requiring new dependency rules for all applications using Solid. Cheers, Kevin -- Kevin Krammer, KDE developer, xdg-utils developer KDE user support, developer mentoring signature.asc Description: This is a digitally signed message part.
Fwd: Top 15 Mailinglists with messages in moderation
The monthly overview - Forwarded Message - 342 decibel 80 kmobiletools 47 kde-contests 46 kde-i18n-pt 43 kgraphviewer-devel 41 kdelibs-bugs 32 kde-usability 31 dot-stories 29 plasma-bugs 29 kde-java 20 kde-embedded 19 kde-openserver 19 kde-news-de 19 kde-france-ca 18 season-of-kde -- Tom Albers KDE Sysadmin
Re: Policy on git feature branches
On 02/01/2011 11:11 AM, Andreas Pakulat wrote: On 01.02.11 10:21:01, Sebastian Trüg wrote: Hi list, I have been working on an improvement for Nepomuk via git-svn for a while now and would now like to push it to kde-runtime. If the branch has been created via git-svn you cannot merge it properly. You need to cherry-pick all commits. However, I would prefer to keep the commit history and backport to 4.6. Thus, I thought of pushing my feature branch into the kde-runtime That won't work, as git-svn created different commits for all the history your branch is based on. So git cannot merge your branch into kde-runtimes history. The only options are to either cherry-pick all commits or rebase your feature branch onto kde-runtime as it is now. Then you can merge it. I did cherry-pick them all into a new branch in my local kde-runtime clone. Merging itself should be local, the history of the branch will be preserved anyway (specify --no-ff in case git merge decides to try a fast-forward) even if you don't push the feature branch into the remote repository. So I merge into master and 4.6 locally and then simply push the two, right? Cheers, Sebastian
Re: Policy on git feature branches
On 01.02.11 13:05:49, Sebastian Trüg wrote: On 02/01/2011 11:11 AM, Andreas Pakulat wrote: On 01.02.11 10:21:01, Sebastian Trüg wrote: Hi list, I have been working on an improvement for Nepomuk via git-svn for a while now and would now like to push it to kde-runtime. If the branch has been created via git-svn you cannot merge it properly. You need to cherry-pick all commits. However, I would prefer to keep the commit history and backport to 4.6. Thus, I thought of pushing my feature branch into the kde-runtime That won't work, as git-svn created different commits for all the history your branch is based on. So git cannot merge your branch into kde-runtimes history. The only options are to either cherry-pick all commits or rebase your feature branch onto kde-runtime as it is now. Then you can merge it. I did cherry-pick them all into a new branch in my local kde-runtime clone. Merging itself should be local, the history of the branch will be preserved anyway (specify --no-ff in case git merge decides to try a fast-forward) even if you don't push the feature branch into the remote repository. So I merge into master and 4.6 locally and then simply push the two, right? Yes. Except that I thought 4.6 was staying feature-frozen not only in kdelibs but also kde-runtime and other modules. But then I don't follow that stuff closely, so maybe I'm wrong. Andreas -- You should go home.
Re: Policy on git feature branches
On 02/01/2011 01:21 PM, Andreas Pakulat wrote: On 01.02.11 13:05:49, Sebastian Trüg wrote: On 02/01/2011 11:11 AM, Andreas Pakulat wrote: On 01.02.11 10:21:01, Sebastian Trüg wrote: Hi list, I have been working on an improvement for Nepomuk via git-svn for a while now and would now like to push it to kde-runtime. If the branch has been created via git-svn you cannot merge it properly. You need to cherry-pick all commits. However, I would prefer to keep the commit history and backport to 4.6. Thus, I thought of pushing my feature branch into the kde-runtime That won't work, as git-svn created different commits for all the history your branch is based on. So git cannot merge your branch into kde-runtimes history. The only options are to either cherry-pick all commits or rebase your feature branch onto kde-runtime as it is now. Then you can merge it. I did cherry-pick them all into a new branch in my local kde-runtime clone. Merging itself should be local, the history of the branch will be preserved anyway (specify --no-ff in case git merge decides to try a fast-forward) even if you don't push the feature branch into the remote repository. So I merge into master and 4.6 locally and then simply push the two, right? Yes. Except that I thought 4.6 was staying feature-frozen not only in kdelibs but also kde-runtime and other modules. But then I don't follow that stuff closely, so maybe I'm wrong. It is not really a feature. Just a fix/improvement/whatever which is rather heavy. Cheers, Sebastian
Re: Top 15 Mailinglists with messages in moderation
On 1 February 2011 12:01, Tom Albers t...@kde.org wrote: The monthly overview - Forwarded Message - 342 decibel I think it's safe to kill this list. The project has been in the land of the unmaintained for at least a year now. snip 41 kdelibs-bugs This is a very useful list for bug triagers - I can volunteer to moderate it if no-one else is currently doing it. snip 29 plasma-bugs Same as kdelibs-bugs for this one. -- George
Re: proposal: remove KTextEditor interface from kdelibs repository
erf; two dependencies in kdelibs on KTextEditor. ok, that makes it a no go then ... hm.. looking at it, only khtml has a build-time dependency on it. if the texteditor part isn't available (or the source of the crash even? :) what does the debugger do at that point? Pop up an error message and abort execution, as it expects it to be part of kdelibs. Which is coincidentally very similar to what KTextEditor tutorials suggest --- see http://techbase.kde.org/Development/Tutorials/Kate/KTextEditor_Example (except it needs katepart in specific) So, as far as I am concerned, this is an incompatible change. (Moving to kdebase-runtime would be fine, of course).
Re: Fwd: Top 15 Mailinglists with messages in moderation
Quoting Tom Albers t...@kde.org: 80 kmobiletools 20 kde-embedded We already have kde-mobile...maybe it's safe to remove these two mailing lists? Cheers, Artur ---
Re: proposal: remove KTextEditor interface from kdelibs repository
Mardi, le 1 février 2011, à 16:43, Maksim Orlovich a écrit: erf; two dependencies in kdelibs on KTextEditor. ok, that makes it a no go then ... hm.. looking at it, only khtml has a build-time dependency on it. if the texteditor part isn't available (or the source of the crash even? :) what does the debugger do at that point? Pop up an error message and abort execution, as it expects it to be part of kdelibs. Which is coincidentally very similar to what KTextEditor tutorials suggest --- see http://techbase.kde.org/Development/Tutorials/Kate/KTextEditor_Example (except it needs katepart in specific) Uh, that is old-fashioned. Should instead ask the user whether she wants to install the proper text editor module. Isn't there some simple standard api for that these days? Cheers Friedrich -- Desktop Summit 2011 - Berlin, Germany - August 6-12th - www.desktopsummit.org
Re: kdelibs, kdebase moving to Git this Saturday
Alle venerdì 28 gennaio 2011, Nicolas Alvarez ha scritto: What do you all think of removing wallpapers from these git repositories? We could put them in a separate git repository, or even keep them in SVN. Now that the workspace repository was pushed without them (so breaking history, past tags and branches), where are the wallpapers now? -- Pino Toscano signature.asc Description: This is a digitally signed message part.
Re: proposal: remove KTextEditor interface from kdelibs repository
On Tuesday, February 1, 2011, Sune Vuorela wrote: So far, we as packagers have been told that applications can expect all plugins (kio slaves, kparts, ...) located in kdelibs and kdebase-runtime to be available, and segfault is a acceptable way of handling missing things. to boil it down to its essence, then, the primary issue is that we have a black box with various runtime plugins in it that applications may or may not rely on. perhaps we should think about being more clear in our runtime definitions and stricter with requiring apps to advertise their runtime expectations, so that we can go from having a huge pile of dependencies to just the requirements for a given application. there's also a conflict of interest between packaging and development going on here. development needs/wants one thing, packaging needs/wants a different thing. exploring ways to more clearly and cleanly create a working division bewteen development and release management may be something for us to consider as well. (i'm thinking about the above mostly in the context of the upcoming Platform11 dev sprint in June .. gathering topics :) -- 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: Top 15 Mailinglists with messages in moderation
On Tuesday, February 1, 2011, George Goldberg wrote: 29 plasma-bugs Same as kdelibs-bugs for this one. i'd appreciate the help with it :) -- 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: proposal: remove KTextEditor interface from kdelibs repository
On 2011-02-01, Friedrich W. H. Kossebau kosse...@kde.org wrote: Uh, that is old-fashioned. Should instead ask the user whether she wants to install the proper text editor module. Isn't there some simple standard api for that these days? A simple standard api for what? installations of scripts and wallpapers and stuff, sure. there is the ghns things. For isntallation of compiled stuff, no. And I'm not sure there should be such a thing. /Sune
Re: proposal: remove KTextEditor interface from kdelibs repository
On 2011-02-01, Aaron J. Seigo ase...@kde.org wrote: perhaps we should think about being more clear in our runtime definitions a= nd=20 stricter with requiring apps to advertise their runtime expectations, so th= at=20 we can go from having a huge pile of dependencies to just the requirements = for=20 a given application. I'm all for modularizing and being more clear, but it should not be done by tearing out parts of kdelibs to see what happens. Rather: Identify how we want apps to communicate their runtime requirements. Get apps to specify it using the communication way described above. This is for all apps built on the KDE Platform, no matter if they resides in git.kde.org, gitorious, launchpad or sourceforge. Get packagers and others to test that things work Break things apart at tarball generation. Test that things work Break up repositories Profit. /Sune
Re: proposal: remove KTextEditor interface from kdelibs repository
On Mon, Jan 31, 2011 at 21:19, Aaron J. Seigo ase...@kde.org wrote: [snip] oh well, KTextEditor isn't an option, Should we give up so easily on this? The whole point of modularization is to remove cross-module dependencies, just like KHTML depending on KTextEditor. Ideally this sort of sideways dependency wouldn't exist. Actually splitting up repos is the easy and less interesting part overall. Ian
Re: proposal: remove KTextEditor interface from kdelibs repository
Mardi, le 1 février 2011, à 18:53, Sune Vuorela a écrit: On 2011-02-01, Friedrich W. H. Kossebau kosse...@kde.org wrote: Uh, that is old-fashioned. Should instead ask the user whether she wants to install the proper text editor module. Isn't there some simple standard api for that these days? A simple standard api for what? installations of scripts and wallpapers and stuff, sure. there is the ghns things. For isntallation of compiled stuff, no. Not something related to packagekit or similar? Eh, IMHO there should be something like that if there isn't. With OBS and Co. compiled stuff is not that much different, you just get a variant tailored to your (hardware) profil. Can someone please empty my TODO list? :) And I'm not sure there should be such a thing. Hm. You don't agree that a user experience like Sorry, missing X to do Y. Would you like to get X now for that? is better than one à la Na, no way to do Y.? Cheers Friedrich -- Desktop Summit 2011 - Berlin, Germany - August 6-12th - www.desktopsummit.org
Re: Top 15 Mailinglists with messages in moderation
On 01/02/2011, George Goldberg grundleb...@googlemail.com wrote: On 1 February 2011 12:01, Tom Albers t...@kde.org wrote: The monthly overview - Forwarded Message - 342 decibel I think it's safe to kill this list. The project has been in the land of the unmaintained for at least a year now. But it should get moderated at least once more. What if there's 300 spam messages and 42 people wanting to resurrect the project? ;) -- Nicolas
Re: proposal: remove KTextEditor interface from kdelibs repository
On 2011-02-01, Friedrich W. H. Kossebau kosse...@kde.org wrote: And I'm not sure there should be such a thing. Hm. You don't agree that a user experience like Sorry, missing X to do Y. Would you like to get X now for that? is better than one à la Na, no way to do Y.? Yes. since we can't assume the user has the right to install to the system directory, and we shouldn't set up a complete development environment for him. /Sune
Re: proposal: remove KTextEditor interface from kdelibs repository
On Tuesday 01 February 2011, Kevin Krammer wrote:
On Tuesday, 2011-02-01, Christoph Cullmann wrote:
...
Yeah, and because of this requirement, which I can agree on, I didn't
remove it from kdelibs, as its public API and I wanted to be SC + BC. And
no, runtime components moving to other modules is not a SC/BC problem.
While it is SC/BC, it changes the contents of the kdelibs package.
Either packagers put in extra effort of extracting the now missing parts
from Kate and add them as dependencies to kdelibs or they create a new
version of kdelibs which no longer satisfies the dependency rules of all
applications packaged against the old one (or with even more effort adding
the old kdelibs package as an alternative for all program packages that do
not use the runtime dependency).
This is about removing libktexteditor, installed currently by kdelibs, from
kdelibs, and moving it into the kate repository, right ?
This would be a source incompatible change.
find_package(KDE4 REQUIRED)
add_executable(Foo ${mySrcs})
target_link_libraries(Foo ${KDE4_KTEXTEDITOR_LIBS})
- does not work anymore, because you cannot rely on that libktexteditor is
there if kdelibs has been found.
So, from my POV, this can't be done for KDE 4.x.y.
Alex
Installing specific packages on demand (was: Re: proposal: remove KTextEditor interface from kdelibs repository)
Mardi, le 1 février 2011, à 19:39, Sune Vuorela a écrit: On 2011-02-01, Friedrich W. H. Kossebau kosse...@kde.org wrote: And I'm not sure there should be such a thing. Hm. You don't agree that a user experience like Sorry, missing X to do Y. Would you like to get X now for that? is better than one à la Na, no way to do Y.? Yes. since we can't assume the user has the right to install to the system directory, We can't assume for all, but in many installations the user does. Like the ususal private computer. For administrated systems, there could be a substitute which instead of allowing to install rather aids the user to file a request to the admin, for convenience and getting things done. and we shouldn't set up a complete development environment for him. I was thinking of interfacing to the normal packaging system of the system. He, something like DrKonqi installing the debug info packages on request. So something like that is existing already, just needs to be generalized perhaps. Cheers Friedrich -- Desktop Summit 2011 - Berlin, Germany - August 6-12th - www.desktopsummit.org
Re: Initial support for kde_projects.xml in kdesrc-build
On Monday 31 January 2011, Aaron J. Seigo wrote: On Sunday, January 30, 2011, Michael Pyne wrote: Like I said, xml-support branch on kdesrc-build git. If you want to give _very_ cool. will the good news today never end? ;) serious question: once this is stabilized, can we make this the default recommended way of building KDE from git on techbase? pros that i can think of: * it would mean that we could cannibalize the docs for kdesrc-build for those pages on techbase * it would be a lot simpler to document than the current 7 headed hydra monster pages we have now :) The big thing is getting all the required dependencies built and installed, or do you see other things which are complicated in building KDE modules ? Alex
Re: proposal: remove KTextEditor interface from kdelibs repository
Mardi, le 1 février 2011, à 19:42, Alexander Neundorf a écrit: On Tuesday 01 February 2011, Friedrich W. H. Kossebau wrote: Mardi, le 1 février 2011, à 18:53, Sune Vuorela a écrit: On 2011-02-01, Friedrich W. H. Kossebau kosse...@kde.org wrote: Uh, that is old-fashioned. Should instead ask the user whether she wants to install the proper text editor module. Isn't there some simple standard api for that these days? A simple standard api for what? installations of scripts and wallpapers and stuff, sure. there is the ghns things. For isntallation of compiled stuff, no. Not something related to packagekit or similar? Eh, IMHO there should be something like that if there isn't. With OBS and Co. compiled stuff is not that much different, you just get a variant tailored to your (hardware) profil. Can someone please empty my TODO list? :) And I'm not sure there should be such a thing. Hm. You don't agree that a user experience like Sorry, missing X to do Y. Would you like to get X now for that? is better than one à la Na, no way to do Y.? I think Lubos proposed something like this recently, i.e. at some point last year here on this list. Others have done now and then as well, e.g., ahem, me ;) here a few years ago: http://markmail.org/message/xo2b4zw2ee6si6g2 Oh, how cheap talk is :P Cheers Friedrich -- Desktop Summit 2011 - Berlin, Germany - August 6-12th - www.desktopsummit.org
Re: proposal: remove KTextEditor interface from kdelibs repository
On Tuesday 01 February 2011, Friedrich W. H. Kossebau wrote: Mardi, le 1 février 2011, à 19:42, Alexander Neundorf a écrit: On Tuesday 01 February 2011, Friedrich W. H. Kossebau wrote: Mardi, le 1 février 2011, à 18:53, Sune Vuorela a écrit: On 2011-02-01, Friedrich W. H. Kossebau kosse...@kde.org wrote: Uh, that is old-fashioned. Should instead ask the user whether she wants to install the proper text editor module. Isn't there some simple standard api for that these days? A simple standard api for what? installations of scripts and wallpapers and stuff, sure. there is the ghns things. For isntallation of compiled stuff, no. Not something related to packagekit or similar? Eh, IMHO there should be something like that if there isn't. With OBS and Co. compiled stuff is not that much different, you just get a variant tailored to your (hardware) profil. Can someone please empty my TODO list? :) And I'm not sure there should be such a thing. Hm. You don't agree that a user experience like Sorry, missing X to do Y. Would you like to get X now for that? is better than one à la Na, no way to do Y.? I think Lubos proposed something like this recently, i.e. at some point last year here on this list. Others have done now and then as well, e.g., ahem, me ;) here a few years ago: http://markmail.org/message/xo2b4zw2ee6si6g2 Oh, how cheap talk is :P I think this might be related: http://www.kdedevelopers.org/node/4232 Alex
Re: Installing specific packages on demand
Mardi, le 1 février 2011, à 20:10, Sune Vuorela a écrit: On 2011-02-01, Friedrich W. H. Kossebau kosse...@kde.org wrote: We can't assume for all, but in many installations the user does. Like the ususal private computer. For administrated systems, there could be a substitute which instead of allowing to install rather aids the user to file a request to the admin, for convenience and getting things done. and we shouldn't set up a complete development environment for him. I was thinking of interfacing to the normal packaging system of the system. He, something like DrKonqi installing the debug info packages on request. So something like that is existing already, just needs to be generalized perhaps. Basically, a piece of software than have three relations: 1) Required things 2) Optional things that should be availably by default 3) optional things that doesn't need to be available by default Packagers should assure that 1) is around. Packagers should try hard to make 2) available for all not uncommon installations. if 1) is missing, file bugs at the distribution. if 2) is missing, file bugs at the distribution or alternatively tell the user you broke your system, you get to keep the pieces. And then there is the handling of 3). Well.. let's not make it a bigger issue than it actually is. Ah, Sune, guess we were missing each other :) I was talking of currently not installed optional things. And not speaking of optional things not existing as packages. E.g. imagine someone installing some program over an expensive/slow connection (think mobile). She just installs the required things, to keep the needed bandwith low. Then hits a feature which is more useful with some optional thing X. Ideally the feature's code would be able to offer the action Trigger install of optional thing X to pimp doing Y. Does this help to understand what I am looking forward to? Cheers Friedrich -- Desktop Summit 2011 - Berlin, Germany - August 6-12th - www.desktopsummit.org
Re: Initial support for kde_projects.xml in kdesrc-build
On Tuesday 01 February 2011 19:53:40 Alexander Neundorf wrote: On Monday 31 January 2011, Aaron J. Seigo wrote: On Sunday, January 30, 2011, Michael Pyne wrote: Like I said, xml-support branch on kdesrc-build git. If you want to give _very_ cool. will the good news today never end? ;) serious question: once this is stabilized, can we make this the default recommended way of building KDE from git on techbase? pros that i can think of: * it would mean that we could cannibalize the docs for kdesrc-build for those pages on techbase * it would be a lot simpler to document than the current 7 headed hydra monster pages we have now :) The big thing is getting all the required dependencies built and installed, or do you see other things which are complicated in building KDE modules ? yes i do. 1. It is a lot of work. if you work on base and want to run trunk there is a myriad of modules to build to get a useful setup. 2. environment variables (which and how to setup). Separate build environment from distro stuff that could interfere. 3. build order 4. which branches, version from which repo (only relevant for some modules) Alex
Re: the next step on the desktop
A stray thought on making plasma-netbook easier to use: have a shortcut to the search field, and put it in the text, so it reads F2 to search instead of Search (given F2 is the shortcut). That way it will be visible to the user what to do. -- Venlig hilsen, Anders
Re: Initial support for kde_projects.xml in kdesrc-build
On Tuesday 01 February 2011, Michael Jansen wrote: On Tuesday 01 February 2011 19:53:40 Alexander Neundorf wrote: On Monday 31 January 2011, Aaron J. Seigo wrote: On Sunday, January 30, 2011, Michael Pyne wrote: Like I said, xml-support branch on kdesrc-build git. If you want to give _very_ cool. will the good news today never end? ;) serious question: once this is stabilized, can we make this the default recommended way of building KDE from git on techbase? pros that i can think of: * it would mean that we could cannibalize the docs for kdesrc-build for those pages on techbase * it would be a lot simpler to document than the current 7 headed hydra monster pages we have now :) The big thing is getting all the required dependencies built and installed, or do you see other things which are complicated in building KDE modules ? yes i do. 1. It is a lot of work. if you work on base and want to run trunk there is a myriad of modules to build to get a useful setup. kdelibs, kdepimlibs, then kdebase. 2. environment variables (which and how to setup). Separate build environment from distro stuff that could interfere. CMAKE_PREFIX_PATH for finding stuff, and install your own stuff e.g. to /opt/mystuff/ Seriously, if that is not enough, what else do you have to do ? Except your lib64-rpath problem. I remember we discussed about that one. What was the outcome ? Problem in cmake itself ? 3. build order Isn't that the same as 1. ? 4. which branches, version from which repo (only relevant for some modules) You mean now with git or also with old svn ? Alex
Re: proposal: remove KTextEditor interface from kdelibs repository
Mardi, le 1 février 2011, à 20:14, Alexander Neundorf a écrit: On Tuesday 01 February 2011, Friedrich W. H. Kossebau wrote: Mardi, le 1 février 2011, à 19:42, Alexander Neundorf a écrit: On Tuesday 01 February 2011, Friedrich W. H. Kossebau wrote: Mardi, le 1 février 2011, à 18:53, Sune Vuorela a écrit: On 2011-02-01, Friedrich W. H. Kossebau kosse...@kde.org wrote: Uh, that is old-fashioned. Should instead ask the user whether she wants to install the proper text editor module. Isn't there some simple standard api for that these days? A simple standard api for what? installations of scripts and wallpapers and stuff, sure. there is the ghns things. For isntallation of compiled stuff, no. Not something related to packagekit or similar? Eh, IMHO there should be something like that if there isn't. With OBS and Co. compiled stuff is not that much different, you just get a variant tailored to your (hardware) profil. Can someone please empty my TODO list? :) And I'm not sure there should be such a thing. Hm. You don't agree that a user experience like Sorry, missing X to do Y. Would you like to get X now for that? is better than one à la Na, no way to do Y.? I think Lubos proposed something like this recently, i.e. at some point last year here on this list. Others have done now and then as well, e.g., ahem, me ;) here a few years ago: http://markmail.org/message/xo2b4zw2ee6si6g2 Oh, how cheap talk is :P I think this might be related: http://www.kdedevelopers.org/node/4232 Oh, nice, missed that before, thanks for the pointer, Alex :) Indeed, that is pretty related. Hm, might be an interesting GSoC task to merge this with DrKonqi's debug packages loading, Phonon's new codec pulling and all the other GHNS/OCS related stuff... so at some not to distant time the KTextEditor example can be changed to code with a better user experience :) Cheers Friedrich -- Desktop Summit 2011 - Berlin, Germany - August 6-12th - www.desktopsummit.org
kdeplasma-addons is on git
Hello! I would like to inform that the move of kdeplasma-addons to git and completed successfully. Now you can find the new repository in: git clone git://anongit.kde.org/kdeplasma-addons Thanks a lot to eean for the help and to our awesome sysadmins. Cheers, Artur ---
Re: Fwd: Top 15 Mailinglists with messages in moderation
On Tuesday 01 February 2011 13:01:32 Tom Albers wrote: 29 kde-java I think we can safely delete that one. We don't have Java bindings anymore and the main bindings ML is kde-bindings. A quick glance at those mails would still be cool (can I somehow view them?). -- Arno Rehn a...@arnorehn.de
Re: proposal: remove KTextEditor interface from kdelibs repository
A Dimarts, 1 de febrer de 2011, Ian Monroe va escriure: On Mon, Jan 31, 2011 at 21:19, Aaron J. Seigo ase...@kde.org wrote: [snip] oh well, KTextEditor isn't an option, Should we give up so easily on this? The whole point of modularization is to remove cross-module dependencies, just like KHTML depending on KTextEditor. Ideally this sort of sideways dependency wouldn't exist. What is your ideal then? Writing KTextEditor in KHTML again since we can not depend on it? Or using a worse component? Albert Actually splitting up repos is the easy and less interesting part overall. Ian
Re: Initial support for kde_projects.xml in kdesrc-build
On Tuesday 01 February 2011 20:35:27 Alexander Neundorf wrote: On Tuesday 01 February 2011, Michael Jansen wrote: On Tuesday 01 February 2011 19:53:40 Alexander Neundorf wrote: On Monday 31 January 2011, Aaron J. Seigo wrote: On Sunday, January 30, 2011, Michael Pyne wrote: Like I said, xml-support branch on kdesrc-build git. If you want to give _very_ cool. will the good news today never end? ;) serious question: once this is stabilized, can we make this the default recommended way of building KDE from git on techbase? pros that i can think of: * it would mean that we could cannibalize the docs for kdesrc-build for those pages on techbase * it would be a lot simpler to document than the current 7 headed hydra monster pages we have now :) The big thing is getting all the required dependencies built and installed, or do you see other things which are complicated in building KDE modules ? yes i do. 1. It is a lot of work. if you work on base and want to run trunk there is a myriad of modules to build to get a useful setup. kdelibs, kdepimlibs, then kdebase. So want Aaaron and me to miss out on kwebkit and scripting, and policykit and rekonq and ... konsole? How do you suppose to use your system without konsole. kdesupport? anyone ... perhaps qt from trunk or qtsoftware to get problems as early as possible? 2. environment variables (which and how to setup). Separate build environment from distro stuff that could interfere. CMAKE_PREFIX_PATH for finding stuff, and install your own stuff e.g. to /opt/mystuff/ Do you only compile stuff? Or do you run it too? Does strigi work for you? STRIGI_PLUGIN_PATH ... but i haven't tested for a while if it needed nowadays. Strigi would not work without it. PKG_CONFIG_PATH, QTDIR (self compiled qt), PATH so your self compiled stuff is picked up, LD_LIBRARY_PATH if you want to run stuff, XDG_DATA_DIRS, KDEDIRS. 3. build order Isn't that the same as 1. ? No. kwebkitpart has to be build after kdelibs and before kdebase. Did you know that? Do you expect Joe NewKdeUser to know? The kdesupport order is much harder to get right. The strigi order? Quick. Order these smokegen, smokeqt, smokekde, qtruby, korundum. 4. which branches, version from which repo (only relevant for some modules) You mean now with git or also with old svn ? Have you ever tried to compile ktorrent? I mean with old svn too. But i expect that to get a tad more difficult with git unless we get a real common branching names strategy. Mike
Re: proposal: remove KTextEditor interface from kdelibs repository
On 01.02.11 19:49:10, Albert Astals Cid wrote: A Dimarts, 1 de febrer de 2011, Ian Monroe va escriure: On Mon, Jan 31, 2011 at 21:19, Aaron J. Seigo ase...@kde.org wrote: [snip] oh well, KTextEditor isn't an option, Should we give up so easily on this? The whole point of modularization is to remove cross-module dependencies, just like KHTML depending on KTextEditor. Ideally this sort of sideways dependency wouldn't exist. What is your ideal then? Writing KTextEditor in KHTML again since we can not depend on it? Or using a worse component? No, the natural fix is to make the dependency chain proper, i.e. KTE depends on kdelibs, khtml depends on KTE+kdelibs. That means khtml cannot be part of kdelibs anymore if KTE is not part of kdelibs anymore. Andreas -- You are confused; but this is your normal state.
Re: proposal: remove KTextEditor interface from kdelibs repository
On Tuesday 01 February 2011, Andreas Pakulat wrote: On 01.02.11 19:49:10, Albert Astals Cid wrote: A Dimarts, 1 de febrer de 2011, Ian Monroe va escriure: On Mon, Jan 31, 2011 at 21:19, Aaron J. Seigo ase...@kde.org wrote: [snip] oh well, KTextEditor isn't an option, Should we give up so easily on this? The whole point of modularization is to remove cross-module dependencies, just like KHTML depending on KTextEditor. Ideally this sort of sideways dependency wouldn't exist. What is your ideal then? Writing KTextEditor in KHTML again since we can not depend on it? Or using a worse component? No, the natural fix is to make the dependency chain proper, i.e. KTE depends on kdelibs, khtml depends on KTE+kdelibs. That means khtml cannot be part of kdelibs anymore if KTE is not part of kdelibs anymore. I agree. Which would mean that khtml would depend on kate. Also the webkit part if it uses the kate component. Which makes the build order harder to get right, as Michael notes in the other thread. Do we want that ? Probably. Can we have that for KDE 4.x.y ? I don't think so. I can remember that a point of criticism about gnome was that it is hard to get it built correctly with all the relatively small independent libs. I think we are moving in that direction... Are we aware of this and is this ok with us ? Alex
Re: Initial support for kde_projects.xml in kdesrc-build
On Tuesday 01 February 2011, Michael Jansen wrote: On Tuesday 01 February 2011 20:35:27 Alexander Neundorf wrote: On Tuesday 01 February 2011, Michael Jansen wrote: On Tuesday 01 February 2011 19:53:40 Alexander Neundorf wrote: On Monday 31 January 2011, Aaron J. Seigo wrote: On Sunday, January 30, 2011, Michael Pyne wrote: Like I said, xml-support branch on kdesrc-build git. If you want to give _very_ cool. will the good news today never end? ;) serious question: once this is stabilized, can we make this the default recommended way of building KDE from git on techbase? pros that i can think of: * it would mean that we could cannibalize the docs for kdesrc-build for those pages on techbase * it would be a lot simpler to document than the current 7 headed hydra monster pages we have now :) The big thing is getting all the required dependencies built and installed, or do you see other things which are complicated in building KDE modules ? yes i do. 1. It is a lot of work. if you work on base and want to run trunk there is a myriad of modules to build to get a useful setup. kdelibs, kdepimlibs, then kdebase. So want Aaaron and me to miss out on kwebkit and scripting, and policykit and rekonq and ... konsole? How do you suppose to use your system without konsole. Yes, with git this has become more stuff. kdesupport? anyone ... perhaps qt from trunk or qtsoftware to get problems as early as possible? I was asking specifically about KDE stuff, i.e. everything starting with kdelibs, not stuff kdelibs depends on (which I also mentioned in my previous mail that this is not too easy to get set up, as you can see above). 2. environment variables (which and how to setup). Separate build environment from distro stuff that could interfere. CMAKE_PREFIX_PATH for finding stuff, and install your own stuff e.g. to /opt/mystuff/ Do you only compile stuff? Or do you run it too? I don't get that far to actually run the stuff I've compiled... A lot of the work I do _for_ KDE is actually work _on_ CMake nowadays. Does strigi work for you? STRIGI_PLUGIN_PATH ... but i haven't tested for a while if it needed nowadays. Strigi would not work without it. PKG_CONFIG_PATH, I don't think so. I never set it for anything. Just use CMAKE_PREFIX_PATH. If something is not found without pkgconfig that's a bug. QTDIR (self compiled qt), Do you need that for running ? For building it's not necessary. Use CMAKE_PREFIX_PATH. PATH so your self compiled stuff For building it's not necessary. Use CMAKE_PREFIX_PATH. is picked up, LD_LIBRARY_PATH if you want to run stuff, RPATH is not working for you ? This would be a bug. XDG_DATA_DIRS, KDEDIRS. This is for running, not for building, right ? 3. build order Isn't that the same as 1. ? No. kwebkitpart has to be build after kdelibs and before kdebase. Did you know that? Do you expect Joe NewKdeUser to know? The kdesupport order is much harder to get right. The strigi order? kdesupport and strigi are before KDE, as mentioned above. This doesn't make it easier, but it is not necessarily anymore in the scope of KDE. Quick. Order these smokegen, smokeqt, smokekde, qtruby, korundum. Ok. kdebindings is weird. 4. which branches, version from which repo (only relevant for some modules) You mean now with git or also with old svn ? Have you ever tried to compile ktorrent? I mean with old svn too. But i expect that to get a tad more difficult with git unless we get a real common branching names strategy. We really need that. Alex
Re: Initial support for kde_projects.xml in kdesrc-build
On Tue, Feb 1, 2011 at 2:58 PM, Michael Jansen i...@michael-jansen.biz wrote: On Tuesday 01 February 2011 20:35:27 Alexander Neundorf wrote: On Tuesday 01 February 2011, Michael Jansen wrote: On Tuesday 01 February 2011 19:53:40 Alexander Neundorf wrote: On Monday 31 January 2011, Aaron J. Seigo wrote: On Sunday, January 30, 2011, Michael Pyne wrote: Like I said, xml-support branch on kdesrc-build git. If you want to give _very_ cool. will the good news today never end? ;) serious question: once this is stabilized, can we make this the default recommended way of building KDE from git on techbase? pros that i can think of: * it would mean that we could cannibalize the docs for kdesrc-build for those pages on techbase * it would be a lot simpler to document than the current 7 headed hydra monster pages we have now :) The big thing is getting all the required dependencies built and installed, or do you see other things which are complicated in building KDE modules ? yes i do. 1. It is a lot of work. if you work on base and want to run trunk there is a myriad of modules to build to get a useful setup. kdelibs, kdepimlibs, then kdebase. So want Aaaron and me to miss out on kwebkit and scripting, and policykit and rekonq and ... konsole? How do you suppose to use your system without konsole. kdesupport? anyone ... perhaps qt from trunk or qtsoftware to get problems as early as possible? 2. environment variables (which and how to setup). Separate build environment from distro stuff that could interfere. CMAKE_PREFIX_PATH for finding stuff, and install your own stuff e.g. to /opt/mystuff/ Do you only compile stuff? Or do you run it too? Does strigi work for you? STRIGI_PLUGIN_PATH ... but i haven't tested for a while if it needed nowadays. Strigi would not work without it. PKG_CONFIG_PATH, QTDIR (self compiled qt), PATH so your self compiled stuff is picked up, LD_LIBRARY_PATH if you want to run stuff, XDG_DATA_DIRS, KDEDIRS. 3. build order Isn't that the same as 1. ? No. kwebkitpart has to be build after kdelibs and before kdebase. Did you know that? Do you expect Joe NewKdeUser to know? a. nope. kwebkitpart only depends on kdelibs! There are no requirements besides that. The previous requirement that you must build kwebkitpart before you compiled the konq-plugins, which have now been moved to kdebase, is now longer valid because of the addition of several Extentsion interfaces to the KParts API. As a result konq-plugins do not have direct dependency on kwebkitpart anymore in KDE = 4.6...
Re: Installing specific packages on demand (was: Re: proposal: remove KTextEditor interface from kdelibs repository)
On Tue, Feb 1, 2011 at 1:55 PM, Friedrich W. H. Kossebau kosse...@kde.org wrote: Mardi, le 1 février 2011, à 19:39, Sune Vuorela a écrit: On 2011-02-01, Friedrich W. H. Kossebau kosse...@kde.org wrote: And I'm not sure there should be such a thing. Hm. You don't agree that a user experience like Sorry, missing X to do Y. Would you like to get X now for that? is better than one à la Na, no way to do Y.? Yes. since we can't assume the user has the right to install to the system directory, We can't assume for all, but in many installations the user does. Like the ususal private computer. For administrated systems, there could be a substitute which instead of allowing to install rather aids the user to file a request to the admin, for convenience and getting things done. and we shouldn't set up a complete development environment for him. I was thinking of interfacing to the normal packaging system of the system. He, something like DrKonqi installing the debug info packages on request. So something like that is existing already, just needs to be generalized perhaps. Cheers Friedrich openSUSE's version of KDE has something like this as well. It might be worth seeing how they do it. -Todd
Re: proposal: remove KTextEditor interface from kdelibs repository
On 2/1/11, Andreas Pakulat ap...@gmx.de wrote: On 01.02.11 19:49:10, Albert Astals Cid wrote: No, the natural fix is to make the dependency chain proper, i.e. KTE depends on kdelibs, khtml depends on KTE+kdelibs. That means khtml cannot be part of kdelibs anymore if KTE is not part of kdelibs anymore. Funny, I would think the proper fix would be for people who put their work into kdelibs to honor the requisite commitment to backwards compatibility, rather than to punish other libraries for doing the right thing in using existing facilities.
Re: Merge or Cherry-Pick?
On Tuesday, February 1, 2011, Alexander Neundorf wrote: On Monday 31 January 2011, Andreas Pakulat wrote: Hi, something that hasn't been written down as far as I can see (if I overlooked it, please point me to it) is what the policy on kdelibs is to be now wrt. merging vs. cherry-picking of changes in branches and master? Andreas Not replying to any particular response in this thread... I don't know whether I missed something, if so, please let me know. no, you didn't miss anything. right now i think everyone is very busy getting up to speed with the basics. for instance, i spent a good portion of the day today struggling with git.reviewboard.kde.org (sysadmin was very helpful, but things are still rough in places ..) there's also the issue that it appears that the 4.6 branch is unmergable with master, complicating things for the time being. in fact, it encourages cherry- picks when probably it should be merges. then i learned today to be extra vigilant about doing `git pull --rebase` and not just `git pull` so i don't accidentally throw merge commits in there while preping for a push. and so yes, it's all a bit hap-hazzard at the moment and many of us are learning at a brisk pace. ;) those that may have much of this information are busy with supporting the migration itself. so ... how do we go from where we are now to where we need to be with documentation? well .. .. i think we need to stop hoping for someone else to do the work. :) there's an email coming in a new thread to get that moving. -- 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: Merge or Cherry-Pick?
On Tue, Feb 1, 2011 at 10:22 PM, Aaron J. Seigo ase...@kde.org wrote: then i learned today to be extra vigilant about doing `git pull --rebase` and not just `git pull` so i don't accidentally throw merge commits in there while preping for a push. Look in man git-config for branch.autosetuprebase. I think this should go into the Git manual after someone has checked this (did not actually try it). Greetings Stefan
irc meeting for kdelibs git workflow
hi everyone ... with git having finally arrived more-or-less, we find ourselves without a well defined work flow for kdelibs (and by extension other KDE repositories) i don't think we can or should hope and pray that our sysadmins will perform another magic trick and solve this for us, nor can we all just sit here looking at each other. so i'd like to suggest that we gather on irc in the near future and hammer this stuff out. weekends tend to be better for many it seems, so i've put up a doodle here: http://doodle.com/htgi56p8n2i7n3i8 where you can register your intention to attend and when you can. it covers this weekend and next. i can't attend this weekend, but that shouldn't stop others if this weekend is best for the majority. a draft agenda might look like: * 3rd party examples we can learn from: http://public.kitware.com/Wiki/Git/Workflow/Topic Qt? ??? * topic branches * strategy overview * git recipes for the common cases * bug fixes * dealing with an unmergable 4.6 * 4.7 and beyond * handling trivial changes * require branches, allow direct to an integration branch or even master? * other common tasks that we should offer nice little recipes for? * adapting http://techbase.kde.org/Policies/SVN_Commit_Policy * using content from http://community.kde.org/Sysadmin/GitKdeOrgManual * identifying other pages on techbase that need work * first draft of workflow documentation the goal should be to emerge from a few hours of meeting with a draft being started based on the early consensus drawn from the meeting. the document(s) can then be passed here on k-c-d for a comment period and then pushed into official status once there's general consensus. -- 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: proposal: remove KTextEditor interface from kdelibs repository
On Tuesday, February 1, 2011, Maksim Orlovich wrote: On 2/1/11, Andreas Pakulat ap...@gmx.de wrote: On 01.02.11 19:49:10, Albert Astals Cid wrote: No, the natural fix is to make the dependency chain proper, i.e. KTE depends on kdelibs, khtml depends on KTE+kdelibs. That means khtml cannot be part of kdelibs anymore if KTE is not part of kdelibs anymore. Funny, I would think the proper fix would be for people who put their work into kdelibs to honor the requisite commitment to backwards compatibility, rather than to punish other libraries for doing the right thing in using existing facilities. it's not about punishing any library or individuals' work. if we modularize kdelibs, then that means we may end up with a small set of interconnected repositories with clear dependency chains. for instance... we could end up with a new kdelibs module that contains just the core stuff such as kdecore, kdeui, kio .. there could be requirements in there about allowable dependencies between those libraries. we may even decide to split things up into dev framework vs platform target. (if this sounds like KDE5 sort of stuff .. well .. yes :) then we'd have other pieces that have been put into kdelibs in the past that maybe should live on as part of the KDE Platform (or whatever call it) but in their own repositories. that could include the KTextEditor interface, perhaps libplasma as well. so in the case of something that uses KTextEditor and is part of kdelibs now, it could still be part of the KDE Platform but be its own module with a dep on corelibs+kate. which is really no different than it is right now, except everything would be explicit and not in one single repository. the big change here would be that applications that require different parts of the KDE Platform might have to define which parts to include (e.g. KTextEditor interface) rather than them being provided implicitly in one big chunk as it is now. the domino effect there would be altering CMakeLists.txt for apps that need KTextEditor (for example) to explicitly include it. alternatively, we could maintain a compatibility FindKDE4-style macro that would pull in all those pieces. so apps that did nothing would still have the same build profile without any modifications, just risk pulling in more libraries than they really need as build requirements. a virtual kdelibs if you will. we sort of have this already with kde-support, imho. apps could then be updated as desired to more accurately note their needs, bringing dependency definition into sharper definition. but most importantly, new apps, or existing Qt apps, could then much more easily say I just want libkdecore or I just want libsolid and get it. there are a hell of a lot of details in between all those broad strokes. if we start pondering them now, though, by the time we hit Randa in June we may be in a very good position to have effective discussions that result in actual decisions :) -- 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: proposal: remove KTextEditor interface from kdelibs repository
On Tuesday, February 1, 2011, Alexander Neundorf wrote: I can remember that a point of criticism about gnome was that it is hard to get it built correctly with all the relatively small independent libs. I think we are moving in that direction... Are we aware of this and is this ok with us ? yes, i am aware of this; and no, i'm not personally ok with it :) if this is to work, we absolutely must find solutions that ballance the benefits of greater modularity with ease of build. there are many possible answers (better build tools; keeping things within the same repositories but with more modular builds within those repostories; relying on packaging instead of upstream tarballs for the modularization) and lots of details to get right (e.g. how to deal with dependencies pulled in at runtime via kde- runtime) i think it is innevitable that we will need to compromise in places to find our optimal mix. it is not a trivial set of questions. we do not, however, need to have an answer today. we have a Platform meeting in June, and we can use the months leading up to that to play around with different scenarios, tugging at the threads to find complications that arise (as we are doing in this thread) and try to have a very good overall picture by the time that in person meeting happens. it's great that we are aware of and thinking about these knock-on effects. it'll take longer than just charging headlong forward, but we will come out with a good solid KDE solution as a result... -- 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: Initial support for kde_projects.xml in kdesrc-build
On Tuesday 01 February 2011, Michael Jansen wrote: ... kdesupport? anyone ... perhaps qt from trunk or qtsoftware to get problems as early as possible? I was asking specifically about KDE stuff, i.e. everything starting with kdelibs, not stuff kdelibs depends on (which I also mentioned in my previous mail that this is not too easy to get set up, as you can see above). So those are not parts of the great big KDE Community and KDE SC? So you do not encourage KDE developers to work on that stuff too? I didn't want to say anything like that. But personally, I care for what is inside KDE. This is what gets released as KDE SC. If this doesn't build properly, I feel guilty. If a package outside KDE SC doesn't build properly, I provide help, but it's up to the respective authors. I must draw a line somewhere. 2. environment variables (which and how to setup). Separate build environment from distro stuff that could interfere. CMAKE_PREFIX_PATH for finding stuff, and install your own stuff e.g. to /opt/mystuff/ Do you only compile stuff? Or do you run it too? I don't get that far to actually run the stuff I've compiled... A lot of the work I do _for_ KDE is actually work _on_ CMake nowadays. That was no knock on you or your excellent work. You ask me what makes compiling kde so difficult and i tell you. Yes, no problem with that. I don't think so. I never set it for anything. Just use CMAKE_PREFIX_PATH. If something is not found without pkgconfig that's a bug. I have no idea what stops working if i unset it. But since i compile KDE with nearly all optional dependencies provided i am pretty sure somewhere in the chain something fails. If you find the place let me know. Do you need that for running ? For building it's not necessary. Use CMAKE_PREFIX_PATH. I always thought that PATH controls which qt version is selected if you have more than one (First qmake found). It was that way some time ago. And QTDIR IS USED in FindQt4.cmake. I don't reevaluate my finding every day so perhaps something changed. Ok. So when an executable is searched, it is searched in a set of default directories (as e.g. /usr/bin/) and in PATH. So setting PATH so that it points to the qmake you want works. CMAKE_PREFIX_PATH is more generic (and didn't exist in cmake 2.4.something). So you can set this too to make cmake find the Qt you want (not pointing to QTDIR/bin, but just to QTDIR). QTDIR is a variable specific to FindQt4.cmake, so it works too. So all three work, the most generic/powerful one is CMAKE_PREFIX_PATH. For building it's not necessary. Use CMAKE_PREFIX_PATH. is picked up, LD_LIBRARY_PATH if you want to run stuff, RPATH is not working for you ? This would be a bug. Yes it is. Even acknowledged by a cmake dev. Which doesn't make it magically work though. That is the lib64 issue you have, right ? I remember this one was tricky. And then there is that funny little gnome helper in okulars build system that totally break without LD_LIBRARY_PATH and sometimes works with LD_LIBRARY_PATH set. XDG_DATA_DIRS, KDEDIRS. This is for running, not for building, right ? I think it is for running mostly. Sometimes some stuff tries to find some policykit, dbus or whatever it was stuff using it. I fixed some of those wrongdoing modules a long time ago. I think there is currently noone misbehaving. Cool :-) Alex
Re: Merge or Cherry-Pick?
On Tuesday, February 1, 2011, Stefan Majewsky wrote: On Tue, Feb 1, 2011 at 10:22 PM, Aaron J. Seigo ase...@kde.org wrote: then i learned today to be extra vigilant about doing `git pull --rebase` and not just `git pull` so i don't accidentally throw merge commits in there while preping for a push. Look in man git-config for branch.autosetuprebase. I think this should go into the Git manual after someone has checked this (did not actually try it). ooh, very cool. ok, i'm going to try running with this and see how it rolls. we _really_ need to start a page to collect all these tidbits together. i'm not sure where yet and i'm afraid i've run out of time for today. an etherpad that we can all edit might be a good place to start collecting these gems, and then we can grab the best bits and put them on a page on techbase... -- 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: Initial support for kde_projects.xml in kdesrc-build
If you find the place let me know. No ... only if i am unable to fix it myself :)) . Do you need that for running ? For building it's not necessary. Use CMAKE_PREFIX_PATH. I always thought that PATH controls which qt version is selected if you have more than one (First qmake found). It was that way some time ago. And QTDIR IS USED in FindQt4.cmake. I don't reevaluate my finding every day so perhaps something changed. Ok. So when an executable is searched, it is searched in a set of default directories (as e.g. /usr/bin/) and in PATH. So setting PATH so that it points to the qmake you want works. CMAKE_PREFIX_PATH is more generic (and didn't exist in cmake 2.4.something). So you can set this too to make cmake find the Qt you want (not pointing to QTDIR/bin, but just to QTDIR). QTDIR is a variable specific to FindQt4.cmake, so it works too. So all three work, the most generic/powerful one is CMAKE_PREFIX_PATH. Then the 100 points question is: If all of them point to a directory with a qt installed (three different versions). Which one wins? a) CMAKE_PREFIX_PATH b) PATH c) QTDIR I remember more than one newbie losing his grip over not beeing able to convince cmake to pickup the right one. Can you answer it without looking at the cmake file? I can't. Yes it is. Even acknowledged by a cmake dev. Which doesn't make it magically work though. That is the lib64 issue you have, right ? I remember this one was tricky. Yes. But there are some executables build and the run during a build that need to pickup the right libs too. I am not sure all of them are doing it right or if there is a right way to do it. The one gnome helper i can point you too is not using cmake. And then there is that funny little gnome helper in okulars build system that totally break without LD_LIBRARY_PATH and sometimes works with LD_LIBRARY_PATH set. Mike
Re: proposal: remove KTextEditor interface from kdelibs repository
On Tue, 1 Feb 2011, Aaron J. Seigo wrote: we could end up with a new kdelibs module that contains just the core stuff such as kdecore, kdeui, kio .. there could be requirements in there about allowable dependencies between those libraries. [...] the big change here would be that applications that require different parts of the KDE Platform might have to define which parts to include (e.g. KTextEditor interface) rather than them being provided implicitly in one big chunk as it is now. Would that be really such a big change? We can certainly redefine a new kdelibs. But I think it will always be just another set where some (sometimes arbitrary boundaries) are drawn. In my eyes, KTextEditor is just a very random example. Will we next have the same discussion about KFileDialog? It uses KPushButton. Should we move out both to avoid sideways dependencies? What I want to say: we can always define what kdelibs comprises. It can be small, it can be big. I don't see a technically perfect optimum, though. At best we can strive for reasonable. Unless unless we find some real technical means to manage compile-time and runtime-dependencies. Maybe even MS Windows can serve as an example of a platform that has gone through all of this, is very extensible and at the same time very much backward compatible? One part of the puzzle I can think of a interfaces (pure .h files) that can be queried at runtime. In one way or the other that has been excersised in KDE in the past already (Corba, KParts, DCOP/D-Bus, KService etc.). Harri.
Re: proposal: remove KTextEditor interface from kdelibs repository
On Tuesday, February 1, 2011, Harri Porten wrote: On Tue, 1 Feb 2011, Aaron J. Seigo wrote: we could end up with a new kdelibs module that contains just the core stuff such as kdecore, kdeui, kio .. there could be requirements in there about allowable dependencies between those libraries. [...] the big change here would be that applications that require different parts of the KDE Platform might have to define which parts to include (e.g. KTextEditor interface) rather than them being provided implicitly in one big chunk as it is now. Would that be really such a big change? We can certainly redefine a new kdelibs. But I think it will always be just another set where some (sometimes arbitrary boundaries) are drawn. In my eyes, KTextEditor is just a very random example. Will we next have the same discussion about KFileDialog? It uses KPushButton. Should we move out both to avoid sideways dependencies? What I want to say: we can always define what kdelibs comprises. It can be small, it can be big. I don't see a technically perfect optimum, though. At best we can strive for reasonable. agreed; and in the case of KFileDialog, i would expect it to be classified as platform target and moved higher up the chain than the dev frameworks. and then there is no sideways dep between it and anything in libkdeui: libkdeui would be dev framework, KFD would be platform target. a more layered approach, iow. the purpose of all this would be to create something that has a profile which 3rd party developers are more likely to take up. right now all of kdelibs is too much and we're losing lots of potential developers. being able to cherry pick just libsolid, e.g., would be a big win. kdelibs is better than it was in kde3 times, but there's still some serious mashing going on between app dev frameworks and platform target stuff (this is an insight i first heard from thiago, btw; i take zero credit and/or blame for it ;) we also need to ask ourselves how we can encourage packagers to split things up better so that libsolid does come in its own binary package on a system ... even if we include it in a larger source module. packagers do this with our applications already, the challenge is in the sorts of things that sune is bringing up .. and much of that is our policy (or lack thereof) surrounding what kdelibs means and what implicit guarantees are provided to apps built using it. Unless unless we find some real technical means to manage compile-time and runtime-dependencies. Maybe even MS Windows can serve as an example of a platform that has gone through all of this, is very extensible and at the same time very much backward compatible? One part of the puzzle I can think of a interfaces (pure .h files) that can be queried at runtime. In one way or the other that has been excersised in KDE in the past already (Corba, KParts, DCOP/D-Bus, KService etc.). yeah, that could definitely be part of the solution to teasing out the runtime dependencies ... -- 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: Fwd: Top 15 Mailinglists with messages in moderation
On Tuesday 01 February 2011 17:14:05 Artur de Souza wrote: Quoting Tom Albers t...@kde.org: 80 kmobiletools 20 kde-embedded We already have kde-mobile...maybe it's safe to remove these two mailing lists? kmobiletools is actually an app for syncing your phone, not part of the mobile/embedded space. See http://kde- apps.org/content/show.php/KMobileTools?content=15259. I'd guess contacting the author would be the best bet to see if it's still needed. John.
Re: Top 15 Mailinglists with messages in moderation
On Tuesday 01 February 2011 13:45:27 George Goldberg wrote: 41 kdelibs-bugs This is a very useful list for bug triagers - I can volunteer to moderate it if no-one else is currently doing it. ditto, if more than 1 or 2 mods are needed. John.
Re: Initial support for kde_projects.xml in kdesrc-build
On Tue, Feb 1, 2011 at 4:14 PM, Michael Jansen i...@michael-jansen.biz wrote: a. nope. kwebkitpart only depends on kdelibs! There are no requirements besides that. The previous requirement that you must build kwebkitpart before you compiled the konq-plugins, which have now been moved to kdebase, is now longer valid because of the addition of several Extentsion interfaces to the KParts API. As a result konq-plugins do not have direct dependency on kwebkitpart anymore in KDE = 4.6... But that requirement came and went without a great announcement. Previously you had to compile kwebkitpart before kdebase so you got the ability to use webkit with konqueror. But that is just it... There never was any requirement of compiling kwebkitpart before kdebase, ever! I think perhaps you are confusing konq-plugins with being in kdebase ? But the konq-plugins prior to the trunk for KDE 4.7 being opened were located in extragear/base and not kdebase. So I do not know where you got the impression of such dependency. It did not exist. The optional dependency that existed was that some of the konq-plugins linked directly against kwebkitpart if available. As such you needed to have compiled and installed kwebkitpart to activate support for it in some of these konq-plugins. And that was the ugly dependency that was solved by the changes I described in my original response. Anyhow, I guess this is not really the point of your discussion, but a rather a bad example you used...
Re: Top 15 Mailinglists with messages in moderation
2011/2/1 Nicolás Alvarez nicolas.alva...@gmail.com: On 01/02/2011, George Goldberg grundleb...@googlemail.com wrote: On 1 February 2011 12:01, Tom Albers t...@kde.org wrote: The monthly overview - Forwarded Message - 342 decibel I think it's safe to kill this list. The project has been in the land of the unmaintained for at least a year now. But it should get moderated at least once more. What if there's 300 spam messages and 42 people wanting to resurrect the project? ;) In that case, I'm happy to go through the queue before it gets (provisionally) removed. -- George
Re: Merge or Cherry-Pick?
On 01.02.11 14:06:47, Aaron J. Seigo wrote: On Tuesday, February 1, 2011, Stefan Majewsky wrote: On Tue, Feb 1, 2011 at 10:22 PM, Aaron J. Seigo ase...@kde.org wrote: then i learned today to be extra vigilant about doing `git pull --rebase` and not just `git pull` so i don't accidentally throw merge commits in there while preping for a push. Look in man git-config for branch.autosetuprebase. I think this should go into the Git manual after someone has checked this (did not actually try it). ooh, very cool. ok, i'm going to try running with this and see how it rolls. In addition to that you probably also want to do git config branch.yourbranchname.rebase true for any branches you already created locally (thats what autosetuprebase does when creating a new local branch from a remote one) We're using that since 1+ year at work now and so far haven't had a single case where it broke something. Andreas -- You love peace.
Re: Initial support for kde_projects.xml in kdesrc-build
On 01.02.11 23:14:26, Michael Jansen wrote: Do you need that for running ? For building it's not necessary. Use CMAKE_PREFIX_PATH. I always thought that PATH controls which qt version is selected if you have more than one (First qmake found). It was that way some time ago. And QTDIR IS USED in FindQt4.cmake. I don't reevaluate my finding every day so perhaps something changed. Ok. So when an executable is searched, it is searched in a set of default directories (as e.g. /usr/bin/) and in PATH. So setting PATH so that it points to the qmake you want works. CMAKE_PREFIX_PATH is more generic (and didn't exist in cmake 2.4.something). So you can set this too to make cmake find the Qt you want (not pointing to QTDIR/bin, but just to QTDIR). QTDIR is a variable specific to FindQt4.cmake, so it works too. So all three work, the most generic/powerful one is CMAKE_PREFIX_PATH. Then the 100 points question is: If all of them point to a directory with a qt installed (three different versions). Which one wins? a) CMAKE_PREFIX_PATH b) PATH c) QTDIR I remember more than one newbie losing his grip over not beeing able to convince cmake to pickup the right one. Can you answer it without looking at the cmake file? I can't. No of course not because you don't know how QTDIR is being used. But thats rather a problem of the FindQt4.cmake module not documented where it uses the QTDIR variable. Once you know it puts that into the PATHS option the rest is a mere look at the cmake manual which lists the order in which it searches for stuff. In particular in your case it'll find the qmake in CMAKE_PREFIX_PATH. Yes it is. Even acknowledged by a cmake dev. Which doesn't make it magically work though. That is the lib64 issue you have, right ? I remember this one was tricky. Yes. But there are some executables build and the run during a build that need to pickup the right libs too. I am not sure all of them are doing it right or if there is a right way to do it. The one gnome helper i can point you too is not using cmake. Well, in kde modules the executables being built will have rpath set too, so that should work - in theory. But as I don't know what exactly Alex and you are talking about here and what your setup is I'll shut up :) Andreas -- You will be given a post of trust and responsibility.
Re: Merge or Cherry-Pick?
On Tue, Feb 1, 2011 at 4:22 PM, Aaron J. Seigo ase...@kde.org wrote: On Tuesday, February 1, 2011, Alexander Neundorf wrote: On Monday 31 January 2011, Andreas Pakulat wrote: Hi, something that hasn't been written down as far as I can see (if I overlooked it, please point me to it) is what the policy on kdelibs is to be now wrt. merging vs. cherry-picking of changes in branches and master? Andreas Not replying to any particular response in this thread... I don't know whether I missed something, if so, please let me know. no, you didn't miss anything. right now i think everyone is very busy getting up to speed with the basics. for instance, i spent a good portion of the day today struggling with git.reviewboard.kde.org (sysadmin was very helpful, but things are still rough in places ..) there's also the issue that it appears that the 4.6 branch is unmergable with master, complicating things for the time being. in fact, it encourages cherry- picks when probably it should be merges. then i learned today to be extra vigilant about doing `git pull --rebase` and not just `git pull` so i don't accidentally throw merge commits in there while preping for a push. I learned this the hard way, but it is even more problematic, at least for me, when you attempt to learn how to adapt or re-learn how to do a particular workflow with git. For example, let us take one of the things Alexander mentioned in his email: * for committing a trivial change to master/trunk If you only had a single change that is already committed into your local repo, then I guess it is simple enough and can be pushed to the origin master branch by doing: git pull --rebase git push But how would a similar work flow except there are multiple fixes present in the local repo ? How would you push only a single fix in such case ? It does not seem possible to me to do that... If that is the case, does it mean we have to create separate branches for each and every fix we work on since branches are cheap to create in git ? Or simply wait until we are ready to push all the changes and do them at once ? What if that is not desirable, i.e. an urgent fix that needs to be committed ? There is probably easier way to do things in git, but despite reading several articles and documentation on git, it is not easy to figure out the uses of git for own work flow for first time users like myself. Perhaps compiling answers for the easiest way to handle the most common work flows being discussed here would be a good starting point for a guide that can be put on techbase... Regards, Dawit A.
Re: Merge or Cherry-Pick?
On Wed, Feb 2, 2011 at 12:58 AM, John Tapsell johnf...@gmail.com wrote: But how would a similar work flow except there are multiple fixes present in the local repo ? How would you push only a single fix in such case ? git rebase -i origin #Bring up a list of your changes. Reorder them in the editor so that the commit you want to push is at the top of the list, save Fix any conflicts that might have arisen because you reordered the commits git pull --rebase #make sure we are up to date git log #copy the SHA of the commit you want to push up to git push origin SHA:head #paste the SHA that you just copied where I wrote SHA Does that make sense? There are other ways to do it, but this way avoids most of the common problems. Yes. Great. IMHO that type of documentation is what is needed in techbase. One question though... why would i need to do git rebase -i origin if I always do git pull --rebase in the first place ? Wouldn't simply following the steps you mentioned after git pull --rebase suffice since I am going to be using the commit SHA to do the push ?
Re: Merge or Cherry-Pick?
On Wed, Feb 2, 2011 at 2:02 AM, Kevin Ottens er...@kde.org wrote: On Wednesday 2 February 2011 07:21:44 Dawit A wrote: On Wed, Feb 2, 2011 at 12:58 AM, John Tapsell johnf...@gmail.com wrote: But how would a similar work flow except there are multiple fixes present in the local repo ? How would you push only a single fix in such case ? git rebase -i origin #Bring up a list of your changes. Reorder them in the editor so that the commit you want to push is at the top of the list, save Fix any conflicts that might have arisen because you reordered the commits git pull --rebase #make sure we are up to date git log #copy the SHA of the commit you want to push up to git push origin SHA:head #paste the SHA that you just copied where I wrote SHA Does that make sense? There are other ways to do it, but this way avoids most of the common problems. Yes. Great. IMHO that type of documentation is what is needed in techbase. One question though... why would i need to do git rebase -i origin if I always do git pull --rebase in the first place ? Wouldn't simply following the steps you mentioned after git pull --rebase suffice since I am going to be using the commit SHA to do the push ? Because the order matters. git will push everything up to the commit with the SHA1 passed as parameter. git rebase -i allows you to reorder your commits first. Ahh... I see. It is push everything upto that commit, not just push that commit. Ouch! That is almost as much a hassle as the convoluted method I am following now. Do not commit anything that is not ready to be pushed into my own local branch. Use git stash to save the uncommited changes before doing the pull --rebase and apply the stashed changes after doing the push...
Re: Merge or Cherry-Pick?
On Wednesday, 2 de February de 2011 05:58:35 John Tapsell wrote:
git rebase -i origin #Bring up a list of your changes.
Reorder them in the editor so that the commit you want to push is at
the top of the list, save
Fix any conflicts that might have arisen because you reordered the commits
git pull --rebase #make sure we are up to date
git log #copy the SHA of the commit you want to push up to
Hint:
git log @{upstream}..
(the two dots included)
git push origin SHA:head #paste the SHA that you just copied where I
wrote SHA
I think head here is supposed to be the branch you want to push to. Please
avoid using head, as it easily is confused with HEAD.
--
Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
Senior Product Manager - Nokia, Qt Development Frameworks
PGP/GPG: 0x6EF45358; fingerprint:
E067 918B B660 DBD1 105C 966C 33F5 F005 6EF4 5358
signature.asc
Description: This is a digitally signed message part.
