Re: Releases in 3 months
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. Cheers, Albert
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: Releases in 3 months
El Dimecres, 17 de juliol de 2013, a les 19:34:17, Scott Kitterman va escriure: 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? As Jonathan's minutes say, most probably 5 months, but you'll have to wait until I propose the new schedule, to see how we can fit the collapsed freezes et al. Cheers, Albert Scott K
Re: Releases in 3 months
Aaron J. Seigo wrote: translations .. this will require some time spent with the translation maintainers to figure out what will work well for those efforts. The risk here is that when branches which have been in preparation for a long time are merged, or simply many branches are merged, the amount of new strings can be quite big. In this case, I think that having a way to inform translators in advance (i.e. way before the freeze) is an important requirement. It is also needed to help with the documentation writers, who would be impacted as well and it could likely happen that they will be one release late. Or at least, if the documentation is written on time, it is possible that there won't be enough time for translating it in the same release. I don't see how it can be easily solved (well, unless developers provide updates for the documentation). Ciao -- Luigi
Re: Releases in 3 months
À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. ;) -- Luca Beltrame - KDE Forums team KDE Science supporter GPG key ID: 6E1A4E79
Re: Releases in 3 months
On 07/15/2013 05:54 AM, Aaron J. Seigo wrote: We are experimenting with the idea of a “long term release” version with kde- workspace. If 4.11 gets widely used, deployed and stabalized (as we hope it will) then blessing specific releases for extended #s of releases may be a good approach. Right now we treat all releases as equal: every 6 month release is as important and as recommended as the one before it. With Plasma Desktop 4.11, that will no longer be the case for Plasma Workspaces. We are recommending that version above others, before before and after, for deployment purposes. So if we do 3 month *development* cycles, but bless just one of the resulting *releases* each year as “this is the one you want to use if you are looking for stability”, perhaps then backporting efforts could focus on that one release. Under that regimen, we might not even have bug fix releases except for that one version. It could work like this: January: Release x.y is made, marked as an “annual” release, x.(y+1) starts February: x.y.1 featuring backports from x.(y+1) March: x.y.2 featuring backports from x.(y+1) April: x.(y+1) and x.y.3 released; x.(y+2) starts Mayt: x.y.4 featuring backports from x.(y+2) June: x.y.5 featuring backports from x.(y+2) July: x.(y+2) and x.y.6 .. etc. These “long term release” versions could happen every 6 months, every 9 months, every 12 months, every 24 months or whatever else strikes our fancy. With this concept instead of caring about x.y and x.(y-1), developers would instead care about the last long term release and the current devel cycle. This would mean developers would care about the same number of releases (e.g. 2) but for different time spans than they do now. Bug fix releases for non-long-term-releases wouldn’t happen; you’d need to upgrade to the next release to get fixes or install the last long-term release. Again, just one user's thoughts, but I love the idea of a long-term-release version of KDE that's supported with bug-fixes but no new features for a year. -Ben
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 07/13/2013 10:19 PM, Inge Wallin wrote: Without having any scientific proof, I believe that there are 2 main categories of users: 1. Those generally satisfied who want stability 2. Those who long for new updates all the time. My feeling is that the first category is the silent majority and the second category is the loud minority. Of course there is always a number of people who want just this special new feature to make it perfect but those are probably split in which feature they want and therefore still a minority. I'm pretty firmly in category #1. KDE has a lot of features already, and what I'm looking for right now is polish that removes bugs and increases stability and makes everything just work the way it is supposed to. Anything that contributes to those things is what I'm looking for - not features at this point. Of course, I'm not saying that developers have to stop working on features (as we all know, developers can work on whatever they want), but what this user wants is bug-fixing and polish on what's there already. If a new feature is introduced, I'd rather it be tested and polished before releasing to the general users, so that it doesn't make the application less stable. Testing periods, integration branches, always releasable master, etc aside, there will always be bugs in all software. And the users want these bugs fixed. If the statement above is indeed true, then the majority of users want to have the bugs fixed without having to suffer through other changes too. Yes! I'd like good ways to have bugs in my current version fixed without new bugs from new features. Right now, I look for the .4 or .5 releases (when I can) in the hopes that they'll be the most stable. I'm on 4.10.2, and I'd like to move to 4.10.5 (not currently available for my distro, so I might have to build it myself). From some emails in this thread, it sounds like maybe it's a vain hope that the .5 releases are the most stable, but stability and polish are generally what I'm looking for. Just 2 cents from this user... -Ben
Re: Releases in 3 months
On Sunday, July 14, 2013 15:23:46 David Faure wrote: On Friday 12 July 2013 17:07:13 Aaron J. Seigo wrote: we ought to think of ways to make master more stable. Exactly. And porting master to qt5/frameworks definitely doesn't make it more stable, so let's not do that. (Yes, I'm mixing both topics, because I see contradictory arguments from the same person in both threads ;) Context is important. When developing the 4.x series, we have something that would benefit from broader testing and usage and which can quite realistically be developed in such a manner. So a “keep master stable at all times” strategy makes every bit of sense. During the Qt5/Frameworks 5 port of kde-workspace, that branch will not be called ‘master’, but KDE/4.11. The rest is semantics: the KDE/4.11 branch becomes the “master” branch for 4.x for kde-workspace from that point forward. During the Frameworks 5 port, the stability goal for master will initially be for the developers doing that work (or who would like to), and then later for early adopter testers and then eventually widespread use. During each of those phases, we will strive to keep master stable for the audience it is addressing. Using master for porting to Frameworks 5 allows us to minimize later work by clearly defining which branches can drift from that development in which ways. We will strive tot keep that master branch as usable as possible during that porting, however; e.g. the use of topic branches for the porting tasks will help us keep master in a sane state during that process. When looking at the needs and requirements of * a stable release series * a major porting effort / devel cycle things do not work identically. Trying to compare statements made in those two contexts will lead one to find that some statements can not be applied with equal accuracy to both contexts. It’s like being surprised that there are differences in the safety precautions taken when driving a car or flying an airplane, despite both being ways of getting from point A to point B. -- Aaron J. Seigo signature.asc Description: This is a digitally signed message part.
Re: Releases in 3 months
On Saturday, July 13, 2013 14:05:13 Jaime Torres Amate wrote: How would the release schedule ( http://techbase.kde.org/Schedules/KDE4/4.11_Release_Schedule) be in a 3 or 4 mounths release? 1 month for new features, 2 or 3 for bugfixing, translating, language bindings? Or like linux kernel, allways develop new features in other branches, and 1 month to merge them and then fixing? I think that’s precisely what Alex wants to discuss with the rest of the developers. :) -- Aaron J. Seigo signature.asc Description: This is a digitally signed message part.
Re: Releases in 3 months
On 2013-07-14, Inge Wallin i...@lysator.liu.se wrote: Here are some assumptions. Correct me if they are wrong: - KDE developers support the last relesed and *maybe* the second to last release with bugfixes. - Distributions have a release cycle of 6 months or longer. - Distributions pick their contents 2-3 months in advance, at least I think these assumptions in general are correct, with some exceptions (the rolling distros like arch and gentoo to one side, and distros like debian in the other side). So therefore I am against the proposal. 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. Thank you for a very well-written email. /Sune
Re: Releases in 3 months
On Saturday, July 13, 2013 09:50:21 Luca Beltrame wrote: Aaron J. Seigo wrote: 1. packagers seem to feel that if upstream doesn’t do the actual commit to the upstream repository, then upstream is not maintaining their software To be honest, that's not always true. Good :) At least the major distributions and a few of the minors have packagers that hold KDE developers accounts. The Yes ... problem is, as I can see, numbers (those people are a minor percentage of $DISTRO_CONTRIBUTORS and they also do packaging) Which is why I wrote: we should try to recruit more people from the user community of downstream distributions who have the skills necessary to merge patches and test. some distributions do this already.” and sometimes expertise (I can touch CMake files and perhaps do little adjustments in C++, but nowhere near fixing complex bugs). Backporting usually does not require that level of skill with C++. When it does, we can certainly call on upstream developers to help out. Most of the changes that would appear in these extended bug fix releases would be just that: backports. A bug fixed in x.y.z should appear in x.y+1, after all. A significant % of code changes in bug fix releases tend to be backported fixes. Exceptions to that most often occur where the code has changed significantly in a future release in such a way that the bug simply no longer exists in that future release; we’ve done that a few times over the years in Plasma Desktop by replacing a plasmoid (for instance) completely. Then backporting is not so much of an option without taking the whole new plasmoid (which usually isn’t a good idea). In which case, one may just have to live with the bug in the older versions. The question is whether the above is a reason to not have 3 month release cycles? (Or whatever # of months is agreed on, where that # is less than 6) -- Aaron J. Seigo signature.asc Description: This is a digitally signed message part.
Re: Releases in 3 months
On Sunday, July 14, 2013 04:19:52 Inge Wallin wrote: Without having any scientific proof, I believe that there are 2 main categories of users: 1. Those generally satisfied who want stability 2. Those who long for new updates all the time. Regardless of whether someone is a Category 1 or a Category 2 user, they want software with as few defects as possible. Agreed? My feeling is that the first category is the silent majority and the second category is the loud minority. Of course there is always a number of people who want just this special new feature to make it perfect but those are probably split in which feature they want and therefore still a minority. This could well be true (I agree with you that it probably is), but it is also not salient to the topic. The goal is not to get features out to users faster; that would be a side-effect, if anything. The goal is to have a development cycle that allows us to fold features and bug fixes into the existing code bases in less disruptive ways. That ought to please the Category 1 people a lot. And the users want these bugs fixed. If the statement above is indeed true, then the majority of users want to have the bugs fixed without having to suffer through other changes too. I don’t see how that follows in the least. You suggest that changes are “suffered through”; perhaps that’s a sign that we’re doing those changes wrong. For example: * smaller changes introduced evenly over a period of time may be easier to adapt to than a large set of changes introduced all at once * smaller change sets may result in fewer bugs making to the user Perhaps our longer cycles are introducing too many changes at once causing more problems for your Category 1 users than any # of bugs fixed in the minor update releases we do. Let's face it: upgrading your distribution is often a pain and always a risk. Configurations have to be redone, sometimes things stop working in mysterious ways, you have to redo any customizations, etc, etc. That’s sort of the thing we’re trying to improve on. Again, you’re arguing that what we’re doing now sucks and so lets keep doing it because if we change we might break it even further. Instead, let’s examine the actual ideas presented instead of posing abstract arguments against all possible alternative approaches. So what is the impact on the user of the proposal to make the release cycle 3 months? Good question, the sort that we need to answer! Basically that there will be no more bugfixes for the end user. The sky will fall and the levies will break asunder! Really the only way this statement could ever be true is if we never, ever made bug fixes anymore. A realistic phrasing of the possible problem might be: It will take much longer for people to get the bug fixes on their system That sounds a lot less scary, I know, but it also sticks to reality in a way that can be responded to. Here are some assumptions. Correct me if they are wrong: - KDE developers support the last relesed and *maybe* the second to last release with bugfixes. - Distributions have a release cycle of 6 months or longer. - Distributions pick their contents 2-3 months in advance, at least Under the current development and release system, yes. We’re suggesting changing those systems, and that means the resulting effects could also change. In fact, that’s the entire idea. So if a distribution picks (say) KDE 4.25 for their new relesae, then 4.26 will come out around the same time as that distribution is released. But only the distro jumpers install a new release in the first few months, the people who want stability (the majority) will wait a couple of months before they do it to get the worst bugs out of the system first. But then KDE 4.27 is released 3 months after the distribution comes out which makes KDE 4.25 more or less unmaintained. This already happens today. Judging just be reports on bugs.kde.org, and not relying at all on common sense whatsoever, a huge % of our user base is using versions of our software that is at least 1 release old and often much more than that. Seeing bug reports filed against versions we released a year ago is commonplace. So this is not a problem we will face, it is a problem we *do* face. So how can we make it better? One way is to improve the quality of each release so that the severity and prevelance of bugs goes down. That’s what this proposal is about. One way is to improve the quality of each release so that the severity and prevelance of bugs goes down. That’s what this proposal is about. Yes, I put that twice, because that is such an important point. :) But now back to the puzzle of how to get bug fixes to releases in distributions that people are actually using ... We are experimenting with the idea of a “long term release” version with kde- workspace. If 4.11 gets widely used, deployed and stabalized (as we hope it will) then blessing
Re: Releases in 3 months
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. Cheers, Albert -Inge
Re: Releases in 3 months
Although Inge supposedly bases his analysis on extrapolation and (very) wise guessing, and despite the obvious lack of hard data (1), I will put my support behind Inge's view. (1) (sadly including here our blatant dissing of, e.g., 527 severe bug reports on nepomuk... that ask for stability and not for features). On Sunday 14 July 2013 04:19:52 Inge Wallin wrote: On Monday, July 08, 2013 15:04:40 Àlex Fiestas wrote: Now that kde-workspace and kdelibs are going to be frozen (which in theory means less work for everybody) I'd like to propose a new release schedule to be applied starting with 4.12. 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. All of the discussion so far has been on how the developers will handle this and to some degree the packagers in the distributions. What not one single post has brought up is the impact of the user except that there will be new features coming out sooner. Without having any scientific proof, I believe that there are 2 main categories of users: 1. Those generally satisfied who want stability 2. Those who long for new updates all the time. My feeling is that the first category is the silent majority and the second category is the loud minority. Of course there is always a number of people who want just this special new feature to make it perfect but those are probably split in which feature they want and therefore still a minority. Testing periods, integration branches, always releasable master, etc aside, there will always be bugs in all software. And the users want these bugs fixed. If the statement above is indeed true, then the majority of users want to have the bugs fixed without having to suffer through other changes too. Let's face it: upgrading your distribution is often a pain and always a risk. Configurations have to be redone, sometimes things stop working in mysterious ways, you have to redo any customizations, etc, etc. Most users are not thrill seekers when it comes to computers - they want to use them as a tool. So what is the impact on the user of the proposal to make the release cycle 3 months? Basically that there will be no more bugfixes for the end user. What?? That can't be true! Well, here is how it would work. Here are some assumptions. Correct me if they are wrong: - KDE developers support the last relesed and *maybe* the second to last release with bugfixes. - Distributions have a release cycle of 6 months or longer. - Distributions pick their contents 2-3 months in advance, at least So if a distribution picks (say) KDE 4.25 for their new relesae, then 4.26 will come out around the same time as that distribution is released. But only the distro jumpers install a new release in the first few months, the people who want stability (the majority) will wait a couple of months before they do it to get the worst bugs out of the system first. But then KDE 4.27 is released 3 months after the distribution comes out which makes KDE 4.25 more or less unmaintained. So a user that installs this distribution as above and finds a bug after 1 month and reports it gets told screw you, we're doing 4.28 now; we don't support that old shit anymore (hopefully in nicer words though :) ). So therefore I am against the proposal. 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. -Inge -- Cristian Tibirna KDE developer .. tibi...@kde.org .. http://www.kde.org signature.asc Description: This is a digitally signed message part.
Re: Releases in 3 months
El Dilluns, 15 de juliol de 2013, a les 09:58:01, Cristian Tibirna va escriure: Although Inge supposedly bases his analysis on extrapolation and (very) wise guessing, and despite the obvious lack of hard data (1), I will put my support behind Inge's view. (1) (sadly including here our blatant dissing of, e.g., 527 severe bug reports on nepomuk... that ask for stability and not for features). I'm sure nepomuk people will accept your help in triaging all those 527 severe bugs. Cheers, Albert On Sunday 14 July 2013 04:19:52 Inge Wallin wrote: On Monday, July 08, 2013 15:04:40 Àlex Fiestas wrote: Now that kde-workspace and kdelibs are going to be frozen (which in theory means less work for everybody) I'd like to propose a new release schedule to be applied starting with 4.12. 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. All of the discussion so far has been on how the developers will handle this and to some degree the packagers in the distributions. What not one single post has brought up is the impact of the user except that there will be new features coming out sooner. Without having any scientific proof, I believe that there are 2 main categories of users: 1. Those generally satisfied who want stability 2. Those who long for new updates all the time. My feeling is that the first category is the silent majority and the second category is the loud minority. Of course there is always a number of people who want just this special new feature to make it perfect but those are probably split in which feature they want and therefore still a minority. Testing periods, integration branches, always releasable master, etc aside, there will always be bugs in all software. And the users want these bugs fixed. If the statement above is indeed true, then the majority of users want to have the bugs fixed without having to suffer through other changes too. Let's face it: upgrading your distribution is often a pain and always a risk. Configurations have to be redone, sometimes things stop working in mysterious ways, you have to redo any customizations, etc, etc. Most users are not thrill seekers when it comes to computers - they want to use them as a tool. So what is the impact on the user of the proposal to make the release cycle 3 months? Basically that there will be no more bugfixes for the end user. What?? That can't be true! Well, here is how it would work. Here are some assumptions. Correct me if they are wrong: - KDE developers support the last relesed and *maybe* the second to last release with bugfixes. - Distributions have a release cycle of 6 months or longer. - Distributions pick their contents 2-3 months in advance, at least So if a distribution picks (say) KDE 4.25 for their new relesae, then 4.26 will come out around the same time as that distribution is released. But only the distro jumpers install a new release in the first few months, the people who want stability (the majority) will wait a couple of months before they do it to get the worst bugs out of the system first. But then KDE 4.27 is released 3 months after the distribution comes out which makes KDE 4.25 more or less unmaintained. So a user that installs this distribution as above and finds a bug after 1 month and reports it gets told screw you, we're doing 4.28 now; we don't support that old shit anymore (hopefully in nicer words though :) ). So therefore I am against the proposal. 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. -Inge
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
Aaron J. Seigo wrote: we should try to recruit more people from the user community of downstream distributions who have the skills necessary to merge patches and test. some distributions do this already.” The reason I mentioned issues with this approach originally originate from (perhaps it's just my naive thinking) the need to prevent burnout at all costs in distro teams. The number of packagers is often even less than developers: for openSUSE, which I know better of, the major packaging work is split between 3 people usually, and increased burden *may* lead to burnout which can be catastrophic with these numbers. I also realize however that I do not want to sound too negative: rationally speaking, what would be nice to see, for such a proposal is a definition (in broad terms) of what can be backportable and what not (kind of like you said further down in the mail). The question is whether the above is a reason to not have 3 month release cycles? (Or whatever # of months is agreed on, where that # is less than 6) It is a matter of workflow, I think, that is that the development workflow (let's call it like that, even if it is improper) should be put in place first, and then applied to shrink release times. -- Luca Beltrame - KDE Forums team KDE Science supporter GPG key ID: 6E1A4E79
Re: Releases in 3 months
On Friday 12 July 2013 17:07:13 Aaron J. Seigo wrote: we ought to think of ways to make master more stable. Exactly. And porting master to qt5/frameworks definitely doesn't make it more stable, so let's not do that. (Yes, I'm mixing both topics, because I see contradictory arguments from the same person in both threads ;) -- David Faure, fa...@kde.org, http://www.davidfaure.fr Working on KDE, in particular KDE Frameworks 5 signature.asc Description: This is a digitally signed message part.
Re: Releases in 3 months
On Monday, July 08, 2013 15:04:40 Àlex Fiestas wrote: Now that kde-workspace and kdelibs are going to be frozen (which in theory means less work for everybody) I'd like to propose a new release schedule to be applied starting with 4.12. 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. All of the discussion so far has been on how the developers will handle this and to some degree the packagers in the distributions. What not one single post has brought up is the impact of the user except that there will be new features coming out sooner. Without having any scientific proof, I believe that there are 2 main categories of users: 1. Those generally satisfied who want stability 2. Those who long for new updates all the time. My feeling is that the first category is the silent majority and the second category is the loud minority. Of course there is always a number of people who want just this special new feature to make it perfect but those are probably split in which feature they want and therefore still a minority. Testing periods, integration branches, always releasable master, etc aside, there will always be bugs in all software. And the users want these bugs fixed. If the statement above is indeed true, then the majority of users want to have the bugs fixed without having to suffer through other changes too. Let's face it: upgrading your distribution is often a pain and always a risk. Configurations have to be redone, sometimes things stop working in mysterious ways, you have to redo any customizations, etc, etc. Most users are not thrill seekers when it comes to computers - they want to use them as a tool. So what is the impact on the user of the proposal to make the release cycle 3 months? Basically that there will be no more bugfixes for the end user. What?? That can't be true! Well, here is how it would work. Here are some assumptions. Correct me if they are wrong: - KDE developers support the last relesed and *maybe* the second to last release with bugfixes. - Distributions have a release cycle of 6 months or longer. - Distributions pick their contents 2-3 months in advance, at least So if a distribution picks (say) KDE 4.25 for their new relesae, then 4.26 will come out around the same time as that distribution is released. But only the distro jumpers install a new release in the first few months, the people who want stability (the majority) will wait a couple of months before they do it to get the worst bugs out of the system first. But then KDE 4.27 is released 3 months after the distribution comes out which makes KDE 4.25 more or less unmaintained. So a user that installs this distribution as above and finds a bug after 1 month and reports it gets told screw you, we're doing 4.28 now; we don't support that old shit anymore (hopefully in nicer words though :) ). So therefore I am against the proposal. 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. -Inge
Re: Releases in 3 months
How would the release schedule ( http://techbase.kde.org/Schedules/KDE4/4.11_Release_Schedule) be in a 3 or 4 mounths release? 1 month for new features, 2 or 3 for bugfixing, translating, language bindings? Or like linux kernel, allways develop new features in other branches, and 1 month to merge them and then fixing? Aaron J. Seigo ase...@kde.org escribió: On Friday, July 12, 2013 10:12:41 Andras Mantia wrote: On Thursday, July 11, 2013 06:53:51 PM andrea diamantini wrote: What about a single official development branch? Just use two branches: - master branch (stable) - kdevel branch (devel) The natural question to come is: why isn't master the devel branch? :) because when there is no stable branch that tracks pre-release development, the # of people testing goes down. which means there is no branch for people who would othewise like to follow development for testing purposes but who need something that is at least beta quality all of the time. that means no half-baked features or “this currently breaks X, Y and Z” commits. there is a reason we don’t have more people running master. even many KDE application developers do NOT use self-built libs, workspace or other application. with kdesrc-build, time and effort are not the problems. one reason for not self-building the libraries is to make sure their application works properly with the current stable libs. however, i know for a fact (because it’s been said to me many times by developers) that many do not use master because it is too much of a stability gamble. what it comes down to is how much we care about people who would test, document or translate our software being able to track development closer. if we don’t care much about that, then we can continue doing what we’re doing. if we do care, we ought to think of ways to make master more stable. we’ve been able to move a lot more people to testing devel for Plasma Active, for instance, since we adopted such an approach. i also think that you’ll find, if you let yourself, that with git working in branches is not only pain free but it often saves a lot of effort. many times times i’ve quickly switched to master to fix a bug without first finishing the feature set i’m working on; many times i’ve switched to someone else’s feature branch to check on progress and try things out before they are fully ready, only to then switch back to master or to my own feature branch(es) to continue my work. it’s a small change in how one works, and i know that change is hard :) .. but this one is so worth it. Ok, let me reformulate again: did we had many breakage in master the past time that affected the official releases? Like we realized at branching time that master is (heavily) broken and we cannot start a new release? no, we just released with breakage. or freaked out at the last moment with people predicting the sky will fall while others work their ass off to fix things. -- Enviado desde mi teléfono Android con K-9 Mail. Disculpa mi brevedad
Re: Releases in 3 months
On Thursday, July 11, 2013 06:53:51 PM andrea diamantini wrote: What about a single official development branch? Just use two branches: - master branch (stable) - kdevel branch (devel) The natural question to come is: why isn't master the devel branch? :) Ok, let me reformulate again: did we had many breakage in master the past time that affected the official releases? Like we realized at branching time that master is (heavily) broken and we cannot start a new release? If not, I don't see what do we want to fix with devel branches. Andras
Re: Releases in 3 months
Àlex Fiestas wrote: 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 Don't forget that at least the bigger distros offer unsupported repositories for newer versions - and at least in the case of openSUSE some are actually used by contributors and early adopters to test the packaging of newest versions. -- Luca Beltrame - KDE Forums team KDE Science supporter GPG key ID: 6E1A4E79
Re: Releases in 3 months
henry miller wrote: latest, but those will never get beyond a .3 release. Distributions that want more stability can work together to submit patches to the long term Bear in mind that not all distros have packagers with coding skills. Also, maintenance of patches downstream can be problematic if they're not trivial (in openSUSE we dropped some because no one was able to maintain them). I realize this is more work for our packagers, but I hope they can script it to a cron job that just checks for changes and creates tarballs once a month. The build process is mostly automated nowadays, however packaging (proper packaging) still requires manual checking. -- Luca Beltrame - KDE Forums team KDE Science supporter GPG key ID: 6E1A4E79
Re: Releases in 3 months
On Thursday, July 11, 2013 01:06:59 PM Sebastian Kügler wrote: On Tuesday, July 09, 2013 12:53:50 Philip Muskovac wrote: On Monday 08 July 2013 18:59:12 Michael Pyne wrote: On Mon, July 8, 2013 17:45:10 Philip Muskovac wrote: What would at least make my life easier here would be a way to easily get a list of all patches that were applied to a stable release (esp. when someone bothers to backport a fix after the last point release is out). The only way to do that, that I found so far, is filtering out mails from kde- commits, which is neither very easy nor reliable. I'm assuming a variant of 'git log --oneline v4.x.y..KDE/4.x' is not adequate for some reason? Admittedly sometimes we need to be reminded to push the release tags but that seems like it should work for all modules in the kde.org-released software. Good point, that's at least more reliable than filtering mail. It still requires me to have a local clone of some 150 repositories and some extra handling for the svn branch so I would prefer something that doesn't require me to pull all of those just to get some statistics. I'll play with that though, thanks! If that's the concern, we can certainly run such a script on one of the build machines, and it probably only needs someone puppy-eyeing a sysadmin to install it. Cheers, Why not make a job on the jenkins/hudson machine(s)? They can be parametrized (you give the labels) or the relevant ones are added and run regularly. Would perhaps increase the visibility of those machines a bit. -- Michael Jansen http://michael-jansen.biz
Re: Releases in 3 months
On Friday, July 12, 2013 10:12:41 Andras Mantia wrote: On Thursday, July 11, 2013 06:53:51 PM andrea diamantini wrote: What about a single official development branch? Just use two branches: - master branch (stable) - kdevel branch (devel) The natural question to come is: why isn't master the devel branch? :) because when there is no stable branch that tracks pre-release development, the # of people testing goes down. which means there is no branch for people who would othewise like to follow development for testing purposes but who need something that is at least beta quality all of the time. that means no half-baked features or “this currently breaks X, Y and Z” commits. there is a reason we don’t have more people running master. even many KDE application developers do NOT use self-built libs, workspace or other application. with kdesrc-build, time and effort are not the problems. one reason for not self-building the libraries is to make sure their application works properly with the current stable libs. however, i know for a fact (because it’s been said to me many times by developers) that many do not use master because it is too much of a stability gamble. what it comes down to is how much we care about people who would test, document or translate our software being able to track development closer. if we don’t care much about that, then we can continue doing what we’re doing. if we do care, we ought to think of ways to make master more stable. we’ve been able to move a lot more people to testing devel for Plasma Active, for instance, since we adopted such an approach. i also think that you’ll find, if you let yourself, that with git working in branches is not only pain free but it often saves a lot of effort. many times times i’ve quickly switched to master to fix a bug without first finishing the feature set i’m working on; many times i’ve switched to someone else’s feature branch to check on progress and try things out before they are fully ready, only to then switch back to master or to my own feature branch(es) to continue my work. it’s a small change in how one works, and i know that change is hard :) .. but this one is so worth it. Ok, let me reformulate again: did we had many breakage in master the past time that affected the official releases? Like we realized at branching time that master is (heavily) broken and we cannot start a new release? no, we just released with breakage. or freaked out at the last moment with people predicting the sky will fall while others work their ass off to fix things. -- Aaron J. Seigo signature.asc Description: This is a digitally signed message part.
Re: Releases in 3 months
On Wednesday, July 10, 2013 12:28:10 Scott Kitterman wrote: This isn't the first time upstream KDE developers have suggested offloading the boring upstream maintenance work to distributions. do you think it’s because it is boring? no. it’s because if when this work is put on the shoulders of too few people it doesn’t get done. boring has nothing to do with it. upstream often does not know which branches and which feature sets matter to downstreams, nor are we able to test all of those branches while downstream has the user audience that can. please stop this “it is shifting responsibility” meme. it’s about finding ways to work together more dynamically and within our areas of ability. 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. right, so the challenges highlighted here seem to be: 0. downstreams have typically invested in recruiting and developer packagers, not developers 1. packagers seem to feel that if upstream doesn’t do the actual commit to the upstream repository, then upstream is not maintaining their software the first challenge indicates we should try to recruit more people from the user community of downstream distributions who have the skills necessary to merge patches and test. some distributions do this already, btw. the second challenge is a matter of mutual understanding which we can work out in this very thread. -- Aaron J. Seigo signature.asc Description: This is a digitally signed message part.
Re: Releases in 3 months
On Wednesday, July 10, 2013 07:44:35 PM Martin Graesslin wrote: 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 *exactly*! the reason for the stability problems is a combination of the improper fit of the 6 month development cycle combined with a near total lack of workflow for how a change makes its way into master. we can’t use the lack of stability of .0 releases to argue against making changes that will improve that ;) (other improvements are underway in frameworks 5 as well with better definition of modules and a greater emphases on unit testing .. so it’s a multi-solution- required type of problem. i don’t want to suggest a change in release schedule will magically fix everything, it will simply allow us to improve the situation. perhaps with all the other incremental improvements in our workflow we’ll get to “fixed”, though.) 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? -- Aaron J. Seigo signature.asc Description: This is a digitally signed message part.
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
Le mercredi 10 juillet 2013 17:55:42 Àlex Fiestas a écrit : On Tuesday 09 July 2013 16:12:35 Andras Mantia wrote: Two point I want to mention: 1) working in a branch for kdepim is quite painful, as you need actually work on branches of 3 (or sometimes 4) modules: kdepimlibs, kdepim-runtime, kdepim (and akonadi). Keep them up-to-date, merge them at the right point, etc. Developing in master is *much* easier. I do this web KDE-Accounts integration, it is more painful but doable, not like the month is ending like it was with svn. 2) some people don't like branches, we have to understand it. :) There is no one schedule that will fit all, that's sure. But dismissing once preference with a way that tells him how he SHOULD do, is not really a good. Developing big features in master is even disrespectful to your fellow developers, countless time things have broken because of this and people have not been able to use master as their work environment. I could understand it for small things, and in the case you are an exceptional developer that does not make mistakes and tests everything before pushing. So maybe we can find a compromise? what about: Features can be developed in master, if they are big or delicate just add compile option to remove them for release. This way we can we could even add something like cmake -DDISABLE_WIP_FEATURES And then leave this up to each module developers to decide whether this way of working is acceptable for them or not. This is an interesting approach, it could help for cross-repository features like a feature requiring changes in kdepimlibs and kdepim, it can also make it easier to test a feature while you are developing another one (basically it boils down to -DWITH_MY_FEATURE=ON -DWITH_SOMEONE_ELSE_FEATURE=ON) There are a few dangers with it though: - It adds more build system work, which can be error-prone. - Depending on how invasive the feature is, at one point you may/will commit code which builds for you but does not build with -DWITH_MY_FEATURE=OFF. - One must be careful to remove the CMake options after the feature is marked as stable, to avoid accumulating cruft. Aurélien
Re: Releases in 3 months
What about a single official development branch? Just use two branches: - master branch (stable) - kdevel branch (devel) You develop wherever you like and push things on kdevel branch when ready. If you like the one branch approach, you devel things directly in kdevel branch. People knows there are just 2 important branches: master and kdevel. One people per project can think merging from kdevel to master when things are ok. I think this adds just a tiny layer for people working with one branch and it is basically the same for multibranches people. And it allows both worlds to cohexists. 2013/7/11 Aurélien Gâteau agat...@kde.org Le mercredi 10 juillet 2013 17:55:42 Àlex Fiestas a écrit : On Tuesday 09 July 2013 16:12:35 Andras Mantia wrote: Two point I want to mention: 1) working in a branch for kdepim is quite painful, as you need actually work on branches of 3 (or sometimes 4) modules: kdepimlibs, kdepim-runtime, kdepim (and akonadi). Keep them up-to-date, merge them at the right point, etc. Developing in master is *much* easier. I do this web KDE-Accounts integration, it is more painful but doable, not like the month is ending like it was with svn. 2) some people don't like branches, we have to understand it. :) There is no one schedule that will fit all, that's sure. But dismissing once preference with a way that tells him how he SHOULD do, is not really a good. Developing big features in master is even disrespectful to your fellow developers, countless time things have broken because of this and people have not been able to use master as their work environment. I could understand it for small things, and in the case you are an exceptional developer that does not make mistakes and tests everything before pushing. So maybe we can find a compromise? what about: Features can be developed in master, if they are big or delicate just add compile option to remove them for release. This way we can we could even add something like cmake -DDISABLE_WIP_FEATURES And then leave this up to each module developers to decide whether this way of working is acceptable for them or not. This is an interesting approach, it could help for cross-repository features like a feature requiring changes in kdepimlibs and kdepim, it can also make it easier to test a feature while you are developing another one (basically it boils down to -DWITH_MY_FEATURE=ON -DWITH_SOMEONE_ELSE_FEATURE=ON) There are a few dangers with it though: - It adds more build system work, which can be error-prone. - Depending on how invasive the feature is, at one point you may/will commit code which builds for you but does not build with -DWITH_MY_FEATURE=OFF. - One must be careful to remove the CMake options after the feature is marked as stable, to avoid accumulating cruft. Aurélien -- Andrea Diamantini WEB: http://www.adjam.org Sponsored by BlueSystems to work on the rekonq project WEB: http://rekonq.kde.org IRC: rekonq@freenode
Re: Releases in 3 months
Àlex Fiestas afies...@kde.org 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. Might I suggest the following addition: every year (exact time debatable) we mark a release long term. Distributions are encouraged to release the latest, but those will never get beyond a .3 release. Distributions that want more stability can work together to submit patches to the long term release: every month we will release a new version of any long term release that has a change. I realize this is more work for our packagers, but I hope they can script it to a cron job that just checks for changes and creates tarballs once a month. The purpose of my proposal is to make it easier for our downstreams to work together. If RHEL ships 4.14 in a long term release and Kubunu ships 4.15: odds are a security bug found in one is in the other. However patches between versions may not apply cleanly so it is extrawork for the second distribution to fix: and this assumes they inform each other of the bug. By giving them a common place where they are encouraged to work together they can both provide better quality which makes us look good. -- Sent from my Android phone with K-9 Mail. Please excuse my brevity.
Re: Releases in 3 months
On Thursday 11 July 2013, andrea diamantini wrote: What about a single official development branch? Just use two branches: - master branch (stable) - kdevel branch (devel) You develop wherever you like and push things on kdevel branch when ready. If you like the one branch approach, you devel things directly in kdevel branch. People knows there are just 2 important branches: master and kdevel. One people per project can think merging from kdevel to master when things are ok. Do we have enough such maintainers ? Alex
Re: Releases in 3 months
On Monday, July 8, 2013 15:04:40 Àlex Fiestas wrote: You can read all the proposal in: http://community.kde.org/KDE_Core/ReleasesProposal Neat ... some thoughts: == On branching this will be much easier for those who develop features in branches rather than use master as a big developer free for all. others have already noted that, of course. for people who don’t use branches, this would likely be a very difficult transition. so the question is: why don’t people use branches? well, we can discard “because i don’t like it”. all developer routines require some matching discipline and adoption of the idea. there are some very real issues related to our lack of workflow related to branches, however. one is developer education: not everyone is used to working with branches and just as we made recipes and started recommending things like kdesrc-build with more emphasis during the move to git, i think we will need to do similarly for branches. then there is workflow .. we have review board, which was also met with a lot of scepticism at first just like branches are by some now, and it is widely used with a lot of success. however, it is not as easy as it could or should be. managing branch reviews with merge requests and what not is more painful than it ought to be. sys admin had made clear that gerrit is not an option, and i support that position for the numerous reasons they have provided. so for me, moving to a 3 month cycle would require first having good branch management and review tools for our workflow. it would make a shorter dev cycle so much easier for so many more of our developers. == On branding and visual presentation some have noted that faster release cycles would make it hard to implement branding updates and artwork refreshes such as wallpapers. the answer to that is simple: these efforts must not be tied to the development cycle. the development cycle has for too long dictated the pace of everything else, even though “everything else” does not follow the same natural pace of development! in the case of artwork, my proposal would be to aim for exactly one refresh per year. do it in the new year, perhaps? the first release of every year could come with a visual refresh and a branding refinement. this would give us a full year to draft and implement these changes. my experience with the branding and visual side of our efforts is that the areas that get touched by these changes are very, very rarely touched by the development of features or bug fixes. so these efforts could have a release cycle of 1 year while the source code development could have a release cycle of 3 months (or whatever) i think this would actually make the changes more impactful on our users and ease the burdon on our art and branding teams == On marketing marketing needs to be separated from development cycles. there is no reason that marketing could not do a twice-yearly big splash announcement about releases that highlights the current status and major progress points of KDE software. note that i did not write ‘KDE SC’. these pushes should try to include a broader picture that includes the frameworks, the workspaces and applications across the KDE community. why shouldn’tAmarok or K3B or Digikam or Calligra pumped in those announcements? there could be a january and a july PR push that woudl pull together all the changes, all the important bits, etc. releases of the SC between those could be released with simplified annnouncements with less fanfare much as we currently do the monthly maintenance updates. it could be even be more dramatic of a change of course: there could be just a single annual Big PR Splash with the rest of the year being filled with smaller and more regular PR announcements. or maybe all releases are done with a simple announcement and instead of tying announcements to releases, a “KDE Magazine” is put out much as KDE e.V. does with quarterly reports that covers the last N months of activity in KDE. in any case, the idea that development cycles dictate when we speak to the public is an anachronism. it really does not have the major impact many of us may think it does because we are no longer a young exciting project (which means we are most repeating ourselves, which is boring) and our bi-annual announcements not only skip over non-SC software but it is does not create much attention-grabbing engagement with people, something a magazine would do much better at. imho, marketing should should be thinking outside the box and release schedules should not be tethered to those efforts. == On scheduling mainenance releases one of the benfits of a shorter cycle, to me, is that the need for monthly mainenance releases is lessened. with a 3 month cycle, i don’t see the point of having 2 bug fix updates. i’d instead suggest having just 1. in such a case, there would be a release every 6 weeks: major, minor, major, minor, etc.
Re: Releases in 3 months
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? 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. So, more work for most people, but no one gains. And as it currently is, we need the .4 and .5 releases. /Sune
Re: Releases in 3 months
On Tuesday 09 July 2013 21:57:51 Alexander Neundorf wrote: On Tuesday 09 July 2013, Sven Brauch wrote: I think Nuno's point is very interesting and worth thinking about. To stick with the firefox example, since they started releasing every ortography fix in the settings dialog as a new major version, I think attention in the media to their releases has declined a lot -- nobody cares any more that a new version of firefox was released since it happens every three days. that's my impression too. I can't comment on promo strategies, but I can comment on news since I read a lot of them. FF pointless releases get small coverage, FF releases containing interesting features get the same coverage as they did before. For example: Firefox 201 has speed improvements and security fixes. This one appears barely. Firefox 202 contains new interface. This one appears everywhere as old firefox releases did. Actually, in the old fashion FF releases only the most important changes (like new interface) got press coverage anyway... so not much have changed.
Re: Releases in 3 months
On Tuesday 09 July 2013 16:12:35 Andras Mantia wrote: Two point I want to mention: 1) working in a branch for kdepim is quite painful, as you need actually work on branches of 3 (or sometimes 4) modules: kdepimlibs, kdepim-runtime, kdepim (and akonadi). Keep them up-to-date, merge them at the right point, etc. Developing in master is *much* easier. I do this web KDE-Accounts integration, it is more painful but doable, not like the month is ending like it was with svn. 2) some people don't like branches, we have to understand it. :) There is no one schedule that will fit all, that's sure. But dismissing once preference with a way that tells him how he SHOULD do, is not really a good. Developing big features in master is even disrespectful to your fellow developers, countless time things have broken because of this and people have not been able to use master as their work environment. I could understand it for small things, and in the case you are an exceptional developer that does not make mistakes and tests everything before pushing. So maybe we can find a compromise? what about: Features can be developed in master, if they are big or delicate just add compile option to remove them for release. This way we can we could even add something like cmake -DDISABLE_WIP_FEATURES And then leave this up to each module developers to decide whether this way of working is acceptable for them or not. What do you think? I also find the motivation somewhat contradictory. Yes, you want to provide new features faster, but by cutting down testing time. *Are you sure?* Testing time by whom? we will be cutting not even a month of user testing (according to 4.11 schedule).
Re: Releases in 3 months
On Tuesday 09 July 2013 21:15:54 Ingo Klöcker wrote: On Tuesday 09 July 2013 09:36:00 andrea diamantini wrote: My idea about this concerns the way we let other people know aboout new features. I usually read our feature plan (e.g. http://techbase.kde.org/Schedules/KDE4/4.11_Feature_Plan). I think we could add one general page per project, similar to that one, listing: - the feature - the branch where it is developed - the developer - the milestone (eg: kde 4.12, october 2103) where developer thinks to merge/release. IMHO there is a tool that's much better suited for this than a wiki: Bugzilla. Yes, I'm talking about our lovely bug tracking tool. It offers fields for all the information you want. The issue summary briefly describes the feature, the branch could be listed in a custom field or simply in the description, the developer is the assignee, target milestones also exist. What's missing are a few nice predefined queries and standardized milestones to allow querying for them over all projects. But the most important part is that the majority of developers makes use of this. Otherwise, it will be as incomplete as the feature plans. To make bugzilla a suiteable tool for the job we should increase the integration with have of our git with it, kind of: CHANGE: Improved 200x loading time of... FEATURE: New magic zoom that tracks flowers The change will have to get added somewhere, and the FEATURE in the list of features.
Re: Releases in 3 months
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.
Re: Releases in 3 months
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. [...] 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: 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. Ciao -- Luigi
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 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.
Re: Releases in 3 months
A Quarta, 10 de Julho de 2013 13:18:57 Aaron J. Seigo escreveu: == On branding and visual presentation some have noted that faster release cycles would make it hard to implement branding updates and artwork refreshes such as wallpapers. the answer to that is simple: these efforts must not be tied to the development cycle. the development cycle has for too long dictated the pace of everything else, even though “everything else” does not follow the same natural pace of development! in the case of artwork, my proposal would be to aim for exactly one refresh per year. do it in the new year, perhaps? the first release of every year could come with a visual refresh and a branding refinement. this would give us a full year to draft and implement these changes. my experience with the branding and visual side of our efforts is that the areas that get touched by these changes are very, very rarely touched by the development of features or bug fixes. so these efforts could have a release cycle of 1 year while the source code development could have a release cycle of 3 months (or whatever) i think this would actually make the changes more impactful on our users and ease the burdon on our art and branding teams == On marketing marketing needs to be separated from development cycles. there is no reason that marketing could not do a twice-yearly big splash announcement about releases that highlights the current status and major progress points of KDE software. note that i did not write ‘KDE SC’. these pushes should try to include a broader picture that includes the frameworks, the workspaces and applications across the KDE community. why shouldn’tAmarok or K3B or Digikam or Calligra pumped in those announcements? there could be a january and a july PR push that woudl pull together all the changes, all the important bits, etc. releases of the SC between those could be released with simplified annnouncements with less fanfare much as we currently do the monthly maintenance updates. it could be even be more dramatic of a change of course: there could be just a single annual Big PR Splash with the rest of the year being filled with smaller and more regular PR announcements. or maybe all releases are done with a simple announcement and instead of tying announcements to releases, a “KDE Magazine” is put out much as KDE e.V. does with quarterly reports that covers the last N months of activity in KDE. in any case, the idea that development cycles dictate when we speak to the public is an anachronism. it really does not have the major impact many of us may think it does because we are no longer a young exciting project (which means we are most repeating ourselves, which is boring) and our bi-annual announcements not only skip over non-SC software but it is does not create much attention-grabbing engagement with people, something a magazine would do much better at. imho, marketing should should be thinking outside the box and release schedules should not be tethered to those efforts. I realy like this ideas :) In fact this would be beter than what we have now, IMO. If we can coordinate the big splash ones, wille providing users with a flux of new features more often, I can only see a win win situation here. brading we still get the big new and improved versions that the media take notice, combined with visual difrences that they actualy can see.
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 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. I would feel compelled to be much more on top of branch and maybe do branch updates when it fits my schedule rather than just wait for the next scheduled release, because it comes too late. and then I end up snapshotting other people's code maybe in a state where they weren't ready to do it. i don=E2=80=99t have a strong opinion or compelling thoughts here, othe= r than to=20 remind us that 3 is not the only number we can consider in this :) We could also consider 6 :) =3D=3D On people being awesome ack. /Sune
Re: Releases in 3 months
A Quarta, 10 de Julho de 2013 17:43:38 você escreveu: On Tuesday 09 July 2013 21:57:51 Alexander Neundorf wrote: On Tuesday 09 July 2013, Sven Brauch wrote: I think Nuno's point is very interesting and worth thinking about. To stick with the firefox example, since they started releasing every ortography fix in the settings dialog as a new major version, I think attention in the media to their releases has declined a lot -- nobody cares any more that a new version of firefox was released since it happens every three days. that's my impression too. I can't comment on promo strategies, but I can comment on news since I read a lot of them. FF pointless releases get small coverage, FF releases containing interesting features get the same coverage as they did before. For example: Firefox 201 has speed improvements and security fixes. This one appears barely. Firefox 202 contains new interface. This one appears everywhere as old firefox releases did. Actually, in the old fashion FF releases only the most important changes (like new interface) got press coverage anyway... so not much have changed. And if we go by your proposal to have major releases that we chage the big numbe we can make that efort by then... I repete there is nothing major about the majpr releses aprat from new branding artwork materials, +promo push, and maybe some features that take longer to develop and that its developer wants to debut in a major release
Re: Releases in 3 months
On Wednesday 10 of July 2013 17:43:38 Àlex Fiestas wrote: On Tuesday 09 July 2013 21:57:51 Alexander Neundorf wrote: On Tuesday 09 July 2013, Sven Brauch wrote: I think Nuno's point is very interesting and worth thinking about. To stick with the firefox example, since they started releasing every ortography fix in the settings dialog as a new major version, I think attention in the media to their releases has declined a lot -- nobody cares any more that a new version of firefox was released since it happens every three days. that's my impression too. I can't comment on promo strategies, but I can comment on news since I read a lot of them. FF pointless releases get small coverage, FF releases containing interesting features get the same coverage as they did before. For example: Firefox 201 has speed improvements and security fixes. This one appears barely. Firefox 202 contains new interface. This one appears everywhere as old firefox releases did. Actually, in the old fashion FF releases only the most important changes (like new interface) got press coverage anyway... so not much have changed. I can't say it was the same for everyone. In the old time, before the run after FF4, I used to read the complete changelog checking for the news. After the run, I only see the headlines like fixes blabla and this new feature and that's it, without digging in, especially when you start to hear the future features of the next version in beta or the next+1 in alpha. A lot overlapped news, I'm never sure which version has what feature and I give up. This brings to my mind also another problem. This race with version numbers just to follow Chrome (and have bigger version number than Emacs) can bring more confusion. In the case of Chromium it brings also other problem (dependencies on newer unpatched versions) which makes things even more complicated for packaging, unless you take the entire precompiled block. This partially (lot less) happen also on FF, but it's still a problem. This is not a problem in the KDE world, but if the idea is to follow the web stuff like this, it can makes thing complicated for people not leaving on the edge with the last version of the applications. The more you go down in the stack, the more you need stability, and no, it's not true that with short release time the features will be smaller with less bugs, because a feature could have been in development for a long time, so it's not so small. You can say that there is more time for testing it, but then something can go wrong in the integration phase (and it happens, that's why the companies invest in QA departments). Ciao -- Luigi
Re: Releases in 3 months
On 2013-07-10, Àlex Fiestas afies...@kde.org wrote: 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. Other developers has said in other contexts 'do not backport patches without running them thru me'. The maintainer of the code in question is the best one to judge wether or not a given patch is suitable for backporting or not. All the rest of us don't know the code as well. So I really do think that marking patches for backporting *should* be done by the people behind the code, not by others. But thank you for making it clear that a large part of the reasoning for this proposal is that you want to drop maintenance of our product. /Sune
Re: Releases in 3 months
On Wednesday 10 of July 2013 19:17:37 Luigi Toscano wrote: The more you go down in the stack, the more you need stability, and no, it's not true that with short release time the features will be smaller with less bugs, because a feature could have been in development for a long time, so it's not so small. You can say that there is more time for testing it, but then something can go wrong in the integration phase (and it happens, that's why the companies invest in QA departments). ... and to complete my thought: as in KDE we don't have a strong structured QE department (even if the people in kde-testing do their work, but there are structural limits), this testing imho can't be outsourced to packagers only when developers moves to master only/devel branches and the next big features. No one can force someone to do it, of course, but... there are simply the resource for moving this work to someone else. And even when the work is more structured in companies, the decision about what to backport and what not is *also* in the hands of developers (with input from other party like QA and project management). Ciao -- Luigi
Re: Releases in 3 months
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. Cheers Martin
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
My idea about this concerns the way we let other people know aboout new features. I usually read our feature plan (e.g. http://techbase.kde.org/Schedules/KDE4/4.11_Feature_Plan). I think we could add one general page per project, similar to that one, listing: - the feature - the branch where it is developed - the developer - the milestone (eg: kde 4.12, october 2103) where developer thinks to merge/release. Having such a central place to know about others' work could help a lot getting informed (i.e. testing the features you'd like to test and not having master broken cause of feature X development while you are working on feature Y merge) and eventually plan a new KDE SC release (you'll know more or less when people thinks to release new features). If you have interesting new things, people will love a two months release. On the other hand, releasing every six months just because the scheduler says so grabs out some attention. Just my 2 cents 2013/7/9 Scott Kitterman k...@kitterman.com 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 -- Andrea Diamantini WEB: http://www.adjam.org Sponsored by BlueSystems to work on the rekonq project WEB: http://rekonq.kde.org IRC: rekonq@freenode
Re: Releases in 3 months
On Monday 08 July 2013 23:08:29 Ingo Klöcker wrote: On Monday 08 July 2013 22:14:28 Aurélien Gâteau wrote: On Monday 08 July 2013 16:26:00 laurent Montel wrote: Le lundi 8 juillet 2013 16:11:05 Frank Reininghaus a écrit : Hi, 2013/7/8 Àlex Fiestas: 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. I like the idea (from the Dolphin development point of view). Most of the changes that went into master during the past months had already been tested rather well before they were merged, and the remaining regressions were found rather quickly by people who use the master branch a lot. Therefore, it would have been nice if some of the improvements could have been shipped to users sooner - quite a few bugs that had been fixed in master (with patches that were IMHO too intrusive for the 4.10 branch) months ago were reported again and again. @Laurent:you say that you have a lot of features to implement, and that this would not be possible with a shorter release schedule. But wouldn't it be possible to implement some of the features for the next version and the rest for the one after that? If you think that you need more time to stabilize a feature in the master branch, then maybe developing the feature in a separate branch and merge it once it's finished might be a good idea? 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). It is true that we have a problem with getting people to test branches. But this problem is independant from the release schedule: I believe developing in branches is a good way to work, no matter if releases are created every 3 or 6 months. Having said so, I think Akonadi is a bad example because: - It was a huge change, quite the equivalent of a rewrite - It was affecting personal data Akonadi was developed in a branch. Okay, this branch was called master and the stable branch was called KDE 4.4 (IIRC), and, of course, this wasn't nice for people who built everything from master. But we tried to communicate very clearly that master was not to be used for anything expect for KDE PIM development. And, of course, we did consider using a proper branch, but then we would have had to maintain 3 branches: KDE 4.4, Akonadi, and master. Given that we didn't and still don't have enough people to even maintain the Akonadi branch (aka master) I still think that this decision was the only sensible one. The only feasible alternative would have been the deletion of master until the first Akonadi-based alpha release. Don't get me wrong: I did not write this as a grief against the way Akonadi was developed. I just wanted to highlight that nowadays most feature branches are less frightening to test than an Akonadi port, because they are much smaller, so you can expect more people to dive in and test it. Aurélien
Re: Releases in 3 months
On Monday 08 July 2013 20:40:59 Heinz Wiesinger wrote: Any reason not to CC kde-packager or kde-release-team? IMHO they'd be primary audiences for this. kde-packagers is a private mailist, I'm not sure how to handle it. kde-release-team, I assumed they were in kde-core-devel as well, but you have a point. Will send an email there if release-team people tell em so.
Re: Releases in 3 months
From my point of view, 3 month releases are going to actually increase quality. At least in Nepomuk. The Nepomuk developers (me included) have often merged feature branches right before the feature freeze even if the branch has some problems. No one wants to wait 8 months (2 months for the current release, and 6 months for the next) for the users to get the feature they are working quite hard on. The end result is that certain things aren't always polished, and the user experience suffers. With 3 month releases one can actually take a decision and delay the feature by about 4-5 months, which is still reasonable. 8 months is just too long to wait. Additionally, with these 3 month releases I am more inclined to release improvements for Nepomuk in 4.12. If 4.12 is supposed to be released in January, I won't be working on any new features. I'll start focusing on KF5, and the role Nepomuk will play over there. Effectively making 4.11 the last release for Nepomuk as well. On Mon, Jul 8, 2013 at 6:34 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 ! -- Vishesh Handa
Re: Releases in 3 months
Hi, [...] (just replying at some point) Two point I want to mention: 1) working in a branch for kdepim is quite painful, as you need actually work on branches of 3 (or sometimes 4) modules: kdepimlibs, kdepim-runtime, kdepim (and akonadi). Keep them up-to-date, merge them at the right point, etc. Developing in master is *much* easier. 2) some people don't like branches, we have to understand it. :) There is no one schedule that will fit all, that's sure. But dismissing once preference with a way that tells him how he SHOULD do, is not really a good. I also find the motivation somewhat contradictory. Yes, you want to provide new features faster, but by cutting down testing time. *Are you sure?* Andras
Re: Re: Releases in 3 months
On Tuesday 09 July 2013 16:12:35 Andras Mantia wrote: I also find the motivation somewhat contradictory. Yes, you want to provide new features faster, but by cutting down testing time. *Are you sure?* Well here we have to ask whether the current testing procedure works. Since the beta got released I have not been running master of the application I maintain. I'm developing ahead in custom branches and don't see a reason why I should switch back to master. I expect that many other developers work in a similar way. Not working ahead in a different branch, means sitting around and doing nothing or wait till a bug report gets in which could be fixed. If you develop in a always releasable master way, the enforced testing period doesn't make any sense. As you say different projects have different development models. If you use master for your development then you need the stabilization time. If you develop in branches, maybe even with an integration branch step before going to master the testing period doesn't give you anything in addition to the larger audience. The testing period slows down the development. Since we are on git, I have started the development of the next release on the day the feature freeze took place. Cheers Martin signature.asc Description: This is a digitally signed message part.
Re: Releases in 3 months
On Tuesday 09 July 2013 16:12:35 Andras Mantia wrote: Hi, [...] (just replying at some point) Two point I want to mention: 1) working in a branch for kdepim is quite painful, as you need actually work on branches of 3 (or sometimes 4) modules: kdepimlibs, kdepim-runtime, kdepim (and akonadi). Keep them up-to-date, merge them at the right point, etc. Developing in master is *much* easier. 2) some people don't like branches, we have to understand it. :) There is no one schedule that will fit all, that's sure. But dismissing once preference with a way that tells him how he SHOULD do, is not really a good. I also find the motivation somewhat contradictory. Yes, you want to provide new features faster, but by cutting down testing time. *Are you sure?* Andras That we are cutting testing time is actually not true, As Laurent has shown in this thread he finished a feature 2 days ago, giving us only a few weeks to test the complete feature. I could apply the same with things that have been merged into master just before the freeze, like for example the new Battery plasmoid.
Re: Releases in 3 months
On Tuesday 09 July 2013 09:36:00 andrea diamantini wrote: My idea about this concerns the way we let other people know aboout new features. I usually read our feature plan (e.g. http://techbase.kde.org/Schedules/KDE4/4.11_Feature_Plan). I think we could add one general page per project, similar to that one, listing: - the feature - the branch where it is developed - the developer - the milestone (eg: kde 4.12, october 2103) where developer thinks to merge/release. IMHO there is a tool that's much better suited for this than a wiki: Bugzilla. Yes, I'm talking about our lovely bug tracking tool. It offers fields for all the information you want. The issue summary briefly describes the feature, the branch could be listed in a custom field or simply in the description, the developer is the assignee, target milestones also exist. What's missing are a few nice predefined queries and standardized milestones to allow querying for them over all projects. But the most important part is that the majority of developers makes use of this. Otherwise, it will be as incomplete as the feature plans. Regards, Ingo signature.asc Description: This is a digitally signed message part.
Re: Releases in 3 months
On Tuesday 09 July 2013, Sven Brauch wrote: I think Nuno's point is very interesting and worth thinking about. To stick with the firefox example, since they started releasing every ortography fix in the settings dialog as a new major version, I think attention in the media to their releases has declined a lot -- nobody cares any more that a new version of firefox was released since it happens every three days. that's my impression too. Alex
Re: Releases in 3 months
On Tuesday 09 July 2013, Andras Mantia wrote: Hi, [...] (just replying at some point) Two point I want to mention: 1) working in a branch for kdepim is quite painful, as you need actually work on branches of 3 (or sometimes 4) modules: kdepimlibs, kdepim-runtime, kdepim (and akonadi). Keep them up-to-date, merge them at the right point, etc. Developing in master is *much* easier. 2) some people don't like branches, we have to understand it. :) There is no one schedule that will fit all, that's sure. But dismissing once preference with a way that tells him how he SHOULD do, is not really a good. +1 Alex
Re: Releases in 3 months
On Monday 08 July 2013 18:59:12 Michael Pyne wrote: On Mon, July 8, 2013 17:45:10 Philip Muskovac wrote: What would at least make my life easier here would be a way to easily get a list of all patches that were applied to a stable release (esp. when someone bothers to backport a fix after the last point release is out). The only way to do that, that I found so far, is filtering out mails from kde- commits, which is neither very easy nor reliable. I'm assuming a variant of 'git log --oneline v4.x.y..KDE/4.x' is not adequate for some reason? Admittedly sometimes we need to be reminded to push the release tags but that seems like it should work for all modules in the kde.org-released software. Good point, that's at least more reliable than filtering mail. It still requires me to have a local clone of some 150 repositories and some extra handling for the svn branch so I would prefer something that doesn't require me to pull all of those just to get some statistics. I'll play with that though, thanks! Philip signature.asc Description: This is a digitally signed message part.
Re: Releases in 3 months
On Monday 08 of July 2013 15:04:40 Àlex Fiestas wrote: Now that kde-workspace and kdelibs are going to be frozen (which in theory means less work for everybody) I'd like to propose a new release schedule to be applied starting with 4.12. 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. If the exception is i18n, well, I guess that most of i18n people would tell you that it will be a pain from translation's point of view. It is true that there is one month before the hard-string freeze and the release, but there is another month before with the soft string freeze, and usually the changes tend to be quite limited in that timeframe. Of course with the new schedule the soft freeze won't be there anymore. As its name indicates, it is a proposal, so please be constructive in the feedback, we can change as many things as we need. From the pure development point of view, imho a shorter release time can be achieved with many more _automated_ tests, not only unit tests. Shortening the release time by one month or one month and a half would be a more reasonable target. IMHO. Ciao -- Luigi
Re: Releases in 3 months
On Monday 08 July 2013 15:14:07 Luigi Toscano wrote: If the exception is i18n, well, I guess that most of i18n people would tell you that it will be a pain from translation's point of view. It is true that there is one month before the hard-string freeze and the release, but there is another month before with the soft string freeze, and usually the changes tend to be quite limited in that timeframe. Of course with the new schedule the soft freeze won't be there anymore. We can establish something like that if that's what i18n people need, can you guys come up with a proposal so we can add it?
Re: Releases in 3 months
Hi, As you know I work a lot on kdepim (but you forgot to ask me if it was a good idea or I didn’t receive mail... :) ) Ok kdelibs and kde-workspace is frozen until KDE SC5 so less work for you for example. But for kdepim we are not a big team, and we have a lot of feature to implement and it’s not possible in 2 months. For example I finished my last feature 2 days ago (sorry I was a lot of feature to do for 4.11) So I disagree to reduce development time to 2 months just because kde- workspace is frozen. And as it’s frozen why reduce development time ? Why increase number of release ? Just to increase number ? So for my point of view it’s not a good idea to reduce time, we will speed to create feature so more bugs because not big period of test, or we will stop to develop feature because we don’t have time to finish. Why is the reason to divide by 2 the release time ? Regards Le lundi 8 juillet 2013 15:04:40 Àlex Fiestas a écrit : 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 ! -- Laurent Montel | laurent.mon...@kdab.com | KDE/Qt Senior Software Engineer KDAB (France) S.A.S., a KDAB Group company Tel. France +33 (0)4 90 84 08 53, Sweden (HQ) +46-563-540090
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
Hi, 2013/7/8 Àlex Fiestas: 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. I like the idea (from the Dolphin development point of view). Most of the changes that went into master during the past months had already been tested rather well before they were merged, and the remaining regressions were found rather quickly by people who use the master branch a lot. Therefore, it would have been nice if some of the improvements could have been shipped to users sooner - quite a few bugs that had been fixed in master (with patches that were IMHO too intrusive for the 4.10 branch) months ago were reported again and again. @Laurent:you say that you have a lot of features to implement, and that this would not be possible with a shorter release schedule. But wouldn't it be possible to implement some of the features for the next version and the rest for the one after that? If you think that you need more time to stabilize a feature in the master branch, then maybe developing the feature in a separate branch and merge it once it's finished might be a good idea? Best regards, Frank
Re: Releases in 3 months
Le lundi 8 juillet 2013 16:11:05 Frank Reininghaus a écrit : Hi, 2013/7/8 Àlex Fiestas: 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. I like the idea (from the Dolphin development point of view). Most of the changes that went into master during the past months had already been tested rather well before they were merged, and the remaining regressions were found rather quickly by people who use the master branch a lot. Therefore, it would have been nice if some of the improvements could have been shipped to users sooner - quite a few bugs that had been fixed in master (with patches that were IMHO too intrusive for the 4.10 branch) months ago were reported again and again. @Laurent:you say that you have a lot of features to implement, and that this would not be possible with a shorter release schedule. But wouldn't it be possible to implement some of the features for the next version and the rest for the one after that? If you think that you need more time to stabilize a feature in the master branch, then maybe developing the feature in a separate branch and merge it once it's finished might be a good idea? 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... Kdelibs and kdebase frozen is good for kdelibs/kdebase dev but it will not impact on kdepim... Best regards, Frank -- Laurent Montel | laurent.mon...@kdab.com | KDE/Qt Senior Software Engineer KDAB (France) S.A.S., a KDAB Group company Tel. France +33 (0)4 90 84 08 53, Sweden (HQ) +46-563-540090
Re: Releases in 3 months
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.
Re: Releases in 3 months
Le lundi 8 juillet 2013 16:19:02 Àlex Fiestas a écrit : I did pasted the link in #kontact and #akonadi a couple of times before sending this email :p I never saw it. And paste on irc is not speak with guy which works several project. The development time is NOT divided and it is NOT limited to 2 months, instead now master will be always open to include features and once every 3 months we'll make a release. So at a specific date you takes code without freeze before ?! For example, if you take a look at this pic: http://community.kde.org/images.community/b/b8/Drawing.png For example between 4.12 branching (15/10) and 4.13 branching (15/01/2014) there will be 3 months. If for whatever reason your feature is not stable to go into 4.13, you can delay it for 4.14 which will happen 3 months after, so not much is changing of how we are doing things now. So you will take code from what ? I will continue to work on master so you will take a broken code ? It’s more logical to freeze master until release otherwise you will release broken code it’s sure. Said it in another way, if you want to keep a 6 months release schedule you can ! this just allow others to ship features more often. Finally, I'm NOT proposing this because kde-workspace and kdelibs are frozen, that's just an opportunity to change the release cycle since it will affect less people. You can read the motivation here: http://community.kde.org/KDE_Core/ReleasesProposal#Motivation The main motivation for this change is to reduce the amount of time between releases and make them simpler, making us able to deliver new features faster to our users while keeping if not improving the current quality. “ deliver new features faster” ? :) new feature broken yes (less time more bugs) Regards Cheers ! On Monday 08 July 2013 15:45:13 you wrote: Hi, As you know I work a lot on kdepim (but you forgot to ask me if it was a good idea or I didn’t receive mail... :) ) Ok kdelibs and kde-workspace is frozen until KDE SC5 so less work for you for example. But for kdepim we are not a big team, and we have a lot of feature to implement and it’s not possible in 2 months. For example I finished my last feature 2 days ago (sorry I was a lot of feature to do for 4.11) So I disagree to reduce development time to 2 months just because kde- workspace is frozen. And as it’s frozen why reduce development time ? Why increase number of release ? Just to increase number ? So for my point of view it’s not a good idea to reduce time, we will speed to create feature so more bugs because not big period of test, or we will stop to develop feature because we don’t have time to finish. Why is the reason to divide by 2 the release time ? Regards -- Laurent Montel | laurent.mon...@kdab.com | KDE/Qt Senior Software Engineer KDAB (France) S.A.S., a KDAB Group company Tel. France +33 (0)4 90 84 08 53, Sweden (HQ) +46-563-540090
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 08 July 2013 10:08:08 Scott Kitterman wrote: 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? From Kubuntu, Rohan, and then he pasted it on kubuntu-devel getting the attention for example of yofel. Additionally I talked with some Fedora people in #solid (Lukas) and Dan Vrátil in jabber. Ofc more feedback is needed, that's why I'm sending this email :p
Re: Releases in 3 months
On Monday 08 July 2013 16:38:02 you wrote: Le lundi 8 juillet 2013 16:19:02 Àlex Fiestas a écrit : I did pasted the link in #kontact and #akonadi a couple of times before sending this email :p I never saw it. And paste on irc is not speak with guy which works several project. Sure, that's why I'm sending the email to kde-core-devel so everybody can be involved in the discussion. Once again, this is a proposal nothing is set in stone (not by far). The development time is NOT divided and it is NOT limited to 2 months, instead now master will be always open to include features and once every 3 months we'll make a release. So at a specific date you takes code without freeze before ?! For example, if you take a look at this pic: http://community.kde.org/images.community/b/b8/Drawing.png For example between 4.12 branching (15/10) and 4.13 branching (15/01/2014) there will be 3 months. If for whatever reason your feature is not stable to go into 4.13, you can delay it for 4.14 which will happen 3 months after, so not much is changing of how we are doing things now. So you will take code from what ? I will continue to work on master so you will take a broken code ? It’s more logical to freeze master until release otherwise you will release broken code it’s sure. Said it in another way, if you want to keep a 6 months release schedule you can ! this just allow others to ship features more often. Finally, I'm NOT proposing this because kde-workspace and kdelibs are frozen, that's just an opportunity to change the release cycle since it will affect less people. You can read the motivation here: http://community.kde.org/KDE_Core/ReleasesProposal#Motivation The main motivation for this change is to reduce the amount of time between releases and make them simpler, making us able to deliver new features faster to our users while keeping if not improving the current quality. “ deliver new features faster” ? :) new feature broken yes (less time more bugs) Not if you only put things in master that have been tested and proven to work. Using the example you gave about the akonadi batch notifications, in the new schedule it would have been merged just after the branching, so we would have 4 months to test it until the release (and the bug was fixed within a month anyway).
Re: Releases in 3 months
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).
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
On Monday 08 July 2013 17:45:10 Philip Muskovac wrote: Hi, With my Kubuntu Developer Hat on, one concern I have is the support timeframe for the planned 4.13 release. Kubuntu 14.04, planned to be released in April 2014 will be a Long Term Support release meaning we'll have to care about it for quite a while. (And it might very well be our last release based on KDE4/Qt4/X11 depending on how things go in the next 1.5 years) I understand that we can have additional point releases if people still find issues that need to be fixed, but with so many short release cycles I expect that the attention for the previous release (even worse: the one before that) will die quickly leaving the distributions with having to do the bugfix backporting. That's ofc. already the case for older releases, but shorter release cycles only amplify the issue as no distribution will change their release cycle to match the new KDE one. (leaving rolling distros aside) Yes, my idea is to have interested parties to maintain whatever branch they are interested on, for example I know that Redhat is still maintaining 3.5.10 branch, which I think it is awesome but we have moved on. We can develop tools to make your life easier (distros) so you can maintain yourselves branches for things like LTS easier, I will be willing to develop such tools if needed. As Scott pointed out, it will also lead to less distributions shipping the same KDE SC release version which leads to less testing efforts for a specific release and more support workload for the distributions later. Take into account that versions will be smaller, meaning less change, less work. What would at least make my life easier here would be a way to easily get a list of all patches that were applied to a stable release (esp. when someone bothers to backport a fix after the last point release is out). The only way to do that, that I found so far, is filtering out mails from kde- commits, which is neither very easy nor reliable. If this is what it takes for having distros in, I propose myself to develop this system ! we can have a BoF in akademy perhaps to design such tool. Cheers !
Re: Releases in 3 months
On Monday 08 of July 2013 18:09:44 Àlex Fiestas wrote: On Monday 08 July 2013 17:45:10 Philip Muskovac wrote: I understand that we can have additional point releases if people still find issues that need to be fixed, but with so many short release cycles I expect that the attention for the previous release (even worse: the one before that) will die quickly leaving the distributions with having to do the bugfix backporting. That's ofc. already the case for older releases, but shorter release cycles only amplify the issue as no distribution will change their release cycle to match the new KDE one. (leaving rolling distros aside) Yes, my idea is to have interested parties to maintain whatever branch they are interested on, for example I know that Redhat is still maintaining 3.5.10 branch, which I think it is awesome but we have moved on. We can develop tools to make your life easier (distros) so you can maintain yourselves branches for things like LTS easier, I will be willing to develop such tools if needed. Well, I can't speak for the company, but RH have the resource to maintain that (subset) of packages in RHEL5. Ditto for the subset of 4.3 in RHEL6. But not all distributions can do it, the community ones do rely more on upstream work. Having something slightly more stable than a 3-month moving target (which pieces that still needs to be coordinated anyway) could help a lot. IMHO. What would at least make my life easier here would be a way to easily get a list of all patches that were applied to a stable release (esp. when someone bothers to backport a fix after the last point release is out). The only way to do that, that I found so far, is filtering out mails from kde- commits, which is neither very easy nor reliable. If this is what it takes for having distros in, I propose myself to develop this system ! we can have a BoF in akademy perhaps to design such tool. ... so first the tool, then the change in the schedule! Ciao -- Luigi
Re: Releases in 3 months
El Dilluns, 8 de juliol de 2013, a les 15:14:07, Luigi Toscano va escriure: On Monday 08 of July 2013 15:04:40 Àlex Fiestas wrote: Now that kde-workspace and kdelibs are going to be frozen (which in theory means less work for everybody) I'd like to propose a new release schedule to be applied starting with 4.12. 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. If the exception is i18n, well, I guess that most of i18n people would tell you that it will be a pain from translation's point of view. It is true that there is one month before the hard-string freeze and the release, but there is another month before with the soft string freeze, and usually the changes tend to be quite limited in that timeframe. Of course with the new schedule the soft freeze won't be there anymore. There will also be less features (since there's less time to develop them), so maybe you don't need that much time. As its name indicates, it is a proposal, so please be constructive in the feedback, we can change as many things as we need. From the pure development point of view, imho a shorter release time can be achieved with many more _automated_ tests, not only unit tests. automated test vs unit test is a technicallity ;-) But agreed, we need more tests and they have to pass. Yes kdepim* people I'm looking at you! Cheers, Albert Shortening the release time by one month or one month and a half would be a more reasonable target. IMHO. Ciao
Re: Releases in 3 months
El Dilluns, 8 de juliol de 2013, a les 15:45:13, laurent Montel va escriure: Hi, As you know I work a lot on kdepim (but you forgot to ask me if it was a good idea or I didn’t receive mail... :) ) Ok kdelibs and kde-workspace is frozen until KDE SC5 so less work for you for example. But for kdepim we are not a big team, and we have a lot of feature to implement and it’s not possible in 2 months. For example I finished my last feature 2 days ago (sorry I was a lot of feature to do for 4.11) Errr, what? You finished a feature 2 days ago? Why? We've been feature frozen for 1 month! Cheers, Albert
Re: Releases in 3 months
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. Cheers, Albert 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
El Dilluns, 8 de juliol de 2013, a les 14:03:19, Scott Kitterman va escriure: 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. That's how it should be, there is people using master daily, you're not supposed to drop unfinished/broken stuff into them. Cheers, Albert Scott K
Re: Releases in 3 months
Le lundi 8 juillet 2013 19:55:46 Albert Astals Cid a écrit : El Dilluns, 8 de juliol de 2013, a les 15:45:13, laurent Montel va escriure: Hi, As you know I work a lot on kdepim (but you forgot to ask me if it was a good idea or I didn’t receive mail... :) ) Ok kdelibs and kde-workspace is frozen until KDE SC5 so less work for you for example. But for kdepim we are not a big team, and we have a lot of feature to implement and it’s not possible in 2 months. For example I finished my last feature 2 days ago (sorry I was a lot of feature to do for 4.11) Errr, what? You finished a feature 2 days ago? Why? We've been feature frozen for 1 month! Yes I finished it 2 days ago, but started 2 months ago. So it was bug fixing, I didn’t create new feature 2 days ago. And I had 6 months to develop it, so think when there is 3 months to do it. Regards. Cheers, Albert -- Laurent Montel | laurent.mon...@kdab.com | KDE/Qt Senior Software Engineer KDAB (France) S.A.S., a KDAB Group company Tel. France +33 (0)4 90 84 08 53, Sweden (HQ) +46-563-540090
Re: Releases in 3 months
On Monday 08 July 2013 20:06:51 Albert Astals Cid wrote: El Dilluns, 8 de juliol de 2013, a les 14:03:19, Scott Kitterman va escriure: 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. That's how it should be, there is people using master daily, you're not supposed to drop unfinished/broken stuff into them. To quote Alex initial mail in this thread: by keeping master always in a releaseable state, Features should not be developed in trunk, though I can understand why some developers do it to get more testing. The concept of integration branches is a solution to this problem: it allows interested people to track the development more closely. Cheers Martin
Re: Releases in 3 months
On Montag, 8. Juli 2013 20:09:47 CEST, laurent Montel wrote: Yes I finished it 2 days ago, but started 2 months ago. So it was bug fixing, I didn’t create new feature 2 days ago. And I had 6 months to develop it, so think when there is 3 months to do it. Hein? And if it took you 10 years or so, ultimately this only gets you more fine grained release cycles, ie. you develop it in 7months, move it to master and then have to wait only 2 months until it gets released instead of 5. If you dump a half broken todo list into master, hoping you'll be able to fix it before the next release you're holding it wrongly in the first place, see the message about ppl. using master on a regular base. The feature btw. still has bugs. I'm dead sure about that. That's not the definition of the feature freeze. The question is: had you added a usable feature before the freeze and 2 days ago fixed a nullptr resolution or similar (bugfix) or was the feature more or less unusable until to days ago (then you technically broke the feature freeze - don't let Albert know in case ;-) Cheers, Thomas
Re: Releases in 3 months
On Montag, 8. Juli 2013 20:30:39 CEST, Martin Graesslin wrote: The concept of integration branches is a solution to this problem +1 They do not only rise testing (beyond your own) but also and especially integrated testing (against feature clashes where A xor B is good and A B miserably fails) Cheers, Thomas
Re: Releases in 3 months
A Segunda, 8 de Julho de 2013 15:04:40 Àlex Fiestas escreveu: 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 ! Juts to share my opinion based on my experience that is different from most usually a release takes time, from a design/marking POV we used to have long conversations about the key messaging, the spirit of the thing what are the selling points, etc etc... It was a alot of work, so much that I started grouping the work in chunks of 2 example the wallpaper is new replace every 2 releases... The problem is that its just to much, I take alot of time maturing a design concept that is scalable, and this process is many times painful. sooo please no it dilutes the marketing work..
Re: Releases in 3 months
On Monday 08 July 2013 20:32:57 Thomas Lübking wrote: On Montag, 8. Juli 2013 20:30:39 CEST, Martin Graesslin wrote: The concept of integration branches is a solution to this problem +1 They do not only rise testing (beyond your own) but also and especially integrated testing (against feature clashes where A xor B is good and A B miserably fails) Eventually we should revise and use: http://community.kde.org/KDE_Core/Platform_11/Git_Workflow But that's another topic, we will need additional infrastructure for doing that right (like a good way of reviewing branches).
Re: Releases in 3 months
El Dilluns, 8 de juliol de 2013, a les 19:32:13, Nuno Pinheiro va escriure: A Segunda, 8 de Julho de 2013 15:04:40 Àlex Fiestas escreveu: 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 ! Juts to share my opinion based on my experience that is different from most usually a release takes time, from a design/marking POV we used to have long conversations about the key messaging, the spirit of the thing what are the selling points, etc etc... It was a alot of work, so much that I started grouping the work in chunks of 2 example the wallpaper is new replace every 2 releases... The problem is that its just to much, I take alot of time maturing a design concept that is scalable, and this process is many times painful. sooo please no it dilutes the marketing work.. Not a marketing expert, but Firefox has been releasing like crazy, https://wiki.mozilla.org/Releases every month it seems, of course it's a totally different domain from ours. Cheers, Albert
Re: Releases in 3 months
A Segunda, 8 de Julho de 2013 20:58:42 Albert Astals Cid escreveu: El Dilluns, 8 de juliol de 2013, a les 19:32:13, Nuno Pinheiro va escriure: A Segunda, 8 de Julho de 2013 15:04:40 Àlex Fiestas escreveu: 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 ! Juts to share my opinion based on my experience that is different from most usually a release takes time, from a design/marking POV we used to have long conversations about the key messaging, the spirit of the thing what are the selling points, etc etc... It was a alot of work, so much that I started grouping the work in chunks of 2 example the wallpaper is new replace every 2 releases... The problem is that its just to much, I take alot of time maturing a design concept that is scalable, and this process is many times painful. sooo please no it dilutes the marketing work.. Not a marketing expert, but Firefox has been releasing like crazy, https://wiki.mozilla.org/Releases every month it seems, of course it's a totally different domain from ours. yes totally diferent, and incomparable in that domain. We dont have that sort of resources... Cheers, Albert
Re: Releases in 3 months
On Monday 08 July 2013 15:04:40 Àlex Fiestas wrote: Now that kde-workspace and kdelibs are going to be frozen (which in theory means less work for everybody) I'd like to propose a new release schedule to be applied starting with 4.12. IMHO that's a bit hasty. There was previous talk about Frameworks, Workspaces and Applications (potentially) having a different release schedule. I don't think anything has been really talked about there yet, but that's something that would definitely play into the current proposal. No matter the outcome of the discussion, you'd want to avoid changing release processes twice within a short period of time, and with releases of KF5 and PW2 sometime next year (assumption) that would certainly be a thing to keep in mind. Basically the idea is to cut testing time and compensate it by keeping master always in a releaseable state, now that two major components are frozen it looks like it is a good time to get used to it. The philosophy is nice, but it's hardly enforcable. So it's something everyone needs to adhere to voluntarily and that may take some convincing, especially when it involves changing current (working) practices. 3 months seems rather ambitious there. Before sending this email I have checked with distro people, i18n people, other developers and almost all of them seemed to either like or be neutral about it (only one exception :p) so I hope that the proposal is not a complete disaster. Any reason not to CC kde-packager or kde-release-team? IMHO they'd be primary audiences for this. Grs, Heinz signature.asc Description: This is a digitally signed message part.
Re: Releases in 3 months
On Monday 08 July 2013 15:04:40 Àlex Fiestas wrote: Now that kde-workspace and kdelibs are going to be frozen (which in theory means less work for everybody) I'd like to propose a new release schedule to be applied starting with 4.12. 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, With my Kubuntu Developer Hat on, one concern I have is the support timeframe for the planned 4.13 release. Kubuntu 14.04, planned to be released in April 2014 will be a Long Term Support release meaning we'll have to care about it for quite a while. (And it might very well be our last release based on KDE4/Qt4/X11 depending on how things go in the next 1.5 years) I understand that we can have additional point releases if people still find issues that need to be fixed, but with so many short release cycles I expect that the attention for the previous release (even worse: the one before that) will die quickly leaving the distributions with having to do the bugfix backporting. That's ofc. already the case for older releases, but shorter release cycles only amplify the issue as no distribution will change their release cycle to match the new KDE one. (leaving rolling distros aside) As Scott pointed out, it will also lead to less distributions shipping the same KDE SC release version which leads to less testing efforts for a specific release and more support workload for the distributions later. What would at least make my life easier here would be a way to easily get a list of all patches that were applied to a stable release (esp. when someone bothers to backport a fix after the last point release is out). The only way to do that, that I found so far, is filtering out mails from kde- commits, which is neither very easy nor reliable. Cheers, Philip
Re: Releases in 3 months
El Dilluns, 8 de juliol de 2013, a les 20:40:59, Heinz Wiesinger va escriure: On Monday 08 July 2013 15:04:40 Àlex Fiestas wrote: Now that kde-workspace and kdelibs are going to be frozen (which in theory means less work for everybody) I'd like to propose a new release schedule to be applied starting with 4.12. IMHO that's a bit hasty. There was previous talk about Frameworks, Workspaces and Applications (potentially) having a different release schedule. I don't think anything has been really talked about there yet, but that's something that would definitely play into the current proposal. No matter the outcome of the discussion, you'd want to avoid changing release processes twice within a short period of time, and with releases of KF5 and PW2 sometime next year (assumption) that would certainly be a thing to keep in mind. Basically the idea is to cut testing time and compensate it by keeping master always in a releaseable state, now that two major components are frozen it looks like it is a good time to get used to it. The philosophy is nice, but it's hardly enforcable. So it's something everyone needs to adhere to voluntarily and that may take some convincing, especially when it involves changing current (working) practices. 3 months seems rather ambitious there. The hardly enforcable argument is a non-argument, our current policies as enforcable as the ones Alex is proposing. Cheers, Albert Before sending this email I have checked with distro people, i18n people, other developers and almost all of them seemed to either like or be neutral about it (only one exception :p) so I hope that the proposal is not a complete disaster. Any reason not to CC kde-packager or kde-release-team? IMHO they'd be primary audiences for this. Grs, Heinz
Re: Releases in 3 months
A Segunda, 8 de Julho de 2013 21:54:02 Albert Astals Cid escreveu: El Dilluns, 8 de juliol de 2013, a les 20:03:14, Nuno Pinheiro va escriure: A Segunda, 8 de Julho de 2013 20:58:42 Albert Astals Cid escreveu: El Dilluns, 8 de juliol de 2013, a les 19:32:13, Nuno Pinheiro va escriure: A Segunda, 8 de Julho de 2013 15:04:40 Àlex Fiestas escreveu: 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 ! Juts to share my opinion based on my experience that is different from most usually a release takes time, from a design/marking POV we used to have long conversations about the key messaging, the spirit of the thing what are the selling points, etc etc... It was a alot of work, so much that I started grouping the work in chunks of 2 example the wallpaper is new replace every 2 releases... The problem is that its just to much, I take alot of time maturing a design concept that is scalable, and this process is many times painful. sooo please no it dilutes the marketing work.. Not a marketing expert, but Firefox has been releasing like crazy, https://wiki.mozilla.org/Releases every month it seems, of course it's a totally different domain from ours. yes totally diferent, and incomparable in that domain. We dont have that sort of resources... Resources for what? Have you seen their announcements? They are basically non existent. yes and they have paid people to do all that stuf, and deliver that, we don't and I supose we don't wnat to deliver on the same tone? Any way, this is just my opininon on an area that completly burned me up... Cheers, Albert Cheers, Albert
Re: Releases in 3 months
On Monday 08 July 2013 16:26:00 laurent Montel wrote: Le lundi 8 juillet 2013 16:11:05 Frank Reininghaus a écrit : Hi, 2013/7/8 Àlex Fiestas: 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. I like the idea (from the Dolphin development point of view). Most of the changes that went into master during the past months had already been tested rather well before they were merged, and the remaining regressions were found rather quickly by people who use the master branch a lot. Therefore, it would have been nice if some of the improvements could have been shipped to users sooner - quite a few bugs that had been fixed in master (with patches that were IMHO too intrusive for the 4.10 branch) months ago were reported again and again. @Laurent:you say that you have a lot of features to implement, and that this would not be possible with a shorter release schedule. But wouldn't it be possible to implement some of the features for the next version and the rest for the one after that? If you think that you need more time to stabilize a feature in the master branch, then maybe developing the feature in a separate branch and merge it once it's finished might be a good idea? 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). It is true that we have a problem with getting people to test branches. But this problem is independant from the release schedule: I believe developing in branches is a good way to work, no matter if releases are created every 3 or 6 months. Having said so, I think Akonadi is a bad example because: - It was a huge change, quite the equivalent of a rewrite - It was affecting personal data When we develop a new feature and want to get more testing, we need to get people to know about it so that they are interested in testing it. If I create a feature but nobody knows about it, it won't get much testing, whether it is in master or on a topic branch. If the feature is developed in master, I have to be careful not to introduce any regression in the existing code before I push any commit, I cannot rely on my group of interested people to spot it because they can't test my work before it reaches master. At feature-freeze time, if my feature is not ready, it is often impossible to revert because the history is mangled with the rest of the work done in master. Furthermore I don't want to revert because it would make me wait for 6 months! If the feature is developed in a topic branch, I should still be careful not to introduce regressions, but I have an extra safety net before it reaches master and can affect people who are not involved in testing my feature. Having it in a branch also gives me a way out: if it turns out the feature is not ready in time for release N, it is possible for me to revert the integration commit (because it has been merged in with --no-ff [1]) and post-pone the feature for the next release. I am still frustrated, but it's not so bad with this new schedule because release N+1 is only 3 months away. I like this new schedule because it should reduce the more-or-less subconscious behavior of let's commit this in master before feature-freeze, it's half broken but I need to commit it now otherwise Albert^Wthe release team is going to (rightfully) yell at me! it's no problem I have more than enough time to fix it before release (famous last words...) Aurélien [1] http://nvie.com/posts/a-successful-git-branching-model/ , section Incorporating a finished feature on develop
Re: Releases in 3 months
On Monday 08 July 2013 22:14:28 Aurélien Gâteau wrote: On Monday 08 July 2013 16:26:00 laurent Montel wrote: Le lundi 8 juillet 2013 16:11:05 Frank Reininghaus a écrit : Hi, 2013/7/8 Àlex Fiestas: 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. I like the idea (from the Dolphin development point of view). Most of the changes that went into master during the past months had already been tested rather well before they were merged, and the remaining regressions were found rather quickly by people who use the master branch a lot. Therefore, it would have been nice if some of the improvements could have been shipped to users sooner - quite a few bugs that had been fixed in master (with patches that were IMHO too intrusive for the 4.10 branch) months ago were reported again and again. @Laurent:you say that you have a lot of features to implement, and that this would not be possible with a shorter release schedule. But wouldn't it be possible to implement some of the features for the next version and the rest for the one after that? If you think that you need more time to stabilize a feature in the master branch, then maybe developing the feature in a separate branch and merge it once it's finished might be a good idea? 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). It is true that we have a problem with getting people to test branches. But this problem is independant from the release schedule: I believe developing in branches is a good way to work, no matter if releases are created every 3 or 6 months. Having said so, I think Akonadi is a bad example because: - It was a huge change, quite the equivalent of a rewrite - It was affecting personal data Akonadi was developed in a branch. Okay, this branch was called master and the stable branch was called KDE 4.4 (IIRC), and, of course, this wasn't nice for people who built everything from master. But we tried to communicate very clearly that master was not to be used for anything expect for KDE PIM development. And, of course, we did consider using a proper branch, but then we would have had to maintain 3 branches: KDE 4.4, Akonadi, and master. Given that we didn't and still don't have enough people to even maintain the Akonadi branch (aka master) I still think that this decision was the only sensible one. The only feasible alternative would have been the deletion of master until the first Akonadi-based alpha release. But all of this is stuff from the past. When we do Akonadi 2 ;-) we'll probably choose a different path. Regards, Ingo signature.asc Description: This is a digitally signed message part.
Re: Releases in 3 months
I think Nuno's point is very interesting and worth thinking about. To stick with the firefox example, since they started releasing every ortography fix in the settings dialog as a new major version, I think attention in the media to their releases has declined a lot -- nobody cares any more that a new version of firefox was released since it happens every three days. Of course this is not the only and not the most important criterion, but I still think an eye should be kept on it. Greetings, Sven 2013/7/8 Ingo Klöcker kloec...@kde.org: On Monday 08 July 2013 22:14:28 Aurélien Gâteau wrote: On Monday 08 July 2013 16:26:00 laurent Montel wrote: Le lundi 8 juillet 2013 16:11:05 Frank Reininghaus a écrit : Hi, 2013/7/8 Àlex Fiestas: 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. I like the idea (from the Dolphin development point of view). Most of the changes that went into master during the past months had already been tested rather well before they were merged, and the remaining regressions were found rather quickly by people who use the master branch a lot. Therefore, it would have been nice if some of the improvements could have been shipped to users sooner - quite a few bugs that had been fixed in master (with patches that were IMHO too intrusive for the 4.10 branch) months ago were reported again and again. @Laurent:you say that you have a lot of features to implement, and that this would not be possible with a shorter release schedule. But wouldn't it be possible to implement some of the features for the next version and the rest for the one after that? If you think that you need more time to stabilize a feature in the master branch, then maybe developing the feature in a separate branch and merge it once it's finished might be a good idea? 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). It is true that we have a problem with getting people to test branches. But this problem is independant from the release schedule: I believe developing in branches is a good way to work, no matter if releases are created every 3 or 6 months. Having said so, I think Akonadi is a bad example because: - It was a huge change, quite the equivalent of a rewrite - It was affecting personal data Akonadi was developed in a branch. Okay, this branch was called master and the stable branch was called KDE 4.4 (IIRC), and, of course, this wasn't nice for people who built everything from master. But we tried to communicate very clearly that master was not to be used for anything expect for KDE PIM development. And, of course, we did consider using a proper branch, but then we would have had to maintain 3 branches: KDE 4.4, Akonadi, and master. Given that we didn't and still don't have enough people to even maintain the Akonadi branch (aka master) I still think that this decision was the only sensible one. The only feasible alternative would have been the deletion of master until the first Akonadi-based alpha release. But all of this is stuff from the past. When we do Akonadi 2 ;-) we'll probably choose a different path. Regards, Ingo
Re: Releases in 3 months
On Mon, July 8, 2013 17:45:10 Philip Muskovac wrote: What would at least make my life easier here would be a way to easily get a list of all patches that were applied to a stable release (esp. when someone bothers to backport a fix after the last point release is out). The only way to do that, that I found so far, is filtering out mails from kde- commits, which is neither very easy nor reliable. I'm assuming a variant of 'git log --oneline v4.x.y..KDE/4.x' is not adequate for some reason? Admittedly sometimes we need to be reminded to push the release tags but that seems like it should work for all modules in the kde.org-released software. Regards, - Michael Pyne signature.asc Description: This is a digitally signed message part.
Re: Releases in 3 months
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. Aleix
