Re: Formal complaint concerning the use of the name System Settings by GNOME
On Saturday, July 23, 2011 04:41:05 AM Ben Cooksley wrote: Hi, I find what is proposed by Shaun to be acceptable, as the distinction between the two is clearly defined. It still allows users to determine the correct System Settings application to use to configure KDE applications with what is probably the most minimal level of confusion. KDE System Settings will continue to be called System Settings under KDE, but will be called KDE System Settings under all other environments. Unfortunately, this is too late for KDE 4.7. Had I been contacted when the decision to use the name System Settings under GNOME, this entire issue could have been avoided - which I think everyone would have preferred. If any GNOME components exist which do similar using of global names, particularly in the space of preferences, it would be much appreciated if you take similar steps. @Matthias: please explain how this doesn't solve the issue. If anyone has any other comments to make on this, please do. I'll make the needed adjustments once KDE 4.7 has been released, unless objections are raised. This will, clearly, run afoul of the KDE rebranding strategy where KDE is a community and not a piece (or collection) of software. Personally I think that says more about the rebranding strategy than this proposal, but this aspect of it should be considered. Scott K
Re: Formal complaint concerning the use of the name System Settings by GNOME
On Sunday, July 24, 2011 05:07:19 PM Ben Cooksley wrote: Dropping GNOME out of this, as it seems quite clear they aren't interested in co-operating at all. Which is fairly typical for them, they're insular and only care for themselves. In any case, we need a short term solution to this. Basically, we are going to have to provide a different name under GNOME, because otherwise GNOME users will complain to distros, who will patch GNOME to ignore System Settings (I refuse to acknowledge their app). A long term solution, sharing settings isn't even counted, as they are bound to screw us over yet again in some way. They are not to be trusted. Adding the panels apps need to them isn't exactly workable either due to the number of applicable panels and apps. As was proposed earlier, System Settings would call itself System Settings under KDE, but would prefix KDE to the name under all other environments. ie. KDE System Settings under xfce. I have recieved objections that this collides with the branding policy however. Given such an objection, what do those of you who object propose? I mentioned this, but didn't actually object (not sure if you got comments from others on this). I think KDE systemsettings is fine. If you wanted to stick with the official rebrandingspeak, I think (I can't tell) it should be either Plasma Workspace Systemsettings, KDE Plasma Systemsettings, or something like System settings for KDE Frameworks. I've no idea really. A solution must be reached, otherwise it is the users of our applications who will ultimately suffer - and we will probably get blamed for it. For Kubuntu we've taken the position that we will follow KDE upstream on this and that until there is an upstream solution the only reasonable distro level thing to do is patch Gnome systemsettings back to it's old name to avoid user confusion. Scott K
Re: Formal complaint concerning the use of the name System Settings by GNOME
On Sunday, July 24, 2011 05:52:08 PM Cornelius Schumacher wrote: On Sunday 24 July 2011 Ben Cooksley wrote: Dropping GNOME out of this, as it seems quite clear they aren't interested in co-operating at all. Which is fairly typical for them, they're insular and only care for themselves. I don't want to let a statement like this stand as it is. There are a lot of people in the GNOME community who do want to cooperate. There certainly are also people who don't. That's the same in our community. Not everybody cares about cross-desktop collaboration, and this creates issues, as we have seen. Still, we should treat each other with respect. I understand that it makes you angry, if things break because of decisions outside your control, which you consider to be wrong. But being angry doesn't solve problems, especially not when communication about a common solution is required. There are a lot of technical things we can do to address this specific problem, taking settings from the platform, making configuration available in context, making KDE applications and frameworks more modular and less interdependent. Not everything can be done easily, but we should look for the right solutions and persue them. Additionally we need to talk about how to do integration across desktops. We should not be content with having insular desktops, neither on the GNOME side, nor on our side, nor anywhere else. This only limits us, how we are perceived, and what users think what they can do with KDE software. We aren't the monolithic desktop, which only runs KDE software, and which is required by all KDE applications. That's exactly the misconception we are trying to get rid of. So let's have a constructive conversation with GNOME and others how to share settings, how to integrate applications running on different workspaces independent of the toolkit they are implemented with. The desktop summit provides a great opportunity for that. But again, please act with respect for your own and other communities. Being aggressive doesn't help in finding good solutions for users, and it's really not the atmosphere, I'd like to see in KDE. I haven't seen anything in any mailing list posts that is nearly as aggressive as knowningly reusing a name that was in use like systemsettings. My word for the messages that the Gnome moderators didn't like the tone of is accurate. Scott K
Re: Formal complaint concerning the use of the name System Settings by GNOME
Thomas Zander zan...@kde.org wrote: On Monday 25 July 2011 07.49.17 Scott Kitterman wrote: I haven't seen anything in any mailing list posts that is nearly as aggressive as knowningly reusing a name that was in use like systemsettings. Please don't assume that was an agressive act. I can totally see that someone that goes with the assumption that a piece of software is only usable on one desktop won't have problems if you call a similar piece of software the same on your desktop. In general; please stop assuming ;) (ask politely first) It was stated up front that Gnome was aware of the naming conflict when they did it and there was zero advance communication, so I don't think I'm assuming anything. Scott K
Re: Plan to transition to KDE Frameworks
On Saturday, August 06, 2011 09:32:02 AM David Faure wrote: .. The next step is to backport the few bits of new api that went into master and that application developers started using, into the 4.7 branch of kdelibs. I'll work on that, but help is welcome too. ... This plan seems to be contrary to the KDE Point Release Policy [1]. At this point I don't see an easy way out, but it would be good if a cutoff point for these additional API changes in 4.7 could be set (perhaps no later than 4.7.1's release). Scott K [1] http://techbase.kde.org/Policies/Minor_Point_Release_Policy
Re: Plan to transition to KDE Frameworks
On Tuesday, August 09, 2011 07:05:53 PM David Faure wrote: On Monday 08 August 2011 00:42:50 Scott Kitterman wrote: On Saturday, August 06, 2011 09:32:02 AM David Faure wrote: .. The next step is to backport the few bits of new api that went into master and that application developers started using, into the 4.7 branch of kdelibs. I'll work on that, but help is welcome too. ... This plan seems to be contrary to the KDE Point Release Policy [1]. At this point I don't see an easy way out, but it would be good if a cutoff point for these additional API changes in 4.7 could be set (perhaps no later than 4.7.1's release). [1] http://techbase.kde.org/Policies/Minor_Point_Release_Policy Under some conditions, the policy allows new API in a stable branch. We decided that these conditions were met :-) (IIRC there were only three, and they were rather minor and safe; a KUrl::List constructor, a new exported method, a new signal) Just to be clear then ... No further API changes are planned for incorporation in the 4.7 branch? From a distro perspective it matters to me that the API be stable after our release (which will be with 4.7.1 or 4.7.2 depending on when they are released), so as long as it's those and no others I'm perfectly happy. Scott K
Re: Plan to transition to KDE Frameworks
On Wednesday, August 10, 2011 08:39:49 AM David Faure wrote: On Tuesday 09 August 2011 19:26:17 Scott Kitterman wrote: On Tuesday, August 09, 2011 07:05:53 PM David Faure wrote: On Monday 08 August 2011 00:42:50 Scott Kitterman wrote: On Saturday, August 06, 2011 09:32:02 AM David Faure wrote: .. The next step is to backport the few bits of new api that went into master and that application developers started using, into the 4.7 branch of kdelibs. I'll work on that, but help is welcome too. ... This plan seems to be contrary to the KDE Point Release Policy [1]. At this point I don't see an easy way out, but it would be good if a cutoff point for these additional API changes in 4.7 could be set (perhaps no later than 4.7.1's release). [1] http://techbase.kde.org/Policies/Minor_Point_Release_Policy Under some conditions, the policy allows new API in a stable branch. We decided that these conditions were met :-) (IIRC there were only three, and they were rather minor and safe; a KUrl::List constructor, a new exported method, a new signal) Just to be clear then ... No further API changes are planned for incorporation in the 4.7 branch? From a distro perspective it matters to me that the API be stable after our release (which will be with 4.7.1 or 4.7.2 depending on when they are released), so as long as it's those and no others I'm perfectly happy. No further plans for new API right now, but as the policy says, it can always happen, if it's necessary for a bugfix. But surely if a distro provides an update to someapp-4.7.3 it can also provide an update to kdelibs-4.7.3, via dependencies. Yes. We (Kubuntu) do post-release updates to KDE SC as a complete set, but the policy is to limit updates to bug fixes in order to minimize post-release regressions. My concern isn't minor API extensions that might be needed to fix a 4.7 bug, but with backporting new features to kdelibs 4.7 to support (rest of the SC) 4.8 development. Scott K
Re: Summary from Buildsystem BoF at Desktop Summit
On Monday, August 15, 2011 05:31:26 PM Alexander Neundorf wrote: 5) Required cmake version David noted that we (KDE) are very conservative with the required CMake version, i.e. we still depend on CMake 2.6.4, which is more than a year old. Me (Alex) noted that this is on purpose to keep the pain for developers as small as possible (having to update Qt from time to time is enough). Now, with the upstreaming efforts (see 1) ), Alex is currently pushing hard to get everything we need into the next cmake release (2.8.6), but possibly not everything will make this deadline. Unfortunately the cmake 2.8.6 release cycle is shorter than the previous CMake release cycles (since they were too long). All attendees agreed that it will be ok if the KDE frameworks branch will require the latest released cmake version, until it has everything we need. This means, KDE frameworks will require CMake 2.8.6 more or less as soon as CMake 2.8.6RC1 has been released. Later on, it may require 2.8.7 and 2.8.8. For kdelibs probably nothing will change. This is good news for me :-) Sorry for the delayed reply ... I think the proposed plan makes sense (KDE frameworks branch will require the latest released cmake version), but the description of released is suprising to me. I don't think of an RC as being released. Could the plan be required when it's released and not RC, not quite released? Scott K
Re: The case for a kdelibs 4.8
On Thursday, September 29, 2011 03:27:58 PM Markus Slopianka wrote: On Donnerstag 29 September 2011 14:01:50 Kevin Kofler wrote: 2. It will be confusing to our users, and even to some packagers, to have a KDE SC 4.8 on kdelibs 4.7. Since almost exactly 2 years we (esp. the promo team) are communicating that Platform/Frameworks, Applications and Workspaces are three separate products that just happen to be shipped on the same date. One of the reasons why the rebranding still didn't get to everybody is that some distributions (mostly Fedora!) still spread the wrong message about some “KDE 4.7” to its users. (see eg. https://fedoraproject.org/wiki/SIGs/KDE/KDE47Packaging#KDE_4.7_Packaging ) Users of other distributions do not have such problems and strangely shipping Kontact 4.4.11 with SC 4.5+ was also not confusing to most users. We did this in Kubuntu and it was confusing. It was also technically challenging. Speaking as someone investing a lot of time in trying to do a high quality job of distributing KDE to end users: Please. Never, ever, do this to us again. I get what you want to communicate, but it's more complicated that that. The integrated release process of KDE has value. Just happen to be shipped on the same date isn't true. Marketing materials saying this are exactly that. Marketing materials. I agree with the goal of trying to make it easier to use pieces of KDE in different contexts, but the integrated delivery process that marketing wants to dispense with has real technical value that I hope KDE will not discard. The transition from kdepim 4.4 - 4.6/4.7 was a special case. I hope it stays that way. While there wasn't another way to do what had to be done in that case, it should not server as a general success story others should model themselves after.
Re: The case for a kdelibs 4.8
On Thursday, September 29, 2011 11:47:22 PM Albert Astals Cid wrote: A Dijous, 29 de setembre de 2011, Scott Kitterman vàreu escriure: On Thursday, September 29, 2011 08:01:00 PM Kevin Kofler wrote: On Thursday 29 September 2011, Heinz Wiesinger wrote: 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. But one of my points is that we need features too, not just bugfixes. Continuing 4.7.x releases solves the problem of bugfixes just fine, but entirely fails to address the issue of features. Even worse, features have already creeped into the 4.7 branch because they are needed and there's no 4.8 branch, so this isn't a theorectical point. Why is that bad, that is what was agreed when the freeze took place. Agreed on by who? As a distributor of KDE, we rely (to meet the commitments we make to our users) on post-release updates of KDE to be bug fixes and not introduce new features. Once we release, we want consistency with the only change being resolution of problems and few/no regressions. I don't like the fact that KDE developers decided to ignore their own policy on maintenance updates. I think it breaks your contract with your downstreams. In the case of what's been done so far, it doesn't have an impact on us. The changes were in before our release and are technically low risk. I was aware of it, but becauase of the timing relative to our release schedule, didn't object. That isn't the same as agreeing. Today was our final freeze for non-critical uploads for our 4.7 based release. Elsewhere in this thread there has been discussion about allowing additional feature creep into the 4.7 branch because there's no 4.8 branch. From here on out it's a problem for us. I know most KDE developers don't pay a lot of attention to anything but the development release. For us integrators, it's mostly the one before that we're paying attention to, so when you mess with it, we tend to not appreciate it. Scott K
Re: The case for a kdelibs 4.8
On Thursday, September 29, 2011 11:47:55 PM Albert Astals Cid wrote: ... That is actually Dirk's plan (or at least that is what i remember from the Release Team BoF in Berlin). ... Are the results of this BoF published anywhere? Scott K
Re: The case for a kdelibs 4.8
On Friday, September 30, 2011 04:15:51 PM Markus Slopianka wrote: (As a side note I also think that KDE Applications should completely lose their version number and get date-based versioning because any application can get major new features at any time – see Dolphin 2.0 in SC 4.8.) Today, for Kubuntu, we work very hard to package all of the KDE SC because we think it's an important value to deliver this upstream set of packages as a complete set to our users (IIRC, except for bindings we accomplished that for 4.7 even with all the package splits). If there is no more integrated release of a KDE SC, then we really don't need to worry about that and so we'll probably focus more just on stuff we use (I know the Debian KDE packagers are already planning this due to all the package splits). So I expect that one side effect of doing away with the traditional KDE release process will be less KDE software packaged in distributions. Scott K
Re: The case for a kdelibs 4.8
On Saturday, October 01, 2011 08:27:02 AM Martin Gräßlin wrote: On Saturday 01 October 2011 00:12:05 Arne Babenhauserheide wrote: Am Freitag, 30. September 2011, 10:07:27 schrieb Aaron J. Seigo: will say Platform 4.7, Plasma Workspaces 4.8 and application updates (or something along those lines). that was not just a marketing ploy, but an attempt to align our public communication with the realities that already existed in KDE development. I hope I am not the first to note that this sounds really horrible. Take this message: KDE releases 4.8: Platform and Workspaces got some spectacular changes, while applications received much polish. In a blog, this becomes YAY! KDE releases 4.8! Take your example. It becomes: Plasma 4.8 released! Well, where is KDE in that? Suddenly the community it is all about becomes a sidenote. And a newspaper will likely only see “hm, some stuff our readers won’t understand” instead of “new version of the tools from KDE!” There is a reason why Apple releases MacOSX 10.8 and not “Xcode 4.1, Apple Mach 1.3, Quartz 4.7, …” One of the main reasons for the rebranding was to realize that KDE is not one product, but a community that produces multiple products among them a desktop environment (Plasma). What you just try to tell us is that the complete rebranding is nonsense and we should go back to talking just about KDE for everything bringing the users back to assuming they need Plasma in order to use KMail. I really like the fact that finally we have a release where it will be clear that KDE is the community and not one large product. All those who did not get it yet, might finally understand it if we write a really good release announcement. I understand it and I think it's great. At the same time, I think this idea that from a development perspective it's OK to mix and match and release any piece of the SC at any given time is technical nonsense. As long as we leave the marketing to the marketeers and the developers don't get distracted by it, then I think it's fine. I think users ought to be able to run KMail (to pick your example) on any desktop environment and have it work well. I completely agree with this idea, but I don't agree with the idea to throw away the coordinated development schedule and release process. Scott K
Re: The future of Power Management - together with Activities
On Saturday, October 01, 2011 08:38:09 PM Dario Freddi wrote: On Saturday 01 October 2011 20:07:12 Stefan Majewsky wrote: On Sat, Oct 1, 2011 at 7:33 PM, Andras Mantia aman...@kde.org wrote: I can't comment on activities, never used them, nor feel the need to use them. So this sounds more like the power management applet would force me to create and use activites. +1. Actually I'm confused by the concept of activities as a whole: On one hand, there are libraries now for reacting to activity switching. On the other hand, activities are said to include running applications, so apps will be closed when switching to a different activity. That seems contradictory. That makes it difficult for me to see where power profiles come into this game: Does this mean that when I want to switch to a different profile, does this mean that I have to create a new activity when I want to change to a different power profile, which would mean that all running applications would close because they belong to the previous activity? I'll let the activities guru answer properly on the previous part; however, the point is that if you never switched a profile manually you will not even feel the difference, as it's simply going to behave the same way. If you were doing such a thing, depending on why you were switching, you might need to create a new activity. I don't understand how creating a new activity represents an improvement to the user. If I understand the proposal correctly the user will only use the power manager to change existing profiles and if they want to create an alternative profile they will have to us something that is not the power manager. I understand the concept of activities for things like plasma-netbook with search and launch and newspaper actitivies. It makes complete sense. So I'm not unfamiliar with the idea. I don't understand how it relates to power management. Splitting how one does power management into two pieces is just going to confuse people. Scott K
Re: The future of Power Management - together with Activities
On Sunday, October 02, 2011 08:37:58 PM Dario Freddi wrote: On Sunday 02 October 2011 20:31:37 Martin Gräßlin wrote: And that's now exactly the point: if you don't have any clue about what is happening your I want to save power and not let the computer decide might be much worse than what the computer would do. No matter how many times I will quote this bit, it will never be enough. Most of the time, as you've said, manual adjustments to power management settings are to avoid having the computer try to save power, not to try and to a better job. The only time I think I can do a better job is when I actually turn hardware off (like bluetooth and wifi) that I know I'm not going to be using. To pick, what is for me a real life example, when I'm on an airplane, I know I don't want bluetooth, I (almost always) don't want wifi, the ethernet port could be powered down, etc. Most of these are things that power management doesn't current deal with, but I could envision (sort of) a airplane mode activity that would shut these things off, but then I wonder about what I am doing on the airplane (what activity I am engaged in) and it could be almost anything: - watching a movie - coding - compiling - reading/writing email - writing other documents - etc So what does how I might want to save power relate to my activity? I still don't understand why having power management things moved from power management to this activity thing that I've never found a use for is going to help me. Make it possible to do whatever you want with activities, I think makes complete sense. Making it the only way to do it, I don't understand. The concepts are orthogonal. Scott K
Re: The future of Power Management - together with Activities
On Sunday, October 02, 2011 09:28:42 PM Dario Freddi wrote: No, sorry to say that again. There are two categories of people: those who know what they are talking about and those who don't. Your understanding of this categorization is coming from the fact that you didn't understand what I am trying to advocate, and my argument about brightness was towards the need of having a separate power profile. If everyone that doesn't agree with you is defined as ignorant, why did you even ask for feedback. Several times you have accused people of not reading what you wrote and that if we would only read it and understand it, we would agree with (or else we are ignorant). If you're just going to engage in argument by authority with any disagreement, there's no point in a dialogue. I'm done with this thread. Don't take the lack of further replies as agreement. Scott K
Re: New Feature for kdelibs (Was: The case for a kdelibs 4.8)
Kevin Kofler kevin.kof...@chello.at wrote: Andrea Diamantini wrote: Ok, let's wait 18 months to see private browsing fixed. Going to update bug reports... Try nagging distros to backport your (or your contributors') patches. Unfortunately, it looks like trying to convince the kdelibs maintainers at KDE is a lost cause, as you can see from this and other threads. :-( They just don't care about their users anymore, instead focusing only on some ideal future. I talked to my fellow Fedora KDE packagers on IRC today and it looks like we'll be backporting (or rather, applying, since 4.x is what they got developed against) the kde#54300 patches. Of course, whenever you ask distros to backport features, it helps if you can already offer a patch(set) against 4.x (as is the case for the kde#54300 patches), since backporting from Frameworks is more work. (Whether the patch is against 4.8, 4.7 or even 4.6 usually won't matter, as long as it's 4.x.) It is probably worth a discussion on packagers to share cross-distro ideas about what kdelibs feature patches to ship with 4.8. Having some commonality at least among the distros seemslike a good idea to me. Scott K
Re: This starts to become a dangerous path (Was: New Feature for kdelibs)
On 11/15/2011 02:46 PM, Thomas Lübking wrote: Am Tue, 15 Nov 2011 13:17:45 -0500 schrieb Scott Kittermank...@kitterman.com: It is probably worth a discussion on packagers to share cross-distro ideas about what kdelibs feature patches to ship with 4.8. While Scott's suggestion to have a commonly downstream patched kdelibs 4.8 may on first sight seem to make a lot of sense, this is essentially the path to a major fork of kdelibs. I guess nobody does or would like such situation, since it will a) drain sources from KDE frameworks Only if the people that would work on this would otherwise work on KDE Frameworks. AFAIK, that's not the case. b) eventually lead to a lead lock, since if applications (a library itself is worth nothing) start to rely on that features (4.8, 4.9, 4.10?!) which have been added to the fork but not been integrated (this way) into frameworks, the applications are spellbound to the fork to avoid a regression - or porting things from kdelibs into vivid (ABI/API stable) frameworks, what to avoid all this trouble is about in the first place. I'm not aware of any cases where people wanted a new feature where they didn't also say they would forward port it to KDE Frameworks. Personally I wouldn't be in favor of accepting a distro patch for something that wasn't going to end up upstream. For this purpose, that's got to be frameworks. c) ultimately waste energy to either or both and the work to resolve the result I don't think it's a wast of energy to provide useful features to users. It is a mistake to assume that resources in FOSS projects are fungible. Just because people are prevented from working on kdelibs in 4.8, doesn't mean more resources are available for KDE Frameworks. --- Now while I can empathize with those who wish to see their feature upstream as fast as possible, I fear Kevin and others do not see the pot. struggles of opening kdelibs. kdelibs is already open. The packagekit/apper change that Kevin discussed is in Fedora. I'm sure Kubuntu will pick it up in order to make the latest Apper work. It's going to happen, the only question is how coordinated it's going to be. KDE frameworks is essentially the approach to segregate kdelibs, what is hard enough on a frozen object but completely impossible on a living being - at least under the conditions of KDE development. To do so it would be necessary to intercept each and every feature commit to kdelibs, inspect, channel, sometimes stall and ultimately merge it to KDE frameworks. While adding a second parameter to a function is a nobrainer, adding complete classes will require to rethink the constellation of the frameworks and that should happen as early as possible, regarding both, frameworks and the new feature. I am sorry to say, the open structure of KDE is a great thing, but it completely lacks the discipline and hierarchy for such (see Valentine's SecretService merge - no offense, i've don worse) and I doubt anyone wanted to buy in /that/ at all (because it'll kill the fun part) (As a sidenote: I also slightly fail to understand the prohibition to implement the new feature in the client(s) and keep it there until the final move to KDE frameworks, but that's not important) I fail to understand it either (I'm not ignorant of the plan, I don't need it explained to me, I just don't think the case to not allow people willing to work on features in 4.8 is at all compelling). --- On the other hand, this is free Software, written by many free individuals - for free and personal joy. This makes it impossible to just say: kdelibs is frozen and that's it. If the pressure to break the freeze grows to strong, people and esp. distros /will/ work around that, with the option for the unfortunate implications mentioned in the first paragraph. One simply cannot command or forbid things and force people to apply to that rules. Instead one has to take a soft path [1], because getting things done right is not invalidated by peoples minds. It's already happening, so the real question is how to minimize the impact. ... Scott K
Re: This starts to become a dangerous path (Was: New Feature for kdelibs)
On 11/15/2011 04:08 PM, Thomas Lübking wrote: Am Tue, 15 Nov 2011 15:20:44 -0500 schrieb Scott Kittermank...@kitterman.com: a) drain sources from KDE frameworks Only if the people that would work on this would otherwise work on KDE Frameworks. AFAIK, that's not the case. If one wants a feature in future KDE versions and such fork wouldn't exist, one would not add it at all rather than to the frameworks? Doesn't make any sense to me, sorry. That's true, but the question is when. For developers focused on more near term things than Frameworks, it's unlikely they'll help with Frameworks in order to get their feature out faster. Are there any examples of people who started working on the Frameworks port because kdelibs 4.8 doesn't exist? I'm not aware of any cases where people wanted a new feature where they didn't also say they would forward port it to KDE Frameworks. The major issue is a pot. time gap. People show up, add things they're interested in and then leave. Happens. It might not in all occasions be possible to add it to kdelibs and frameworks at the very same time. That's true. I think that improves the case for doing the work to support 4.8. I don't think it's a wast of energy to provide useful features to users. And I didn't say so at all, please don't put things into my mouth. But if something /is/ added to kdelibs and lost in the frameworks, it's been a waste. If a fork of kdelibs makes a merge to the frameworks impossible in reasonable time, all work on the frameworks was wasted. You do not question that, do you? I agree with that, but we are talking about a limited number of features required for specific applications, not a free for all of feature changes for change sake. I think 'fork' is a very strong word and it's really overkill for the case we're discussion. It is a mistake to assume that resources in FOSS projects are fungible. That is generally a valid argument, but applied on the wrong case. Just because people are prevented from working on kdelibs in 4.8, doesn't mean more resources are available for KDE Frameworks. We're not talking about the i'm working on the windowmanager and cannot fix akonadi at all situation. Entirely not. I agree. This isn't about capability, but timelines. kdelibs or frameworks are not features but locations, but people are interested in feature, not in locations. They are also interested in timeframes. Eg. Valentin wants his SecretService to be used by KDE software - if that means to add it to frameworks, he'll add it there. If it means to add it to kdelibs, he'll add it there. Everything else would be religious nonsense. It also means that if there are applications making use of it before KDE Frameworks is out, then it'll be left to distros to figure out how to stitch it together with the existing kdelibs to make it work (or just give up on the newer applications/features). Unless no one will make use of the work for things that are released before Frameworks is released, keeping it out of kdelibs just makes things harder for distributors. kdelibs is already open. I am not talking about downstream patches. If individual distributions like to backport things (happens and has happened a lot) or add proprietary stuff, that is completely different from opening the API, sorry. But the issues start, when those downstream changes get coordinated into a fork. Fortunately no one is talking about doing that. I fail to understand it either You really meant: Why not add it to the application (link static) and put it into frameworks later? (as i wrote.) No. I meant I don't understand how telling people their work can't go into KDE SC 4.8 will incentivize them to work on Frameworks. If they are interested in Frameworks, they're probably doing it already. It's already happening, so the real question is how to minimize the impact. This is why i've posted this mail in the first place. Minimizing the impact means to align up- and downstream, ie. find a way to provide features *now* w/o really opening kdelibs to new features but at best accelerate frameworks development. (as you probably read in the rest and unfortunately not commented part of my original post) I did read that part, but didn't comment on it. Since I'm not involved in Frameworks development, I've no opinion on if something like that is feasible. My suspicion is that KDE Frameworks will stay on the path it's on and the rest of us need to figure out how to deal with it. Scott K
Re: This starts to become a dangerous path (Was: New Feature for kdelibs)
On 11/16/2011 11:31 AM, Aaron J. Seigo wrote: On Tuesday, November 15, 2011 16:28:21 Scott Kitterman wrote: On 11/15/2011 04:08 PM, Thomas L�bking wrote: If one wants a feature in future KDE versions and such fork wouldn't exist, one would not add it at all rather than to the frameworks? Doesn't make any sense to me, sorry. That's true, but the question is when. For developers focused on more near term things than Frameworks, it's unlikely they'll help with Frameworks in order to get their feature out faster. Are there any examples of people who started working on the Frameworks port because kdelibs 4.8 doesn't exist? yes, though granted few, which is to be largely expected because frameworks is new and in addtion despite coming to this list with a _consensus decision_ by the _current maintainers and bulk of developers_ we have not received the kind of cooperation and support that one might be led to expect from the KDE community. in any case, because i've been strict about this with libplasma2, people have contributed to the frameworks branch (though sporadically as frameworks is still fledgling). beyond new people, it is just as important that this allows those of us who are working on it to do so without spending time forward porting. every time the KDE/4.7 branch changes, it slows us down as we then have to merge-and-fix (both into frameworks as well as master, btw). realize, as noted already, that as frameworks progresses these merges will become harder and more labor intensive. with the let things flow into KDE/4.7 approach, controlled or not, we not only lower incentive to work on frameworks but we make the efforts that are going into frameworks less efficient. the math is very evident from that point forward for what that means for frameworks. again, we've walked this path before. we know how this turns out. we can improve how we do things. I don't see how any of that couldn't be addressed equally well with a policy that said new features in kdelibs 4.x only after they are in frameworks. I don't think anyone would object to that and it would avoid any negative impact on the people doing the bulk of the work on KDE Frameworks (which I agree is an important goal). I agree with that, but we are talking about a limited number of features required for specific applications, not a free for all of feature changes for change sake. I think 'fork' is a very strong word and it's really overkill for the case we're discussion. agreed. i stil think there are significant risks for downstreams in this. kdelibs or frameworks are not features but locations, but people are interested in feature, not in locations. They are also interested in timeframes. agreed. and the answer is for us to get those timeframes together. this is something i've committed to getting done since that ball got dropped. the answer, however, is not to therefore make those working on frameworks harder, which is like working around a bug when we can just as easily fix the bug. Eg. Valentin wants his SecretService to be used by KDE software - if that means to add it to frameworks, he'll add it there. If it means to add it to kdelibs, he'll add it there. Everything else would be religious nonsense. It also means that if there are applications making use of it before KDE Frameworks is out, then it'll be left to distros to figure out how to stitch it together with the existing kdelibs to make it work (or just give up on the newer applications/features). Unless no one will make use of the work for things that are released before Frameworks is released, keeping it out of kdelibs just makes things harder for distributors. we are already doing this with kactivities, however. and will be doing so with ksecretservice. so your concern is simply unfounded. i think i may see a very important stumbling block here: many of us are still thinking of kdelibs as a monolithic thing. frameworks is going in the other direction and increasing modularity (we will be keeping the monolithic option for those who don't want to be bothered with a dozen new repos :) Except in kdelibs 4.x, it is monolithic like that, so just shoving features into a branch somewhere for people who are interested in it doesn't help distributors that want to try and support the widest variety of use cases. the only issue is with new features to existing libraries (and we've worked around this for KWallet...) and then it's like _any other kdelibs release_: it will be in the next feature release. we want this cycle to be medium length: it will be more than the usual 6 months, but if we coordinate together we can make FAR FAR shorter than the *3 YEARS* that the last revamp took (also for KDE 2) or the ~2 years (iirc?) that 3.0 took. we want sometihng more like 3.0, which took under a year. but that will only work if, like 3.0, we keep the scope
Re: This starts to become a dangerous path (Was: New Feature for kdelibs)
On 11/17/2011 04:05 AM, Thomas Zander wrote: On Thursday 17 November 2011 00.14.23 Scott Kitterman wrote: the best way to deal with it is not to consider it a fork of kdelibs but the next version of kdelibs (that's what it is) and help out with it I'd be interested if I could, but learning C++ didn't make it to the topof the TODO yet. I'm mostly interested in understanding how todistribute things in a functional, reliable, supportable way for all of4.x until the next generation is ready (then I'll probably be figuringout the same for it. If there is one thing to take away from the many emails, and especially Aarons excellent guidance towards the common thinking of the people doing the work, then its to not wait until Frameworks is ready. The Qt5 and kdelibs - frameworks transitions are much much less intrusive for apps than the Qt4 one and while it may take a little while to get the first stable frameworks vesion out, you can focus on frameworks already as the next version. I'm not sure why Scott is so focussed on the 4.x kdelibs and what lead to the conclusion to ignore frameworks until its ready. So I'm just saying that you should consider refocussing that attention. If you have a feature you would love to get into the common libs, you can still do what we have done for the last 10 years in KDE. * You first develop it in your own application, write the unit tests, you then stabilize it and you get more than one app to use it. * Then you get library reviews and you pick a target library to push it into. In this case this is frameworks; by default since 4.8 is closed. I'm unsure why thats an issue for anyone. Its not a huge wait, and it guarentees that your code will be in KDE for many years to come. On the other hand focussing on kdelibs which is essentially a stable branch now, will mean your code will die when apps switch to frameworks. Bottom line, I think this thread has too many talk and too little people volunteering for doing the work. And to be honest, I am not in a position to put time into this either. My €0.02 is that Aaron made clear the enormous amout of work (man-years!) and dedication it takes to do what Scott asked the kdelibs developers to do. And I'm still not seeing anyone put in the in comparison tiny fraction of time of porting the auto-download plasma thing to frameworks. Scott K wrote also; I get that what you're doing makes complete sense from your perspective. It also makes sense from the long term, the medium term and the KDE community perspectives. The short term you have to talk to the maintainer of the application you are targetting; but thats obviously off topic for this list. I'm reasonably confident we are still talking past each other (I'm not claiming any kind of bad intentions - I just don't think we are communicating very well). I'm convinced it wouldn't have been difficult at all to allow limited feature additions to kdelibs 4.8 and still wouldn't for 4.9 (since I assume we'll at least have that release before we move to KDE Frameworks), but the people doing the work are equally convinced that's not possible without side effects that make it not worth doing. It's clear this isn't a productive use of anyone's time, so I'll quit digging now. Scott K
Re: bugzilla situation
On Wednesday, February 22, 2012 07:00:26 PM Martin Gräßlin wrote: Am 22.02.2012 18:13, schrieb Laszlo Papp: The suggestion remains: to allow everyone to edit and close bugs, as is apparently the case in some other bug trackers. +1. Worked fine on the MeeGo bugzilla for instance, I previously used. Personally I'm not sure whether the MeeGo bugzilla can be compared to the KDE one (technical oriented vs. user oriented). From my personal experience (KWin bugtracker is felt 90 % a user support forum) I would not allow users to edit/close all bugs. We have too many users who report bugs, get it set to WONTFIX/INVALID and just reopen it. If I now imagine that everyone would be allowed to do so... Also I clearly don't want that people can change product or confirm bugs - that is something I like to see people doing where I know that I can trust them. Funny site note: I find it annoying that bugs reported by other developers are opened as NEW instead of UNCONFIRMED. I really like the idea of giving further rights to users who care. That is there are enough users in the bugtracker where you very fast notice that they are capable of doing bug tracking work. Helping them to become a triager - maybe just by sending a mail do you want more rights - might bring us quite some help in that area. I'm willing to invest some time in doing this kind of thing, but it wasn't obvoius to me how to go about getting rights to do it. Scott K
Re: ALERT: KDElibs (at least) 4.8.4 is actually 4.8.80+
On Monday, June 11, 2012 07:20:50 AM Sebastian Kügler wrote: On Sunday, June 10, 2012 01:22:03 Kevin Kofler wrote: On Sunday 10 June 2012, Nicolás Alvarez wrote: Why not start now and make the next kdelibs 4.8.5? Releasing a kdelibs 4.9 will just add to the confusion of how kdelibs development is working. Because having a kdelibs version different from (and especially lower than) the KDE SC version messes up our packaging pretty badly. I'd consider that a bug in your packaging. There's no absolute requirement of an app for a specific version of kdelibs. If your packages need that, you should probably fix them. The decoupling of libs and apps, and especially the modularization of kdelibs into Frameworks will only reveal more problems with your packages. Currently my About KDE says: Platform Version 4.8.3 (4.8.3) Once kdelibs versioning is desynchronized from the rest of the platform, what version is it? Scott K
Re: Proposed adjustments to our release cycles
On Friday, June 15, 2012 01:05:44 PM Sebastian Kügler wrote: Hi all, During our sprint in Pineda de Mar, we sat down and thought about how our release cycles relate to the structures in our software, we came up with the following proposal we'd like you to consider and provide feedback about. Starting with KDE Frameworks 5, we will release Frameworks, Workspaces and Applications each with their own release cycles. Each of these releases would be a set of tarballs of the latest stable versions of the application (or codebase in more general). As an example, Frameworks could release updates every 2 months, while our application collection is updated monthly. New iterations of the workspaces come every four months. (These numbers are completely arbitrary, and here only for illustration purpose!) More specifically for the Workspaces, we would like to release all workspaces at the same time. This model would * Allow components to skip releases if they need to take a longer development cycle * encourage developers to have an always releasable master * put more emphasis on continuous integration and other automated testing As far as we can judge, this would be in line with our communication strategy, and allow us to target different groups more clearly. That is something to streamline with the people at kde-promo, though. Opinions? Speaking as a packager for Kubuntu, it's hard for me to know how this would work for us. The current model serves us very well because we can tie a specific KDE SC minor feature version to each specific Kubuntu release and then update with bugfix only micro versions once they are available and tested. If I am reading your proposal correctly, I don't see anything about a stable supported branch to which only bug fixes were added? Where is the post-release support model in this? Perhaps there should be a standard interval (maybe even 6 months) for all of KDE SC to have one temporally aligned set of releases to provide post-release bugfix support for? That would allow the more rapid, less synchronized process you're advocating, but still give a supported target for distros to aim at. Scott K
Re: Proposed adjustments to our release cycles
On Friday, June 15, 2012 01:05:44 PM Sebastian Kügler wrote: Hi all, During our sprint in Pineda de Mar, we sat down and thought about how our release cycles relate to the structures in our software, we came up with the following proposal we'd like you to consider and provide feedback about. Starting with KDE Frameworks 5, we will release Frameworks, Workspaces and Applications each with their own release cycles. Each of these releases would be a set of tarballs of the latest stable versions of the application (or codebase in more general). As an example, Frameworks could release updates every 2 months, while our application collection is updated monthly. New iterations of the workspaces come every four months. (These numbers are completely arbitrary, and here only for illustration purpose!) More specifically for the Workspaces, we would like to release all workspaces at the same time. This model would * Allow components to skip releases if they need to take a longer development cycle * encourage developers to have an always releasable master * put more emphasis on continuous integration and other automated testing As far as we can judge, this would be in line with our communication strategy, and allow us to target different groups more clearly. That is something to streamline with the people at kde-promo, though. Opinions? I've read every message in this thread. From the perspective of a distribution packager, I'd like to sum up my perspective on this. Who are these releases for (what's the target audience)? It takes effort from packagers to packager a release. The level of effort is both per package and per release, so even without changing the release model, the move to frameworks, etc. is going to increase the amount of work we have to do. I don't think most distributions have spare developers waiting in the wings to deal with all this. Add more releases and I expect they aren't going to get packaged. If the target is people who build from source directly, then are releases for them really necessary if there's an always 'stable' integration branch people can build from? Once we get past a certain point in our release cycle and for certain in post- release updates we can only take bugfixes. Currently the vast majority of the KDE SC bug fixes we deliver are delivered via the KDE SC point releases where KDE developers have decided what is appropriate to backport to a stable release. We need this. For users that get KDE SC via a distribution these make a big difference. There was mention of the idea of designating a certain set of releases as LTS releases that would get post-release support like current releases do. I think that would solve most of the packaging problems I can think of from this proposal. We would likely aim to package those and use update releases as they became available. Scott K
Re: Compiler version
On Thursday, June 28, 2012 09:20:54 PM Thiago Macieira wrote: On quinta-feira, 28 de junho de 2012 18.53.03, viv...@gmail.com wrote: Il 28/06/2012 16:31, Thiago Macieira ha scritto: On quinta-feira, 28 de junho de 2012 14.38.37, viv...@gmail.com wrote: 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 That's nonsense. C++11 support in GCC 4.5 and 4.6 is just fine. Thiago you work to qt5 which include the c++11 stuff, so probably you know better than rumors around, must admit that I've spoken by those rather than an extended experience in the field. We may not be talking about the same thing. What made me think the rumors were true is: a) many programs which support to be compiled with c++11 syntax require gcc-4.7 It depends on which C++11 feature you're using. Qt has an #define for each of them so you can know if the compiler supports such a feature. Qt does not require C++11 and will not for many years. What's more, any program requiring full and unrestricted C++11 support will be extremely niche and not very popular until at least 2014. For those of us living in the real world, we have to accept that C++11 support is limited and therefore limit what we use of it. That being the case, GCC 4.5 and 4.6 are more than enough. b) that the resolved/fixed bug list is rather long: I used GCC 4.5 and 4.6 each for a year and I don't remember any serious bugs with them. There was one bug I reported (I think it was 4.5), which wasn't promptly fixed because it was in C++11 and that was experimental. Another issue I remember, which is definitely non-fatal, is that constexpr variables end up in the .data section instead of the .rodata one in 4.6. It's probably worth mentioning that there are issues in GCC 4.7 with mixing C++98 and C++11 code on one system. Here's the best discussion of it I could find: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53646 I don't pretend to understand all that, so I'm unlikely to be a good source of further answers, but this isn't just theoretical. There are some projects in Ubuntu that were making a lot of use of C++11 features and they stepped all over this once Ubuntu moved to GCC 4.7 (which is standard in the current development release). Scott K
Re: Compiler version
On Sunday, July 01, 2012 11:08:43 PM Ivan Čukić wrote: ... - 4.6 is desired for the features, but problematic since not all current stable versions of distros sport this version (last to fall into line - Slackware) ... Debian Stable (Squeeze) is also 4.5 by default. The next version (Wheezy) will be gcc 4.7 by default. Scott K
Re: Releases in 3 months
On Monday, July 08, 2013 03:04:40 PM À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. 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. You can read all the proposal in: http://community.kde.org/KDE_Core/ReleasesProposal 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. As its name indicates, it is a proposal, so please be constructive in the feedback, we can change as many things as we need. Finally, I have scheduled a Bof at Akademy, would be nice to have all the feedback from the community that is not able to come before it happens: http://community.kde.org/Akademy/2013/Wednesday#Room_A2_-_17_July What distro people did you check with? Scott K
Re: Releases in 3 months
On Monday, July 08, 2013 04:35:30 PM Àlex Fiestas wrote: On Monday 08 July 2013 16:26:00 laurent Montel wrote: No it’s not a good idea because nobody tests branch you can see pb that we had when we merge akonadi branch (last big changes). So no develop in branch will just create more bugs. And same question: why reduce time by 2 ? What we will have as result ? Ok in january with will release 4.14 great, so it’s right we will never release a so big number of kde but don’t know if it’s a good idea to run after number... And when we reduce time for example for 4.12 which finish in october, for me for example I have 2 weeks of vacations = dev == 1 month 1/2 ! Great for create features... Then you can target your features for January (4.13) there is no pressure. As I said before you can keep having 6 months schedule while others like Frank (or myself) can release features based on 3 month schedule. You don't have to change the way you work because of this. We've already experienced having some parts of the SC skip releases and it was a real problem from a distribution perspective. Please, let's not do it again. Scott K
Re: Releases in 3 months
On Monday, July 08, 2013 04:59:50 PM Àlex Fiestas wrote: On Monday 08 July 2013 10:40:21 Scott Kitterman wrote: We've already experienced having some parts of the SC skip releases and it was a real problem from a distribution perspective. Please, let's not do it again. KDE-PIM will be released, just not with the features of those working with a 6 months release cycle. For example, in the case of 4.12 it will have (I hope) my kde-accounts integration but it might not have some of the features developed by Laurent (this is just an hypothetical example). I don't know how to reconcile that with what you said in the mail I was replying to (that you snipped): Then you can target your features for January (4.13) there is no pressure. As I said before you can keep having 6 months schedule while others like Frank (or myself) can release features based on 3 month schedule. You don't have to change the way you work because of this. Either they do have to change and do releases every three months or elements of the SC get skipped on some releases. I don't see how you can have it both ways. Scott K
Re: Releases in 3 months
Albert Astals Cid aa...@kde.org wrote: El Dilluns, 8 de juliol de 2013, a les 11:25:42, Scott Kitterman va escriure: On Monday, July 08, 2013 04:59:50 PM Àlex Fiestas wrote: On Monday 08 July 2013 10:40:21 Scott Kitterman wrote: We've already experienced having some parts of the SC skip releases and it was a real problem from a distribution perspective. Please, let's not do it again. KDE-PIM will be released, just not with the features of those working with a 6 months release cycle. For example, in the case of 4.12 it will have (I hope) my kde-accounts integration but it might not have some of the features developed by Laurent (this is just an hypothetical example). I don't know how to reconcile that with what you said in the mail I was replying to (that you snipped): Then you can target your features for January (4.13) there is no pressure. As I said before you can keep having 6 months schedule while others like Frank (or myself) can release features based on 3 month schedule. You don't have to change the way you work because of this. Either they do have to change and do releases every three months or elements of the SC get skipped on some releases. I don't see how you can have it both ways. * all the repositories get released * repositories only get features that are completed * If your feature will take more than 3 months to develop, you do it in a branch I don't see where's the problem and why elemens of the SC will need to skip some releases. As long as they are developing features in branches, I agree. Scott K
Re: Releases in 3 months
On Tuesday, July 09, 2013 02:02:48 AM Aleix Pol wrote: On Mon, Jul 8, 2013 at 3:04 PM, Àlex Fiestas afies...@kde.org 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. 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. You can read all the proposal in: http://community.kde.org/KDE_Core/ReleasesProposal 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. As its name indicates, it is a proposal, so please be constructive in the feedback, we can change as many things as we need. Finally, I have scheduled a Bof at Akademy, would be nice to have all the feedback from the community that is not able to come before it happens: http://community.kde.org/Akademy/2013/Wednesday#Room_A2_-_17_July Cheers ! Hi, I think this can be an important step forward in KDE. I see here that we're essentially adding flexibility to our project delivery, it's something that we've missed for longtime and I'd say that we want to use this opportunity to our favor. Most of the arguments I see here are technical complaints about such a management change. Most of us here are technologists and we can deal with those changes. Moreover, we just adopted git and some developers are still using it as svn. I think that agreeing upon having a clean and usable master will be healthy for all KDE projects, one of the biggest problems I've had as a maintainer is lack of future versions' users. We want those, and I know many KDE developers who don't test regularly what our users will end up suffering. This has to stop. Either way, I hope that our project maintainers will keep making sure no unfinished features end up in our final releases. Getting this workflow firmly in place seems like a reasonable pre-requisite to the shorter release cycle. Scott K
Re: openSUSE packagers' take on the 3 month release cycle
On Monday, July 08, 2013 09:55:28 PM Albert Astals Cid wrote: El Dilluns, 8 de juliol de 2013, a les 20:35:22, Luca Beltrame va escriure: (apologies for breaking your threading, but I'm not subscribed to k-c-d; in fact, please CC me with replies, thanks!) Currently, the people working on openSUSE packages are against the proposal. A detailed explanation follows. First and foremost, the KDE packaging in openSUSE is almost completely community driven. This means that most of the work is done by volounteers which handle what they can in their (limited) time. Faster releases may mean worse packaging and increased maintenance (and I think this is also an issue w/most non rolling distros). From total ignorace, how much time do you need to change a 4.12 to a 4.13 in a spec file? What is consuming your time doing a packaging of a new release? For Kubuntu (also mostly volunteer effort), it took about two weeks to package the 4.11 beta. For generating package updates for already existing packages, we have a script that will produce initial packages. These all have to be test compiled, checked for new or missing files, checked for files that have moved between packages, checked for license/copyright updates, etc. In the case of new packages (which the newly split modules are), packaging needs to be developed. For a split module, the information can largely be derived from the old mega-module, but it's done by hand, it's not automated. Also, all new packages undergo an extra layer of review before they are accepted into the archive that takes more time. For 4.11, the new packages took most of the time, but checking all the existing ones still took substantial time due to changes. Beta 2 took substantially less time, but there are still changes that need to be checked. Assuming no changes that impact the packaging, the RC's, final, and point releases will be mostly running a script and sanity checking the results. For us, each new major release is a significant effort. For the added releases (at the halfway mark from where releases would be expected with the current cycle) the .0 release will land just about at the same time as feature freeze for the distro release. This means not a lot of time to get a fair amount of work done. My assessment is that we could live with the three month release cycle from a development perspective. The biggest thing we'd lose having fewer point releases for post-release updates (we ship all the point releases to our end users and appreciate the added stability they provide). If we could figure out a good plan to deal with better post-release testing/support, then I think the proposal would be manageable for us (my opinion only, not a collective Kubuntu position). Scott K
Re: openSUSE packagers' take on the 3 month release cycle
On Tuesday, July 09, 2013 12:05:30 PM Àlex Fiestas wrote: On Monday 08 July 2013 22:01:29 Andrea Scarpino wrote: We don't just run a sed rule on each spec (pkgbuild, in my case) file. We check for new dependencies (resp. dependencies not needed anymore), new modules (resp. modules not part of the SC anymore), build failure, etc... Can't we do something so you don't have to hunt this down but instead just read a list? For build time dependencies, we could do something by looking for find_package, and for runtime dependencies we should figure something out. Our projects are a mess when it comes to runtime dependencies, why don't we fix that for example? How would a run time only dependency be expressed? I've seen some people put them in find_package, which is wrong and then we end up having to patch it away. For build-time dependencies, particularly determining minimum version requirements, I end up reading CMakeLists.txt in my favorite editor. That's not ideal either. Scott K
Re: openSUSE packagers' take on the 3 month release cycle
On Tuesday, July 09, 2013 12:11:48 PM Àlex Fiestas wrote: On Monday 08 July 2013 20:16:16 Scott Kitterman wrote: For Kubuntu (also mostly volunteer effort), it took about two weeks to package the 4.11 beta. For generating package updates for already existing packages, we have a script that will produce initial packages. This is quite fast, should be compatible with 3 month release apparently. It's about 4% of a 6 month cycle and 8% of a 3 month cycle, so the time does become more significant on the shorter cycle. These all have to be test compiled, checked for new or missing files, checked for files that have moved between packages, checked for license/copyright updates, etc. I guess you have all this mostly automagically done? Some yes, some no. The copyright/licensing stuff is the hardest and it's very manual. It's work that has to be done to ensure we are legally distributing the packages, so there's no way around it. In the case of new packages (which the newly split modules are), packaging needs to be developed. For a split module, the information can largely be derived from the old mega-module, but it's done by hand, it's not automated. Also, all new packages undergo an extra layer of review before they are accepted into the archive that takes more time. Maybe I'm wrong, but until plasma-workspace2 I don't see any more splitting happening, all modules are now in git, have been split, and in anyway spliting is something we do exceptionally, we can add rules for that. Some of the recent releases were more work than we'll probably see in the near future, I wasn't trying to predict workload, but describe what's my recent experience has been. For 4.11, the new packages took most of the time, but checking all the existing ones still took substantial time due to changes. Beta 2 took substantially less time, but there are still changes that need to be checked. Assuming no changes that impact the packaging, the RC's, final, and point releases will be mostly running a script and sanity checking the results. For us, each new major release is a significant effort. For the added releases (at the halfway mark from where releases would be expected with the current cycle) the .0 release will land just about at the same time as feature freeze for the distro release. This means not a lot of time to get a fair amount of work done. Have you taken into account that releases will be smaller? the amount of changes in every release can be expected to be smaller, less breakage, less splitin less everything. That's a theory. I expect it will be someone less churn, but every module has to be checked to some degree, so even if it's half the develop changes landing, it's not half the work for us. My assessment is that we could live with the three month release cycle from a development perspective. The biggest thing we'd lose having fewer point releases for post-release updates (we ship all the point releases to our end users and appreciate the added stability they provide). If we could figure out a good plan to deal with better post-release testing/support, then I think the proposal would be manageable for us (my opinion only, not a collective Kubuntu position). Awesome! this is the kind of feedback I want :) If we could make all developers make better use of commit tags, I think this could help. Once we get use to that we could develop scripts or websdites showing all fixes, maybe even with categories, kinda: FIX: IMPORTANT FIX: MINOR FIX: Also, in the case of BUG: we could extract from bugzilla some information, so you can decide whether backport it or not. What do you think? I want the point releases. The reasons for wanting them are for consistency, marketing, and for distro policy releases its' much easier to get a set of packages that are part of a release through the post distro release QA process than a set of indiviual changes. Also, as a pratical matter, we manage to find the volunteer motivation to package a point release, but only rarely for individual changes. I don't think it would help much. A related point is KDE support policy. AIUI, currently KDE will provide security support for the previous two releases. After that, distros are on their own. Did you envision that changing to four with this proposal? If not, you're cutting my upstream security support in half. I would like to figure out something about a better way to test point releases and be able to do them more reliably/longer. I'll think about it. I do think this has to be addressed in some manner before going to your proposed schedule. Scott K
Re: openSUSE packagers' take on the 3 month release cycle
Vishesh Handa m...@vhanda.in wrote: On Tue, Jul 9, 2013 at 4:13 PM, Scott Kitterman k...@kitterman.com wrote: These all have to be test compiled, checked for new or missing files, checked for files that have moved between packages, checked for license/copyright updates, etc. I guess you have all this mostly automagically done? Some yes, some no. The copyright/licensing stuff is the hardest and it's very manual. It's work that has to be done to ensure we are legally distributing the packages, so there's no way around it. Could you please elaborate why the licensing stuff cannot be automatically done? Most licenses follow a similar template. In fact most developers just copy paste the license (as they should). I can imagine writing a simple script the extract the copyright holder's name and type of license from any file. Maybe it would only work for 90% of the cases, but it should still work. And for that remaining 10%, you can always ask the developer to use a standard version of the license, thereby decreasing your work in the future. There I'd a licensecheck script that does this. It helps, but the results have to be checked and properly documented and so thete is still substantial manual work required. KDE packages are generally better about consistently documenting copyright and licensing, but we still find bugs and it's still a lot of work. Scott K
Re: openSUSE packagers' take on the 3 month release cycle
On Tuesday, July 09, 2013 12:52:04 PM Àlex Fiestas wrote: On Tuesday 09 July 2013 06:43:48 Scott Kitterman wrote: I want the point releases. The reasons for wanting them are for consistency, marketing, and for distro policy releases its' much easier to get a set of packages that are part of a release through the post distro release QA process than a set of indiviual changes. Also, as a pratical matter, we manage to find the volunteer motivation to package a point release, but only rarely for individual changes. I don't think it would help much. We can have as many point releases as needed, in any version as long as there is somebody doing the backporting and the testing. The reality, even nowdays is that even though we do backports almost nobody is testing the stable branch (and some people even forget to do backports). So we end up having point releases that are less stable than their predecessors. So, in anyway (independently of 3 or 6 months release schedule) we need a better way of doing minor releases. A related point is KDE support policy. AIUI, currently KDE will provide security support for the previous two releases. After that, distros are on their own. Did you envision that changing to four with this proposal? If not, you're cutting my upstream security support in half. I was not aware of this, I'm sure we can include it. I would like to figure out something about a better way to test point releases and be able to do them more reliably/longer. I'll think about it. I do think this has to be addressed in some manner before going to your proposed schedule. As i said before, we need the interested parties to do the backporting and the testing, you are the ones that know what is bothering your users. We also need to do a better work on making your life easier, use bugzilla correctly, commit tags etc. We (not me, someone else working on Kubuntu) solved a longstanding riddle in our build infrastructure that was blocking having regular builds of the stable branches. We're looking into the possibility of providing tip of stable packages that would make it easier for our users to test the stable branch. If we can get better testing and upstream developers do a good job of landing suitable fixes, then it ought to be mostly a matter of the KDE release team being willing to do the releasing. Scott K
Re: Releases in 3 months
On Wednesday, July 10, 2013 06:08:04 PM Àlex Fiestas wrote: On Wednesday 10 July 2013 13:22:20 Sune Vuorela wrote: On 2013-07-09, Sune Vuorela nos...@vuorela.dk wrote: So. first one. Second one Release frequency. We have a giant quality problem. Distros won't ship a .0 release to real users (as opposed to testers/power users) and wait until there has been a couple of bug fix releases. Until we ensure that our .0 releases are usable I don't see how we can cut down on that. Some distros release in a 6 month cycle. Others in a 8. and ones even in longer cycles. Going for anything shorter than 6 months will ensure that distros are going to skip releases. why work with releases that they aren't going to ship to users anyways? Not by distributions working that way I guess. Part of the reasons why I want this release schedule is exactly for these distros. Let me explain. Right now distributions pick the release they see fit and make a distro with it. It might be .0, .2 or .5. If a distribution in their right decide to pick a .5 release wile a .0 is already out there (this already happened), what is happening here is that a HUGE release with a LOT of changes won't even get to the users of that distribution at least for another distribution cycle. This usually happens with distributions that have a release cycle of 9 months. With having releases every 3 months we make the amount of features smaller and more often so distributions will always be able to pick a more updated release than with the current situation. And given there need to be some stabilization and integration work, I'm sure skipping releases would be the default for most distros. Hopefully distros can coordinate and at least skip the same. Mostly leading to the other releases being useless because they only reach very few users. This is already happening, no change here. And as it currently is, we need the .4 and .5 releases. and .6 and .7 and .8 and .9, we could have a 4.0.200, there is always need of bugfixing releases, question is how many of these point releases are pending of upstream KDE and not downstream distros. To make it clear, I WANT to have .4 and .5 releases, just not made by upstream developers. This isn't the first time upstream KDE developers have suggested offloading the boring upstream maintenance work to distributions. It's still not a good idea. We don't particularly have spare manpower to pick this work up and many of us are primarily packagers who lack the skills needed to do this. I'm glad to work on better ways to test and give feedback so the point releases are stronger, but I don't think outsourcing them is the right answer. Scott K
Re: Releases in 3 months
On Wednesday, July 10, 2013 06:54:06 PM Àlex Fiestas wrote: On Wednesday 10 July 2013 18:26:55 you wrote: On Wednesday 10 of July 2013 18:08:04 Àlex Fiestas wrote: On Wednesday 10 July 2013 13:22:20 Sune Vuorela wrote: On 2013-07-09, Sune Vuorela nos...@vuorela.dk wrote: So. first one. Second one Release frequency. We have a giant quality problem. Distros won't ship a .0 release to real users (as opposed to testers/power users) and wait until there has been a couple of bug fix releases. Until we ensure that our .0 releases are usable I don't see how we can cut down on that. Some distros release in a 6 month cycle. Others in a 8. and ones even in longer cycles. Going for anything shorter than 6 months will ensure that distros are going to skip releases. why work with releases that they aren't going to ship to users anyways? Not by distributions working that way I guess. Part of the reasons why I want this release schedule is exactly for these distros. Let me explain. Right now distributions pick the release they see fit and make a distro with it. It might be .0, .2 or .5. If a distribution in their right decide to pick a .5 release wile a .0 is already out there (this already happened), what is happening here is that a HUGE release with a LOT of changes won't even get to the users of that distribution at least for another distribution cycle. This usually happens with distributions that have a release cycle of 9 months. The Linux kernel itself maintain old branches with big number of point releases. See 3.0.85, 3.2.48, 3.4.52, done by kernel developers. Done by the kernel developers interested on those. My proposal is to make the parties interested on this, actually do this. [...] And as it currently is, we need the .4 and .5 releases. and .6 and .7 and .8 and .9, we could have a 4.0.200, there is always need of bugfixing releases, question is how many of these point releases are pending of upstream KDE and not downstream distros. To make it clear, I WANT to have .4 and .5 releases, just not made by upstream developers. Uhm... are you sure this will work? It can work for paid contributors, but not for unpaid ones. Moreover, this means that it's fine if users don't receive the last version, which was one of your goals stated above: I can't fight with distros, and I don't want to fight with them. If distros need .5 .6 and .200 so be it, just they will have to do them themselves (and I hope we can make the process smooth so they can actually do it). As has been said in this thread, almost no KDE developer is using the stable branch, blindly backporting has shown to be dangerous and has created many issues in the past so we are not the right people to make these point releases. I think distros can help with getting more testing and even provide good feedback on if a point release is baked. I don't think we should be looking in git and deciding what should be backported or not. I think the developers of the code should do that. Scott K
Re: Releases in 3 months
On Wednesday, July 10, 2013 07:44:35 PM Martin Graesslin wrote: On Wednesday 10 July 2013 17:13:11 Sune Vuorela wrote: On 2013-07-10, Aaron J. Seigo ase...@kde.org wrote: =3D=3D On scheduling mainenance releases in a longer 4 month cycle, i=E2=80=99d cut that to 8 weeks and keep jus= t the one=20 update. this would ease the burdon on our release team (and by extension packag= ers)=20 while also giving developers more time to get better tested fixes in. I don't think that it would lessen the burden on anyone. And as long as our quality of our stable releases is like they are, we need the first couple of point releases early. Sorry, but you are doing an incorrect conclusion here. People don't test betas and wait for the .0 because that's the stable release. It results in .0 not being stable as the beta has not been tested. So people wait for .1 because .0 is not stable enough. That results in .1 not being stable because nobody tested the betas and the .0. If we go by that in the end also the .4 will not be stable which is used by Debian. We need to get away from it's not stable enough to it's stable. The only way is to increase the testing and make everything we can do to have an awesome and rocking .0. I think Alex approach is the right one. Reducing the number of features going into a release reduces automatically the number of possible problems. Having master in an always releasable state means there cannot be lots of problems. And I know what I'm talking about, KWin follows the always releasable master for years, because too many people rely on KWin master working properly. It's just a matter of discipline and I highly recommend to go to the Quality talk on Saturday with nice stories by vhanda and me how we f***d up from a quality perspective and what we learned from it. My main topic of the talk will be stable updates are untested. Today when I drafted the slide I thought about calling our point releases Schrödinger's KDE - you don't know whether the release is good or bad till you tried it. And that's only the case for the point releases, the .0 is way better tested. I agree this is a problem. Currently before we expose all Kubuntu users to post-release updates (post the Kubuntu release, usually that amounts to 4.x.3 and later) we provide packages from an unofficial archive (PPA, for those that know/care about details) for testing before we ever start the formal QA process in large part due to knowing about the lack of testing. As I think I've mentioned before in this thread, we're going to look into providing tip of the stable branch packages that people can test so that there is more testing before the point release happen. Independent of the release cycle discussion, I think this an area that needs improvement. Scott K
Re: Releases in 3 months
On Friday, July 12, 2013 05:27:53 PM Aaron J. Seigo wrote: On Wednesday, July 10, 2013 14:23:24 Scott Kitterman wrote: I've mentioned before in this thread, we're going to look into providing tip of the stable branch packages that people can test so that there is more testing before the point release happen. Independent of the release cycle discussion, I think this an area that needs improvement. is there anything upstream developers can help to make this a reality? Not at the moment. Until recently (like last week) we hadn't pursued this idea due to a problem in the Ubuntu build infrastructure that's finally been worked around. Now that we're no longer blocked, I think it's mostly a matter of us having time to set things up. Scott K
Re: Releases in 3 months
On Monday, July 15, 2013 02:48:01 PM Albert Astals Cid wrote: El Diumenge, 14 de juliol de 2013, a les 04:19:52, Inge Wallin va escriure: I think keeping 6 months is a good figure to ensure both reasonable turn-around *and* actual bugfixes of versions being used in the real world. It may be a reasonable turn-around for some users, but it is also not defenitely reasonable for some developers. Real data: October 25, 2012: KDE SC 4.10 Soft Feature Freeze August 14, 2013: KDE SC 4.11 Release This means that if a new developer suggest a new feature (with half finished code) just after the soft-freeze has kicked in, when told he has to wait almost 10 months to see his feature released, he will probably walks away since he thinks that's too long, i might be dead in 10 months. And we just lost a potential developer, and to be honest, users can be sometimes awesome, but I'll take a developer over a user any time, since the developer will help us getting more users ;-) We need to find a way to make it easier to hook-in this kind of developers, 10 months is just too much. Picking this apart a bit more, this 10 months represents: FF - Release - Development - FF - Release So time between last opportunity to land an unplanned feature is two times the time from soft feature freeze to release plus one times the development window in the next cycle. Based on the 4.11 schedule, that looks like: Wednesday, February 6, 2013: KDE SC 4.10 Release Wednesday, May 22, 2013: KDE SC 4.11 Soft Feature Freeze Wednesday, August 14, 2013: KDE SC 4.11 Release FF - Release = 15 weeks Development window = 12 weeks 15 x 2 + 12 = 42 weeks (or ~ your ten months) 30 of the 42 weeks are spent in some kind of freeze state. Without process changes to get from feature complete to released there's no way to get to a three month cycle. Rather than aim for some arbitrary cycle length when you are discussing it, I think that it would be useful to look ways to reduce the time from FF to release without reducing code quality at release time. Once there's a reasonable approach to do that, then, based on how long that period needs to be, it'll be pretty clear how long the release cycle should be. Every week that can be taken out of the FF to release process actually gets the time when the hypothetical new contributor can see their contribution in a release reduced by two weeks. The other nice thing about focusing on process improvements around FF to release is that they can be done/demonstrated to work without simultaneously shortening the release cycle. I think one step at a time would be a safer approach for the project. Scott K
Re: Releases in 3 months
On Monday, July 15, 2013 09:00:27 PM Luca Beltrame wrote: À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. Replying to the message starting the thread because I forgot something important at least from the openSUSE perspective: what we call maintenance updates. Starting recently the KDE team at openSUSE is also managing to push minor releases of the latest stable SC included in the distribution. The rationale is that the number of bugs fixed between minor releases is *always* signficant and doing branch diffs is way more costly from a time and human perspective. However the issue is that this may be problematic in case of shorter releases. Again, I really don't want to sound negative or dissing the proposal: what I mean to say is that there are /doubts/, rather than absolute certainties. We're happy to be proven wrong, in fact. ;) Kubuntu has also pushed minor releases as updates similarly (for several years). I have a similar concern. Scott K
Re: Releases in 3 months
I wish I was there. Scott K Albert Astals Cid aa...@kde.org wrote: Just as a reminder, we have the Release Team BOF tomorrow July 17 at 10:15 at Room A2 Cheers, Albert El Dimarts, 16 de juliol de 2013, a les 14:38:47, Scott Kitterman va escriure: On Monday, July 15, 2013 09:00:27 PM Luca Beltrame wrote: À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. Replying to the message starting the thread because I forgot something important at least from the openSUSE perspective: what we call maintenance updates. Starting recently the KDE team at openSUSE is also managing to push minor releases of the latest stable SC included in the distribution. The rationale is that the number of bugs fixed between minor releases is *always* signficant and doing branch diffs is way more costly from a time and human perspective. However the issue is that this may be problematic in case of shorter releases. Again, I really don't want to sound negative or dissing the proposal: what I mean to say is that there are /doubts/, rather than absolute certainties. We're happy to be proven wrong, in fact. ;) Kubuntu has also pushed minor releases as updates similarly (for several years). I have a similar concern. Scott K
Re: Releases in 3 months
On Thursday, July 18, 2013 01:19:12 AM Albert Astals Cid wrote: El Dimecres, 17 de juliol de 2013, a les 07:37:16, Luca Beltrame va escriure: Albert Astals Cid wrote: Just as a reminder, we have the Release Team BOF tomorrow July 17 at 10:15 at Room A2 Would it be possible to post the outcome of the discussion here? It would be very helpful (as unfortunately I'm not in Bilbao). Jonathan sent the minutes in an email with subject release schedule BoF The outcome as I understand it is: * I'll propose a new schedule for 4.12 where all the freezes are collapsed into one * Alex will (or will find someone to) create tools that will help with release management, e.g. git hooks, templates, and whatnot. And for 4.13 we'll re-evaluante if it makes sense to a 4 (or 3) month release or go back to 6 months. Hope this is acceptable for everyone. What's the length of the 4.12 release cycle then? Scott K
Re: Upcoming changes to CI system
Ben Cooksley bcooks...@kde.org wrote: Hi all, In order to improve the maintainability and cleanliness of the shared dependencies the way they will be handled on the CI system will be changing. The nature of this change is that all projects which need a shared dependency will now need to declare a dependency against it in the appropriate file in the CI script configuration. A shared dependency is essentially a non-KDE project: a) Where distribution packages are too old (like CMake) b) projects which depend on Qt (and therefore cannot be installed system wide) A list of shared dependencies can be seen at http://build.kde.org/view/External_Deps/ I have the following known shared dependencies at the moment: ... kde/kdebindings/pykde4: shared/pyqt4 For pykde4 there is also sip: http://www.riverbankcomputing.com/software/sip ... Scott K
Re: Review Request 119221: Don't rewrite mailto: URLs als mailto://
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/119221/#review62106 --- This change makes kdelibs consistent with RFC 2368 (which defined the mailto URL scheme). - Scott Kitterman On July 10, 2014, 8:40 p.m., Felix Geyer wrote: --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/119221/ --- (Updated July 10, 2014, 8:40 p.m.) Review request for kdelibs. Repository: kdelibs Description --- KUrl::prettyUrl() rewrites mailto: URLs als mailto:// if the path is empty. MUAs don't handle mailto:// URLs correctly. mailto:t...@example.com and mailto:?to=t...@example.com are both valid and semantically equivalent. KUrl::prettyUrl() converts the latter one to mailto://?to=t...@example.com This works fine: kde-open mailto:t...@example.com but this fails: kde-open mailto:?to=t...@example.com For example with Thunderbird it creates a mail with: To: // To: t...@example.com The proposed change special cases mailto so it always uses mailto: instead of mailto://. Diffs - kdecore/io/kurl.cpp 8c491f7 kdecore/tests/kurltest.cpp 1fd204f Diff: https://git.reviewboard.kde.org/r/119221/diff/ Testing --- Tested with kdelibs 4.13.2 and Thunderbird, Evolution and KMail. Thanks, Felix Geyer
Re: Review Request 119302: Make FindPyQt4 work with PyQt's new build system.
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/119302/#review62456 --- I think PYQT4_SIP_DIR can still be determined automatically, but I'm still sorting through the details. Upstream for PyQt refers to the configure.py for QScintilla2 as a sample for how things should be done in the new world order and it appears to determine it. I'll provide details shortly.. - Scott Kitterman On July 15, 2014, 9:19 p.m., Raphael Kubo da Costa wrote: --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/119302/ --- (Updated July 15, 2014, 9:19 p.m.) Review request for Build System, KDE Bindings, kdelibs, Alex Merry, Luca Beltrame, and Simon Edwards. Bugs: 337462 http://bugs.kde.org/show_bug.cgi?id=337462 Repository: kdelibs Description --- Since PyQt 4.10, PyQt.pyqtconfig is deprecated and not available unless PyQt is built using the old configure script. There is no direct replacement for it, as PyQt's new build system does not provide as much information as before by design. Luckily, most of the variables we are interested in can be obtained from PyQt's QtCore module itself even if its old build system is used. The only exception is `pyqt_sip_dir`, which cannot be determined at all if pyqtconfig is not available. In this case, there is nothing we can do but ask the user to specify it manually via CMake with something like `-DPYQT4_SIP_DIR=/usr/share/sip`. To this effect, all variables set by FindPyQt4.cmake have been made cache variables, which means their values can be overriden by the user, thus ignoring the contents read via FindPyQt.py. Diffs - cmake/modules/FindPyQt.py 5d2f9514d87553d5a16a95943618572316c92861 cmake/modules/FindPyQt4.cmake b176b4f8cfee471a1b7aecdd2723d165b0496a85 Diff: https://git.reviewboard.kde.org/r/119302/diff/ Testing --- I was able to make Kate find PyQt by passing `-DPYQT4_SIP_DIR=...` with my PyQt installation without `pyqtconfig.py`, and calling `FindPyQt.py` by hand on a Debian system with `pyqtconfig.py` worked as before. Thanks, Raphael Kubo da Costa
Re: Review Request 119302: Make FindPyQt4 work with PyQt's new build system.
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/119302/#review62457 --- This is the method used in qscintilla2's configure.py (which upstream has generally endorsed): #! /usr/bin/python import sys import os if sys.platform == 'win32': data_dir = sys.prefix else: data_dir = sys.prefix + '/share' py_sip_dir = os.path.join(data_dir, 'sip') # Note: Set this by hand since the logic to figure out if we're using PyQt4 or # PyQt5 isn't relevant to the question (QScintilla does do this, but it's not # germane). pyqt = 'PyQt4' if pyqt is not None: pyqt_sip_dir = os.path.join(py_sip_dir, pyqt) else: pyqt_sip_dir = None print(pyqt_sip_dir) # prints /usr/share/sip/PyQt4 We should use something similar. - Scott Kitterman On July 15, 2014, 9:19 p.m., Raphael Kubo da Costa wrote: --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/119302/ --- (Updated July 15, 2014, 9:19 p.m.) Review request for Build System, KDE Bindings, kdelibs, Alex Merry, Luca Beltrame, and Simon Edwards. Bugs: 337462 http://bugs.kde.org/show_bug.cgi?id=337462 Repository: kdelibs Description --- Since PyQt 4.10, PyQt.pyqtconfig is deprecated and not available unless PyQt is built using the old configure script. There is no direct replacement for it, as PyQt's new build system does not provide as much information as before by design. Luckily, most of the variables we are interested in can be obtained from PyQt's QtCore module itself even if its old build system is used. The only exception is `pyqt_sip_dir`, which cannot be determined at all if pyqtconfig is not available. In this case, there is nothing we can do but ask the user to specify it manually via CMake with something like `-DPYQT4_SIP_DIR=/usr/share/sip`. To this effect, all variables set by FindPyQt4.cmake have been made cache variables, which means their values can be overriden by the user, thus ignoring the contents read via FindPyQt.py. Diffs - cmake/modules/FindPyQt.py 5d2f9514d87553d5a16a95943618572316c92861 cmake/modules/FindPyQt4.cmake b176b4f8cfee471a1b7aecdd2723d165b0496a85 Diff: https://git.reviewboard.kde.org/r/119302/diff/ Testing --- I was able to make Kate find PyQt by passing `-DPYQT4_SIP_DIR=...` with my PyQt installation without `pyqtconfig.py`, and calling `FindPyQt.py` by hand on a Debian system with `pyqtconfig.py` worked as before. Thanks, Raphael Kubo da Costa
Re: Review Request 119302: Make FindPyQt4 work with PyQt's new build system.
On July 16, 2014, 1:42 a.m., Scott Kitterman wrote: This is the method used in qscintilla2's configure.py (which upstream has generally endorsed): #! /usr/bin/python import sys import os if sys.platform == 'win32': data_dir = sys.prefix else: data_dir = sys.prefix + '/share' py_sip_dir = os.path.join(data_dir, 'sip') # Note: Set this by hand since the logic to figure out if we're using PyQt4 or # PyQt5 isn't relevant to the question (QScintilla does do this, but it's not # germane). pyqt = 'PyQt4' if pyqt is not None: pyqt_sip_dir = os.path.join(py_sip_dir, pyqt) else: pyqt_sip_dir = None print(pyqt_sip_dir) # prints /usr/share/sip/PyQt4 We should use something similar. So markdown and python code comments don't mix. The bolded things all have a leading '#'. - Scott --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/119302/#review62457 --- On July 15, 2014, 9:19 p.m., Raphael Kubo da Costa wrote: --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/119302/ --- (Updated July 15, 2014, 9:19 p.m.) Review request for Build System, KDE Bindings, kdelibs, Alex Merry, Luca Beltrame, and Simon Edwards. Bugs: 337462 http://bugs.kde.org/show_bug.cgi?id=337462 Repository: kdelibs Description --- Since PyQt 4.10, PyQt.pyqtconfig is deprecated and not available unless PyQt is built using the old configure script. There is no direct replacement for it, as PyQt's new build system does not provide as much information as before by design. Luckily, most of the variables we are interested in can be obtained from PyQt's QtCore module itself even if its old build system is used. The only exception is `pyqt_sip_dir`, which cannot be determined at all if pyqtconfig is not available. In this case, there is nothing we can do but ask the user to specify it manually via CMake with something like `-DPYQT4_SIP_DIR=/usr/share/sip`. To this effect, all variables set by FindPyQt4.cmake have been made cache variables, which means their values can be overriden by the user, thus ignoring the contents read via FindPyQt.py. Diffs - cmake/modules/FindPyQt.py 5d2f9514d87553d5a16a95943618572316c92861 cmake/modules/FindPyQt4.cmake b176b4f8cfee471a1b7aecdd2723d165b0496a85 Diff: https://git.reviewboard.kde.org/r/119302/diff/ Testing --- I was able to make Kate find PyQt by passing `-DPYQT4_SIP_DIR=...` with my PyQt installation without `pyqtconfig.py`, and calling `FindPyQt.py` by hand on a Debian system with `pyqtconfig.py` worked as before. Thanks, Raphael Kubo da Costa
Re: Review Request 119302: Make FindPyQt4 work with PyQt's new build system.
On July 16, 2014, 1:42 a.m., Scott Kitterman wrote: This is the method used in qscintilla2's configure.py (which upstream has generally endorsed): #! /usr/bin/python import sys import os if sys.platform == 'win32': data_dir = sys.prefix else: data_dir = sys.prefix + '/share' py_sip_dir = os.path.join(data_dir, 'sip') # Note: Set this by hand since the logic to figure out if we're using PyQt4 or # PyQt5 isn't relevant to the question (QScintilla does do this, but it's not # germane). pyqt = 'PyQt4' if pyqt is not None: pyqt_sip_dir = os.path.join(py_sip_dir, pyqt) else: pyqt_sip_dir = None print(pyqt_sip_dir) # prints /usr/share/sip/PyQt4 We should use something similar. Scott Kitterman wrote: So markdown and python code comments don't mix. The bolded things all have a leading '#'. Luca Beltrame wrote: Good idea. Can this be done? Raphael Kubo da Costa wrote: I did look at QScintilla's build system when writing my patch, but chose not to follow this path: doing this only works for the default values (`sys.prefix/sip` on Windows, `sys.prefix/share/sip` elsewhere), which in the worst case can be a different installation unrelated to the one used by the PyQt version we're using. I didn't see much value in just working out of the box in some specific cases. I think working out of the box in the standard, default case using the upstream recommended method is much better than requiring the value to be set by hand in all cases. This change set is about adjusting to the new upstream approach to things, so using the upstream recommended solution seems only logical. If this doesn't get included upstream, I'll add it as a distro patch for Debian/Kubuntu as I think it's definitely a superior approach. - Scott --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/119302/#review62457 --- On July 15, 2014, 9:19 p.m., Raphael Kubo da Costa wrote: --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/119302/ --- (Updated July 15, 2014, 9:19 p.m.) Review request for Build System, KDE Bindings, kdelibs, Alex Merry, Luca Beltrame, and Simon Edwards. Bugs: 337462 http://bugs.kde.org/show_bug.cgi?id=337462 Repository: kdelibs Description --- Since PyQt 4.10, PyQt.pyqtconfig is deprecated and not available unless PyQt is built using the old configure script. There is no direct replacement for it, as PyQt's new build system does not provide as much information as before by design. Luckily, most of the variables we are interested in can be obtained from PyQt's QtCore module itself even if its old build system is used. The only exception is `pyqt_sip_dir`, which cannot be determined at all if pyqtconfig is not available. In this case, there is nothing we can do but ask the user to specify it manually via CMake with something like `-DPYQT4_SIP_DIR=/usr/share/sip`. To this effect, all variables set by FindPyQt4.cmake have been made cache variables, which means their values can be overriden by the user, thus ignoring the contents read via FindPyQt.py. Diffs - cmake/modules/FindPyQt.py 5d2f9514d87553d5a16a95943618572316c92861 cmake/modules/FindPyQt4.cmake b176b4f8cfee471a1b7aecdd2723d165b0496a85 Diff: https://git.reviewboard.kde.org/r/119302/diff/ Testing --- I was able to make Kate find PyQt by passing `-DPYQT4_SIP_DIR=...` with my PyQt installation without `pyqtconfig.py`, and calling `FindPyQt.py` by hand on a Debian system with `pyqtconfig.py` worked as before. Thanks, Raphael Kubo da Costa
Re: Review Request 119302: Make FindPyQt4 work with PyQt's new build system.
On July 16, 2014, 1:42 a.m., Scott Kitterman wrote: This is the method used in qscintilla2's configure.py (which upstream has generally endorsed): #! /usr/bin/python import sys import os if sys.platform == 'win32': data_dir = sys.prefix else: data_dir = sys.prefix + '/share' py_sip_dir = os.path.join(data_dir, 'sip') # Note: Set this by hand since the logic to figure out if we're using PyQt4 or # PyQt5 isn't relevant to the question (QScintilla does do this, but it's not # germane). pyqt = 'PyQt4' if pyqt is not None: pyqt_sip_dir = os.path.join(py_sip_dir, pyqt) else: pyqt_sip_dir = None print(pyqt_sip_dir) # prints /usr/share/sip/PyQt4 We should use something similar. Scott Kitterman wrote: So markdown and python code comments don't mix. The bolded things all have a leading '#'. Luca Beltrame wrote: Good idea. Can this be done? Raphael Kubo da Costa wrote: I did look at QScintilla's build system when writing my patch, but chose not to follow this path: doing this only works for the default values (`sys.prefix/sip` on Windows, `sys.prefix/share/sip` elsewhere), which in the worst case can be a different installation unrelated to the one used by the PyQt version we're using. I didn't see much value in just working out of the box in some specific cases. Scott Kitterman wrote: I think working out of the box in the standard, default case using the upstream recommended method is much better than requiring the value to be set by hand in all cases. This change set is about adjusting to the new upstream approach to things, so using the upstream recommended solution seems only logical. If this doesn't get included upstream, I'll add it as a distro patch for Debian/Kubuntu as I think it's definitely a superior approach. Raphael Kubo da Costa wrote: I think working out of the box in the standard, default case using the upstream recommended method is much better than requiring the value to be set by hand in all cases. This change set is about adjusting to the new upstream approach to things, so using the upstream recommended solution seems only logical. *shrug* Done in patch v2. If this doesn't get included upstream, I'll add it as a distro patch for Debian/Kubuntu ... ok? Thanks for including it despite it not being your preference. - Scott --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/119302/#review62457 --- On July 16, 2014, 7:49 p.m., Raphael Kubo da Costa wrote: --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/119302/ --- (Updated July 16, 2014, 7:49 p.m.) Review request for kdelibs, Alex Merry, Luca Beltrame, and Simon Edwards. Bugs: 337462 http://bugs.kde.org/show_bug.cgi?id=337462 Repository: kdelibs Description --- Since PyQt 4.10, PyQt.pyqtconfig is deprecated and not available unless PyQt is built using the old configure script. There is no direct replacement for it, as PyQt's new build system does not provide as much information as before by design. Luckily, most of the variables we are interested in can be obtained from PyQt's QtCore module itself even if its old build system is used. The only exception is pyqt_sip_dir, which cannot be determined at all if pyqtconfig is not available. In this case, the most we can do is guess the default path like QScintilla2 does, and fail if it does not exist. The user then needs to specify it manually via CMake with something like -DPYQT4_SIP_DIR=/usr/share/sip/PyQt4. To this effect, all variables set by FindPyQt4.cmake have been made cache variables, which means their values can be overriden by the user, thus ignoring the contents read via FindPyQt.py. Diffs - cmake/modules/FindPyQt.py 5d2f9514d87553d5a16a95943618572316c92861 cmake/modules/FindPyQt4.cmake b176b4f8cfee471a1b7aecdd2723d165b0496a85 Diff: https://git.reviewboard.kde.org/r/119302/diff/ Testing --- I was able to make Kate find PyQt by passing `-DPYQT4_SIP_DIR=...` with my PyQt installation without `pyqtconfig.py`, and calling `FindPyQt.py` by hand on a Debian system with `pyqtconfig.py` worked as before. Thanks, Raphael Kubo da Costa
Re: kwallet-query moved to kdereview
On Thursday, April 23, 2015 10:55:17 PM Albert Astals Cid wrote: El Dijous, 23 d'abril de 2015, a les 22:25:20, Valentin Rusu va escriure: Hello, Please be advised sysadmins moved kwallet-query to kdereview for your constructive critics. You may found more informations about it here: https://barlog.rusu.info/valentin/blog/?p=386 This is a rather simple script and I think it should go to kde-utils. I'd like to write a manpage for it, buy AFAICT that's not the KDE way of doing it. Yes there is. See for example http://quickgit.kde.org/?p=dragon.gita=treeh=bd7c7b5b35d317843ca3f377be1d3 c64d0af1087hb=8fea297d688e63d379197344c7f1c0a265c146bdf=doc You're missing a Messages.sh file. Also, please add COPYING.LIB for LGPL 2, since that's the license you're using for the project. Scott K
Re: Why is C90 enforced in KDE?
On Monday, December 07, 2015 04:33:37 PM Thomas Lübking wrote: > On Montag, 7. Dezember 2015 15:54:40 CEST, Luca Beltrame wrote: > > Given you've said this multiple times, with my packager hat on I'll just > > mention this: just don't make it harder *for us* to work just because > > you're targeting another platform. > > I actually don't think this related at all. > > Compiling C99 (beyond some minor additions like the comments, but that's not > guaranteed to be the only usage) on MSVC is a general problem to begin with > (if you care about elder versions of what MS calls a "compiler"), so > Boudewijn's primary problem is the usage of flex/yacc to begin with and > he'll prefer pre-translated C-fixed-to-90 (hello sed ;-) OR flex/yacc being > translated to *.cpp (where "i build every shit and just guess what the > developer meant" MSVC still sucks, but not that much) > > Distros and notably self-builders would probably prefer such as well (less > build time dependency, yeah!), so there's no conflict. > > Otoh, developers will prefer to have flex/yacc in the CI and will require a > cmake rule to include *.l & *.y in the source list (so it's regenerated on > local changes) but otherwise there's (afaik) no strong reason to not simply > ship the pre-translated sources (along the lex sources which are usually > not invoked on build) > > The situation is (afaik) slightly different w/ *.moc since you might run > into "the moc that generated this header is too old" issues (latter > happens, so we can/should not ship pre-built mocs; but I'm not sure whether > such problems can show up with lex as well) As long as you also ship the source, as a Debian packager, I'm happy. We have to have preferred form of modification and the ability to rebuild from that source. It's not 100% required that we rebuild, but how do you know you can, unless you do. I don't mind the additional dependency at all. My preference would be that on Linux, at least, if flex/yacc are detected, the rebuilding is automatic. Scott K
Re: [Kde-bindings] A new attempt on PyKDE5 binding generation
On Thursday, April 07, 2016 12:16:58 AM Albert Astals Cid wrote: > So my suggestion would be renaming pykde5.git to pykf5.git, and that means > *only* KDE Frameworks 5 bindings would go in there, any other repo that > wants to provide python bindings (say okular, marble or krita) should do > somewhere else, ideally their own repo so the binding and the original code > are close together and it's easier to keep in sync when api changes. > > Am I making sense? FWIW, I think this is exactly right. Scott K
Re: [Kde-bindings] A new attempt on PyKDE5 binding generation
On Saturday, March 26, 2016 10:30:18 PM Shaheed Haque wrote: > Hi all, > > I've given up on trying to get the twine2 PyKDE bindings generator > working [1] because not only is the code there broken, but it seems a > Sysiphusian task to maintain a C++ parser. Instead, a few evenings > with clang 3.9 have yielded what I hope is the basis of a way forward: > about 800 lines of Python code [2] which can already create 684 .sip > files [3]. > > What I hope is important about the new tool is that it is documented, > and has a rule-driven approach to adding the SIP annotations which > should ensure that the bindings are easier to maintain once we > actually get them working. > > The current status is: > > #1 I have not tried to actually run the SIP compiler :-). > > #2 I have not checked whether the tool is failing to process some > .h files (i.e. I have not checked whether I have all the relevant .h > headers, or whether the new tool is failing on some .h files). > > #3 I have toyed with, but not mounted a full attack on, the SIP > annotations problem (see below) > > #4 I have not tried to map the KDE5 module naming scheme to > anything in Python. > > #5 No integration with CMake and the rest of the KDE build system. > > On the annotations problem, looking at PyKDE4 as my guide, I frankly > don't understand when to use /Transfer/ instead of /TransferThis/, or > why some references parameters have a /In/ and others a /Out/ or > whatever. If anybody can actually explain, that would be great. In any > event, I am hopeful that the structure of the rules engine [4] will > make this tractable, but I'd really prefer not to blindly match what I > see in PyKDE4!!! This is great. I did take a run at using twine2 and never got anywhere with it either. Due to the Kf5, Plasma, Applications split, I would strongly recommend not calling what you're doing PyKDE5 as KDE5 is not a thing. I'd suggest starting with binding the Kf5 modules and calling that PyKf5. Scott K
