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 =)
Saturday, May 10, 2008
breathing together
Subscribe to:
Post Comments (Atom)
11 comments:
As a user all i can say is that kde 4 was, in my only point of view, much better stable and usable in trunk than in stable branche, before the change in plasma api of course.
So perhaps it is a good solution to have incremental month release, delayable, and when big changes have to be happen, like for WoC integration, make it in // in an other branche with no fixed planning release and with your one "breathing" and commit in trunk in the first day of a new short cycle ?
But perhaps that synchronization will be the hell ?
To avoid regressions each bug concerning an element affected in a // working branch should be fixed in the concerned branch before the trunk.
I make this remark after seen the situation with 4.0 releases but perhaps it is not the good release to consider for talking of such improvement ?!
Cheers and a big thanks for you're great work !
Fixing bugs within a branch first makes regressions more likely if the developer in question forgets to fix it in trunk as well. Fixing things in trunk first and eventually forgetting to fix it in a branch afterwards is not perfect but in my opinion more sane in the long run.
I don't like the idea of explicit development strategies, but I'd say that your proposed development methodology is called "Agile Software Developent" - something that actually came from the web-2.0 scene. Even the linux kernel is heading to this development model, but they'd never really admit it.
'I'd say that your proposed development methodology is called "Agile Software Developent"'
absolutely. i didn't invent it, i just like it ;)
Btw, the WINE people are currently also discussing these issues:
http://www.winehq.org/pipermail/wine-devel/2008-May/065388.html
Yes it is indeed much based on Agile methods. Looks very much like SCRUM. I'm sure you would like to read something about that Aaron (If you haven't already ;)).
>>> Sebas also proposes the rather radical idea of, "What if we never froze trunk?" Or, as he put it, "always summer in trunk".
better... "NeverWinter trunk" :P
Yes. YES. A working running release.
Any structure imposed on free software is evil. There are necessary evils (see svn). But evil nonetheless.
Simple rules. Trunk. Must. Build.
Great catastrophic or monumental rewrites happen off tree. No one can test them anyways, so the advantage of in tree becomes a liability.
Releases are recognized in retrospect. It will be stable when ... no longer applies. It was stable at X. That is the release.
Derek (who likes this more and more, and always has great ideas and time during freezes)
Hi Aaron! I've just tried the OpenSuse KDE 4.1 LiveCD - it *rocks!* Even at this early stage, I didn't have a single crash! Oh, and I love the new layout of the K-menu (with the tabs at the bottom) - MUCH better! It's far easier to use now, and you can find your way around very well. Looks like 4.1 is
going to be a real kick-butt release! Well done to all of the KDE devs!
Sorry, late to the ongoing discussion, but just have to add my two cents.
I always thought the most logical way to handle public releases would be by completely decoupling feature development, stability development and release development, leaving it to every single developer when to make use of which. In the case of KDE it would probably looks like this:
-Feature development happens in what's now called /trunk, is never frozen and by the very nature of being a moving target is likely to be broken and/or internally inconsistent. So this, let's call it /development, is only of use for the actual developers of each particular module.
-Stability development, let's call it /stable, is similarly to /development a moving target. But in contrary to /development the only actual development happening there is stabilising the code. New features and broken code are worked on only in /development, and defining a new feature or refactored code finished and thus merging it with /stable is an opt-in decision of every respective developer.
-Only release development makes use of (public) branches. The act of making a branch of a current /stable snapshot constitutes what's called a "feature freeze". Releases can be strictly time based, the duration for stabilising the code further from /stable can be adapted as necessary and possibly even be handle by distributors themselves while developers not wanting to bother with releases can focus on feature development in /development and, by voluntary opt-in choice, ensure the stability of finished code within /stable.
The advantages of doing this are plentyfold:
-Every developer and application can have its own schedule. If some particular feature doesn't make it a specific release the respective previous stable veersion is still being included. In case of KDE this neatly does away with the separation of core KDE stuff, KOffice and all the completely independent Extragear apps.
-Releases can be numerous. Since feature development and stability development are separated from release development it's no longer the releases that actually matter for developer. What matter is stable finished code, which can then be included in whatever upcoming release branch. Release branches then are limited to bug fixing, and can be done in short cycles like 4, 6 or even 12 times a year. Alternatively distributors could do release branches themselves as they see fit.
I surely missed the problem, as the above solution seems so straight forward to me that I'm surprised nobody seems to have thought of this before...
I still think that the idea is worth investigating even if it is on a non 6-month cycle.
But if you are certain there is no benefit to be had (or at least no benefit worth having) for upstreams within the framework of this idea...Then ok, you'd know better than I would.
Sorry to have aroused you unnecessarily.
Post a Comment