- The file dialog defaulting to $HOME instead of the currently viewed directory when opening it from places like the KIPI Batch Processing plugin.
- No options for image size or file size in the thumbnails
Well, the file dialog problem doesn't seem to exist in 4.4 (I don't know if it existed in 4.3 or earlier as I don't have an installation to test on) and the image and file sizes are now available in the thumbnail views in trunk, which means that will be part of Gwenview that comes with the KDE Software Compilation v4.5 this summer.
What I found really interesting was how difficult it was to get the use case for why that information was needed in the thumbnail out of the people who wanted that feature. Aurelien wasn't sure why they were needed and I had to do a fair amount of careful reading and picking through comments to figure it out. Here is a formulation of the use case:
"Carla have a folder with several pictures in it that she will be posting to a blog
as part of an article (or to some other resource that puts a constraint on the
size of the image, the file or both). She looks through the folder to see which
images are too large and scales those that are above those limits."
Coming up with use cases isn't hard, but it isn't perfectly simple either. When you a clear use case is provided, sans rant and extraneous "analysis of the bigger picture", work gets done quicker. Not every use case will result in the change hoped for, but it really does increase the odds. Even when a use case is deemed "out of scope" it helps document much clearer what that scope is.
14 comments:
And of course inflexible freeze policies mean it'll take at least 6 months for users to actually benefit from that 4.5 improvement. Add to that:
* 2-3 weeks for Fedora as 4.n.0 updates tend to stay in updates-testing that long as we invariably need to fix regressions our users report to us (or get them fixed by upstream developers).
* 2 months for Kubuntu as they don't push version updates to their releases at all and they release 2 months after KDE.
* potentially much longer for more conservative distros.
We really need a way to bring those usability improvements to users faster. Distro backports are not an ideal solution as:
* some upstream developers, including you, frown upon them.
* we will not pick up translations for the new strings. Some distros "solve" this by having their own translation teams work on KDE software, but that just leads to duplicated work.
* several distros just refuse to backport things outright (and they really shouldn't have to).
So as far as I can tell, this leaves just relaxed feature and string freezes in upstream KDE SC as a possible solution. Thus, IMHO, that'd be the only good solution for this problem.
4.4 has not even been released yet and users are already being told to wait for 4.5 for much needed usability improvements, surely that can't be the answer!
I think Kevin Kofler has an interesting point.
Should KDE consider changing its policies for stable releases?
Because you always read on the planet how a developer made this tiny little change that didn't make it into 4.$almost-out, and how you will have to wait 6+ months to get something that might be a handful of lines of code.
Would it be possible to also have small open/string frozen periods for each point release where small-ish features could be added, and not just bug fixes? Or is that the path to madness?
Fully agreed with Kevin and Anjo. I'm very much for decoupling most applications from KDE's release cycle.
I've summed this up here, if you are interested:
Package Splitting and Release Cycles
Regards, Mark.
"4.4 has not even been released yet and users are already being told to wait for 4.5 for much needed usability improvements, surely that can't be the answer!"
That is exactly what I think everytime when new main release of KDE SC is coming out.
I know users who are waiting new release. I hear a lot from them about bugs and features what they want. I suggested almost every time that they should make the account in bugs.kde.org and give wishes etc there. But that is really such hard place to use by avarage joe and the bugreporter from application Help menu is not helping things either. (Maybe time to make a KDE application to manage the reporting and storing user own reports more like GHNS styled way?). And they are too lazy or does not have skills to do mockups for KDE brainstorming area on forums.kde.org.
I follow everyday the planetkde and people ask from me about new features what is coming to new KDE SC release and it is usually pleasure to tell about them. But then same time it is always sad that I can not tell them that what problems have be found just before release and what did not make there.
And I feel personally that it leaves me in very bad position because I know that they are going to regret some of the features and have again same ideas "This could be done like this and this needs fixing". And then I need to listen that and I feel bad because I need to tell them "You need to wait 6 months to get that feature completed".
So I have stopped to telling people about new KDE SC release stuff etc. Because there is always a information what did not make there and what you need to wait for 6 months.
It is very great that we can read these development ideas and stuff. But really, it does not sound well at all that you hear that very important feature of technology X was moved to next release because developer did not make it for in time but was just few hours away from pushing the code before freezing.
It just makes so sad to think "Okay, so on next summer I can truly use that technology".
Like right now again with Nepomuk or some other technologies. There are some key features what are not available on any other platform and they could really push the KDE SC out to wider use. But it is so sad to know it so many times get pushed 6-12 months forward.
I remember the Mark Shuttleworth idea to have a planned release dates for all projects. And I disagree with him totally. I believe that open source power is that we can release early and often. So we can really get the users feedback from the work that has done. That means we should move more work for the distributors to actually choose the correct codes. What makes it one way harder for upstream to maintain the brand of quality.
Should the 6 months limit be adding a new technologies or applications. And keep 1 month release as improving and bugfixing existing ones? What good we could get with that?
Maybe the switch to Git would allow to have more stable release. I think Sebas even wrote a post about that I think http://vizzzion.org/?blogentry=815
I dont think that Git would help to make a more stable release, because I can not find such problems with stableness but just missing features what are done but did not just make them to the freezing.
So maybe with Git it would be easier for others to pull the wanted parts from playground etc?
The problem is the entire desktop DE is treated as a single release which is *FINE* twice a year. Rest of the year individual kde applications should be updating and be able to be updated independently.
If dolphin adds some basic 4.4.1 feature that doesn't need any kde-libs changes I should be able to easily get this update even if I don't use trunk.
Basically KDE4 needs to be split up. So many distros already hack KDE up into what ever parts they want anyway. Instead I say we just let them join whatever pkgs they want instead of splitting.
There has been some discussion on this issue already on the mailing-lists.
I think having a more relaxed release policy has its pros and cons. The pros are well discussed. On the cons side, stability is something which is on the fence. Every development model has freeze deadlines. This _forces_ the developers to work on getting rid of as much bugs as possible before a release rather than work on new features.
If a lot of applications decouple from the KDE's release and tagging process, then you put the work (release and tagging) work on the distributions.
I personally cannot wait for the next version. That is why I live on the opensuse's unstable 'weekly trunk snapshots' repo. But on the con side, I face a potential "release depression" :-) This is when I do not see any major difference between KDE SC 4.4 RC 2 and KDE SC 4.4.
first off, categorizing adding two new checkboxes to a menu as a "much needed usability improvements" is hyperbole. we could easily categorize nearly all changes to our software as such, implying that we should have to compress all future work down to one release cycle that released yesterday. that is wishful thinking, not realistic project management. there will always be something "in the next release", and when those releases happen twice a year it's going to naturally have the effect that where it feels like "the carrot is always just in front of us".
leading up to releases, we are trying to keep more focus on the release itself (something that has come up explicitly on the kde-promo mailing list and which we have general consensus on), but there will be "what we are doing in 4.5" blog entries all the same. this one was a direct follow up to a user issue.
i think it's pretty sad that we address an issue and the response is "not going to be released fast enough!" it easily leads to a situation where developers feel that there is no pleasing "you people" and that is highly demotivating.
now, that's me speaking from my decade+ of personal management experience rather than the developer who wrote that patch. ime, it's deadly to a team to never recognize milestones when they are arrive, or to meet each milestone with a complaint.
ok, now, on to the REAL question: should the SC be radically split up?
i think some of the comments have made good arguments for the benefits of doing so.
i don't think the costs have been similarly covered, however. since everything has strengths and challenges, costs and benefits, it's very important to cover both sides equally when making such large decisions. i hope you'll agree with that? :)
the costs of splitting up the SC are many. they include:
* translation becomes much less straightforward, as the translation teams now have to track dozens and dozens of individual projects instead of one big one (+ the extragear apps)
* release engineering costs are far higher since instead of doing one big release, we're doing dozens and dozens of smaller ones. we don't have any release engineering manpower to spare as it is.
* for small packaging teams (Slackware is a good, though not only, example) this would be a deal breaker. this is, actually, a primary reason why Slackware dropped GNOME in favour of KDE. one big set of packages released on a consistent schedule means lower package bookkeeping overhead. for larger packaging teams (or ones with terrific tools?) this isn't as big (or even any) issue. i don't think it's fair to discount the huge number of regional distributions that use KDE, however. it is one of our quiet strengths.
* we will lose much of the developer network-effect. KDE Games is a very good example: it's one community that ebbs and flows and which works on many of the games in parallel. splitting each game into its own repository will gain them nothing, and will likely only result in fewer cross-app efforts leading to an overall slower pace of development.
* promo of dozens of small apps is really, really hard to do. big releases gives us the opportunity to get very wide coverage. we would completely lose this with a split.
now, there are some apps that do not have the above characteristics. they are large enough in terms of developer teams and user base to easily manage their own release engineering, promo, etc. Amarok is a good example of such an app (and i do think that Marky's involvement with Amarok really colours his assessment of the situation :)
so, there are huge costs and some benefits. no matter how often we release, there will always be a lag in delivery to the user. so that benefit is actually somewhat less than we might expect / hope for. the biggest benefit, i think, would be development cycles that match the natural rhythm of different app teams.
more on that in the next comment ;)
with the move to git, i really would like to see a workflow adopted that helps us separate the development cycle from the release cycle.
an "always stable" branch that is our mainline for packaging, with "hotter" branches or development that get sync'd down to mainline at regular intervals at the discretion of the individual application would be terrific imho.
it would allow apps to decide their own rhythm for development without being tied so aggressively to what is really a release engineering effort (which includes things like packaging, translating and promo). the two are not the same, and trying to optimize them simultaneously will always have compromise writ large into the results.
some apps will almost certainly continue to develop exactly as they do now: directly into a "next release" branch and then dumped once every six months into the release branch. most developers and testers will follow the "next release" branch just as we do now.
but some apps (and i think Plasma falls into this category) would adopt more aggressive schedules (as Amarok has already done) and do shorter devel iterations with a more regular sync-to-mainline shedule.
then, if these apps have the release engineering power, they can do interim releases on their own from mainline.
downtreams could also pull more "randomly" from the mainline release branch if they wish (so they could get this gwenview change sooner if they desire, because it's safe enough that it could pretty easily be pushed down to the release branch quickly after 4.4.0).
meanwhile, SC release engineering would still be able to say "no string changes in the release branch during weeks X-Y to provide a safe translation window", "we are putting together a SC release on this date", "we are doing a patch release to the SC on that date", etc.
i think it is ultimately feasible to design a simple branch and procedures policy that isn't hard to follow and which separate development cycles and release cycles as much as possible so that we can optimize parallel solutions for both with a lot less compromise.
this should avoid most of the costs covered in my last comment and get most of the benefits of a complete split.
what do you think about that idea?
Aaron,
You couldn't have put it better. What you are describing sounds just like what I was imagining. I have read the mailing-list for this topic (latest thread I could find) before it turned into what git can and can't do. I felt like an ass posting my last comment without a bit more research or effort put into it. I was on a time constraint tho and knew if I didn't post something I would get back on track and forget I was drifting over your blog.
The other advantage I see is not crapping my pants each time I upgrade KDE4 to the next release. Majority of the time no thought is put in upgrade paths and it leads to me needing to ensure I have a fresh backup of ~/.kde so I can delete it and install the update then bring back in my bookmarks,kmail,krdc etc settings.
Akonadi about broke me on 4.4rc1, I fought with that thing for 3 days until I finally just deleted every reference to Akonadi from my users home folder and let kde reconfigure it all on a fresh login. This was problematic cause Kmail couldn't be opened until Akonadi was started. Akonadi worked perfectly under a new user account but complained about errors and missing resource agents that were clearly available. Even the Akonadi devs were limited help on an upgrade path. Then to top it off I was told to not start adding resources unless I wanted them destroyed as Akonadi was really only meant for KAddressbook, that really made my day.
I am loving Nepomuk and can't wait to try the Akonadi virtual folder integration once its stable. Unless I am mistaken and I can use virtual folders without Akonadi at all.
@ Aaron: "i think it's pretty sad that we address an issue and the response is "not going to be released fast enough!" it easily leads to a situation where developers feel that there is no pleasing "you people" and that is highly demotivating."
I think it would help a lot that developers would blog about new functions after the release and not before it. Then readers do not get the feeling that they would get half baked cake. ;)
Of course, I have started to think that best way is not to read blogs until release.
Still I same way believe that tight release schedule is not so good. As open source have always be "release when ready" with the "release early, release often" models. And every developer should make their own time so that they enjoy about it because it is their own time what the spend.
Maybe we got lots of problems when the project grows bigger than just one application? There is no time and man power to communicate between developers? Maybe it is just that because on big companies, you start soon having just meetings after meetings about meetings and the actual work leaves behind.
Maybe it would help a lot if there would be 1 developer for every 100 users what could translate, fix small bugs etc. Exactly what the bugs.kde.org tries to solve with the idea assigning smaller bugs to younger coders.
There is just too many "maybe's".
I've been using the 4.4 RC's on my desktop and I think they are great (apart from 2 small issues, but that's nitpicking :)
"We want all the features, yesterday!" isn't really a working plan, but I think Aaron's idea of shorter devel iterations for the apps that want to and are able to might prove to be an interesting compromise between "all apps release alone" and "all together, at the same time". It would also cut back on backporting, which is also an issue with a lot of distros, because they could ship a new-ish version of an application instead of being "stuck" between releasing "6 month old news" and testing builds of the "new stuff".
I don't agree with Fri13 saying that developers shouldn't blog about new stuff before a release that won't be coming until the next release. Communication is essential in large oss projects, and developers don't just blog for users, they blog for whoever they want, including other developers, so they shouldn't hold back from doing so. It's through communication that we become aware of what surrounds us, allowing people to exchange ideas and come up with new ones.
Post a Comment