Re: KDE Frameworks Release Cycle
[Taking k-c-d out, too much cross-posting] On Monday 05 May 2014 21:54:42 Alexander Neundorf wrote: If we have more than 50 libraries, do all of them need a full new release every month ? Not doing that leads to 1) a huge mess of versioning. The latest available version for each framework would be different, so how do you make sure you have the latest of each? And the min required version in each find_package would have to be increased manually, since it would no longer be the same everywhere. In a year we'd be at KArchive 5.3, KIO 5.7 required by KParts 5.1 required by KTextEditor 5.4, etc. etc. This seems extremely messy to deal with, for everyone. We decided long ago against this, for these very reasons. 2) more work for me: every month, for each of the 61 frameworks, I'd have to decide which ones need to be released and which one shouldn't 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 ? That's exactly what will happen for the frameworks which didn't see many changes. The monthly release will include at most a few bugfixes and updated translations. The only difference is whether to call this 5.2 or 5.1.1 -- but again, these are libraries, so e.g. new methods don't break existing apps, the fear of new features doesn't work the same way as in applications. -- David Faure, fa...@kde.org, http://www.davidfaure.fr Working on KDE Frameworks 5 ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: KDE Frameworks Release Cycle
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Am 04.05.2014 18:36, schrieb David Faure: [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. One thing I want to mention here because I think there is no real work around: When will you add new dependencies? In a rolling release process this is possible every month. From a packagers point of view, this is hardly doable: You cannot accept new dependencies in a security update. So what is the solution for the packager? Probably make a branch on top of the release that was used first, and try to find as many bug fixes as possible that will still apply. While rereading your email I see the following thing: fixes in KF5 will only be available in 6 months, and I want the bug fixed now. If these are _fixes_, why are they not backported to the stable branch atm? Maybe we should fix another issue here, and instead modify our understanding of stable branch. Even if it is hard for me, the maintainance of the Linux Kernel could be an example: with clear maintainers (or teams) of branches which will check which issues need backports. I think this is also the way it would happen (distros would probably try to maintain stable branches together), so I'd prefer if we could plan this ahead of the first release instead and possibly involving the developers of the libraries. regards, Patrick -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.21 (MingW32) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBAgAGBQJTa/OHAAoJEPAKI6QtGt1xyGoP/3mjMSidWSYy0jyw53Gl+ksW FWGeYU9drfo253iR+DemaiD3VSa6vOgdKl2RK03dpdM1GaKl2Hhpls/HcbucmCza 7vUa+IqjDiaFWLWtEn95ktRTCmbPHCGB87G1D9m7KrVmBqVHwVtIbkn3myXdPRR8 4fq1e4sPid020QGZNL6WoGqbYFePeFEf8rLu7pyNUTvE3mJsqSsXHDUKfCeDzW1a epxiheJxgCsz99GwQbvY7w3E3ge1I36jDlnCfCSwWoUbZe+uFU+wRD5fxtCDQcyE rkpy9IV4uzqFhloNI0wnTXrfBjME+b15uDDWCQBDGczWx6nJIS/ie7tI8BHNh8lf q2xdviVaBvgDCgjYjf5vxYr+HnO4LiRT5mZktCtjDbNEjAfhuOos5fLVqDFXXT3j oJUtmn7pxqM/0rrTTExRXtdKN8pz/bHdciOlo8I4T/j+bVn4Sd7MQFJE4DYmsfa3 /ZZW63dgbUbRHEBFl3hjLQ3NtB1nk+YHlhwi89VB1yBmi8M5MVQDazkxhpygrPJC K/JWRYfbar2dJSjZiQl0psl5ieJB/6+CL+sHK/36FGht1Otrx+rUAY+Km7oCxYy+ l9vzPd2CgL7LQHRxRxbEgRrNlSq0zrqApxUmau5sJsW9HoinOUvUvSr7qXQczPQB wyo3Djyu0lKuS8227eoV =LbgL -END PGP SIGNATURE- ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: KDE Frameworks Release Cycle
On Thursday, May 08, 2014 22:08:06 David Faure wrote: [Taking k-c-d out, too much cross-posting] On Monday 05 May 2014 21:54:42 Alexander Neundorf wrote: If we have more than 50 libraries, do all of them need a full new release every month ? Not doing that leads to 1) a huge mess of versioning. The latest available version for each framework would be different, so how do you make sure you have the latest of each? And the min required version in each find_package would have to be increased manually, since it would no longer be the same everywhere. In a year we'd be at KArchive 5.3, KIO 5.7 required by KParts 5.1 required by KTextEditor 5.4, etc. etc. This seems extremely messy to deal with, for everyone. We decided long ago against this, for these very reasons. Yes, I know, I see it exactly the same way. That's the situation you have if you have a number of separate libraries. IMO it would be the correct thing if each of these libraries would actually specify the exact version of the other libraries they actually need... dependency hell. OTOH this would mean I could update one or a set of the frameworks libraries if I see the need to, without having to update them all, just because they all require for simplicity the same version of all libraries. That's why I still think we may have gone a bit too far with the splitting. 2) more work for me: every month, for each of the 61 frameworks, I'd have to decide which ones need to be released and which one shouldn't Well, if we say we have 61 independent frameworks libraries, ideally each should have a maintainer who takes care of releases, required dependencies etc., i.e. not one single person doing it for all. I know we don't have enough maintainers in real life. Just my 2c. Alex ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: KDE Frameworks Release Cycle
[This message is a reply to all people requesting a long-term-maintained frameworks branch.] On Sunday 04 May 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; 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. In case of the Linux kernel those stable branches are maintained by dedicated volunteers. Without those volunteers there wouldn't be any long-term-maintained Linux kernel branches. If you (Luigi and/or Alex [Neundorf] and/or Patrick) are willing to maintain a stable frameworks branch then nobody will stop you from doing so. On the contrary, I'm sure many people would be grateful for your initiative and all the work you put into maintaining such a branch. But please don't expect other people (in particular the small number of frameworks maintainers) to do this job for you. Remember, that in KDE (as in any other volunteer organization) you should never say we should do foo unless you mean I volunteer to [help with] do[ing] foo. Regards, Ingo signature.asc Description: This is a digitally signed message part. ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: KDE Frameworks Release Cycle
On Monday, May 05, 2014 11:11:53 Martin Klapetek wrote: 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. Worse, they'll stack up: Wait for new kdelibs first (could take up to 7 months, including freezes, and only then the distro freeze period (imagine the target kdelibs release is just past the distro freeze deadline). You'll easily end up with this bug will be fixed in one year. -- sebas http://www.kde.org | http://vizZzion.org | GPG Key ID: 9119 0EF9 ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
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 ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
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 ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: KDE Frameworks Release Cycle
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). Possibility for opting out from the monthly releases for individual frameworks (i.e. still released with the bundle, but no monthly changes). I'm wondering about going this way on KDocTools. Ciao -- Luigi ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: KDE Frameworks Release Cycle
[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. -- David Faure, fa...@kde.org, http://www.davidfaure.fr Working on KDE Frameworks 5 ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: KDE Frameworks Release Cycle
David Faure ha scritto: [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. I think that application developers relying on distributions packages will continue to workaround to have application working on their reference distribution. If they were able to provide patches in libraries before (kdelibs4), they will continue to do so, of course, but otherwise I don't see too many changes. Not everyone is on rolling distributions or Windows or MacOSX. Ciao -- Luigi ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: KDE Frameworks Release Cycle
On Sunday 27 April 2014, Kevin Ottens wrote: Of course, going with this type of cycle comes with some price of its own: * Features in released modules can only be introduced in a very fine grained way so as to not jeopardize the stability; on one hand I'll probably miss feature branches, on the other hand, I really like the discipline that this methos requires, it may well drive to a good quality increase -- Marco Martin ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: KDE Frameworks Release Cycle
On Sunday 27 April 2014 11:51:01 Kevin Ottens wrote: Short story: we'll go for a one month release cycle, with no branch. This is a bold move. I like it. Rapid release cycles have their own challenges, but I think we have the means to make them work. And they come with benefits. Getting our stuff in the hands of users more early certainly is worth the changes which are necessary to accomplish this. People will judge us by the stability of our releases. Testing and reviews are essential for this. You stated the key points of that already. Good to see you being on top of things :-) -- Cornelius Schumacher schumac...@kde.org ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: KDE Frameworks Release Cycle
On 27/04/14 10:51, Kevin Ottens wrote: Hello people, As you may have noticed, we're covering quite a few tasks here during the sprint. But, we're also having discussion topics, and the most important one we covered is the release cycle. Indeed, we got the question several times already of once 5.0 is out what will happen? It is what I'll try to address in this email. Short story: we'll go for a one month release cycle, with no branch. As an addendum, extra-cmake-modules will (for now, at least) tend to release in sync with frameworks. However, e-c-m has its own version scheme, and there will not necessarily be a release for every frameworks release. It will also never be frozen, as there are no translations to be made. I am going to demand unit tests for new modules (other than find modules, which are too system-dependent to reasonably unit test) and new features in existing modules, and I welcome unit tests for existing code. Alex ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: KDE Frameworks Release Cycle
I am not blaming anyone. I'm just raising the question if this list may have lost its usefulness or may need repurposing. Please do not see complains where the is none. Cheers, Albert Enviat des del meu telèfon intel·ligent BlackBerry 10. Missatge original De: David Faure Enviat: domingo, 27 de abril de 2014 16:09 Per a: kde-frameworks-devel@kde.org Respon a: KDE release coordination A/c: Albert Astals Cid; release-t...@kde.org Tema: Re: Fwd: KDE Frameworks Release Cycle On Sunday 27 April 2014 15:55:07 Albert Astals Cid wrote: Interesting fact here that original the mail was just sent to k-f-d and k-c-d. That was my suggestion, to avoid cross-posting to 4 lists everytime someone answers, which always creates issues because kde-packager@ is moderated. I am seeing similar patterns in the plasma land, where they went their own way with the releasing discussion and only sent to this list after the discussion happened (or that's my impression) (Note i'm not complaining of being left aside since actually i was there in person for the KF5 dicussion). Then please don't confuse issues in the plasma world with issues in the KF5 world. I feel like you're blaming me for plasma issues I'm just raising the question if we want to: a) Try to make the KF5 and plasma people work more in the release-team list when discussing about releases b) Rename the release-team list to kde-applications-release-team or something like that to make it clear it is about KDE Applications side of the previous three Applications, Plaform and Workspaces sides of a release c) Disband the relase-team altogether. I am the release team (with input from Kévin and you) when it comes to KF5 releases, and I was part of the discussion, so I think your claim that release-team was not involved in the discussion just doesn't apply to the KF5 release cycle discussion. Please don't bring me/us into your complaints towards plasma. -- David Faure, fa...@kde.org, http://www.davidfaure.fr Working on KDE Frameworks 5 ___ release-team mailing list release-t...@kde.org https://mail.kde.org/mailman/listinfo/release-team ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
