Re: Review Request 111335: Fix for one of the oldest KIO bugs: multiple dialogs when KIO encounters SSL errors
On July 5, 2013, 2:23 p.m., David Faure wrote: kio/kio/scheduler.cpp, line 766 http://git.reviewboard.kde.org/r/111335/diff/2/?file=167766#file167766line766 Please don't put this code in scheduler.cpp I'm trying to properly split core and gui aspects of KIO in frameworks, and scheduler is definitely core, while kmessagebox is definitely not. Please find a way to separate the two. Dawit Alemayehu wrote: So how were you planning to separate the core and gui aspects in frameworks? Without this patch KIO::Scheduler will still be linking against gui libraries because of its use of KIO::Slave. Perhaps if I know how you were planning to perform the split, I could follow the same approach to resolve this issue and it would be one less thing you have to deal with. David Faure wrote: I'm separating core/gui stuff for jobs using delegates and delegate extensions and factories. (the trick is that the kiowidgets library can register stuff using code that runs automatically, just by linking to the library, see Q_CONSTRUCTOR_FUNCTION in kio/jobuidelegate.cpp) But nothing is done yet for the messagebox stuff in Slave. So this is good timing, let's come up with a solution (which we could probably apply to both branches). Context: SlaveInterface::messageBox() is called by kioslaves, in the application process. Let's brainstorm. I can think of 3 solutions on top of my head: 1) Defining an interface in kiocore and implementing it in both libs. The core implementation would have to return Cancel every time, for lack of a possibility to interact with the user. Apps could still reimplement that interface to give predefined answers. 2) Propagating the call up to the job, which can then use the delegate mechanism for showing the messagebox (with again a canned reply for core-only code) 3) Delegating the messagebox to a separate process, e.g. kuiserver. This is the KDE3 solution, actually. The commit that removed that (8d6f7d340e0) says that modal messagebox were blocking kuiserver. But we could use non-modal messageboxes instead. Either with a blocking dbus call (using dbus transactions in kuiserver), or with real async everywhere. Problem: what if kuiserver isn't available. Or what if you wanted a core-only command-line tool which would not interact with the user. Any other ideas? Any input on the above possibilities? I kind of like number 2, to reduce the number of interfaces being used to call gui stuff from kiocore. Dawit Alemayehu wrote: I do not have any additional ideas than the one you presented here. I like #2 as well. I am not fond of the separate process solution at all. One cannot really associate the dialog with the client (read: window). We have hacks that attempt to simulate that, but they are still hacks ; so I prefer solution #2 as well. David Faure wrote: OK then, let's go for that. Do you plan on implementing it, or should I put it on my own TODO list? Dawit Alemayehu wrote: I can do it since I want to resolve this bug and have already started the process so to speak. But I need your help to get started. What should I look at to understand how the separation of concerns (core/gui) work in frameworks? I see how jobuidelegate works in KIO under KDE 4 and seems to be a straight forward step for me to move the current code there, but I suspect that class has changed some in frameworks to do the split, correct? David Faure wrote: In frameworks, KIO's JobUiDelegate still exists, but implements new interfaces (now it derives from both KDialogJobUiDelegate and JobUiDelegateExtension) so that its kio-specific API (askFileRename/askSkip/...) can be called from within core-only KIO jobs. So if you need to add new API to KIO::JobUiDelegate in kde4 that's fine, I'll just add it to JobUiDelegateExtension in frameworks so that it can still be called. Dawit Alemayehu wrote: Hmm... I can only move the GUI related portion of the code I wrote out of the scheduler. Everything else has to remain there in order for this to work since the message box is much like the password server. In fact, if this separation works, we should also switch the password server to this model in frameworks. Anyhow, this is my current plan: 1.) Move the messagebox portion of the current code, effectively the else statement in UserNotificationHandler::processRequest, to jobuidelegate. 2.) Move the code from step one to KIO::JobUiDelete::askUser(...)??? 2.) Change the else statement in UserNotificationHandler::processRequest to call either r-slave-job()-requestMessageBox or r-slave-job()-ui()-askUser. Probably the former one which itself will end up calling the latter one. Does this seem reasonable to you? Any
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: Review Request 111335: Fix for one of the oldest KIO bugs: multiple dialogs when KIO encounters SSL errors
On July 5, 2013, 2:23 p.m., David Faure wrote: kio/kio/scheduler.cpp, line 766 http://git.reviewboard.kde.org/r/111335/diff/2/?file=167766#file167766line766 Please don't put this code in scheduler.cpp I'm trying to properly split core and gui aspects of KIO in frameworks, and scheduler is definitely core, while kmessagebox is definitely not. Please find a way to separate the two. Dawit Alemayehu wrote: So how were you planning to separate the core and gui aspects in frameworks? Without this patch KIO::Scheduler will still be linking against gui libraries because of its use of KIO::Slave. Perhaps if I know how you were planning to perform the split, I could follow the same approach to resolve this issue and it would be one less thing you have to deal with. David Faure wrote: I'm separating core/gui stuff for jobs using delegates and delegate extensions and factories. (the trick is that the kiowidgets library can register stuff using code that runs automatically, just by linking to the library, see Q_CONSTRUCTOR_FUNCTION in kio/jobuidelegate.cpp) But nothing is done yet for the messagebox stuff in Slave. So this is good timing, let's come up with a solution (which we could probably apply to both branches). Context: SlaveInterface::messageBox() is called by kioslaves, in the application process. Let's brainstorm. I can think of 3 solutions on top of my head: 1) Defining an interface in kiocore and implementing it in both libs. The core implementation would have to return Cancel every time, for lack of a possibility to interact with the user. Apps could still reimplement that interface to give predefined answers. 2) Propagating the call up to the job, which can then use the delegate mechanism for showing the messagebox (with again a canned reply for core-only code) 3) Delegating the messagebox to a separate process, e.g. kuiserver. This is the KDE3 solution, actually. The commit that removed that (8d6f7d340e0) says that modal messagebox were blocking kuiserver. But we could use non-modal messageboxes instead. Either with a blocking dbus call (using dbus transactions in kuiserver), or with real async everywhere. Problem: what if kuiserver isn't available. Or what if you wanted a core-only command-line tool which would not interact with the user. Any other ideas? Any input on the above possibilities? I kind of like number 2, to reduce the number of interfaces being used to call gui stuff from kiocore. Dawit Alemayehu wrote: I do not have any additional ideas than the one you presented here. I like #2 as well. I am not fond of the separate process solution at all. One cannot really associate the dialog with the client (read: window). We have hacks that attempt to simulate that, but they are still hacks ; so I prefer solution #2 as well. David Faure wrote: OK then, let's go for that. Do you plan on implementing it, or should I put it on my own TODO list? Dawit Alemayehu wrote: I can do it since I want to resolve this bug and have already started the process so to speak. But I need your help to get started. What should I look at to understand how the separation of concerns (core/gui) work in frameworks? I see how jobuidelegate works in KIO under KDE 4 and seems to be a straight forward step for me to move the current code there, but I suspect that class has changed some in frameworks to do the split, correct? David Faure wrote: In frameworks, KIO's JobUiDelegate still exists, but implements new interfaces (now it derives from both KDialogJobUiDelegate and JobUiDelegateExtension) so that its kio-specific API (askFileRename/askSkip/...) can be called from within core-only KIO jobs. So if you need to add new API to KIO::JobUiDelegate in kde4 that's fine, I'll just add it to JobUiDelegateExtension in frameworks so that it can still be called. Dawit Alemayehu wrote: Hmm... I can only move the GUI related portion of the code I wrote out of the scheduler. Everything else has to remain there in order for this to work since the message box is much like the password server. In fact, if this separation works, we should also switch the password server to this model in frameworks. Anyhow, this is my current plan: 1.) Move the messagebox portion of the current code, effectively the else statement in UserNotificationHandler::processRequest, to jobuidelegate. 2.) Move the code from step one to KIO::JobUiDelete::askUser(...)??? 2.) Change the else statement in UserNotificationHandler::processRequest to call either r-slave-job()-requestMessageBox or r-slave-job()-ui()-askUser. Probably the former one which itself will end up calling the latter one. Does this seem reasonable to you? Any
Re: KDE/4.11 branched what to do with kde-workspace?
On Wednesday 10 July 2013 01:25:06 Andras Mantia wrote: On Tuesday, July 09, 2013 11:45:39 PM Martin Graesslin wrote: * master is opened for feature development and will lead to Plasma Workspaces 2 (or whatever the release will be called in the end). Does this mean that kde-workspace in master will exists, but with a different content (and I assume unstable)? we have not yet talked about which branch we use. But just because we switch to Qt 5 doesn't mean it will become unstable ;-) Does it mean the KDE 4.11 branch of kde-workspace will be needed even for master users (or for KDE 4.11)? master is just a name one specifies in kdesrc-buildrc ;-) I don't think that this really matters to anyone except the developers of kde-workspace. And if we do important changes I'm sure e.g. Aaron will blog about it. Cheers Martin
Re: KDE/4.11 branched what to do with kde-workspace?
On Wed, July 10, 2013 1:19 pm, Martin Graesslin wrote: On Wednesday 10 July 2013 01:25:06 Andras Mantia wrote: On Tuesday, July 09, 2013 11:45:39 PM Martin Graesslin wrote: * master is opened for feature development and will lead to Plasma Workspaces 2 (or whatever the release will be called in the end). Does this mean that kde-workspace in master will exists, but with a different content (and I assume unstable)? we have not yet talked about which branch we use. But just because we switch to Qt 5 doesn't mean it will become unstable ;-) Does it mean the KDE 4.11 branch of kde-workspace will be needed even for master users (or for KDE 4.11)? master is just a name one specifies in kdesrc-buildrc ;-) I don't think that this really matters to anyone except the developers of kde-workspace. And if we do important changes I'm sure e.g. Aaron will blog about it. For those who don't use kdesrc-build, knowing which branch to use does matter. kdesrc-buildrc and blogging are fine, but there needs to be an simple way later on to know which branch to use, without having to search through config files which you don't have a copy of, or past blogs. -- David Jarvie. KDE developer. KAlarm author - http://www.astrojar.org.uk/kalarm
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: KDE/4.11 branched what to do with kde-workspace?
On Wednesday, July 10, 2013 02:12:41 PM David Jarvie wrote: On Wed, July 10, 2013 1:19 pm, Martin Graesslin wrote: On Wednesday 10 July 2013 01:25:06 Andras Mantia wrote: On Tuesday, July 09, 2013 11:45:39 PM Martin Graesslin wrote: * master is opened for feature development and will lead to Plasma Workspaces 2 (or whatever the release will be called in the end). Does this mean that kde-workspace in master will exists, but with a different content (and I assume unstable)? we have not yet talked about which branch we use. But just because we switch to Qt 5 doesn't mean it will become unstable ;-) Does it mean the KDE 4.11 branch of kde-workspace will be needed even for master users (or for KDE 4.11)? master is just a name one specifies in kdesrc-buildrc ;-) I don't think that this really matters to anyone except the developers of kde-workspace. And if we do important changes I'm sure e.g. Aaron will blog about it. For those who don't use kdesrc-build, knowing which branch to use does matter. kdesrc-buildrc and blogging are fine, but there needs to be an simple way later on to know which branch to use, without having to search through config files which you don't have a copy of, or past blogs. And there are people using my tool (build-tool). There are people using their own script and some even doing it manually. There are the packagers who need to know. Not sure if there are distros that track our development versions. Linux from scratch or so? Because of that it should be announced. BIG TIME. I am not hopeful because this is the one area we fail to get consistent all the time. Announcing our version control strategy, changes and anything related. I know because i am subscribed to all relevant mailing lists and still fail to catch many moves and changes. Only when stuff fails to compile i notice. Mike -- Michael Jansen http://michael-jansen.biz
Re: KDE/4.11 branched what to do with kde-workspace?
On Mittwoch, 10. Juli 2013 15:34:43 CEST, Michael Jansen wrote: Because of that it should be announced. BIG TIME. I'd suggest to keep master as it is and develop PWv2 in a new branch. Those who want to develop on or use it will hopefully find it and others can continue to use master as it is. (And where important bugfixes etc. for 4.12 can go) Maybe have a git hook to limit write access to master to a fistful of developers to ensure nobody accidentally pushes features there instead into PWv2. Announcing policy anywhere (mygreat.blog - yeah, dot.kde, k-c-d) but through controlling it by code will fail for sure. kde-workspace has far more and more casual commiters than kdelibs. One of us will stumble. Cheers, Thomas
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: openSUSE packagers' take on the 3 month release cycle
Hi, one of Debian's Qt/KDE packagers here. Àlex Fiestas wrote: On Monday 08 July 2013 20:35:22 Luca Beltrame wrote: (apologies for breaking your threading, but I'm not subscribed to k-c-d; in fact, please CC me with replies, thanks!) Currently, the people working on openSUSE packages are against the proposal. A detailed explanation follows. First and foremost, the KDE packaging in openSUSE is almost completely community driven. This means that most of the work is done by volounteers which handle what they can in their (limited) time. Faster releases may mean worse packaging and increased maintenance (and I think this is also an issue w/most non rolling distros). Well, KDE is also ran by volunteers doing what they can in their limited time. If we can achieve 3 month releases, meaning developing features, promo, i18n, etc I'm sure you can package it as well. My question to you (all distro people) is, what can we do to help? and what is more interesting, what can you do, distro people, to help yourselves? I see at least a duplicated effort across all distros which is adding/figuring out new dependencies. Can't we coordinate on that so everybody life is easier? First of all, thanks for this nice thread, it's awesome to see it well discussed :) WRT licenses: whatever we can do to improve the situation here will surely help us **a lot**, no matter what the schedule is. The same can be applied to dependencies, of course. Also, what can we do, upstream to make this happen? so far what I read in this thread is This doesn't work perfectly for us, -1, what I'd love to read is a This as it is won't work for us, but if we do X and Y and Z, maybe we can do it. There are some factors that you can't simply manage, distro side. For example, every new major upstream release requires a transition in our side, to allow build-dependencies be correctly rebuilt. And that requires distro coordination (in our case, with the release team). We are currently waiting for an ACK to push KDE 4.10 to unstable. For more than a month. Of course, this is not somthing the you folks can help (at least as far as I understand it), but shortening the release cycle will surely not help us.
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: KDE/4.11 branched what to do with kde-workspace?
El Dimecres, 10 de juliol de 2013, a les 15:55:01, Thomas Lübking va escriure: On Mittwoch, 10. Juli 2013 15:34:43 CEST, Michael Jansen wrote: Because of that it should be announced. BIG TIME. I'd suggest to keep master as it is and develop PWv2 in a new branch. Those who want to develop on or use it will hopefully find it and others can continue to use master as it is. (And where important bugfixes etc. for 4.12 can go) But there's not going to be a kde-workspace 4.12 as announced a while ago. Cheers, Albert Maybe have a git hook to limit write access to master to a fistful of developers to ensure nobody accidentally pushes features there instead into PWv2. Announcing policy anywhere (mygreat.blog - yeah, dot.kde, k-c-d) but through controlling it by code will fail for sure. kde-workspace has far more and more casual commiters than kdelibs. One of us will stumble. Cheers, Thomas
Re: KDE/4.11 branched what to do with kde-workspace?
On Mittwoch, 10. Juli 2013 21:58:34 CEST, Albert Astals Cid wrote: Those who want to develop on or use it will hopefully find it and others can continue to use master as it is. (And where important bugfixes etc. for 4.12 can go) But there's not going to be a kde-workspace 4.12 as announced a while ago. No idea what's announced but that's silly and will just cause confusion downstream - we also have kdelibs 4.10 atm and 4.11 soon while technically that's still 4.7 or whatever. There'll have to be (minor) patches to kde-workspace (you cannot keep shipping known and fixable crashes), thus new tarballs and shipping kdelibs 4.13.2, workspace 4.11.12 (depending on kdelibs 4.13.2) and kde-runtime 4.13.2 does not sound very reasonable to me. Cheers, Thomas
Re: KDE/4.11 branched what to do with kde-workspace?
On Mittwoch, 10. Juli 2013 22:39:01 CEST, Scott Kitterman wrote: I thought you said in the 3 month release cycle discussion that every module I think this discussion in unrelated to the new release cycle thread. Frozen workspace and the question what to do with the branches in kde-workspace is real! now! ;-) Cheers, Thomas
Re: Re: KDE/4.11 branched what to do with kde-workspace?
On Wednesday 10 July 2013 22:39:29 Thomas Lübking wrote: On Mittwoch, 10. Juli 2013 21:58:34 CEST, Albert Astals Cid wrote: Those who want to develop on or use it will hopefully find it and others can continue to use master as it is. (And where important bugfixes etc. for 4.12 can go) But there's not going to be a kde-workspace 4.12 as announced a while ago. No idea what's announced but that's silly and will just cause confusion downstream - we also have kdelibs 4.10 atm and 4.11 soon while technically that's still 4.7 or whatever. There'll have to be (minor) patches to kde-workspace (you cannot keep shipping known and fixable crashes), thus new tarballs and shipping kdelibs 4.13.2, workspace 4.11.12 (depending on kdelibs 4.13.2) and kde-runtime 4.13.2 does not sound very reasonable to me. I expected that we would just tag 4.12.0 and so on from the 4.11 branch. Whether it's master or branch doesn't really matter. I agree that this is something we learned from kdelibs that we need to keep the releases going even if they do not contain new features. Cheers Martin signature.asc Description: This is a digitally signed message part.
