Re: Review Request 112081: Add reviewboard-am, a tool to apply patches from KDE reviewboard
--- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/112081/#review37834 --- How does this compare to rbt patch? (http://www.reviewboard.org/docs/rbtools/0.5/rbt/commands/patch/) It sounds to me like it's meant to accomplish the same thing - Heinz Wiesinger On Aug. 14, 2013, 3:26 p.m., Aurélien Gâteau wrote: --- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/112081/ --- (Updated Aug. 14, 2013, 3:26 p.m.) Review request for kdelibs and David Edmundson. Description --- Add reviewboard-am, a tool to apply patches from KDE reviewboard. (subscribing the kdelibs group to this request because there seems to be no kde-dev-scripts group) Diffs - reviewboard-am PRE-CREATION Diff: http://git.reviewboard.kde.org/r/112081/diff/ Testing --- I and a few others, most notably David Edmundson, have been using it for quite some time now. Thanks, Aurélien Gâteau
Re: Releases in 3 months
On Monday 08 July 2013 15:04:40 Àlex Fiestas wrote: Now that kde-workspace and kdelibs are going to be frozen (which in theory means less work for everybody) I'd like to propose a new release schedule to be applied starting with 4.12. IMHO that's a bit hasty. There was previous talk about Frameworks, Workspaces and Applications (potentially) having a different release schedule. I don't think anything has been really talked about there yet, but that's something that would definitely play into the current proposal. No matter the outcome of the discussion, you'd want to avoid changing release processes twice within a short period of time, and with releases of KF5 and PW2 sometime next year (assumption) that would certainly be a thing to keep in mind. Basically the idea is to cut testing time and compensate it by keeping master always in a releaseable state, now that two major components are frozen it looks like it is a good time to get used to it. The philosophy is nice, but it's hardly enforcable. So it's something everyone needs to adhere to voluntarily and that may take some convincing, especially when it involves changing current (working) practices. 3 months seems rather ambitious there. Before sending this email I have checked with distro people, i18n people, other developers and almost all of them seemed to either like or be neutral about it (only one exception :p) so I hope that the proposal is not a complete disaster. Any reason not to CC kde-packager or kde-release-team? IMHO they'd be primary audiences for this. Grs, Heinz signature.asc Description: This is a digitally signed message part.
Re: Compiler version
On Saturday 30 June 2012 17:02:27 Alexander Neundorf wrote: On Thursday, 28. June 2012 14:38:37 viv...@gmail.com wrote: Il 27/06/2012 23:41, Martin Gräßlin ha scritto: On Wednesday 27 June 2012 23:28:30 Ivan Čukić wrote: Hi all, I've tested the waters some time ago [1] what would people say if we started asking for more modern compilers. I've stated there I'll start the discussion on k-c-d once we branch out 4.9, so I'm doing as promised. The post was only about kactivities, but the same could be applied to more stuff. Thanks for bringing up the issue, I actually intended to write a similar mail tomorrow to request that applications are allowed to require compilers supporting C++11 features. actually for stability and feature related to c++11 gcc-4.7 is nearly the minimum, but in my experience gcc-4.7 is still a bit rough so +1 for gcc-4.6 So +1 for a minimum requirement of gcc 4.6 or clang 3.1 -1 from me. Latest Slackware release has 4.5, and I would very much prefer if this stays working. I don't see the features mentioned worth dropping platforms. Next Slackware will come with 4.7 (and clang 3.0) so raising the bar for future kde releases shouldn't be a problem there IMHO (based on the fact that there are no official major kde updates for old releases). However, the point of dropping platforms in general remains, I suppose. Grs, Heinz signature.asc Description: This is a digitally signed message part.
Re: The case for a kdelibs 4.8
On Thursday 29 September 2011 14:01:50 Kevin Kofler wrote: Hi, as you probably already know, a decision was recently made that kdelibs 4.7 would be the last 4.x release series of kdelibs, and work would be ongoing in the 5.0 (frameworks) and 4.7 (KDE/4.7) branches only. I think this is a huge mistake, for several reasons (the TL/DR crowd can stop right here, but if you want to know why, please read on!) [..] From what I remember from the desktop summit the picture you draw here is quite an exaggeration of what is actually happening. kdelibs 4.7 is meant to be frozen for new features, but not for bugfixes. Bugfix releases of kdelibs-4.7 happenend and I'm sure will continue on happening. As for the versioning I don't see why one of those bugfix releases couldn't be rebranded as 4.8.0 if that makes things easier (that was even briefly mentioned at the release team BoF). It does not solve feature backports of course. The KDE Frameworks 5.0 development is not meant to take forever. In fact I think it's meant to be finished around early 2012, which would leave us with a frozen kdelibs for one KDE SC release, maximum two. It's also not a huge *we will break everything! Kittens will die!* release, but basically just a restructuration of the code, with little to no adjustments necessary for applications. (that was how it was marketed, anyway). The way I understood it was that there could very well be a KDE SC 4.9 release shipping a 4.9 workspace on top of 5.0 frameworks. As for the version numbers, I don't really see the problem. As long as the integrity of the KDE SC releases remains, different version numbers in its components are not really /that/ important. I do see how it could help though. Grs, Heinz signature.asc Description: This is a digitally signed message part.
