Linux Tag has been a great show, and I've really enjoyed it. The presentations and booths have been terrific and I managed to meet up with several projects that I haven't had enough time with recently.
The two talks I did went well, and the other KDE people's presentations were seriously great. Till's presentation on Akonadi started with the new logo splashed across the projection on the wall behind him and it's just so stunningly beautiful; a great visual for a really excellent project, which Till does a great job in representing. Sebas' talk on beautiful features in KDE4 reminded me how beautiful (and not just visually) KDE4 has become.
I also managed to switch over to the KDE4 version of Kontact this week, leaving just one other major KDE3 application I'm still using on a daily basis (konversation) and two minor ones (krandrtray and knetworkmanager). I'm hoping KDE4 replacements for all three of those will be available by the time 4.2 rolls up.
Kontact is really taking shape; there are some small oddnesses to it at the moment (such as no visual feedback on dragging as to the current drop target folder) but it works solidly in 4.1 Beta1, migrated nearly all my settings perfectly from the KDE3 version and the new painting style for events in korganizer is really rather beautiful.
Unfortunately, not all is roses. I have one more day after today in the city and then it's back to the airports for me as I trek back to Canada. I'm also dealing with a fairly unending stream of sillyness from my blog entry on desktop icons, which now has over 200 comments and has spawned a couple of really poorly informed replies in the blogosphere.
It's been a really good reminder of the importance to keep things simple in my blog so as not to confuse the heck out of people as well as how emotionally attached many people are to the desktop we are working on.
Live and learn.
While it has been tempting to just stop communicating at all about these things (people can't complain ignorantly about things they don't know about ;) that runs counter to my belief that things should be developed openly.
It has been very rewarding, however, to not only read many positive responses to that blog entry but even more so to watch people coming by the KDE booth at Linux Tag here, use the demo systems and be really happy with it.
It's also been great to meet some faces in the project that I haven't met before, as well as see some old friends I haven't seen in a while. All the same, I can't wait to be back home. I got the P-man a bunch of stickers for his laptops, as well. =)
Saturday, May 31, 2008
Friday, May 23, 2008
more 4.1 sexiness: marble
KDE is about more than just Plasma. A lot more, to the tune of several hundred shipped binaries (libraries, executables) that comprise an amazing number of applications. These applications often "live together" in thematic package, such as games or office or media. The educational package, produced by the awesome community that is the KDE Edu team, includes a desktop globe called Marble.
When I read Torsten's blog the other day about Open Street Map (OSM) integration, I just had to check this out for myself. Verdict: it works. Look, there's even the pub across the street from my house:
Even though this is new code that is still being worked on, the zooming and panning are already pretty smooth. It will be fun to see just how good it gets, really. I've heard rumour of integrating the OSM search as well.
So now Marble not only handles multiple projections (globe, flat and mercator thus far), provides multiple overlay options (countries, geographical features, temperatures, nighttime, ...), shows the stars in "space" when you zoom out, supports the KML format (as made popular by Google Earth), can load GPS traces, lets you measure distances, print maps, etc, etc, etc ... it also lets you browse right down to the street level.
I'm a huge fan of OSM because maps are, IMHO, a very important set of data and they've found a sustainable way to make that information Freely (as in Freedom) available to all. Best of all, if the maps in your area aren't great you can help them fix that by contributing GPS routes and annotating existing data.
Now OSM has a kick ass and highly portable rich client user interface thanks to Marble. Marble works very well on Linux, BSD, OpenSolaris, Microsoft Windows and MacOS X operating systems and on a variety of hardware form factors (desktop, laptop, UMPC, tablet). It also ships by default with the KDE desktop environment; what other mainstream desktop ships with a 3D globe? =)
Massive props to the people who have breathed life into both the Marble and OSM projects.
(Awesome side note: Marble is the first hit on Google when querying "mac os desktop globe". It's "only" third when searching for "macos desktop globe" though.)
When I read Torsten's blog the other day about Open Street Map (OSM) integration, I just had to check this out for myself. Verdict: it works. Look, there's even the pub across the street from my house:
Even though this is new code that is still being worked on, the zooming and panning are already pretty smooth. It will be fun to see just how good it gets, really. I've heard rumour of integrating the OSM search as well.
So now Marble not only handles multiple projections (globe, flat and mercator thus far), provides multiple overlay options (countries, geographical features, temperatures, nighttime, ...), shows the stars in "space" when you zoom out, supports the KML format (as made popular by Google Earth), can load GPS traces, lets you measure distances, print maps, etc, etc, etc ... it also lets you browse right down to the street level.
I'm a huge fan of OSM because maps are, IMHO, a very important set of data and they've found a sustainable way to make that information Freely (as in Freedom) available to all. Best of all, if the maps in your area aren't great you can help them fix that by contributing GPS routes and annotating existing data.
Now OSM has a kick ass and highly portable rich client user interface thanks to Marble. Marble works very well on Linux, BSD, OpenSolaris, Microsoft Windows and MacOS X operating systems and on a variety of hardware form factors (desktop, laptop, UMPC, tablet). It also ships by default with the KDE desktop environment; what other mainstream desktop ships with a 3D globe? =)
Massive props to the people who have breathed life into both the Marble and OSM projects.
(Awesome side note: Marble is the first hit on Google when querying "mac os desktop globe". It's "only" third when searching for "macos desktop globe" though.)
no more desktop icons in 4.1
(Now that I have your attention with that title ... ;)
I just committed a change to the default desktop containment that removes desktop icon support. Yes, it has finally happened ... no more splattering icons from the "desktop" folder across the screen. Buh-bye.
Let me pause while some of you get all worked up and ready to punch the "Add comment" link to flame me to kingdom come.
<pause>
Ok, so here's what a Plasma desktop looks like with a fresh user account right now (well, minus the trashcan):
In the screenshot you can see krunner doing its thing as well as the new panel layout. There are some icon sizing issues remaining to be worked out in the panel as you can probably see, but it's getting closer.
"Hey!" I hear you say, "I see icons on that desktop!" That's quite right. (And, I must say, you are quite observant today. ;) So what was a mumbling about earlier then when I said the icons were gone?
Well, we now have a folder view applet courtesy of Frederik Höglund. It can view any folder you want, including the desktop folder. You can also set a filter, making it possible to, for instance, view just images or whatever. It uses KIO so you can view remote folders as well. You can drag items to and from it, delete files, scroll, etc. It lines everything up in a nice grid and uses the same drawing routines that Dolphin, Konqueror, KRunner and others use from kdelibs for the icons.
You can have 0, 1 or more of these folder views in your plasma, all viewing different (or the same, I suppose) folders. You can put them on different activity areas (aka "desktop containments") as well.
Chani has been working on the activity area support and now has a rather crazy setup on her laptop with 10 or so containments of various sorts. She's also made it possible to switch around between them (as well as applets in side them) using the keyboard only ... but I'll let her blog more about that herself. Suffice it to say for now that you can easily build project or activity specific sets of files, folders, launchers and widgets and swap between them easily.
In the future we'll have a little label in the folderview telling you which folder you are looking at, it will turn into an icon with a menu listing in horizontally constrained containments (e.g. panels), it will be collapsible on the desktop with a single click (it's already resizable, rotatable and removable) and you will be able to use it as a containment itself.
That last bit is important: it means that you can have an Old Skool(tm) desktop with an icon mess if that's what you really, really want. So don't bother with that flame, nobody has anything to complain about. ;)
In 4.2 we'll be separating context menus and background rendering from containments so that those functionalities can be easily shared; so while in 4.1 you can set the folder view as your desktop containment ... it's not going to be as pretty as it will be in 4.2. In 4.2 it will be completely seamless, whereas right now you'll get a "nice" wallpaper based on the applet background svg. Call it the Model T wallpaper: any colour you want, as long as it's the applet background ;)
This is all yet another set of steps in the move away from a file-centric system and towards one that is flexible enough to work the way you do rather than making you work the way the computer thinks you should.
I just committed a change to the default desktop containment that removes desktop icon support. Yes, it has finally happened ... no more splattering icons from the "desktop" folder across the screen. Buh-bye.
Let me pause while some of you get all worked up and ready to punch the "Add comment" link to flame me to kingdom come.
<pause>
Ok, so here's what a Plasma desktop looks like with a fresh user account right now (well, minus the trashcan):
In the screenshot you can see krunner doing its thing as well as the new panel layout. There are some icon sizing issues remaining to be worked out in the panel as you can probably see, but it's getting closer.
"Hey!" I hear you say, "I see icons on that desktop!" That's quite right. (And, I must say, you are quite observant today. ;) So what was a mumbling about earlier then when I said the icons were gone?
Well, we now have a folder view applet courtesy of Frederik Höglund. It can view any folder you want, including the desktop folder. You can also set a filter, making it possible to, for instance, view just images or whatever. It uses KIO so you can view remote folders as well. You can drag items to and from it, delete files, scroll, etc. It lines everything up in a nice grid and uses the same drawing routines that Dolphin, Konqueror, KRunner and others use from kdelibs for the icons.
You can have 0, 1 or more of these folder views in your plasma, all viewing different (or the same, I suppose) folders. You can put them on different activity areas (aka "desktop containments") as well.
Chani has been working on the activity area support and now has a rather crazy setup on her laptop with 10 or so containments of various sorts. She's also made it possible to switch around between them (as well as applets in side them) using the keyboard only ... but I'll let her blog more about that herself. Suffice it to say for now that you can easily build project or activity specific sets of files, folders, launchers and widgets and swap between them easily.
In the future we'll have a little label in the folderview telling you which folder you are looking at, it will turn into an icon with a menu listing in horizontally constrained containments (e.g. panels), it will be collapsible on the desktop with a single click (it's already resizable, rotatable and removable) and you will be able to use it as a containment itself.
That last bit is important: it means that you can have an Old Skool(tm) desktop with an icon mess if that's what you really, really want. So don't bother with that flame, nobody has anything to complain about. ;)
In 4.2 we'll be separating context menus and background rendering from containments so that those functionalities can be easily shared; so while in 4.1 you can set the folder view as your desktop containment ... it's not going to be as pretty as it will be in 4.2. In 4.2 it will be completely seamless, whereas right now you'll get a "nice" wallpaper based on the applet background svg. Call it the Model T wallpaper: any colour you want, as long as it's the applet background ;)
This is all yet another set of steps in the move away from a file-centric system and towards one that is flexible enough to work the way you do rather than making you work the way the computer thinks you should.
Wednesday, May 21, 2008
plasma and documentation
As Ade has been blogging over the last few days, Shane-of-FSFE has been working his way through KDE4.
Shane notes what is currently our biggest achiles heel for users: documentation. The website is woefully out of date, there is no user documentation to speak of, and even our techbase tutorials are lagging. It's really pathetic and I feel really bad about the situation.
We've been busy coding and arting (is that a word? =) and bug fixing and communicating and strategizing and ... all the things that go into making the product rock. But this has come at the expense of any documentation being written.
We do have a FAQ hidden away in our developer coordination wiki page that is being kept up by a fearless band of wikiers (is that a word?!) but really that's just not enough.
Plasma introduces a number of rather new (for the end user, anyways) concepts and we're really adding a whole pile more in 4.1. We're finally getting to the point where the vision is starting to be visible.
But the documentation isn't there to support it. For 4.2 we must have user documentation, developer tutorials and that welcome plasmoid that tells the user things like "hey, those cashews you see? you can configure things with them!" It should then let you click on an action pad that will cause the cashews to throb a bit so the user notices them.
This will be a major goal for 4.2, just as getting panel configuration, scriptability, WoC and krunner together was for 4.1.
But until then, I humbly offer my public apologies to all the users out there who we've completely screwed over by the lack of documentation. *sob* *grovel*
To Shane: I appreciate your patience and I've been watching your blog. Much love, I'll try and repay it in words.
I'm considering going away for a week this fall to somewhere nice and quiet (forests? mountains? rivers? oceans?) and do nothing but write in solitude.
And in case you are wondering, I have no time until 4.1.0 is out to walk anyone through things to make Plasma docu possible.
p.s. Shane: The P-man has three stickers on his laptop so far: two are KDE themed and the third one is the FSFE logo. Keep on rocking in the Free world! =)
Shane notes what is currently our biggest achiles heel for users: documentation. The website is woefully out of date, there is no user documentation to speak of, and even our techbase tutorials are lagging. It's really pathetic and I feel really bad about the situation.
We've been busy coding and arting (is that a word? =) and bug fixing and communicating and strategizing and ... all the things that go into making the product rock. But this has come at the expense of any documentation being written.
We do have a FAQ hidden away in our developer coordination wiki page that is being kept up by a fearless band of wikiers (is that a word?!) but really that's just not enough.
Plasma introduces a number of rather new (for the end user, anyways) concepts and we're really adding a whole pile more in 4.1. We're finally getting to the point where the vision is starting to be visible.
But the documentation isn't there to support it. For 4.2 we must have user documentation, developer tutorials and that welcome plasmoid that tells the user things like "hey, those cashews you see? you can configure things with them!" It should then let you click on an action pad that will cause the cashews to throb a bit so the user notices them.
This will be a major goal for 4.2, just as getting panel configuration, scriptability, WoC and krunner together was for 4.1.
But until then, I humbly offer my public apologies to all the users out there who we've completely screwed over by the lack of documentation. *sob* *grovel*
To Shane: I appreciate your patience and I've been watching your blog. Much love, I'll try and repay it in words.
I'm considering going away for a week this fall to somewhere nice and quiet (forests? mountains? rivers? oceans?) and do nothing but write in solitude.
And in case you are wondering, I have no time until 4.1.0 is out to walk anyone through things to make Plasma docu possible.
p.s. Shane: The P-man has three stickers on his laptop so far: two are KDE themed and the third one is the FSFE logo. Keep on rocking in the Free world! =)
krunner quicky update
I put together a quick screencast to update one of our artists on what's happened to krunner in the last day. It's not really meant as a promo piece, but you get to hear me meander about through the new things that popped up in the last 24 hours so I figured maybe one or two of you might want to check it out as well. Still lots of polishing left, particularly in the artwork dpt. Enjoy the ogg-iliciousness, all 5MB of it.
Tuesday, May 20, 2008
more gem vs ttm vs classic benchmarking
Thomas_Hellström posted some more benchmarks comparing various i915 drivers this time with a newer version of GEM, some new tests and on yet a third machine.
krunner for 4.1
I have said a few times that the user interface for krunner in 4.0.x was not meant to be a production interface. It was actually something I threw together in 10 minutes one day to test things and then it just stuck around. Ugh! Just under the wire for the feature freeze, we managed to get a new UI that we've been working on for a bit into svn for 4.1.
There are a number of things left to do, including:
These are all pretty minor items compared to we have done already though, and will be pretty easily achieved before the deep freeze. So what have we done? We've rovided a much nicer experience including more speed, solid stability, better usability (hooray for the tab key!), more configurability (including a UI to select which runners get used) and fun eye candy.
The people who have contributed signficantly to this release include Ryan Bitanga (threading work, configuration), Jordi Polo (abstracting out the management code, various improvements in efficiency), Riccardo Iaconelli (user interface and design), David Bettio (user interface) and yours truly. Thanks to everyone who's helped make krunner a bit shinier for 4.1.
Oh, before a forget, here's a screencast in ogg format (in which I forgot to mention that different kinds of matches have different colours; I was tired, so shoot me =):
There are a number of things left to do, including:
- single runner mode (this is supported in libplasma, just not in the UI)
- fixed query mode (ditto)
- selected item presentation improvements (bigger, comlete text, float to top)
- put back access to per-match options in the UI
- replace the ugly pushbuttons with something cuter
- paging (so when there are more items than fit you can easily move between them)
- short text below individual match icons
- better default artwork
- respect the desktop graphical effects setting (to turn off all the glitz)
- consolidate the animation timers into just one (probably via
PhaseAnimator) - slightly better timeouts for updates so we don't icon dance toooo much
- documentation
These are all pretty minor items compared to we have done already though, and will be pretty easily achieved before the deep freeze. So what have we done? We've rovided a much nicer experience including more speed, solid stability, better usability (hooray for the tab key!), more configurability (including a UI to select which runners get used) and fun eye candy.
The people who have contributed signficantly to this release include Ryan Bitanga (threading work, configuration), Jordi Polo (abstracting out the management code, various improvements in efficiency), Riccardo Iaconelli (user interface and design), David Bettio (user interface) and yours truly. Thanks to everyone who's helped make krunner a bit shinier for 4.1.
Oh, before a forget, here's a screencast in ogg format (in which I forgot to mention that different kinds of matches have different colours; I was tired, so shoot me =):
Monday, May 19, 2008
pretty.
Spring/summer is here, time for the flowers to bloom and the earth to teem with new life. Keeping with the times, KDE is about to go into feature freeze tomorrow so we can have a Summer child in the form of KDE 4.1 and all sorts of prettyness is showing up. Two of my favourites:
Marco unveils the innovative new panel settings UI, complete with a screen cast. Artwork, layouting details, corner cases and discoverability enhancements will be worked on for 4.1, but here it is:
My other fave-of-theday is Akonadi's new logo: it is hot, hot and more hot:
The two colour and small size versions even rock!
Marco unveils the innovative new panel settings UI, complete with a screen cast. Artwork, layouting details, corner cases and discoverability enhancements will be worked on for 4.1, but here it is:
My other fave-of-theday is Akonadi's new logo: it is hot, hot and more hot:
The two colour and small size versions even rock!
i915 and GEM
So I read over at Phoronix about Intel's new GEM framework and how it has sped up the i915 driver 50-60%. As a user primarily of Intel graphics chips this is great news.
Unfortunately, there's some not so great news.
Those performance comparisons are against the current i915 driver which has no memory management, so of course if one adds some memory management to it you should be getting an improvement.
This begs the question of what would happen if the i915 driver using GEM was benchmarked against a different memory management system, such as the open, stable and available TTM. TTM was passed up, despite being available, open and complete because the i915 team at Intel decided they didn't like it and they came up with their own solution and called it GEM.
TTM is complicated internally: it has support for a lot of rather "interesting" memory models that exist out there in the real world. This means GEM, while lacking that complexity, is useful for only a subset of hardware approaches out there. It does covers the lion's share of today's open source drivers, but I doubt that will hold true forever. This is problematic for obvious reasons, since hardware support is .. well .. pretty important.
And how do the two approaches stack up performance wise? Here are some numbers I've seen comparing i915 drivers built with GEM and TTM on the same hardware running the same benchmarks:
So while GEM offers improvements to the current i915 driver by adding memory management where none before existed, it really falls short of what is possible. In some cases, such as the texture uploading cases, massively short to the point of making some of the things we're considering doing not very tenable with this driver.
If other drivers are built on top of GEM instead of TTM (or something similarly well written) this pattern will repeat: drivers will improve somewhat, but still lag significantly behind what they should be doing. Worse, there may well be hardware that appears that simply won't work with GEM without it growing significantly in internal complexity (leading one to wonder if the end result won't be simply a hard road to rewriting TTM).
This is all complicated by the fact that TTM from DRM's dev branch hasn't made it into the Linux kernel yet despite being completed around a year ago, making it hard for people to rely on it (since it is up to individual distros to include this on their own). These bits of code have been sent for review but not integration into the Linux kernel. It's all a bit of an odd and unfortunate situation.
Hopefully whatever ends up in the kernel is flexible enough to allow something like TTM to occur so we can really go crazy with the graphics development on top of X.
Please x.org people, don't let your users down: Do The Right Thing(tm) and use the best available open technology.
Unfortunately, there's some not so great news.
Those performance comparisons are against the current i915 driver which has no memory management, so of course if one adds some memory management to it you should be getting an improvement.
This begs the question of what would happen if the i915 driver using GEM was benchmarked against a different memory management system, such as the open, stable and available TTM. TTM was passed up, despite being available, open and complete because the i915 team at Intel decided they didn't like it and they came up with their own solution and called it GEM.
TTM is complicated internally: it has support for a lot of rather "interesting" memory models that exist out there in the real world. This means GEM, while lacking that complexity, is useful for only a subset of hardware approaches out there. It does covers the lion's share of today's open source drivers, but I doubt that will hold true forever. This is problematic for obvious reasons, since hardware support is .. well .. pretty important.
And how do the two approaches stack up performance wise? Here are some numbers I've seen comparing i915 drivers built with GEM and TTM on the same hardware running the same benchmarks:
Test GEM TTM
openarena 52.8 fps 61.0 fps
ipers ~125000 Polygons/sec ~298000 Polygons/sec
texdown, subimage 148MB/s 1014MB/s
So while GEM offers improvements to the current i915 driver by adding memory management where none before existed, it really falls short of what is possible. In some cases, such as the texture uploading cases, massively short to the point of making some of the things we're considering doing not very tenable with this driver.
If other drivers are built on top of GEM instead of TTM (or something similarly well written) this pattern will repeat: drivers will improve somewhat, but still lag significantly behind what they should be doing. Worse, there may well be hardware that appears that simply won't work with GEM without it growing significantly in internal complexity (leading one to wonder if the end result won't be simply a hard road to rewriting TTM).
This is all complicated by the fact that TTM from DRM's dev branch hasn't made it into the Linux kernel yet despite being completed around a year ago, making it hard for people to rely on it (since it is up to individual distros to include this on their own). These bits of code have been sent for review but not integration into the Linux kernel. It's all a bit of an odd and unfortunate situation.
Hopefully whatever ends up in the kernel is flexible enough to allow something like TTM to occur so we can really go crazy with the graphics development on top of X.
Please x.org people, don't let your users down: Do The Right Thing(tm) and use the best available open technology.
Sunday, May 18, 2008
Discussing free software syncronicity
I've been quiet for the last week as I've had a house guest here during that time and it's been rather distracting. In a good way, but still, it took up the time I'd usually spend obsessively blogging and doing similar such things. It's back to normal come this week, however, and I'm looking at Monday as the hard feature freeze day with a bit of excitement and a bit of trepidation. (It's always like that for me =)
Which brings my thoughts back to release cycles ("oh no!" you say, "not that again!"), so it was timely to read Mark's post that was, at least in part, a reply to my previous blogs on this matter. (Thanks, Mark, for taking the time to read and reply =)
The good news is that I think we're finding common ground: Mark sees the logic behind staggering upstream to reflect dependencies. This makes a lot more sense than the overly simplified "everyone synchronize!" message that was getting bandied about. It will still be insanely tricky to get these cycles timed out right so that dependencies are met, but it'll be interesting to perhaps try.
I do hope that as the projects start to look at each other's cycles more closely that they also start to look at each other's integration points more closely. There are obvious points of integration between certain projects that just haven't materialized in very compelling ways largely because of a lack of value put on such things in Free software projects.
I did notice that Mark also didn't bring up the "it's better for marketing!" argument this time. As a blogger on internetnews.com put it, "From a selfish journalist point of view - Shuttleworth's version of syncronicity would also be terribly boring. I mean instead of being able to write about Ubuntu, Fedora and OpenSUSE releases on their own specific release dates and give each their due - I'd have one release day for all and lump them all together." I really hope that we have put aside the whole marketing canard in this discussion for good, because it actually is a weak point in the argument for syncronicity rather than a strong point.
Getting back to release cycles ... Mark talked about punting features being a strength; he's approaching it from the perspective of discipline. I agree, but that's just half the picture. The other half is that if you set up your cycles such that you are punting more than you should, you end up with a jilted development system that is in a constant state of hurk-and-jerk with features not making open windows and getting delayed. You end up slowly marching into the molasses as features have dependencies, too, and so delaying one changeset will end up delaying other changesets. Rinse, repeat, watch development spread out thinner and thinner on the timeline.
Mark talked about missing the opportunity to be in a down stream release (and, btw, mistakenly says it would be another 6 months; that would imply a near miss, which is usually not the case meaning it's almost always rather less than 6 months), but he didn't talk about individual features and fixes missing releases either which is essentially the same thing.
I suggest that true syncronicity takes into consideration the total life-cycle of software, from inception as an idea to design to draft code to releasable code to release to system integration to user. To tie a release cycle to a development cycle will hurt one or the other in the sense of making one of them less efficient. This is needless waste.
Mark suggests doing development in branches and merging them in "when they are ready". This obviously favors the release process which is a point in time event that requires a fraction of the resources involved in the actual development process. Given that the creative process is ongoing and consumes the bulk of resources, the release process should flow from the development process not the other way around. Decoupling of to-market-release from development would let development happen unabated in a mainline branch with release points being syncronized from the actual streams of development. As long as there is some discipline in the development stream (such that known-good-points can be identified), release should be quite possible.
This does not imply a wild west development scenario where things are in constant flux. That would be Bad(tm). It instead lets each component pick its pace and sync at regular intervals as it makes sense to. Hopefully those cycles are nice and short, such as a few weeks at most.
The benefit of doing it this way, which is really sort of the opposite direction that Mark suggests (with development out of mainline and release being mainline instead), is that instead of N different branches happening everywhere it's possible to once again work together on the code base. Some things do benefit from being done in a branch: experimental or highly disruptive changes, for example. Then again, there are few things as frustrating as fixing multiple branches to work together as work in one diverges things. Been there, done that.
Generally, however, having people working in their own copies (microbranches?) with them pushing up to mainline keeps things moving really well. There's a lot to be said about being able to test everyone else's work nearly constantly in such an environment; problems get caught sooner, improvements are suggested earlier. There's less effort wasted in general. It's also a bit inane to branch to work on smaller changes, which tend to dominate most development cycles. Mark talked about lean processes, but only from the integration point of view; there are lean process in development as well, and defining the development cycle by the release cycle, particularly the wrong one, erodes the leanness of the development process. Since development is the bulk of resources ... it should be obvious where to pay attention to leanness more.
There's also the social/psychological aspect of not working together. When working alone in a branch, it moves only as fast as you do. In fact, when others move faster the integration of their changes into your branch can actually slow you down if you don't do it often enough. This is about more than just conflicts in lines of code changes, but also things like regressions in features that interact with or depend on each other. When working together in a common area with a minimal (but no less) amount of separation (something I'm really liking git for, btw; it seems to really "get it right" in this respect) other people's work moves your code base forward, too. You get a sense of momentum, of things happening, of excitement.
It is not overly dramatic to say that if we make Free software development overly sterile via choice of process, there will be a commensurate diminishment in participation and momentum.
Remember that it is the development process that delivers nearly all the value in a Linux distribution. The distributions make that value accessible to the masses and create new kinds of value on top of it (support, marketing, etc) but it is the development not the integration that is primary source of the value. It should then be obvious that the development process is not something you screw with lightly; fortunately I think both Mark and I can have our cake and eat it too by decoupling the two processes into coordinated, parallel efforts.
I think Mark understands this on some level, because he says, "There’s a lot of discussion about the exact length of cycle that is “optimal”, with some commentary about the windows of development, freeze, QA and so on. I think that’s a bit of a red herring, when you factor in good branching, because feature development absolutely does not stop when the trunk is frozen in preparation for a release. Those who prefer to keep committing to their branches do so, they scratch the itch that matters most to them."
So he gets it that the two processes should be decoupled, but maybe he gets the solution a bit backwards. Reality is that development does slow down during freezes; reality is that freezes happen at times that aren't convenient for people (remember that a good 70% of KDE development is done in people's own time!); reality is that as fixes happen in mainline, they then need to trickle back out to other branches.
So I'd much rather see release be done in a branch with development in a rapidly cycling mainline.
What about bug fixes and stabilization in releases? We've done exactly this for years in KDE: we backport bug fixes from trunk/ to branches/ so that fixes trickle out to the next minor release (e.g. 4.0.x) as we work on the next major release (e.g. 4.1.x).
So now here's a really radical idea (so hold on): given that there is a hunger for synchronized release cycles for downstream .... why doesn't downstream take on producing releases? Why not cease waiting for tarballs to be delivered to your doorstep and start working on a release engineering service!
Why not have the system integration community (mostly the OSVs, really) come together and branch things for release at a certain point in time, defined by them, and work with upstream on stabilization of that branch? Instead of hoping that upstream does what they want, why don't they rally a bunch of cohorts from Novell, Red Hat, Debian, Mandriva, the MacOS and Windows communities, Canonical and whomever else wishes to engage and start offering a real, serious release process for upstream development to filter into? Upstreams that adopt a compatible method of development (such that branching could be done with at least semi-predictable results) could candidate for this service.
Just imagine how much efficiency there is to be gained by each project not having to build it's own entire release team and infrastructure but share a common one that is riding on the pulse of the downstream integrators! This would incentivate upstream (time and energy savings), free upstream development from release constraints and give integrators a direct influence over release points.
This work would be right within the core compentencies of the OSVs (release engineering) and would be scratching their itch at the same time. Heck, you'd even manage to get the same version of software in all the participating distribution releases "for free" by virtue of them preparing the releases in a common arena together.
There would be a number of details to work out, but having thought about it I think it's really doable.
I know this would be a non-trivial investment, but if Mark is truly serious about what he suggests this would be a very compelling way to put his currency where his mouth is, so to speak. Stop trying to convince the world and just start doing it.
Which brings my thoughts back to release cycles ("oh no!" you say, "not that again!"), so it was timely to read Mark's post that was, at least in part, a reply to my previous blogs on this matter. (Thanks, Mark, for taking the time to read and reply =)
The good news is that I think we're finding common ground: Mark sees the logic behind staggering upstream to reflect dependencies. This makes a lot more sense than the overly simplified "everyone synchronize!" message that was getting bandied about. It will still be insanely tricky to get these cycles timed out right so that dependencies are met, but it'll be interesting to perhaps try.
I do hope that as the projects start to look at each other's cycles more closely that they also start to look at each other's integration points more closely. There are obvious points of integration between certain projects that just haven't materialized in very compelling ways largely because of a lack of value put on such things in Free software projects.
I did notice that Mark also didn't bring up the "it's better for marketing!" argument this time. As a blogger on internetnews.com put it, "From a selfish journalist point of view - Shuttleworth's version of syncronicity would also be terribly boring. I mean instead of being able to write about Ubuntu, Fedora and OpenSUSE releases on their own specific release dates and give each their due - I'd have one release day for all and lump them all together." I really hope that we have put aside the whole marketing canard in this discussion for good, because it actually is a weak point in the argument for syncronicity rather than a strong point.
Getting back to release cycles ... Mark talked about punting features being a strength; he's approaching it from the perspective of discipline. I agree, but that's just half the picture. The other half is that if you set up your cycles such that you are punting more than you should, you end up with a jilted development system that is in a constant state of hurk-and-jerk with features not making open windows and getting delayed. You end up slowly marching into the molasses as features have dependencies, too, and so delaying one changeset will end up delaying other changesets. Rinse, repeat, watch development spread out thinner and thinner on the timeline.
Mark talked about missing the opportunity to be in a down stream release (and, btw, mistakenly says it would be another 6 months; that would imply a near miss, which is usually not the case meaning it's almost always rather less than 6 months), but he didn't talk about individual features and fixes missing releases either which is essentially the same thing.
I suggest that true syncronicity takes into consideration the total life-cycle of software, from inception as an idea to design to draft code to releasable code to release to system integration to user. To tie a release cycle to a development cycle will hurt one or the other in the sense of making one of them less efficient. This is needless waste.
Mark suggests doing development in branches and merging them in "when they are ready". This obviously favors the release process which is a point in time event that requires a fraction of the resources involved in the actual development process. Given that the creative process is ongoing and consumes the bulk of resources, the release process should flow from the development process not the other way around. Decoupling of to-market-release from development would let development happen unabated in a mainline branch with release points being syncronized from the actual streams of development. As long as there is some discipline in the development stream (such that known-good-points can be identified), release should be quite possible.
This does not imply a wild west development scenario where things are in constant flux. That would be Bad(tm). It instead lets each component pick its pace and sync at regular intervals as it makes sense to. Hopefully those cycles are nice and short, such as a few weeks at most.
The benefit of doing it this way, which is really sort of the opposite direction that Mark suggests (with development out of mainline and release being mainline instead), is that instead of N different branches happening everywhere it's possible to once again work together on the code base. Some things do benefit from being done in a branch: experimental or highly disruptive changes, for example. Then again, there are few things as frustrating as fixing multiple branches to work together as work in one diverges things. Been there, done that.
Generally, however, having people working in their own copies (microbranches?) with them pushing up to mainline keeps things moving really well. There's a lot to be said about being able to test everyone else's work nearly constantly in such an environment; problems get caught sooner, improvements are suggested earlier. There's less effort wasted in general. It's also a bit inane to branch to work on smaller changes, which tend to dominate most development cycles. Mark talked about lean processes, but only from the integration point of view; there are lean process in development as well, and defining the development cycle by the release cycle, particularly the wrong one, erodes the leanness of the development process. Since development is the bulk of resources ... it should be obvious where to pay attention to leanness more.
There's also the social/psychological aspect of not working together. When working alone in a branch, it moves only as fast as you do. In fact, when others move faster the integration of their changes into your branch can actually slow you down if you don't do it often enough. This is about more than just conflicts in lines of code changes, but also things like regressions in features that interact with or depend on each other. When working together in a common area with a minimal (but no less) amount of separation (something I'm really liking git for, btw; it seems to really "get it right" in this respect) other people's work moves your code base forward, too. You get a sense of momentum, of things happening, of excitement.
It is not overly dramatic to say that if we make Free software development overly sterile via choice of process, there will be a commensurate diminishment in participation and momentum.
Remember that it is the development process that delivers nearly all the value in a Linux distribution. The distributions make that value accessible to the masses and create new kinds of value on top of it (support, marketing, etc) but it is the development not the integration that is primary source of the value. It should then be obvious that the development process is not something you screw with lightly; fortunately I think both Mark and I can have our cake and eat it too by decoupling the two processes into coordinated, parallel efforts.
I think Mark understands this on some level, because he says, "There’s a lot of discussion about the exact length of cycle that is “optimal”, with some commentary about the windows of development, freeze, QA and so on. I think that’s a bit of a red herring, when you factor in good branching, because feature development absolutely does not stop when the trunk is frozen in preparation for a release. Those who prefer to keep committing to their branches do so, they scratch the itch that matters most to them."
So he gets it that the two processes should be decoupled, but maybe he gets the solution a bit backwards. Reality is that development does slow down during freezes; reality is that freezes happen at times that aren't convenient for people (remember that a good 70% of KDE development is done in people's own time!); reality is that as fixes happen in mainline, they then need to trickle back out to other branches.
So I'd much rather see release be done in a branch with development in a rapidly cycling mainline.
What about bug fixes and stabilization in releases? We've done exactly this for years in KDE: we backport bug fixes from trunk/ to branches/ so that fixes trickle out to the next minor release (e.g. 4.0.x) as we work on the next major release (e.g. 4.1.x).
So now here's a really radical idea (so hold on): given that there is a hunger for synchronized release cycles for downstream .... why doesn't downstream take on producing releases? Why not cease waiting for tarballs to be delivered to your doorstep and start working on a release engineering service!
Why not have the system integration community (mostly the OSVs, really) come together and branch things for release at a certain point in time, defined by them, and work with upstream on stabilization of that branch? Instead of hoping that upstream does what they want, why don't they rally a bunch of cohorts from Novell, Red Hat, Debian, Mandriva, the MacOS and Windows communities, Canonical and whomever else wishes to engage and start offering a real, serious release process for upstream development to filter into? Upstreams that adopt a compatible method of development (such that branching could be done with at least semi-predictable results) could candidate for this service.
Just imagine how much efficiency there is to be gained by each project not having to build it's own entire release team and infrastructure but share a common one that is riding on the pulse of the downstream integrators! This would incentivate upstream (time and energy savings), free upstream development from release constraints and give integrators a direct influence over release points.
This work would be right within the core compentencies of the OSVs (release engineering) and would be scratching their itch at the same time. Heck, you'd even manage to get the same version of software in all the participating distribution releases "for free" by virtue of them preparing the releases in a common arena together.
There would be a number of details to work out, but having thought about it I think it's really doable.
I know this would be a non-trivial investment, but if Mark is truly serious about what he suggests this would be a very compelling way to put his currency where his mouth is, so to speak. Stop trying to convince the world and just start doing it.
Monday, May 12, 2008
the hands of many
thomasz just posted a link to this email from a KDE-on-Kubuntu user. Honest and heartfelt, it's one of the most beautiful things I've read in a while.
The person writing, Robert, bought his daughter a computer for her 14th birthday. He got what they could afford, and due to financial constraints that meant not much. Price often isn't the compelling selling feature for business users in the "first" world (gah, I hate that term), but for many others it is. In this case, it made all the difference. The best part is that this family is not getting cheated because they don't happen to have endless amounts of disposable income: they get to participate on their terms without limitation.
So just what difference does free-as-in-freedom software make? Robert speaks eloquently and clearly:
Yeah, I'm a little misty eyed now. Maybe you should be too: with what skills we have we're making a difference. It may not solve world hunger in this decade or bring about instant world peace, but together we are undeniably improving things in our own little way by contributing in a positive fashion to the ethical stature and fairness of our societies. There are few other achievements in life as important, valuable or rewarding.
I believe that untangling the various miseries in our world will occur in the form of a long series of small steps taken by many people as part of their daily lives. Who knows what the people of the world will do tomorrow because of what we are doing today.
Indeed, a bright future requires a little bit of Hope. To Robert: thanks for the reminder. Hugs, peace and love.
The person writing, Robert, bought his daughter a computer for her 14th birthday. He got what they could afford, and due to financial constraints that meant not much. Price often isn't the compelling selling feature for business users in the "first" world (gah, I hate that term), but for many others it is. In this case, it made all the difference. The best part is that this family is not getting cheated because they don't happen to have endless amounts of disposable income: they get to participate on their terms without limitation.
So just what difference does free-as-in-freedom software make? Robert speaks eloquently and clearly:
"I cant tell you how much I appreciate
the work you all have done. Its a work of art. If I could thank each and every one of
you I would.
You have given her the world to learn and explore.
So if you get frustrated or tired in
your work for Open Source/Free Software, just remember that somewhere in Missouri
there is a 14 year-old girl named Hope, an A-student who runs on the track team,
who is now your biggest fan and one of the newest users of
Linux/Ubuntu."
Yeah, I'm a little misty eyed now. Maybe you should be too: with what skills we have we're making a difference. It may not solve world hunger in this decade or bring about instant world peace, but together we are undeniably improving things in our own little way by contributing in a positive fashion to the ethical stature and fairness of our societies. There are few other achievements in life as important, valuable or rewarding.
I believe that untangling the various miseries in our world will occur in the form of a long series of small steps taken by many people as part of their daily lives. Who knows what the people of the world will do tomorrow because of what we are doing today.
Indeed, a bright future requires a little bit of Hope. To Robert: thanks for the reminder. Hugs, peace and love.
i don't want a keyboard. i want a screen.
so tonight i was thinking/daydreaming a bit. daydreaming is a very underrated past-time / skill, imho. anyways... i was thinking about laptops and it occurred to me that i'd love a laptop with two screens: one where it usually is, and one where the keyboard is. kind of like a great big nintendo DS.
the "bottom" screen would be a multitouch surface so that i could put a keyboard there. when the keyboard layout switched, the keys could actually change. the touchpad would also be on the "screen", and though could simply be "put away" when i didn't want it (e.g. when i have a mouse plugged in). perhaps it could even autohide when i have a mouse plugged in? hm.
best of all, those "multimedia buttons" could be replaced with real software. i'd be able to put any set of buttons i wanted there. perhaps even the toolbars from apps. imagine how useful that would be in a word processor! no taking the hands off the "keyboard" just to swap fonts or paragraph style: just reach up and press the font or style combo and it would pop down over the keys.
you could have a volume button somewhere that would popup an actual volume slider ... you could put useful widgets, such as perhaps a news, weather or stock ticker above the keys. or put the taskbar there for easy switching between windows.
the possibilities are limitless.
i googled for something like this and found this year+ old story about a vapourware laptop. the logitech G15 seems to come sort of close, but misses by not going all the way and replacing the whole thing with a dispay surface. oh well.
thinking about it some more i suppose it's probably not overly realistic to expect such a laptop to come about until we have something better than today's batteries for portable power (fuel cells?).
but still .. damn. it would be sooo cool. one more place to play with plasma ;)
speaking of which, the new krunner ui is coming along nicely and the dialog-less panel config is downright awesome. i'm trying to schedule time for a screencast this week so i can share it with everyone who isn't tracking svn (or, in the case of the krunner ui, the git repo for it)
the "bottom" screen would be a multitouch surface so that i could put a keyboard there. when the keyboard layout switched, the keys could actually change. the touchpad would also be on the "screen", and though could simply be "put away" when i didn't want it (e.g. when i have a mouse plugged in). perhaps it could even autohide when i have a mouse plugged in? hm.
best of all, those "multimedia buttons" could be replaced with real software. i'd be able to put any set of buttons i wanted there. perhaps even the toolbars from apps. imagine how useful that would be in a word processor! no taking the hands off the "keyboard" just to swap fonts or paragraph style: just reach up and press the font or style combo and it would pop down over the keys.
you could have a volume button somewhere that would popup an actual volume slider ... you could put useful widgets, such as perhaps a news, weather or stock ticker above the keys. or put the taskbar there for easy switching between windows.
the possibilities are limitless.
i googled for something like this and found this year+ old story about a vapourware laptop. the logitech G15 seems to come sort of close, but misses by not going all the way and replacing the whole thing with a dispay surface. oh well.
thinking about it some more i suppose it's probably not overly realistic to expect such a laptop to come about until we have something better than today's batteries for portable power (fuel cells?).
but still .. damn. it would be sooo cool. one more place to play with plasma ;)
speaking of which, the new krunner ui is coming along nicely and the dialog-less panel config is downright awesome. i'm trying to schedule time for a screencast this week so i can share it with everyone who isn't tracking svn (or, in the case of the krunner ui, the git repo for it)
Saturday, May 10, 2008
breathing together
Sebas writes a tremendously great blog, in my opinion, on the issues we face with a 6 month cycle. Please go and read it, as he really gets the issues at hand on all sides.
Sebas also proposes the rather radical idea of, "What if we never froze trunk?" Or, as he put it, "always summer in trunk".
My dream situation would be to have 2 weeks of devel, 3-4 days minimum to stabilize that work (but longer if necessary), rince and repeat with natural breaks for things like life's little interferences, bug fixing orgies and what not. I think we'd find a natural cycle where significant feature improvements would land every quarter or so.
At each known stable point we'd push the changes in the branch back to mainline for others to use and test. The beauty here would be that other developers and testers wouldn't get horrible breakage periods, just steps from relatively stable to relatively stable.
When a release time comes up, we'd sync the last stable point to the release branch and continue on working. No further syncs would happen until the release process of betas and RCs was over, at which point we'd sync up again at the next stable point.
Bugs and other issues that come up during the release periods would be addressed and backported, just as we do for minor releases (though in the other direction).
It would allow KDE to do whatever release cycles the umbrella project wanted while allowing us to breath, as Sebas put it so eloquently, to our own heartbeat.
My hope in discussing this is openly is that we can make necessary changes to allow the above utopia to occur. Maybe not today, or even for 4.2. But eventually. It probably means using a tool that is better than the current svn release (I see a number of improvements in svn 1.5; maybe that will be enough? I'm doubtful, but also hopeful), it means making release branch development not the norm (which it is today) and it means trusting our own rhythms. Such an approach is applicable to far more than just Plasma; many of the more interesting application in KDE's svn face these same issues.
At the same time I don't want to see KDE's development become a difuse diaspora of repositories and chaos. We can come up with best practices together and find a way to satisfy both the release desires of downstream and the development desires of upstream (that's us =)
Sebas also proposes the rather radical idea of, "What if we never froze trunk?" Or, as he put it, "always summer in trunk".
My dream situation would be to have 2 weeks of devel, 3-4 days minimum to stabilize that work (but longer if necessary), rince and repeat with natural breaks for things like life's little interferences, bug fixing orgies and what not. I think we'd find a natural cycle where significant feature improvements would land every quarter or so.
At each known stable point we'd push the changes in the branch back to mainline for others to use and test. The beauty here would be that other developers and testers wouldn't get horrible breakage periods, just steps from relatively stable to relatively stable.
When a release time comes up, we'd sync the last stable point to the release branch and continue on working. No further syncs would happen until the release process of betas and RCs was over, at which point we'd sync up again at the next stable point.
Bugs and other issues that come up during the release periods would be addressed and backported, just as we do for minor releases (though in the other direction).
It would allow KDE to do whatever release cycles the umbrella project wanted while allowing us to breath, as Sebas put it so eloquently, to our own heartbeat.
My hope in discussing this is openly is that we can make necessary changes to allow the above utopia to occur. Maybe not today, or even for 4.2. But eventually. It probably means using a tool that is better than the current svn release (I see a number of improvements in svn 1.5; maybe that will be enough? I'm doubtful, but also hopeful), it means making release branch development not the norm (which it is today) and it means trusting our own rhythms. Such an approach is applicable to far more than just Plasma; many of the more interesting application in KDE's svn face these same issues.
At the same time I don't want to see KDE's development become a difuse diaspora of repositories and chaos. We can come up with best practices together and find a way to satisfy both the release desires of downstream and the development desires of upstream (that's us =)
re: Singing in tune
Robert has posted his thoughts, mostly a summary of Mark Shuttleworth's talk at a past Akademy, about 6 month release cycles. It's an interesting read and worth taking the time to do so.
Unfortunately, Mark's presentation was simply full of the same unfounded or just plain ridiculous assertions that Mark is fond of making in public these days. Let's take a few of them:
To whom? And to what end? It turns out that this rhythm is mostly to downstream, and the structure is completely based on the sense of perception not anything concrete. We can provide for downstream's desire for rhythm, but we don't need to harmonize release cycles with every other "appropriate" project.
It would be like going into a large company that makes hundreds of different products with a loose common theme (ours is software; Lockheed-Martin would be aerospace; GE would be anything that attempts to make money ;) to sync up all those product cycles. Not only is it ridiculously expensive to do so, it just doesn't add up to anything meaningful production wise.
This is the classic mistaking of "what I want translates to what you do". I completely am on side with providing downstream with what works for them, but at the expense of our productivity? Nope. Thankfully I think we can have both.
I've yet to see any evidence for this.
Let's assume project A depends on B, and B releases at the same time as A. That means that A is either going to be one cycle behind B in using what B provides, or will have to track B's bleeding edge for the latter part of their cycle allowing some usage. What you really want is a staggered approach where B releases right about when A starts to work on things.
This goes completely counter to the "everyone on the same month, every 6 months" doctrine Mark preaches, of course.
If A and B are orthogonal, then who cares. There is no cooperation to be had. Unless, of course, you are a downstream integrator wanting new features across the board on every release. I don't think that's really what the mass market wants or cares about, but it's useful to recognize the real drive behind this: it isn't software development, it's software integration for a very specific set of people.
The implied statement here is that distributors can't trust KDE if there isn't a set cycle. History proves this one wrong on its face, both in the general sense (last time I checked Oracle, SAP, Microsoft, etc.. didn't do this) and in the specific sense (lots of trust in KDE out there). So this one rubs me wrong just for how it's phrased: it's meant to manipulate based on fear of being left out. I hate being manipulated.
Beyond semantics, however, this can be achieved by KDE simply setting schedules and sticking to them, as we did throughout KDE2 and KDE3 and have begun doing again now that KDE4 is on the tracks. It has nothing to do with set schedules or synchronization.
Absolutely.
This is a classic tactic: recognize the flaw in your position, then spin it slightly differently. Honestly, I don't care if we were sync'd with someone. I care that our development processes work well. Synchronicity matters not one bit if the product is hobbled.
Absolutely; but again this doesn't address the issue of the size of the time based schedule. The kernel developers do not use a six month cycle.
Absolutely.
What is the value, exactly? I mean to the software development process that actually creates the value in the software in the first place. I get downstream's benefit, but since this "value" to them comes at a cost to me and their value is a derivative of my value ... can't they see the shortsighted nature of this position? Really, show me the value. I've challenged people who take this position to do it many times in the past and it turns out the value is in integration and immediate gratification for users. Excuse me for being a strategist, but I'd prefer to win in the long term.
So show me the value. Show me the actual measured benefits of a six month cycle that is generally applicable to every software project.
Great, because that's pretty much what I'm debating. We either need a way to allow for multiplicity in time delay for development while keeping synchronicity in delay for release, or we need to adjust the delay. But seriously, when Mark says this and then follows it up with "oh, but 6 months is what we found best because ..." and then continues to go on at every opportunity how people should be on a 6 month cycle, the agenda is pretty clear. It may be up for debate ... as long as that debate is whether it should be 6 months starting in April or 6 months starting in October.
So, to reiterate: I'm not against time based development, I'm just not in favour of binding development time frames to the artifice of 6 month release cycles that have exactly one benefactor (distros) and many who pay (upstream and eventually the users).
Unfortunately, Mark's presentation was simply full of the same unfounded or just plain ridiculous assertions that Mark is fond of making in public these days. Let's take a few of them:
"Regular, predictable releases which are synced with appropriate other projects provide a sense of rhythm and structure."
To whom? And to what end? It turns out that this rhythm is mostly to downstream, and the structure is completely based on the sense of perception not anything concrete. We can provide for downstream's desire for rhythm, but we don't need to harmonize release cycles with every other "appropriate" project.
It would be like going into a large company that makes hundreds of different products with a loose common theme (ours is software; Lockheed-Martin would be aerospace; GE would be anything that attempts to make money ;) to sync up all those product cycles. Not only is it ridiculously expensive to do so, it just doesn't add up to anything meaningful production wise.
This is the classic mistaking of "what I want translates to what you do". I completely am on side with providing downstream with what works for them, but at the expense of our productivity? Nope. Thankfully I think we can have both.
"It allows projects up/down and across-stream to plan better and co-operate more efficiently."
I've yet to see any evidence for this.
Let's assume project A depends on B, and B releases at the same time as A. That means that A is either going to be one cycle behind B in using what B provides, or will have to track B's bleeding edge for the latter part of their cycle allowing some usage. What you really want is a staggered approach where B releases right about when A starts to work on things.
This goes completely counter to the "everyone on the same month, every 6 months" doctrine Mark preaches, of course.
If A and B are orthogonal, then who cares. There is no cooperation to be had. Unless, of course, you are a downstream integrator wanting new features across the board on every release. I don't think that's really what the mass market wants or cares about, but it's useful to recognize the real drive behind this: it isn't software development, it's software integration for a very specific set of people.
"If distributors believe they can trust KDE's release schedule and release quality then they will allow a smaller safety margin between the time KDE makes a release and the time when distributors need to ship their next release."
The implied statement here is that distributors can't trust KDE if there isn't a set cycle. History proves this one wrong on its face, both in the general sense (last time I checked Oracle, SAP, Microsoft, etc.. didn't do this) and in the specific sense (lots of trust in KDE out there). So this one rubs me wrong just for how it's phrased: it's meant to manipulate based on fear of being left out. I hate being manipulated.
Beyond semantics, however, this can be achieved by KDE simply setting schedules and sticking to them, as we did throughout KDE2 and KDE3 and have begun doing again now that KDE4 is on the tracks. It has nothing to do with set schedules or synchronization.
"Getting the release out is the most important feature."
Absolutely.
"It would be wrong for KDE to specifically pick a distribution to sync with. Instead pick a date which 'conveniently' matches that of other software at the same level in the stack"
This is a classic tactic: recognize the flaw in your position, then spin it slightly differently. Honestly, I don't care if we were sync'd with someone. I care that our development processes work well. Synchronicity matters not one bit if the product is hobbled.
"Regular time-based releases are much easier if features can be landed when they are complete, so that the primary work going on in trunk is integration [..] The kernel developers have proved that this approach can work."
Absolutely; but again this doesn't address the issue of the size of the time based schedule. The kernel developers do not use a six month cycle.
"The regular cycle may have to be suspended for big backwards-compatibility breaking upgrades (KDE 4)"
Absolutely.
"The value of synchronization is sufficiently high"
What is the value, exactly? I mean to the software development process that actually creates the value in the software in the first place. I get downstream's benefit, but since this "value" to them comes at a cost to me and their value is a derivative of my value ... can't they see the shortsighted nature of this position? Really, show me the value. I've challenged people who take this position to do it many times in the past and it turns out the value is in integration and immediate gratification for users. Excuse me for being a strategist, but I'd prefer to win in the long term.
So show me the value. Show me the actual measured benefits of a six month cycle that is generally applicable to every software project.
"The time delay is subject to debate."
Great, because that's pretty much what I'm debating. We either need a way to allow for multiplicity in time delay for development while keeping synchronicity in delay for release, or we need to adjust the delay. But seriously, when Mark says this and then follows it up with "oh, but 6 months is what we found best because ..." and then continues to go on at every opportunity how people should be on a 6 month cycle, the agenda is pretty clear. It may be up for debate ... as long as that debate is whether it should be 6 months starting in April or 6 months starting in October.
So, to reiterate: I'm not against time based development, I'm just not in favour of binding development time frames to the artifice of 6 month release cycles that have exactly one benefactor (distros) and many who pay (upstream and eventually the users).
Friday, May 09, 2008
re: re: ramblings on 6 month cycles and Plasma
Toma took the time to reply to my blog entry on the six month cycle. He raised some ambiguities that I could probably clarify on a bit.
As Toma calculates, 4 out of 6 months are spend in feature development. At least that's what the schedule says. A common pitfall in management (of any sort) is to keep your eyes on what is written on paper (the theory) and not glance up to examine what's really going on in reality. Reality is that right after a release I spend time doing the following three things:
It is not unusual, in my experience, for working on bugs, wishlists and drafting the next cycle's hit list (which hopefully is based partly on an already laid out set of goals, but must also include what got punted as well as shifted priorities) to take a few weeks of time. Therefore, I don't expect a ton of new feature development in the first month of a cycle. This is born out by what happened this first cycle around, and matches with my experience from past projects as well.
That means that effectively we have 3 months of feature development. Sure, what's written down in the theory (the schedule) says 4 months ... but I live in reality, and therefore management of my resources should too.
No arguments from me there ;)
Not if we don't do any development in KDE's svn and simply use it as a release dump. There are decent scripts out there to replay git commits into, e.g. svn. This would be a lot easier if KDE were using git as well, but really .. I don't want to start the vcs discussion here. This is about release schedules, the tools that we use making that harder or easier to cope with is another discussion altogether.
We use review board for this and it works just fine, actually, especially for larger patches. We can always replay the git commits one by one if we wish, but really that too is a detail. With development happening in a separate repository, we can do all our small commits in usual chunks there and then merge back to the release branch however we see fit.
This is where I get really uncomfortable, though: to solve the issue with an inappropriately sized cycle, I end up moving the development away from the KDE infrastructure which is totally counter productive from the perspective of shared development. This particularly hits us when it comes to internationalization (i18n), but more on that in a minute.
That alone makes me hesitate. I feel like I'm between a rock and a hard place on this one. The rock is a poor choice of release cycle for my work in plasma, and the hard place is our current vcs tool being too poor at merging branches to even consider using it as a solution to the release cycle problem.
Ugh.
The number of such commits would be trivial and easily tracked even manually. Still not wonderful, but I'd rather optimize for mainline development speed than occasional build and bug fixes.
Note that I already read every commit to the plasma codebases (libplasma, plasma, krunner, extragear, ..) so this is already factored into my work life.
It actually isn't the build fixes, however, that will be a paint. It's the translations: those are scripted to work against our shared svn repository and those would need to get sync'd back and forth regularly. Supporting i18n scares me in this scenario.
Merging from a mainline devel git repository to an virtual read-only release branch in one big go is 15 minutes work. Watching for code commits from svn and syncing those back isn't a big issue either, and also mostly able to be automated.
So I think you're vastly overstating the overhead this would incur on my part. Unfortunately, it would really hinder i18n and raise the bar for new people to get involved (another repo you have to know about and another vcs that you have to know how to use).
It's really interesting how this choice in cycles results in degrading one or more of the following: existing development efforts, new comer involvement and i18n. Yes, I know it all looks good in theory ... but history is littered with failures due to deciding based on theory instead of what the theory actually means in practice.
Well, this isn't exactly the first project I've ever worked on. =) As for plasma itself, I've seen what this cycle has done and have already spent some time mapping out the next one; I fully expect the next cycle to be a repeat in many ways of this one. So, lots of good development, but lots of punting combined with sprinting to get features in under the wire. This is really the funny thing about the choice of "6 months": it's short enough that timing matters a lot, but not short enough to be suited for fast iterations in development.
It's a lot like trying to avoid stepping on the cracks in a sidewalk where the slabs aren't quite a multiple of your natural stride: you can do it but you end up losing your rhythm and looking like a bit of a goofball in the process.
If I had an idea of what would both work globally and also wouldn't result in me sinking days of my time into a discussion and decisions process I would. Right now, I'm not sure what the best solution is for all of KDE. I honestly haven't gotten to that point in thinking about it. I just know that for the project I'm most deeply involved in, it sucks. That doesn't mean it isn't perfect for other aspects of the project; as I said in my original blog this is a "one size does not fit all" sort of issue, and I suspect 6 months might work just fine for kdelibs.
If you're wondering why previous release cycles didn't cause such angst, it's because if a cycle is longer than you need or short enough to match natural short-term iterations it's not a big deal. KDE always tended to have longer-than-strictly-needed cycles which made them fit really well a broad cross section of the project and, I would argue, thereby actually increasing the development pace.
It's really hard to argue with the pace of KDE3 development.
Damn! And here I was hoping someone smarter than me would come up with the brilliant and obvious solution ;)
This is the "it will eventually be done" theory. That theory works really well for projects which have a fairly limited scope (so a limited amount of internal pressure) that gets applied in an environment that is mostly static (so little to no external pressure). Unfortunately, Plasma has both huge ambitions (so lots of internal pressure to keep moving) and competes in what is right now one of the more competitive and evolving areas (primary user interfaces and the bling that makes them sing) which means lots of external pressure to keep moving.
I'd be very surprised if core Plasma development settles down within two years time. While we may not be mucking with existing code (source and binary compat being what it is), there is a lot left to be added.
Anyways, thanks, Toma, for taking the time for a well reasoned reply. Hopefully the above gives you a bit clearer idea of what thoughts are rattling around my wee little head.
"First point is the very complex reasoning of the available time to do new features with a six months release cycle, which according to Aarons calculation means that half of the year we are in non-feature development. I don't understand that. "
As Toma calculates, 4 out of 6 months are spend in feature development. At least that's what the schedule says. A common pitfall in management (of any sort) is to keep your eyes on what is written on paper (the theory) and not glance up to examine what's really going on in reality. Reality is that right after a release I spend time doing the following three things:
- Catching my breath a bit (let's call that a day or three, so not significant)
- Responding to bug and wishlist reports; these tend to pick up right after a release and I like to spend the start of each cycle working on the x.1 release that is going to come out soon after the x.0 release. This is usually a significant time sink in the first couple weeks.
- Surveying the landscape, revisiting the feature plan and figuring out exactly what will be done in this next cycle. This is impacted by the results of the last cycle as well as the ever evolving needs and desires for the product. This too takes time and prevents immediately diving in to new feature development
It is not unusual, in my experience, for working on bugs, wishlists and drafting the next cycle's hit list (which hopefully is based partly on an already laid out set of goals, but must also include what got punted as well as shifted priorities) to take a few weeks of time. Therefore, I don't expect a ton of new feature development in the first month of a cycle. This is born out by what happened this first cycle around, and matches with my experience from past projects as well.
That means that effectively we have 3 months of feature development. Sure, what's written down in the theory (the schedule) says 4 months ... but I live in reality, and therefore management of my resources should too.
"I hear you scream that svn branches suck."
No arguments from me there ;)
"moving it to git repositories will give you a lot more overhead and merging that all back at intervals to KDE's svn will frustrate you as well."
Not if we don't do any development in KDE's svn and simply use it as a release dump. There are decent scripts out there to replay git commits into, e.g. svn. This would be a lot easier if KDE were using git as well, but really .. I don't want to start the vcs discussion here. This is about release schedules, the tools that we use making that harder or easier to cope with is another discussion altogether.
"With git you usually merge a completed feature, making the diff too large for people to check on the mailinglists. At least I prefer ten smaller commits to review than one big one."
We use review board for this and it works just fine, actually, especially for larger patches. We can always replay the git commits one by one if we wish, but really that too is a detail. With development happening in a separate repository, we can do all our small commits in usual chunks there and then merge back to the release branch however we see fit.
This is where I get really uncomfortable, though: to solve the issue with an inappropriately sized cycle, I end up moving the development away from the KDE infrastructure which is totally counter productive from the perspective of shared development. This particularly hits us when it comes to internationalization (i18n), but more on that in a minute.
That alone makes me hesitate. I feel like I'm between a rock and a hard place on this one. The rock is a poor choice of release cycle for my work in plasma, and the hard place is our current vcs tool being too poor at merging branches to even consider using it as a solution to the release cycle problem.
Ugh.
"After the period merge back, people using KDE's svn will make build fixes, etc. That will need to sync back to the git repository."
The number of such commits would be trivial and easily tracked even manually. Still not wonderful, but I'd rather optimize for mainline development speed than occasional build and bug fixes.
Note that I already read every commit to the plasma codebases (libplasma, plasma, krunner, extragear, ..) so this is already factored into my work life.
It actually isn't the build fixes, however, that will be a paint. It's the translations: those are scripted to work against our shared svn repository and those would need to get sync'd back and forth regularly. Supporting i18n scares me in this scenario.
"I'm sorry, but if you want more hacking time, this is not the way to go in my opinion."
Merging from a mainline devel git repository to an virtual read-only release branch in one big go is 15 minutes work. Watching for code commits from svn and syncing those back isn't a big issue either, and also mostly able to be automated.
So I think you're vastly overstating the overhead this would incur on my part. Unfortunately, it would really hinder i18n and raise the bar for new people to get involved (another repo you have to know about and another vcs that you have to know how to use).
It's really interesting how this choice in cycles results in degrading one or more of the following: existing development efforts, new comer involvement and i18n. Yes, I know it all looks good in theory ... but history is littered with failures due to deciding based on theory instead of what the theory actually means in practice.
I also disagree with the general remark that a 'six month cycle' does not work for you in this project. How on earth is it possible to judge that, when the very first cycle is not even completed.
Well, this isn't exactly the first project I've ever worked on. =) As for plasma itself, I've seen what this cycle has done and have already spent some time mapping out the next one; I fully expect the next cycle to be a repeat in many ways of this one. So, lots of good development, but lots of punting combined with sprinting to get features in under the wire. This is really the funny thing about the choice of "6 months": it's short enough that timing matters a lot, but not short enough to be suited for fast iterations in development.
It's a lot like trying to avoid stepping on the cracks in a sidewalk where the slabs aren't quite a multiple of your natural stride: you can do it but you end up losing your rhythm and looking like a bit of a goofball in the process.
"I always learned from my mother (hi mam!) that I need to give it a try for a couple of times before deciding it does not work."
That's good advice from your mother. I'm sure she'd also tell you to learn from the mistakes and successes of others, to not repeat errors you've made in the past and to repeat your successes whenever possible. It's not like creation cycles are a new science.
It may be the first time KDE's tried to stick consistently to such a short cycle period, but it's not my first time around."The schedule is not set in stone and if you have reasons to change things, mail the release-team."
If I had an idea of what would both work globally and also wouldn't result in me sinking days of my time into a discussion and decisions process I would. Right now, I'm not sure what the best solution is for all of KDE. I honestly haven't gotten to that point in thinking about it. I just know that for the project I'm most deeply involved in, it sucks. That doesn't mean it isn't perfect for other aspects of the project; as I said in my original blog this is a "one size does not fit all" sort of issue, and I suspect 6 months might work just fine for kdelibs.
If you're wondering why previous release cycles didn't cause such angst, it's because if a cycle is longer than you need or short enough to match natural short-term iterations it's not a big deal. KDE always tended to have longer-than-strictly-needed cycles which made them fit really well a broad cross section of the project and, I would argue, thereby actually increasing the development pace.
It's really hard to argue with the pace of KDE3 development.
So, I've no concrete solutions for the problems mentioned in Aarons blog,
Damn! And here I was hoping someone smarter than me would come up with the brilliant and obvious solution ;)
I can understand that a new project requires a lot of setup for the infratructure, but when that's done things will get easier.
This is the "it will eventually be done" theory. That theory works really well for projects which have a fairly limited scope (so a limited amount of internal pressure) that gets applied in an environment that is mostly static (so little to no external pressure). Unfortunately, Plasma has both huge ambitions (so lots of internal pressure to keep moving) and competes in what is right now one of the more competitive and evolving areas (primary user interfaces and the bling that makes them sing) which means lots of external pressure to keep moving.
I'd be very surprised if core Plasma development settles down within two years time. While we may not be mucking with existing code (source and binary compat being what it is), there is a lot left to be added.
Anyways, thanks, Toma, for taking the time for a well reasoned reply. Hopefully the above gives you a bit clearer idea of what thoughts are rattling around my wee little head.
Thursday, May 08, 2008
ramblings on scripting
Today I may have stumbled upon why the people working on scripting for Plasma tend not to grok at first the point and purpose of ScriptEngines or any of the other mechanisms we have put in place for this:
In most cases, the API is defined by the host and the language binding is just a mapping of that API into the runtime environment the code will be run in.
With Plasma it's really the other way around. The language support (not necessarily bindings!) define the API while libplasma simply provides the canvas and management of the components. The language support defines the API, which could be a 1:1 mapping to the libplasma API but really doesn't need to be.
So the language people have been looking at Plasma asking, "So... how do I bind to this API?" and see ScriptEngine which is totally unsuited for that and scratching their head. Meanwhile, I get to explain for the Nth time (where N == number of languages people are working on ;), probably rather clumsily, that binding isn't the point of those classes. =)
Now that I finally understand this difference in perspective, perhaps I'll be able to articulate it more accurately in future.
In most cases, the API is defined by the host and the language binding is just a mapping of that API into the runtime environment the code will be run in.
With Plasma it's really the other way around. The language support (not necessarily bindings!) define the API while libplasma simply provides the canvas and management of the components. The language support defines the API, which could be a 1:1 mapping to the libplasma API but really doesn't need to be.
So the language people have been looking at Plasma asking, "So... how do I bind to this API?" and see ScriptEngine which is totally unsuited for that and scratching their head. Meanwhile, I get to explain for the Nth time (where N == number of languages people are working on ;), probably rather clumsily, that binding isn't the point of those classes. =)
Now that I finally understand this difference in perspective, perhaps I'll be able to articulate it more accurately in future.
ramblings on 6 month cycles and Plasma
.. continuing my "I'm feeling ill, so am soaking in a bath" rambling thoughts:
Most of the plasmoids I personally wanted to work into 4.1 are getting punted to 4.2. WoC and a few other things sapped my time. Thankfully others have been working on plasmoids so we'll have some great new stuff there, I just wish I could've been able to play in Plasmoid land more (it strikes me as more fun than the infrastructure issues I deal with ;)
This is one aspect of the 6 month release cycle that I really don't like for Plasma: the punt rate increases. For some apps this is a complete non-issue, but for more complex bodies of code that are in high development states a 3 month feature window is just too tight to fit in more than a few things. The first month of a release cycle is usually not spent on new features in my experience, and the last couple of months in a 6 month cycle are spent stabilizing. What this means is that we spend half the year in non-feature development; over 3 years time a 9 month cycle (with 3 months of stabilization) gives me 20 months of feature dev while 6 months gives me 18 months. That sounds similar enough, but the windows are tiny in the 6 month cycle, meaning more punting which in turn means that many features will be delivered in 12 months time to the user rather than 9.
It's also pretty obvious to me that for other projects, a 4 month cycle is probably even more useful than a 6 month cycle. Web based CMS projects come to mind as a good example where 4 month cycles would be the "Goldilocks" (aka "just right!") cycle.
In fact, I suspect 4 months might the Golidlocks number for Plasma: 2-3 months of features, 1-2 months of stabilization and exercising those new features via plugins. Unfortunately, 6 is not very evenly divisible by 4 ;) so this wouldn't work for the current release cycle.
I know that 6 months is all the craze right now, mostly IMHO for the wrong reasons like "marketing" or "downstream synchronization", but also partly for the right reasons such as quick cycles with a known clock rate for better iterative development patterns. I really dislike the marketing and downstream control issues because the former is complete BS (I want to smack someone with a marketing textbook every time I hear them opine on how six month cycles are better for promo) and the latter is misplaced priorities (accommodating downstream by hobbling upstream is remarkably short sighted). Really it comes down to finding a way to satisfy different sets of priorities.
I spent some time today thinking about what it would mean if mainline Plasma development moved to a git repository outside of KDE's svn, syncing at "known good revision points" back to svn except during KDE feature freeze periods so that we can have development windows that make sense for Plasma without breaking KDE's release cycles. Downstream gets what they want (a tarball every 6 months) and Goldilocks gets what she wants. We could stabilize the Plasma code base wheneverit would make sense for Plasma and downstream can simply get whatever the last "good point" was when a KDE release happens. This effectively decouples release schedules from development schedules, not unlike what the Linux kernel has managed to do.
I don't think this will work if our merge cycle is longer than 6 months however: testers and new developers will likely work against what is in svn and I don't want to require people to have to use another repository just to get at Plasma. So the merge cycle would have to be shorter than 6 months to keep the illusion of "development done in svn".
Perhaps there's another answer, but something needs to shift because one development window size does not fit all. At the same time the road of "hundreds of individual repositories and tarballs released whenever they want" is not really an option either as that'd just be integration hell for everyone.
So there you go: ramblings with no real concrete answers .. yet. =)
Most of the plasmoids I personally wanted to work into 4.1 are getting punted to 4.2. WoC and a few other things sapped my time. Thankfully others have been working on plasmoids so we'll have some great new stuff there, I just wish I could've been able to play in Plasmoid land more (it strikes me as more fun than the infrastructure issues I deal with ;)
This is one aspect of the 6 month release cycle that I really don't like for Plasma: the punt rate increases. For some apps this is a complete non-issue, but for more complex bodies of code that are in high development states a 3 month feature window is just too tight to fit in more than a few things. The first month of a release cycle is usually not spent on new features in my experience, and the last couple of months in a 6 month cycle are spent stabilizing. What this means is that we spend half the year in non-feature development; over 3 years time a 9 month cycle (with 3 months of stabilization) gives me 20 months of feature dev while 6 months gives me 18 months. That sounds similar enough, but the windows are tiny in the 6 month cycle, meaning more punting which in turn means that many features will be delivered in 12 months time to the user rather than 9.
It's also pretty obvious to me that for other projects, a 4 month cycle is probably even more useful than a 6 month cycle. Web based CMS projects come to mind as a good example where 4 month cycles would be the "Goldilocks" (aka "just right!") cycle.
In fact, I suspect 4 months might the Golidlocks number for Plasma: 2-3 months of features, 1-2 months of stabilization and exercising those new features via plugins. Unfortunately, 6 is not very evenly divisible by 4 ;) so this wouldn't work for the current release cycle.
I know that 6 months is all the craze right now, mostly IMHO for the wrong reasons like "marketing" or "downstream synchronization", but also partly for the right reasons such as quick cycles with a known clock rate for better iterative development patterns. I really dislike the marketing and downstream control issues because the former is complete BS (I want to smack someone with a marketing textbook every time I hear them opine on how six month cycles are better for promo) and the latter is misplaced priorities (accommodating downstream by hobbling upstream is remarkably short sighted). Really it comes down to finding a way to satisfy different sets of priorities.
I spent some time today thinking about what it would mean if mainline Plasma development moved to a git repository outside of KDE's svn, syncing at "known good revision points" back to svn except during KDE feature freeze periods so that we can have development windows that make sense for Plasma without breaking KDE's release cycles. Downstream gets what they want (a tarball every 6 months) and Goldilocks gets what she wants. We could stabilize the Plasma code base wheneverit would make sense for Plasma and downstream can simply get whatever the last "good point" was when a KDE release happens. This effectively decouples release schedules from development schedules, not unlike what the Linux kernel has managed to do.
I don't think this will work if our merge cycle is longer than 6 months however: testers and new developers will likely work against what is in svn and I don't want to require people to have to use another repository just to get at Plasma. So the merge cycle would have to be shorter than 6 months to keep the illusion of "development done in svn".
Perhaps there's another answer, but something needs to shift because one development window size does not fit all. At the same time the road of "hundreds of individual repositories and tarballs released whenever they want" is not really an option either as that'd just be integration hell for everyone.
So there you go: ramblings with no real concrete answers .. yet. =)
ramblings on 4.2
I'm not feeling very well today; been having a bit of a hard time sleeping the last few nights and now I think I know why: my stomach was churning most of the day up until mid-afternoon. Feeling better now, but it seems I was probably fighting off some sort of bug. I don't tend to get really ill, I just get dragged down when I catch something. Anyways .. not very exciting nor what you probably care to read about. ;) It did mean that I spent most of the day being unproductive coding-wise; instead I soaked in the bath a bit and thought about various things. Here are some ramblings from that down time thinking.
Part of the 4.2 roadmap for Plasma is already taking shape in my head. Yesterday while talking with Chani and J.P. on irc, I realized something that is pretty obvious in retrospect (hindsight, 20/20, yadda yadda): containments have become the place to do both functionality customization (layouting, toolboxing, applet addition/removal controls ..) as well as background painting. These things are pretty orthogonal, however, and what you really want to do is mix and match between these two sets of functionalities as a developer.
There will be some odd ducklings that do everything themself: a MacOS X style dock, for instance, would want to control both the background painting as well as the layouting and applet selection. Fair enough.
But many will want to have a given style of functionality, but use the same background painting that exists elsewhere. Or vice versa.
So in 4.2 I'm going to explore adding some add-on functionality for containments: backgrounds and context menus. The latter was already planned, but the backgrounds as separate add-ons is a new idea driven by the understanding that to avoid lots of duplicated code we really need to have a way to share background painting.
This won't affect the "any applet can be a containment" situation at all, nor will it force containments to use these new add on categories. The containmnet will remain in full control, this will just provide a painless way to access work done by others.
Additionally, I'll need to go back and do some KConfig hacking again for 4.2. In particular, besides doing the API review for KConfigBackend so that we can confidently export that interface for 3rd party use in plugins, I need to make KConfigSkeleton aware of KConfigBase so that we can use KConfigGroup with it. Plasma uses KConfigGroup extensively in its config system, but KConfigSkeleton is unaware of it. This is due to KConfigSkeleton coming about before KConfigBase was really interesting or useful to write against; it was more a "behind the scenes class" versus the useful base class it is now. The problem for Plasma here is that this means we can't use KConfigSkeleton really anywhere, which sucks since it's a very convenient way to both define and document configuration systems. It also makes driving the configuration user interface simple (e.g. one line of code). We already have support for plasmoids from packages (e.g. scripted plasmoids) to have code-less configurations, but it doesn't actually work when it comes time to save the config due to this issue. It's too late for 4.1, so this gets moved to 4.2.
(edit: i completely forgot the following in the first run at this.. doh!)
4.2 will also be when we go for concrete binary compat, move libplasma into a libs module (perhaps even kdelibs?) and either split out the Package classes into KNewStuff2 or make KNewStuff2 use libplasma.
At least we'll have a happy Plasma for 4.1.
Part of the 4.2 roadmap for Plasma is already taking shape in my head. Yesterday while talking with Chani and J.P. on irc, I realized something that is pretty obvious in retrospect (hindsight, 20/20, yadda yadda): containments have become the place to do both functionality customization (layouting, toolboxing, applet addition/removal controls ..) as well as background painting. These things are pretty orthogonal, however, and what you really want to do is mix and match between these two sets of functionalities as a developer.
There will be some odd ducklings that do everything themself: a MacOS X style dock, for instance, would want to control both the background painting as well as the layouting and applet selection. Fair enough.
But many will want to have a given style of functionality, but use the same background painting that exists elsewhere. Or vice versa.
So in 4.2 I'm going to explore adding some add-on functionality for containments: backgrounds and context menus. The latter was already planned, but the backgrounds as separate add-ons is a new idea driven by the understanding that to avoid lots of duplicated code we really need to have a way to share background painting.
This won't affect the "any applet can be a containment" situation at all, nor will it force containments to use these new add on categories. The containmnet will remain in full control, this will just provide a painless way to access work done by others.
Additionally, I'll need to go back and do some KConfig hacking again for 4.2. In particular, besides doing the API review for KConfigBackend so that we can confidently export that interface for 3rd party use in plugins, I need to make KConfigSkeleton aware of KConfigBase so that we can use KConfigGroup with it. Plasma uses KConfigGroup extensively in its config system, but KConfigSkeleton is unaware of it. This is due to KConfigSkeleton coming about before KConfigBase was really interesting or useful to write against; it was more a "behind the scenes class" versus the useful base class it is now. The problem for Plasma here is that this means we can't use KConfigSkeleton really anywhere, which sucks since it's a very convenient way to both define and document configuration systems. It also makes driving the configuration user interface simple (e.g. one line of code). We already have support for plasmoids from packages (e.g. scripted plasmoids) to have code-less configurations, but it doesn't actually work when it comes time to save the config due to this issue. It's too late for 4.1, so this gets moved to 4.2.
(edit: i completely forgot the following in the first run at this.. doh!)
4.2 will also be when we go for concrete binary compat, move libplasma into a libs module (perhaps even kdelibs?) and either split out the Package classes into KNewStuff2 or make KNewStuff2 use libplasma.
At least we'll have a happy Plasma for 4.1.
Subscribe to:
Posts (Atom)
