Re: Review Request 111480: Notifications are shown multiple times
--- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/111480/ --- (Updated July 12, 2013, 7:08 a.m.) Review request for kde-workspace and Marco Martin. Changes --- Fix Copy finished side-effect by checking source... Description --- Do not replace notifications with same summary and body Here a patch similar to this colibri commit. See REVIEW: 110745 http://quickgit.kde.org/?p=colibri.gita=commith=9a96b9512579215bcddd8fc88041fdd7130dbb0f This addresses bug 313440. http://bugs.kde.org/show_bug.cgi?id=313440 Diffs (updated) - plasma/generic/applets/notifications/contents/ui/Notifications.qml ce3f8de Diff: http://git.reviewboard.kde.org/r/111480/diff/ Testing --- Working here Thanks, Cedric Bellegarde
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: Review Request 111335: Fix for one of the oldest KIO bugs: multiple dialogs when KIO encounters SSL errors
--- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/111335/#review35879 --- Looks good. I share your concern about the new public API, how about moving the method from SimpleJob to SimpleJobPrivate? And marking the job uidelegate one as internal? - David Faure On July 11, 2013, 11:37 p.m., Dawit Alemayehu wrote: --- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/111335/ --- (Updated July 11, 2013, 11:37 p.m.) Review request for kdelibs. Description --- The attached patch addresses one of the oldest bugs in KIO. Due to the muti-process nature of KIO, if any of the ioslaves encounter something that requires user input, the user might end up getting prompted multiple times. The best example of this is SSL error warnings sent to the client by kio_http. The patch completely resolves this problem using the same approach as kpasswdserver, but without the need for an additional kded process. This addresses bugs 154100 and 265228. http://bugs.kde.org/show_bug.cgi?id=154100 http://bugs.kde.org/show_bug.cgi?id=265228 Diffs - kio/CMakeLists.txt 4854829 kio/kio/job.cpp 096a7d7 kio/kio/jobclasses.h d771cfe kio/kio/jobuidelegate.h 25e0728 kio/kio/jobuidelegate.cpp 85679c2 kio/kio/slaveinterface.h 4bfcec8 kio/kio/slaveinterface.cpp aa0fc44 kio/kio/slaveinterface_p.h e31ec5e kio/kio/usernotificationhandler.cpp PRE-CREATION kio/kio/usernotificationhandler_p.h PRE-CREATION Diff: http://git.reviewboard.kde.org/r/111335/diff/ Testing --- Visit a site that throws up SSL warnings and causes KIO to show more than one error dialog. Thanks, Dawit Alemayehu
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
Usability Workshops
Heya folk! One of our resident usability experts, Björn Balazs, will team up with yours truly to host a Usability Workshop on Monday at Akademy, provided we can find people interested in them. The plan will be more or less as follows: * We center the session around one or a small number of applications. This will be decided, as much as possible, in advance of the sessions. * Björn will introduce the sessions with some theory about user tests and usability. * we find a volunteer from the audience who isn't experienced with the application in question * we let a developers from the application guide the user through the app, asking questions (avoiding suggestive ones). Björn guides the developer through this. * afterward we discuss the results. Perhaps the developers can hack on their app now, in any case: everybody did learn something. I have booked 10:30-12:30 and 14:00-16:00 on Monday room B3 for two sessions. With great demand we could add sessions (or have less if nobody cares). From you folks, especially the developers who participate in Akademy, I'd like to know if you're interested in having your application be the victim. A few things to note: * Ideally, at least 2 developers are present * Ideally, it is possible to find people unfamiliar with the application (very hard for Dolphin and Gwenview, for example) * This type of usability testing tends to show the Real Bad Stuff™, it's not terribly good at fine tuning an already quite good application. So who's up for having his/her app checked out? Note that nobody replied on the akademy-attendee list so unless people sign up here, we'll cancel the workshop. Cheers, Björn and Jos signature.asc Description: This is a digitally signed message part.
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: KDE/4.11 branched what to do with kde-workspace?
On Friday, July 12, 2013 10:19:45 Andras Mantia wrote: On Thursday, July 11, 2013 07:41:37 AM Martin Gräßlin wrote: 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. With kdelibs didn't we switch back to branch and tag it from master even though master is closed (which was not true due to some bugfixes)? It was let’s strive for accuracy: * master was never closed to bugfixes * there were 2 main reasons the branched-kdelibs shifted back to master- kdelibis: * people were too stubborn and too (willfully) uninformed to understand why this was a useful thing and just kept pelting it with stop energy at every possible opportunity. * it took so long to get frameworks 5 on track, that eventually the pressure simply won out those two point played into each other. this was a non-technical failure, so don’t look for technical justification from the kdelibs branch experience. if your point is that people will again be stubborn and ignorant and sabotage the effort, then we can discuss how to avoid that. *older*. Ask David Faure how many times he got complaints to merge the branch to master... had this actually been done according to the original plan, kdelibs would have remained at version 4.x (where x = 7?) and we would now be up to 4.7.some relatively big number and we’d never have merged into master. ever. this was a mistake. we can learn from that. we don’t need to repeat mistakes made when we try again. For this reason I suggest to keep master as now and branch from there every time and for a bigger refactoring use a branch (yes, this is the opposite I there’s a problem with that. in 6-12 months time, we’ll need to merge all of that back into master. or, i suppose, abandon master forever. if bug fixes continue on in master, it will be nightmare to do the merge as the PW2 code will have drifted signficantly in two ways: the code base is going to be reorganized (in a similar fashion to what is happening for frameworks 5 right now) and the changes in some components will be significant making changes in the stable branch (be it master or not) completely innaplicable to the newer work. thankfully, there’s an easier way to do this: * do all stable releases from a stable branch * make all bug fix changes in the stable branch * do all individual refactorings in branches * merge those branches down to master as they are ready * release from master in a year’s time and call it Plasma Workspaces 2 (or whatever) the challenge with this is means people who aren’t actually doing the work need to be supportive in some pretty small ways, namely: be ok with drawing releases from the 4.11 branch. that really can’t be too much to ask? -- Aaron J. Seigo signature.asc Description: This is a digitally signed message part.
Re: KDE/4.11 branched what to do with kde-workspace?
On Thursday, July 11, 2013 12:37:39 Frank Reininghaus wrote Merging frameworks into master in kdelibs has the following disadvantages from my point of view (besides the makes it harder for i agree; the window for doing this closed a while ago. we’ve made some poor decisions that we need to live with now, but we don’t need to make it even worse. so +1 for leaving kdelibs going in the trajectory it currently is. -- Aaron J. Seigo signature.asc Description: This is a digitally signed message part.
Re: KDE/4.11 branched what to do with kde-workspace?
On Wednesday, July 10, 2013 22:39:29 Thomas Lübking wrote: 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. regardless of what happens in 4.x for x = 12 ... .. what do you think is going to happen wiith Plasma Workspaces 2? if anyone still thinks that there will be any guarantee that plasma workspaces will release with the exact same version #s and use the exact same release cycle as Frameworks 5, let me fix that for you: it won’t. -- Aaron J. Seigo signature.asc Description: This is a digitally signed message part.
Re: KDE/4.11 branched what to do with kde-workspace?
On Wednesday, July 10, 2013 15:34:43 Michael Jansen wrote: Because of that it should be announced. BIG TIME. I am not hopeful because agreed. so what i’d like to see is a definitive listing of all the places that this should be announced and in what form. since i’ve gotten this wrong enough times in the past, i’d appreciate a listing of: * email lists to send an announcement to * blogs and forums that should get a posting * which web sites should be targeted for articles along with a suggested re-posting frequenc for each. i’ve tried numerous combinations in the past, and innevitably someone in this very community complains about not having heard about it. so if the people in the community can offer some direction, i’m happy to oblige and make sure all the suggested bases are covered. -- Aaron J. Seigo signature.asc Description: This is a digitally signed message part.
Re: KDE/4.11 branched what to do with kde-workspace?
On Tuesday, July 9, 2013 23:45:39 Martin Graesslin wrote: If someone wants to do a 4.12 release from kde-workspace module it can be branched from the 4.11 branch. fwiw, i take no responsibility for branches other than the 4.11 one. if someone feels the burning urge to make a release 4.12, i’d stringly recommend that the relevant changes necessary be done in that branch. at most a tag to called 4.12 or whatever. but please don’t branch things unless you are signing up to take over maintenance (and will explain to people why there won’t be a long term 4.11 release) the workflow implications as well as the communication impacts have been considered in making this decision. calling the sixth (or whatever) stable release of the 4.11 branch “4.12.0” is misleading and dilutes the message of “we’re doing a long term series of releases based on this feature-frozen code base”. having a multitude of branches that the maintainers are not actually tracking is dangerous. people have been extremely receptive to the idea of a long series of point releases based on the 4.11 workspaces code. if packagers have real and demonstrable challenges with having kde-workspace 4.11.x installed with a kde-runtime 4.12, please let us know with clear explanations along with the expected impacts of those challenges. i have no interest in the “but that’s the way we’ve always done it” argument, but am open to real issues we may not be aware of at this point. -- Aaron J. Seigo signature.asc Description: This is a digitally signed message part.
Re: Review Request 111480: Notifications are shown multiple times
--- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/111480/#review35898 --- plasma/generic/applets/notifications/contents/ui/Notifications.qml http://git.reviewboard.kde.org/r/111480/#comment26576 is the duplicated notification always guaranteed to be the first one? it may make more sense to have a hash of source/appName/summary/body/actions for each notification stored in a (Q)set and then checked for? - Aaron J. Seigo On July 12, 2013, 7:08 a.m., Cedric Bellegarde wrote: --- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/111480/ --- (Updated July 12, 2013, 7:08 a.m.) Review request for kde-workspace and Marco Martin. Description --- Do not replace notifications with same summary and body Here a patch similar to this colibri commit. See REVIEW: 110745 http://quickgit.kde.org/?p=colibri.gita=commith=9a96b9512579215bcddd8fc88041fdd7130dbb0f This addresses bug 313440. http://bugs.kde.org/show_bug.cgi?id=313440 Diffs - plasma/generic/applets/notifications/contents/ui/Notifications.qml ce3f8de Diff: http://git.reviewboard.kde.org/r/111480/diff/ Testing --- Working here Thanks, Cedric Bellegarde
Re: KDE/4.11 branched what to do with kde-workspace?
On Friday, July 12, 2013 05:52:02 PM Aaron J. Seigo wrote: On Wednesday, July 10, 2013 15:34:43 Michael Jansen wrote: Because of that it should be announced. BIG TIME. I am not hopeful because agreed. so what i’d like to see is a definitive listing of all the places that this should be announced and in what form. since i’ve gotten this wrong enough times in the past, i’d appreciate a listing of: * email lists to send an announcement to * blogs and forums that should get a posting * which web sites should be targeted for articles along with a suggested re-posting frequenc for each. i’ve tried numerous combinations in the past, and innevitably someone in this very community complains about not having heard about it. so if the people in the community can offer some direction, i’m happy to oblige and make sure all the suggested bases are covered. I personally think there is no combination that will ever work. We have to many part time developers and people with limited resources. And all channels we currently use have to many content so its impossible to catch up after being away for some bigger time. Both Mailing lists and planet kde i mean. I guess we need a dedicated channel for these announcements. Either a smaller blog aggregator / dedicated blog or use a dedicated mailing list for that stuff. But i fear it will never be enough. There are to many people involved that don't know all processes we agree upon. I am quite sure the core devs will do it mostly right. That's why i would prefer convention over announcement. Don't break the expectations of your users. Don't go away from processes that people learned to take for granted unless there is a VERY good reason. Especially if nothing breaks for those thinking the old process is still valid. Example given: Build-tool failed to follow the repository switch of amarok (it was announced. i missed it because of being very busy) and continued to build the old stuff for months without problems. Mike -- Michael Jansen http://michael-jansen.biz
Re: KDE/4.11 branched what to do with kde-workspace?
On Fri, July 12, 2013 4:42 pm, Aaron J. Seigo wrote: * there were 2 main reasons the branched-kdelibs shifted back to master- kdelibis: * people were too stubborn and too (willfully) uninformed to understand why this was a useful thing and just kept pelting it with stop energy at every possible opportunity. That's unnecessarily negative - why do you think that people would willfully remain uninformed? Much more likely is that they would be innocently uninformed due to not having seen announcements. Even for people who saw the announcements, it's still all too easy (even with the best of intentions) for old habits to take over and to accidentally use master again. This happened to me more than once. On Fri, July 12, 2013 5:08 pm, Michael Jansen wrote: On Friday, July 12, 2013 05:52:02 PM Aaron J. Seigo wrote: On Wednesday, July 10, 2013 15:34:43 Michael Jansen wrote: Because of that it should be announced. BIG TIME. I am not hopeful because agreed. so what i'd like to see is a definitive listing of all the places that this should be announced and in what form. since i've gotten this wrong enough times in the past, i'd appreciate a listing of: * email lists to send an announcement to * blogs and forums that should get a posting * which web sites should be targeted for articles along with a suggested re-posting frequenc for each. i've tried numerous combinations in the past, and innevitably someone in this very community complains about not having heard about it. so if the people in the community can offer some direction, i'm happy to oblige and make sure all the suggested bases are covered. I personally think there is no combination that will ever work. We have to many part time developers and people with limited resources. And all channels we currently use have to many content so its impossible to catch up after being away for some bigger time. Both Mailing lists and planet kde i mean. I guess we need a dedicated channel for these announcements. Either a smaller blog aggregator / dedicated blog or use a dedicated mailing list for that stuff. But i fear it will never be enough. There are to many people involved that don't know all processes we agree upon. I am quite sure the core devs will do it mostly right. That's why i would prefer convention over announcement. Don't break the expectations of your users. Don't go away from processes that people learned to take for granted unless there is a VERY good reason. Especially if nothing breaks for those thinking the old process is still valid. Example given: Build-tool failed to follow the repository switch of amarok (it was announced. i missed it because of being very busy) and continued to build the old stuff for months without problems. I agree. I'm sure that this must have caught out innocent people more often than willful miscreants. -- David Jarvie. KDE developer. KAlarm author - http://www.astrojar.org.uk/kalarm
Re: Review Request 111335: Fix for one of the oldest KIO bugs: multiple dialogs when KIO encounters SSL errors
--- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/111335/ --- (Updated July 13, 2013, 1:30 a.m.) Review request for kdelibs. Changes --- - Removed the new public from SimpleJob. Added it to SimpleJobPrivate instead. - Changed the JobUiDelegate API into multiple simple APIs that directly correspond to the KMessageBox API. Description --- The attached patch addresses one of the oldest bugs in KIO. Due to the muti-process nature of KIO, if any of the ioslaves encounter something that requires user input, the user might end up getting prompted multiple times. The best example of this is SSL error warnings sent to the client by kio_http. The patch completely resolves this problem using the same approach as kpasswdserver, but without the need for an additional kded process. This addresses bugs 154100 and 265228. http://bugs.kde.org/show_bug.cgi?id=154100 http://bugs.kde.org/show_bug.cgi?id=265228 Diffs (updated) - kio/CMakeLists.txt 4854829 kio/kio/job_p.h 0c1fd64 kio/kio/jobuidelegate.h 25e0728 kio/kio/jobuidelegate.cpp 85679c2 kio/kio/scheduler.cpp 802f8b8 kio/kio/slaveinterface.h 4bfcec8 kio/kio/slaveinterface.cpp aa0fc44 kio/kio/slaveinterface_p.h e31ec5e kio/kio/usernotificationhandler.cpp PRE-CREATION kio/kio/usernotificationhandler_p.h PRE-CREATION Diff: http://git.reviewboard.kde.org/r/111335/diff/ Testing --- Visit a site that throws up SSL warnings and causes KIO to show more than one error dialog. Thanks, Dawit Alemayehu
