Re: Release Strategy Proposal
Imho this is a good strategy for the 1%, for those applications that need heavy re-factoring in order to work or make proper use of Qt5 (Plasma and KWin), however I'm still not convinced that this is a good strategy for the other 99%. We could apply the same argument we can use for applications to most of kde-workspace and kde-runtime, their port to Qt5 will be mostly execute a script and use KDE4support. Besides that, there are a few areas where we'll see development possibly beyond 4.11 like powerdevil, nepomuk, and some kcm's. Holding these changes until PW2 could result in a series of bad side effects like loosing manpower, or KDE 4.0 effect (lot of untested changes). I'd like to propose one of these two options: -We split Plasma and KWin in separate repos, we freeze them. -We freeze kde-workspace/runtime and if you want to develop anything you have to split it. This proposal is based on a discussion we had in plasma-devel where most developers there (iirc was consensus) agreed that in the future kde-workspace should be a meta-repository (like extragear/base) containing all the repos needed to have a workspace, for example current repos like bluedevil, plasma-nm or print-manager should be included. This will make the transition to a more splited kde-workspace something gradual, done step by step and organically, no stress for developers, no stress for packagers, maybe bit more work for release team though. Cheerz. ___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
Re: Release Strategy Proposal
On Saturday, April 27, 2013 12:27:49 AM Aaron J. Seigo wrote: > On Friday, April 26, 2013 18:15:03 Scott Kitterman wrote: > > impression is that your goal is to get more people working on KFS/PW2 and > > your chosen method to achieve it is by enforcing a stop on feature work in > > KDE4 platform/workspace. > > this isn't our goal. our goal is to allow those of us currently working on > workspaces to focus feature development where it already is: the Qt5 / KF5 > ports of Plasma (you can see the work in the plasma-framework repository) > and kde-workspace. > > we simply can't do both 4.x and 5.x feature development, for both technical > and man-power reasons. we also don't want to let the 4.x releases of kde- > workspace happen without any visible changes (have fun writing those release > notes :) without some communication behind it, and we also understand there > is a desire from at least some of our downstreams to have a long-term > release they can focus on. so this represents a potential win-win situation > in which we can communicate our shift of focus while also delivering a > long-term release. > > at the same time, we don't want to put pressure on application developers to > shift focus away from 4.x. until KF5 is ready, there is no reason to do > this. > > we feel that stating clearly that workspaces is feature frozen covers all > the above concerns. > > if this also causes other people to join our efforts .. that would be a > bonus. it is not the primary goal, however. > > > Avoiding a long period of feature freeze between with KDE4 > > platform/workspace development stops and when KFS/PW2 is usable and > > available is an important part of the story. > > does it matter if the applications keep releasing? has anyone noticed this > is already the case for a year in kdelibs? It matters less that workspace is frozen if applications aren't, but unlike kdelibs, users see the workspace. I just upgraded my main laptop to 4.10.2 and I appreciate the changes in both (4.10 continues the trend of every release starting with 4.1 being a significant improvement over the rest). I'm not opposed to the suggestion, only trying to suggest another way to look at things. Packaging KFS in all its component parts is going to be a lot of work. If they can be incrementally released, that will not only bring in early adopters, but also spread out the packaging work over more time (we can mostly script updates, but initial packaging is labor intensive). So I have two motivations for suggesting getting some stuff released soon. Scott K ___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
Re: Release Strategy Proposal
On Friday, April 26, 2013 18:15:03 Scott Kitterman wrote: > impression is that your goal is to get more people working on KFS/PW2 and > your chosen method to achieve it is by enforcing a stop on feature work in > KDE4 platform/workspace. this isn't our goal. our goal is to allow those of us currently working on workspaces to focus feature development where it already is: the Qt5 / KF5 ports of Plasma (you can see the work in the plasma-framework repository) and kde-workspace. we simply can't do both 4.x and 5.x feature development, for both technical and man-power reasons. we also don't want to let the 4.x releases of kde- workspace happen without any visible changes (have fun writing those release notes :) without some communication behind it, and we also understand there is a desire from at least some of our downstreams to have a long-term release they can focus on. so this represents a potential win-win situation in which we can communicate our shift of focus while also delivering a long-term release. at the same time, we don't want to put pressure on application developers to shift focus away from 4.x. until KF5 is ready, there is no reason to do this. we feel that stating clearly that workspaces is feature frozen covers all the above concerns. if this also causes other people to join our efforts .. that would be a bonus. it is not the primary goal, however. > Avoiding a long period of feature freeze between with KDE4 > platform/workspace development stops and when KFS/PW2 is usable and > available is an important part of the story. does it matter if the applications keep releasing? has anyone noticed this is already the case for a year in kdelibs? -- Aaron J. Seigo signature.asc Description: This is a digitally signed message part. ___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
Re: Release Strategy Proposal
On Friday, April 26, 2013 03:27:40 PM Sebastian Kügler wrote: > Hi, > > > Let's make 4.11 the last feature release for platform and workspace in the 4 > series, make 4.11 a long term maintainance release. > > > I would like to propose the following for our release planning in the next > year: > > - Make 4.11 Platform and Workspaces a long-term maintainance release with > bugfix updates for two years > > - After 4.11.0, shift feature development to Frameworks 5 and Plasma > Workspaces 2, in order to not delay this forever > > - Applications are not part of this proposal, we'd need feedback from App > module maintainers. It doesn't need to be decided along with this proposal > though. For now, App developers should be encouraged to make releases on > top of 4.x, and jump onto KF5 "when it's ready" > > Reasons: > * This strategy will cement our leading role as desktop environment > * It eases transition to KF5/PW2 by giving ample room to keep the old > version * It communicates that we do not abandon SC4, but actively support > it * It makes downstreams happy, particularly those with long term releases > as they will have a version with multiple years of bug fixes to focus on * > kdelibs 4.x is already feature frozen, we plan to do the same for Plasma > after 4.11 and concentrate on PW2 then > > How this will look like exactly: > > 4.11 gets out as normal, but with the clear message: This is going to > maintained for a longer period of 2 years: If you're doing an Enterprise > distro, this one is the one you want > > > Of course, this being a proposal, its main purpose is to sollicit feedback, > but I'd also move towards a solution, as far as this describes common ground > among all stakeholders. > > > What do you think? I have a couple of thoughts for you from a strategy perspective. My impression is that your goal is to get more people working on KFS/PW2 and your chosen method to achieve it is by enforcing a stop on feature work in KDE4 platform/workspace. Disclaimer: My upstream involvement in KDE development is limited and I only know what I read on kde-devel about KFS. Another approach to accomplishing this goal might be to focus resources on making initial releases of some parts of KFS so that external developers can use it. Qt5 code is being written right now and no one outside KDE will be looking at unreleased KFS modules to see if using them might make their project easier (as an example, Canonical is currently engaged in a complete rewrite of Unity using Qt5/QML). If there are KFS modules that are released and available to the broader FOSS community, that ups the chances that people might actually make use of them and become engaged in KDE. The other risk here is that the feature freeze demotivates people and instead of working on KFS/PW2, the just stop. Labor in FOSS projects isn't fungible. Perhaps, rather than a feature freeze, it would be better to offer more encouragement to developers to work on KFS/PW2 (which by the way I think releasing some stuff would help) and see how many people are willing to switch their focus. Then reassess based on the work on 4.11 if it's effectively frozen itself or if a 4.12 makes sense. Avoiding a long period of feature freeze between with KDE4 platform/workspace development stops and when KFS/PW2 is usable and available is an important part of the story. >From a selfish perspective of my distro, I'd want 4.12 to be the LTS release >as that lines up with the next Kubuntu LTS release really well. Scott K ___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
Re: Release Strategy Proposal
Hey, On Friday, April 26, 2013 23:28:34 Albert Astals Cid wrote: > > Of course, this being a proposal, its main purpose is to sollicit > > feedback, > > but I'd also move towards a solution, as far as this describes common > > ground among all stakeholders. > > > > What do you think? > > I'm all for it if modules want to do this, what we're going to need the > list of exact modules that stop development of new features and make sure > all the parties that live under that module agree, i.e. kde-workspace has > solid and powerdevil stuff in there. Have you talk to this guys and do they > agree to the "feature freeze"? The idea actually came up at a barbecue where Alex Fiestas (CC:'ed) was present, and about to head off to Brno for the Solid sprint. One thing I checked with him afterwards is was about a possible rewrite of parts of powerdevil, but I believe in the end the Solid team decided against the rewrite, so that is probably off the table. Another, possibly intrusive thing is the introduction of KPeople, a framework to "normalize" the concept of Contacts across the workspace. I don't know enough to judge this, input here is welcome in how far this needs changes all over the workspace, or would need adjustments to the presented plan. Martin (also CC:'ed), maybe you could weigh in here? Cheers, -- sebas http://www.kde.org | http://vizZzion.org | GPG Key ID: 9119 0EF9 ___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
Re: Release Strategy Proposal
El Divendres, 26 d'abril de 2013, a les 15:27:40, Sebastian Kügler va escriure: > Hi, > > > Let's make 4.11 the last feature release for platform and workspace in the 4 > series, make 4.11 a long term maintainance release. > > > I would like to propose the following for our release planning in the next > year: > > - Make 4.11 Platform and Workspaces a long-term maintainance release with > bugfix updates for two years > > - After 4.11.0, shift feature development to Frameworks 5 and Plasma > Workspaces 2, in order to not delay this forever > > - Applications are not part of this proposal, we'd need feedback from App > module maintainers. It doesn't need to be decided along with this proposal > though. For now, App developers should be encouraged to make releases on > top of 4.x, and jump onto KF5 "when it's ready" > > Reasons: > * This strategy will cement our leading role as desktop environment > * It eases transition to KF5/PW2 by giving ample room to keep the old > version * It communicates that we do not abandon SC4, but actively support > it * It makes downstreams happy, particularly those with long term releases > as they will have a version with multiple years of bug fixes to focus on * > kdelibs 4.x is already feature frozen, we plan to do the same for Plasma > after 4.11 and concentrate on PW2 then > > How this will look like exactly: > > 4.11 gets out as normal, but with the clear message: This is going to > maintained for a longer period of 2 years: If you're doing an Enterprise > distro, this one is the one you want > > > Of course, this being a proposal, its main purpose is to sollicit feedback, > but I'd also move towards a solution, as far as this describes common ground > among all stakeholders. > > > What do you think? I'm all for it if modules want to do this, what we're going to need the list of exact modules that stop development of new features and make sure all the parties that live under that module agree, i.e. kde-workspace has solid and powerdevil stuff in there. Have you talk to this guys and do they agree to the "feature freeze"? Cheers, Albert P.S: I'm in a business trip next week so I'll be very unreliable answering mail ___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
Re: Release Strategy Proposal
Hi Alex, On Friday, April 26, 2013 18:35:41 Alexander Neundorf wrote: > On Friday 26 April 2013, Sebastian Kügler wrote: > > > > Let's make 4.11 the last feature release for platform and workspace in the > > 4 series, make 4.11 a long term maintainance release. > > > > IMO this is not about handling releases, but about the mid-term development > strategy of KDE. > I think setting the direction for KDE is not task of the release team. This thread is not about setting the direction perse, it's about asking feedback from involved parties. I was actually wondering wether or not to CC: k-c-d, but decided against to first have a few more directly related people weigh in: i.e. if the release team says it can't be done, we have to go back to the drawing board. > I think this should be discussed more public, i.e. on k-c-d. > > Beside that, trying to get KF5 more into a working-towards-a-release > development mode seems like a good idea to me. That's an intended side-effect. Cheers, -- sebas http://www.kde.org | http://vizZzion.org | GPG Key ID: 9119 0EF9 ___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
Re: Release Strategy Proposal
On Friday 26 April 2013 18:35:41 Alexander Neundorf wrote: > On Friday 26 April 2013, Sebastian Kügler wrote: > > Hi, > > > > > > Let's make 4.11 the last feature release for platform and workspace in the > > 4 series, make 4.11 a long term maintainance release. > > > > IMO this is not about handling releases, but about the mid-term development > strategy of KDE. > I think setting the direction for KDE is not task of the release team. > > I think this should be discussed more public, i.e. on k-c-d. IMHO no. We in the workspace do not want to force anyone to switch to KF5 or block anyone from doing a 4.12 release (and expect that to happen, maybe even a 4.13 release). Every team should follow the development speed which suits them best. So I think it's not a question about mid-term development strategy for all of KDE. It's especially that we in the workspace do not want to end up in a situation like prior to 4.0. -- Martin ___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
Re: Release Strategy Proposal
On Friday 26 April 2013, Sebastian Kügler wrote: > Hi, > > > Let's make 4.11 the last feature release for platform and workspace in the > 4 series, make 4.11 a long term maintainance release. > IMO this is not about handling releases, but about the mid-term development strategy of KDE. I think setting the direction for KDE is not task of the release team. I think this should be discussed more public, i.e. on k-c-d. Beside that, trying to get KF5 more into a working-towards-a-release development mode seems like a good idea to me. Alex ___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
Re: Release Strategy Proposal
Hi, 2013/4/26 Sebastian Kügler: > On Friday, April 26, 2013 15:37:09 Frank Reininghaus wrote: >> 2013/4/26 Sebastian Kügler: >> > >> > Let's make 4.11 the last feature release for platform and workspace in the >> > 4 series, make 4.11 a long term maintainance release. >> > > >> What exactly is part of this proposal then? Is it >> >> (a) All modules which are released as part of the "KDE SC 4.11", or >> (b) only kdelibs, kde-runtime (and kde-workspace)? >> >> Sorry if this is a stupid question, but apparently, I'm still not >> familiar enough with the SC/Platform/Workspace/... terminology > > Good question: The initial thinking is kdelibs, kde-runtime, kde-workspace. I > think it's too early for kde-baseapps to jump on this bandwagon, but you might > have a different opinion on this -- or not. :) That's what I'd like to find > out here. :) Thanks for the clarification! I agree that it might be too early to feature-freeze and string-freeze kde-baseapps and some other modules now. Best regards, Frank ___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
Re: Release Strategy Proposal
On Friday, April 26, 2013 08:44:35 Rex Dieter wrote: > With my packager-hat on, this raises some concern about future possible > version assumptions being broken (ie, packaging that assumes constant > versioning across all kde core packages). That's something that will > have to be dealt with sooner or later (with frameworks5) anyway, so > maybe it's not necessarily a bad thing. Yeah, something we have to figure out. My thinking (and I'm undecided on which way to go there): - If we only increase version numbers for the things that actually get feature updates, we might create confusion as to what fits together - If we keep all numbers consistent (basically our current release policy -- all get the same number), people might misunderstand, distros might not dare upgrading to, for example 4.12 because they want to ship long-term-maintained code. Input, especially from distros is most welcome to fledge this out futher. Cheers, -- sebas http://www.kde.org | http://vizZzion.org | GPG Key ID: 9119 0EF9 ___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
Re: Release Strategy Proposal
On Friday, April 26, 2013 15:37:09 Frank Reininghaus wrote: > 2013/4/26 Sebastian Kügler: > > > > Let's make 4.11 the last feature release for platform and workspace in the > > 4 series, make 4.11 a long term maintainance release. > > > What exactly is part of this proposal then? Is it > > (a) All modules which are released as part of the "KDE SC 4.11", or > (b) only kdelibs, kde-runtime (and kde-workspace)? > > Sorry if this is a stupid question, but apparently, I'm still not > familiar enough with the SC/Platform/Workspace/... terminology Good question: The initial thinking is kdelibs, kde-runtime, kde-workspace. I think it's too early for kde-baseapps to jump on this bandwagon, but you might have a different opinion on this -- or not. :) That's what I'd like to find out here. :) Cheers, -- sebas http://www.kde.org | http://vizZzion.org | GPG Key ID: 9119 0EF9 ___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
Re: Release Strategy Proposal
On 04/26/2013 08:37 AM, Frank Reininghaus wrote: Hi, 2013/4/26 Sebastian Kügler: Hi, Let's make 4.11 the last feature release for platform and workspace in the 4 series, make 4.11 a long term maintainance release. I would like to propose the following for our release planning in the next year: - Make 4.11 Platform and Workspaces a long-term maintainance release with bugfix updates for two years - After 4.11.0, shift feature development to Frameworks 5 and Plasma Workspaces 2, in order to not delay this forever - Applications are not part of this proposal, we'd need feedback from App module maintainers. It doesn't need to be decided along with this proposal though. For now, App developers should be encouraged to make releases on top of 4.x, and jump onto KF5 "when it's ready" What exactly is part of this proposal then? Is it (a) All modules which are released as part of the "KDE SC 4.11", or (b) only kdelibs, kde-runtime (and kde-workspace)? clearly the latter, "Make 4.11 Platform and Workspaces..." but may be a good idea to explicitly enumerate which modules that includes to avoid any confusion. With my packager-hat on, this raises some concern about future possible version assumptions being broken (ie, packaging that assumes constant versioning across all kde core packages). That's something that will have to be dealt with sooner or later (with frameworks5) anyway, so maybe it's not necessarily a bad thing. -- rex -- rex ___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
Re: Release Strategy Proposal
Hi, 2013/4/26 Sebastian Kügler: > Hi, > > > Let's make 4.11 the last feature release for platform and workspace in the 4 > series, make 4.11 a long term maintainance release. > > > I would like to propose the following for our release planning in the next > year: > > - Make 4.11 Platform and Workspaces a long-term maintainance release with > bugfix updates for two years > > - After 4.11.0, shift feature development to Frameworks 5 and Plasma > Workspaces 2, in order to not delay this forever > > - Applications are not part of this proposal, we'd need feedback from App > module maintainers. It doesn't need to be decided along with this proposal > though. For now, App developers should be encouraged to make releases on top > of 4.x, and jump onto KF5 "when it's ready" What exactly is part of this proposal then? Is it (a) All modules which are released as part of the "KDE SC 4.11", or (b) only kdelibs, kde-runtime (and kde-workspace)? Sorry if this is a stupid question, but apparently, I'm still not familiar enough with the SC/Platform/Workspace/... terminology ;-) Best regards, Frank ___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
Re: Release Strategy Proposal
On Friday 26 April 2013 15.27.40 Sebastian Kügler wrote: > Hi, > > > Let's make 4.11 the last feature release for platform and workspace in the 4 > series, make 4.11 a long term maintainance release. > > > I would like to propose the following for our release planning in the next > year: > > - Make 4.11 Platform and Workspaces a long-term maintainance release with > bugfix updates for two years > > - After 4.11.0, shift feature development to Frameworks 5 and Plasma > Workspaces 2, in order to not delay this forever > > - Applications are not part of this proposal, we'd need feedback from App > module maintainers. It doesn't need to be decided along with this proposal > though. For now, App developers should be encouraged to make releases on > top of 4.x, and jump onto KF5 "when it's ready" > > Reasons: > * This strategy will cement our leading role as desktop environment > * It eases transition to KF5/PW2 by giving ample room to keep the old > version * It communicates that we do not abandon SC4, but actively support > it * It makes downstreams happy, particularly those with long term releases > as they will have a version with multiple years of bug fixes to focus on * > kdelibs 4.x is already feature frozen, we plan to do the same for Plasma > after 4.11 and concentrate on PW2 then > > How this will look like exactly: > > 4.11 gets out as normal, but with the clear message: This is going to > maintained for a longer period of 2 years: If you're doing an Enterprise > distro, this one is the one you want > > > Of course, this being a proposal, its main purpose is to sollicit feedback, > but I'd also move towards a solution, as far as this describes common ground > among all stakeholders. > > > What do you think? A solid +1 with the disclamer that we should keep a fixed release schedule as far as dates are concerned when the time for releasing different parts in different version. /Regards Torgny ___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
Release Strategy Proposal
Hi, Let's make 4.11 the last feature release for platform and workspace in the 4 series, make 4.11 a long term maintainance release. I would like to propose the following for our release planning in the next year: - Make 4.11 Platform and Workspaces a long-term maintainance release with bugfix updates for two years - After 4.11.0, shift feature development to Frameworks 5 and Plasma Workspaces 2, in order to not delay this forever - Applications are not part of this proposal, we'd need feedback from App module maintainers. It doesn't need to be decided along with this proposal though. For now, App developers should be encouraged to make releases on top of 4.x, and jump onto KF5 "when it's ready" Reasons: * This strategy will cement our leading role as desktop environment * It eases transition to KF5/PW2 by giving ample room to keep the old version * It communicates that we do not abandon SC4, but actively support it * It makes downstreams happy, particularly those with long term releases as they will have a version with multiple years of bug fixes to focus on * kdelibs 4.x is already feature frozen, we plan to do the same for Plasma after 4.11 and concentrate on PW2 then How this will look like exactly: 4.11 gets out as normal, but with the clear message: This is going to maintained for a longer period of 2 years: If you're doing an Enterprise distro, this one is the one you want Of course, this being a proposal, its main purpose is to sollicit feedback, but I'd also move towards a solution, as far as this describes common ground among all stakeholders. What do you think? -- sebas http://www.kde.org | http://vizZzion.org | GPG Key ID: 9119 0EF9 ___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
