Re: Please avoid noisy merge commits in frameworks
2012/2/19 Ben Cooksley : > > First, our hooks are in python - so any changes would need to be in Python > as well. I can speak a bit of python, would be a nice way for learning more :) > > Second, there is a legitimate use for pushing merge commits - namely > integrating a seperate remote branch. I have no idea if it would be possible > to determine if this is a local only branch merge or not. Indeed merge commits are useful in that case - although there's a different pattern in the ones Stephen was complaining about, since you always merge master onto (remote) master in such commits which never makes sense. And besides that, as many on this list already know, I advocated multiple times for crystal clear git policies across at least all KDE core repositories - this is just one of the issues to tackle. > > Third, please ensure that you disable the previously mentioned auto-rebase > on git pull if you are merging a reemote branch, otherwise you will > duplicate many commits, in addition to triggering the hooks for all those > commits (which will not happen if you just merge). The hooks could even > decide to reject your push, as it will contain too many new commits. Also interactive rebasing can help here, but at this point a fetch+rebase -i is actually a better option. > >> >> Thanks, >> >> Steve. >> >> > > Regards, > Ben Cooksley > KDE Sysadmin. ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Which package will provide the common KDE library version number ?
On Sunday 19 February 2012, Stephen Kelly wrote: > Alexander Neundorf wrote: ... > > KF5 package, as small as it may be. A library containing only a function > > which returns the version, or something like this. > > Depending on this small (header only ?) > > It would have to be compiled in probably, so it can't be header only I > think. Well, my main point is that it would be a build-time-only dependency, no runtime dependency, i.e. no shared library, but basically a file existing at buildtime, a header or cmake file or something. It can't be a static library for technical reasons. Alex ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Which package will provide the common KDE library version number ?
Alexander Neundorf wrote: > On Saturday 18 February 2012, Kevin Ottens wrote: >> On Saturday 18 February 2012 18:13:00 Alexander Neundorf wrote: >> > On Saturday 18 February 2012, Kevin Ottens wrote: >> > > So the other possibility would be to have the version number in the >> > > main CMakeLists.txt of each framework >> > >> > This is the clean and obvious way to do it. >> > Each library defines its own version number. >> > >> > But... >> > >> > > which raises potential consistency issues... >> > >> > Exactly. >> > >> > > Solution would then be that the scripts used to generate the >> > > release tarballs verify the version is properly set everywhere. >> > >> > ...or scripts which regularly update the version numbers in git. >> >> Let's pursue that solution then. Anyone willing to take a look at how >> hard it would be to implement and have at least a proof of concept? > > Just to make it clear: I think this is the wrong approach. > > Just to avoid creating a tier0 KF5 entity, we create a script which does, > when executed, what this KF5 entity naturaly would be. > > > Or, maybe we should discuss another question first: what makes a library a > KDE frameworks library ? What properties do KDE frameworks libraries have > ? > > > Can KDE frameworks libraries of different versions be mixed together ? I would say that's unsupported (by us). The ones that work together are released together. We're not going to test all possible (and numerous) version combinations. We don't need to make it impossible, but we don't need to ensure that it always works either. If someone else decides that they want some random version combination to work (for a reason I can't think of), they can maintain that combination. > E.g. can I build a tier2 library against different versions of tier1 > libraries, or does this in general only work if they have the same version > ? If so, they wouldn't necessarily share the same KDE frameworks version > number... > > Can I install different libraries from the KDE frameworks set of libraries > to different locations and use them together ? I don't see why not. As long as CMAKE_PREFIX_PATH has the correct content. > > If the answer to these questions is yes, then KDE frameworks is really > just a set of loosely coupled libraries, which of course can have > different versions. Yes, but the KDE applications and workspaces will use one version of all the frameworks that they use. > > If the answer is no, i.e. if these libraries should still be seen as one > coherent package, I would say that from the perspective of a developer creating a KDE application, it is one coherent package. >From the perspective of a Qt application developer who wants (for example) to be able to create zip files (using karchive) or some extra itemmodels classes, the libraries are distinct. > then there should be a package they all depend on, I don't follow the logic from 'they can be seen as one package' to 'they must share a common dependency'. > the > KF5 package, as small as it may be. A library containing only a function > which returns the version, or something like this. > Depending on this small (header only ?) It would have to be compiled in probably, so it can't be header only I think. > library would be the burden > necessary to get the stamp "you are a KDE framework library". > Thanks, Steve. ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Please avoid noisy merge commits in frameworks
2012/2/19 Stephen Kelly : > Stephen Kelly wrote: > >> >> Hi there, >> >> I was reviewing the changes in the frameworks branch from yesterday. >> Something I noticed was that there are a lot of merge commits that don't >> need to exist. > > Ugh. Yet more of this just appeared... Recent history in the frameworks > branch looks far more complex than it is and is harder to follow. > > There are too many people unaware that they're doing it maybe... What about having a small volunteer day in which we draft some policies for git commits and eventually implement some hooks to avoid these (and other) things happening? > ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
libkwindowsystem in staging
hi all... there is a new library in staging: libkwindowsystem it pulls in kdeui/windowmanagement/ and Plasma::WindowEffects as well as a few x11 helper classes from kdeui. these helper classes are public API in Platform 4.x but are only used by the classes in libkwindowsystem. as such i've made them private. i did duplicate one class from kdeui as a short term measure by making a copy of the header and source file: KXErrorHandler. this is also used in kdeui/util/kmanagerselection.cpp. KSelectionWatcher and KSelectionOwner are rather x11 specific concepts on the one hand .. and on the other they are only used by kde-workspace (so could be moved into there easily enough) and KMenuBar in kdeui. they are used in KMenuBar for global menu integration. however, as global menu support is now in Qt 4.8 (and therefore will be in 5.0 as well) i'd like to propose the following: * KMenuBar loses the KDE-specific implementation; this also cuts the dependency on KSelectionOwner/Watcher completely in kdelibs * move kmanagerselection.h/cpp into libkworkspace in kde-workspace for the 4.9 and use that in kde-workspace (pre-porting for Frameworks 5 :) * remove kmanagerselection.h/cpp and kxerrorhandler.h/cpp from kdeui in frameworks branch thoughts / input / objections? as for the "definition of done" progress for libkwindowsystem the following are done: No dependency on kdeui or kdecore Modularized CMakeLists.txt (afaik, anyways :) Does not install any Find*.cmake modules itself All Find*.cmake modules needed by the framework and used also by other frameworks have been upstreamed to extra-cmake-modules (via the kde- buildsystem mailing list) or directly to cmake (via the cmake list) Follows the policy on directory organization Has an appointed maintainer Maintains source compatibility over kdelibs (modulo the above unused classes becoming private) not done are: Installs a Config.cmake file for itself (due to not yet being clear on how this should look in the frameworks dir; i've done this for libkactivities, but i need to find out what, if anything, has changed there) Unit tested (pending upcoming work by mgraeslin) Does not use any Q_WS_* defines. (pending upcoming work by mgraeslin) -- Aaron Seigo signature.asc Description: This is a digitally signed message part. ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: /cmake/modules/ vs. /cmake/
Alexander Neundorf wrote: > If some library needs some exotic library, it should be good enough if it > contains the Find-module itself. This wasn't on the wiki page. I added it with the recommendation that such find modules shouldn't be installed. ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
