Re: KDE Frameworks Release Cycle
On Sun, May 4, 2014 at 6:36 PM, David Faure fa...@kde.org wrote: [Cross posting against my will...] On Sunday 04 May 2014 16:27:44 Luigi Toscano wrote: I understand that the big concern was about the testing: stable branches did not receive the same attention This is not the main concern. My main concern is that application developers prefer to work around bugs in KF5 (previously: kdelibs) rather than fix things at the right level, because fixes in KF5 will only be available in 6 months, and I want the bug fixed now. Your suggestion (6-months stable release) brings us back to exactly that. We'd like to try something better. Monthly small increments. Never big changes that break things, they get cut into small increments too. So no reason to buffer changes for 6 months. However this highly depends on the distro policies - if some of the big distros say we will not update KF5 every month because our policies, then the 6 months buffer is just moved elsewhere, at the distro level because they will update only with the new release. If the application makes a hard requirement on some specific version (which would be the point of this), then distros would not package that fixed app before there would be that particular version of KF5, so I imagine the app developers would still work around the bugs in their own code and release a minor version which the distro would package. Or worse there would be patches at distro level. Imho distributions' opinion should be highly taken into consideration because these are the people actually delivering our code to 98% of users. I like the original proposal, but I also think we need to stay pragmatic and work with real world facts. Cheers -- Martin Klapetek | KDE Developer
Re: KDE Frameworks Release Cycle
0.0.1 version releases seem to work pretty well for Qt and are released as necessary iiuc. On 5/5/2014 2:36 AM, David Faure wrote: [Cross posting against my will...] On Sunday 04 May 2014 16:27:44 Luigi Toscano wrote: I understand that the big concern was about the testing: stable branches did not receive the same attention This is not the main concern. My main concern is that application developers prefer to work around bugs in KF5 (previously: kdelibs) rather than fix things at the right level, because fixes in KF5 will only be available in 6 months, and I want the bug fixed now. Your suggestion (6-months stable release) brings us back to exactly that. We'd like to try something better. Monthly small increments. Never big changes that break things, they get cut into small increments too. So no reason to buffer changes for 6 months.
Re: KDE Frameworks Release Cycle
On Mon, May 5, 2014 at 11:11 AM, Martin Klapetek martin.klape...@gmail.com wrote: On Sun, May 4, 2014 at 6:36 PM, David Faure fa...@kde.org wrote: [Cross posting against my will...] On Sunday 04 May 2014 16:27:44 Luigi Toscano wrote: I understand that the big concern was about the testing: stable branches did not receive the same attention This is not the main concern. My main concern is that application developers prefer to work around bugs in KF5 (previously: kdelibs) rather than fix things at the right level, because fixes in KF5 will only be available in 6 months, and I want the bug fixed now. Your suggestion (6-months stable release) brings us back to exactly that. We'd like to try something better. Monthly small increments. Never big changes that break things, they get cut into small increments too. So no reason to buffer changes for 6 months. However this highly depends on the distro policies - if some of the big distros say we will not update KF5 every month because our policies, then the 6 months buffer is just moved elsewhere, at the distro level because they will update only with the new release. If the application makes a hard requirement on some specific version (which would be the point of this), then distros would not package that fixed app before there would be that particular version of KF5, so I imagine the app developers would still work around the bugs in their own code and release a minor version which the distro would package. Or worse there would be patches at distro level. (please also note the relevant thread on the kde-release ML) You always have an arbitrary delay between when we release something and when a distro ships it, completely independent of our own cadence. Currently we may release every 6 months, that does not mean that distros do, nor does it mean that a distro releases according to our schedules. For example had Kubuntu stuck to their own feature freeze then Kubuntu 14.04 would have shipped with KDE Platform and Applications 4.12 rather than 4.13. So, a monthly release definitely resolves the presented argument of people having to do workarounds (well, at least redcues the scope). As the primary problem is that until a new kdelibs becomes available to all users of the bigger distributions you have to look at about a year, dependening on how our 6 month cadance aligns with the respective distro schedules. So, the distro might be to include $app 3 months after its release, but there is no new kdelibs yet, so $app is blocked because the next kdelibs release is in another 3 months, at which point $distro is in feature freeze... That being said, with a monthly release scheme: if a distro can pick up a new version of $app they can also pick up a new montly release for frameworks, and if they can't pick up a new version of $app then it doesn't matter anyway. So actually dependening on a very specific and very new version of a framework becomes less of a problem from an application developer POV; there's at most one month between $app release and the next frameworks release. HS
KDE Frameworks: There will be a beta 3
Hello all, After the release of beta 2, we realized that it couldn't be the last beta for several reasons: * a long standing release blocker in libsolid still wasn't addressed in time for beta 2, it'll hopefully be solved in the next few days, otherwise we'll put in place a contingency plan; * the paint is still a bit fresh on some of the internationalization work after the sprint and it could benefit from some more testing; * some quirks were still found in the release scripts, so having an extra run before final can't hurt to check all the pieces fit together now. That's why on early June we'll release a beta 3. In turn, the final is now due to be out on early July (one month later than expected). Thanks for your attention. Regards. -- Kévin Ottens, http://ervin.ipsquad.net KDAB - proud supporter of KDE, http://www.kdab.com signature.asc Description: This is a digitally signed message part.
Re: KDE Frameworks Release Cycle
On Sunday, May 04, 2014 16:27:44 Luigi Toscano wrote: Kevin Ottens ha scritto: So, we had a team discussion here with Albert, Aleix, Alex, Alex, Aurélien, David, Rohan and myself. We juggled with several options, trying to address the following constraints: * We don't have many contributors; * We don't have enough testing in the stable branches, developers tend to have a hard time to dog food those; * We don't have enough contributions coming from the application developers because it takes a lot of time for them to benefit from their changes so they tend to workaround instead and consider kdelibs more and more as a black box; going forward we don't want that for KDE Frameworks. So, I've seen no discussion about this (not on this list, I think it's going on somewhere else) but I would like to rise my concerns with this decision. It can increase the balkanization of the version shipped by distribution. This is going in the opposite direction of the advocated give users a real KDE experience. With no stable branches, distributions will have to randomly choose one branch to stabilize and the risk is that based on their schedule, they will choose different versions, heavily patching them (_more_ than what happens today, where there are few synchronization points). Other big projects with frequent releases, like the Linux kernel or Firefox have stable branches too; not all of the releases, but some of them. Firefox had to provide a esr version (long support, one year) because it's not really possible to update an entire stack in long-term supported distributions. And Firefox is mostly a leaf in the dependency tree (with the exception of libnss and libnspr, which can break and broke in the past from one esr to another); here we have an entire bunch of core libraries (as in Linux with its long-term branches). I understand that the big concern was about the testing: stable branches did not receive the same attention, but I think that killing them is not the solution; solutions include an increase number of automated tests (unit, integration, scenario) as first step, and a bit of time invested in the rest (manual) testing, with contribution of distributions but not only them. We had a lot of coding sprint, we can organize test sprints as well (which benefits also the main master branch, of course!) I also think that many frameworks will stabilize after the initial rush, so it will. I suspect (just a feeling, not backed by any fact) that Tier1 will stabilize sooner, Tier3 will have more moving part (please note that this is not about ABI/API, which I'm sure will keep the compatibility as it was before). If this is true, it could help in creating naturally stable branches; KDocTools is a good example, it's unlikely to have new important changes too frequently, but I guess it will be the same for KI18n and others. Minor point: the original statement of three releases for Porting Aids should be fixed to be time based (I guess at least 6 is not 9 months). So, my proposal(s). I think that some kind of long term branch branch is needed. It could be an yearly release (and we could do a testing sprint for that, solving the problem for the love), or a bit more frequent, like twice a year (no more!); still at least one release could benefit from a sprint. Collaboration from distribution is needed, so that they can coordinate. In case of yearly releases, if few distributions want to have an official stabilization branch (like in Linux) they will able to create and manage a special branch (with some input from developers). After the initial rush, revise the release schedule in the light of the stable frameworks, maybe they can be naturally on a stable branch (because no big changes will land in them). Maybe this should be considered seriously ? If we have more than 50 libraries, do all of them need a full new release every month ? As Luigi says, some of the smaller libraries may not see many changes at all, and maybe only old style patch level releases for them would be good enough ? Alex
Question about currencies
Hi all, I have a question about the currency features. In KLocale, you can get KCurrencyCode for the current locale, which is fine. Now, for KMyMoney we need to get the list of all currencies for all countries (since a user usually deals with multiple currencies). I haven't found an API for this, only the KLocale one for current locale. Is there any other way to access the list of currencies? Thanks! Regards, Alvaro
Re: Question about currencies
On Tue, May 6, 2014 at 12:03 AM, Alvaro Soliverez asolive...@kde.orgwrote: Hi all, I have a question about the currency features. In KLocale, you can get KCurrencyCode for the current locale, which is fine. Now, for KMyMoney we need to get the list of all currencies for all countries (since a user usually deals with multiple currencies). I haven't found an API for this, only the KLocale one for current locale. Is there any other way to access the list of currencies? Thanks! Regards, Alvaro I don't really know much about the issue, but after having gone through similar code I think that your best bet is on using KStandardDirs (or QStandardPaths) to find the currencies directory and use QDir to list them. Aleix PS: I think KCurrencyCode is being deprecated for KF5, you might want to see what's the alternatives too.
