.. 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. =)
Subscribe to:
Post Comments (Atom)
23 comments:
".. continuing my "I'm feeling ill, so am soaking in a bath" rambling thoughts:"
Two words: Waterproof Laptop
In effect you would be making KDE downstream of plasma if it was moved to an outside git repo ;) Not necessarily a bad thing either - anything can be solved with an additional layer of abstraction...
"making KDE downstream of plasma"
essentially, yes. i'm not exactly fond of that idea, but a 6 month release cycle borders on the stupid for plasma. it's neither long enough to avoid punting, but it's too long to do quick cycles. even if we went with 2 or 3 month cycles (so that it was evenly divisible into 6) it would end up with every 2nd or 3rd cycle being "missed".
ah well.
Maybe you should give to the 6 month release cicle another try. I mean, of course you feel frustrated because you were not able to work on the plasmoids which is much more fun than working with the infrastructures, but that had a lot to do with implementing WoC and other basic stuff. Maybe later when the code base of plasma is more stable you will feel more confortable with the 6 month release cycle.
What I want to say is that right now plasma is in a special time and under heavy development and maybe is not easy to know right now what's the development cycle that best fits it when it is more stable
@raul: yes, we'll probably do one more 6 month cycle just due to the library movement, but i really don't see 6 months ever being "right" for plasma except by occassional coincidence.
using the wrong development pace can kill an open project while using one that fits can make it go much faster. the roughly 9 month cycles of kde3 worked *really* well, while there is pretty interesting evidence that 6 month cycles have really put a damper on similar projects out there.
there really is no "one size fits all": the development window is really an assumption of the time it takes to move the code base forward in a meaningful fashion. also remember that not all projects will start developing new features right at day 0. often features appear "spontaneously"; open source doesn't tend to have these really strict, laid in concrete development paths. it's a lot more plastic than that, and so it's not just "do you need 4 months?" it's also "will 4 months be a big enough window to capture enough of the changes?"
6 months is just fine for the libs, which usually see sporadic development on an as-needed basis, and the small apps which usually don't get more than month or so of hacking time each per release in general. so those are small dev windows that get caught quite well by a 6 month net.
plasma, on the other hand, sees almost constant development and the work is usually non-trivial. i really don't see this stopping any time soon, either, even after we move to source and binary compatibility in libplasma.
i think projects like kdevelop, quanta, etc will find themselves in a similar world of pain.
so i think what may end up being an unintended side effect of this movement is that actively developed, non-trivial applications currently in svn end up moving to be more like the apps in extra gear.
in the end this may not be a bad thing. i'd *like* to see kde's base modules more conservative.
Why not have a "master" branch that is reasonably stable that syncs with svn and also other branches where the development happens?
With git, we can also easily create branches and merge them to "master" when they are done so that people working on something like making all background painting shared would not interfere with others trying to work on something else. This still allows for people who want to help with making background painting shared to be able to just "pull" the branch from the people who are working on it (like the Linux kernel does).
Aaron could be the "benevolent dictator" of plasma and control what goes into svn after ok-ing the changes (like pulling/merging a branch). This is basically what review board does now though... It would me much cooler/easier with git I think. Also, we can have pretty graphs with github.
@Thomas: yes, git would make a lot of things niftier. i didn't delve into that much because i really didn't want to start a vcs discussion; this is really motivated by the 6 month cycle, not svn annoyances.
So here's a thought... If you want to decouple the KDE and Plasma release cycles, have you considered some sort of pipeline model?
You could have two mainline branches: "Stable" and "Devel". (Stable can be KDE SVN, if you like.) There would also be N feature branches for stuff that's in progress. These would likely be owned by individual devs, and would come and go as features are developed and stabilized.
Features should be developed in the branches, then pushed to Devel once the biggest and most obvious bugs have been worked out. (Have the feature dev(s) use it and bang on it for a bit.)
Once in Devel, you will (hopefully) have a wider audience for testing, as all the Plasma devs, and anyone who wants bleeding-edge, would likely use Devel.
Features have a chance to stabilize in Devel. They will get wider exposure and testing, exposing less common or less serious bugs. (If you are concerned about Devel's stability, you can enforce a merge window similar to Linux's.)
Once a feature has cooked for a while in Devel, it can be pushed to Stable.
Stable means what it says. Fixing bugs in Stable should always be top priority. The goal is for Stable to be high-quality to the point that it can be used for a KDE (or Plasma) release at any point in time.
You can choose to make a release from Stable whenever you wish. Features that happen to be in Stable get released, and those that aren't, don't. (So if a feature happens to be in, great, if not, too bad -- maybe next time.)
This does two things for you: (a) it insulates you from the KDE release cycle, and (b) allows you to make frequent, stable releases on your own schedule.
If Linux is any indication, the main challenge will be getting enough people to test Devel. The danger is, features get developed and merged, but not enough people test them to get 'em rock-solid before merging to Stable.
I know this isn't a VCS discussion, but as thomas pointed out, git can really help you here -- Subversion merging (at least in 1.4 and earlier) is migraine-inducing.
(Disclaimer: I synthesized a lot of this from reading what others have written on the subject, particularly on KernelTrap. I've tried models that are similar, if simplified, and they have worked well for me in the past. IANALinus. YMMV. Never said it was a good idea, just an idea. ;) Hope it helps.)
@deskitty: that's essentially what i proposed in the blog entry, albeit not with as much detail as you laid out.
I've been rather deeply concerned about a) the switch to a 6 month release cycle and b) the duration and severity of the feature freeze. Am I correct in saying that one may not even complete already started features during the freeze? This sounds counterproductive to me - nothing messes up a code-base or demoralizes developers like having to tear out a feature that they've been working on for some time and which they could easily stabilise in time for release just because of some arbitrary and draconian deadline.
I don't really want to criticise the Release Team as I know they are volunteers and skilled people, but I am frankly failing to see an upside to either decision: the adoption of a 6-monthly release cycle seems to be based on little more than "$competitor does it; Shuttleworth wants it" (although I can readily see the benefits of longer but still constant time release); and the capital-H Hard-ness of the freeze doesn't seem useful in a volunteer-driven community where motivation of developers is paramount.
I'm especially unimpressed with pandering to Mr Shuttleworth, whose actions towards KDE (but not, of course, his words) have always been ambivalent at best: for all his talk of making Kubuntu a "first class distro", he has done remarkably little to make this happen, and I suspect he would not have hired Jonathan had he not made a rather public appeal. His rather cynical and transparent stunt with the KDE T-Shirt on the eve of uncertainty about Novell's attitude to KDE a few years back, coupled with empty promises about factoring the lack of KDE developers into his hiring strategy a few years back (the last person that I know of to be hired by Canonical was Mirco "MacSlow" Mueller - a very talented and, by all accounts, pleasant man, to be sure, but I take it as just further evidence of Mr Shuttleworth's commitment to Kubuntu) make it clear to me personally that loudly proclaiming "Look, Mr Shuttleworth, we've switched to a 6-month release cycle, just like you wanted!" isn't going to change his actual stance towards KDE one iota.
Assuming I'm correct about the definition of the Hard freeze, this also seems to be a questionable decision: it leaves a very tiny window for large-scale changes; means that new developers with small, risk-free itch-scratches will be turned away for an entire third of the year; penalises areas of KDE which are doing acceptably well for stability but which really need features (Plasma is just one example) and just seems to be occurring at entirely the wrong phase in KDE4's cycle: Qt4 and kdelibs allows great things to be accomplished with unprecedentedly small amounts of work and KDE4 needs this - criticisms so far have not been about stability but about *features*, and a 6-month cycle with a 2-month freeze, as you note, is just a really bad environment for new features and really constrains developers. I hope the Release Team are going to be flexible about this and adopt a longer release cycle if this proves to be sub-optimal.
Anyway, this is rapidly degenerating into a rant, so I'll cut this short by simply stating that I'm glad at least one "higher up" in KDE shares at least some of my concerns :)
I have the same kind of concern for the KOffice schedule, once 2.0 has been released we are going to a time based schedules, and some people seems to favor the 6 months schedule for the wrong reason of aligning ourself on distributions (while anyway there are distributions releases all the time, so I don't understand how it should matter).
While in fact, I agree the fact that end-users features, and infrastructure don't have the same time requirements. That's why I wonder if a two-times schedules couldn't be a good solution : 9 monthes for regular changes, and a 4.5 monthes for plugins.
"Am I correct in saying that one may not even complete already started features during the freeze?"
if a feature has been started, you can complete it. if it hasn't been started by the time the hard freeze sets in, it's too late and will have to wait until the next release.
in that sense, it's no different than what we've always done.
"I can readily see the benefits of longer but still constant time release"
yes, i also quite like time based releases. it's just the coupling of downstream needs (every 6 months) with upstream development (not just releases) that i find dubious.
also, it's not just ubuntu that does this now; fedora does as well. opensuse still has their mostly-time-based release schedule but it isn't 6 months iirc, more like 8-9.
in any case, i'm really ambivalent to any pandering that may or may not be going on. i just know that 6 months is a poor fit for plasma, and i'd like to find a way to fix that. =)
"if a feature has been started, you can complete it. if it hasn't been started by the time the hard freeze sets in, it's too late and will have to wait until the next release."
Ah, that's something of a relief, and something that is most definitely not clear from the text on the Schedules page:
http://techbase.kde.org/Schedules/KDE4/4.1_Release_Schedule
This goes quite some way to dispelling my fears (phew!), but I definitely agree that a 6-month cycle definitely isn't really suitable for Plasma.
Dont stabilise? If by downstream & marketing you mean Canonical & Novel.
If you were to drop the stabilisation to just "get stuff working", then push it out to the marketers and pander to the downstream. Let them fix bugs & truly stabilise it, then integrate their fixes into your code. e.g
release 4.1>release 4.2>include 4.1 fixes>release 4.3 or release 4.1>work on4.2>include 4.1 fixes (to say 4.1.1)>release 4.2
This drops the stabalisation to maybe a month, giving you 24 months of feature dev, it also outsources the bug fixing, and gets products more testing.
OTOH it releys on others, and means only .*.1 releases are worth using.
I dunno, probably not worth it. sounds like an 8/9 month cycle would suit you best
Well, if you stop breaking ABI/API compatibility each major version (not a criticism, just a fact), you can add more plasmoids in dot releases (say for example 4.1.1).
I thought you had said a lot time ago that plasmoids won't follow KDE release cycle, and that would be one of it's advantages over old kicker/kdesktop. What happened to the idea? Will happen only after 4.2, or do you plan to break things from 4.2 to 4.3 again?
As I said, no criticism, just curious.
Just a note:
From a user perspective, 6 month release cycles are a way to go, it's just excellent.
More than that, I would like to see distros syncing theirs releases, so all of them would use the same kernel/libs/desktop version.
It would be MUCH EASIER for developers of small projects.
Bad for KDE/Plasma?
Good for kde-apps.org.
Sad that someone loses on that timing scheme, but I believe most cool apps that run in KDE today are not from KDE team itself, such as amarok, k3b, video encoders, k9copy, subtitle editors and such.
Even my beloved Quanta+ can't be said to be really a KDE team product yet, it's just like a external developed one that uses kde releases and svn :)
FYI, Fedora releases happen very close to the Ubuntu releases, so if you align to the Ubuntu schedule, you'll align to Fedora's too as a side effect. On the other hand, Fedora is pretty flexible about post-release version upgrades (within reason of course, there's no way we would upgrade a release which shipped with KDE 3 to KDE 4, for example!), so aligning to Fedora's schedule might not be all that useful.
How about this proposal: Drop the global feature freeze, let the individual application maintainers decide when to accept what new features. Just make it clear that KDE will not slip to accomodate individual applications, it's their reponsibility to make sure they have something releasable when KDE releases. In part, this is similar to the "Dont stabilise?" suggestion, the difference is that components which are really critical and/or expect to really need that much time to stabilize could still follow the same strict schedule, but implementing a small feature in a small application wouldn't have to follow the freezes as long as it's ready in time for the release. On the other hand, I'm not sure how much this would help for Plasma because it's one of the most critical components.
@Iuri Fiedoruk
Depending on where you draw the line what a KDE-project is and what not, nothing or everything can be. But that's your decision since it's your line :)
I think feature branches are pretty important for 6 month release cycles really. With something like Plasma it's pretty important to have the latest thing "out there" since it's still being finished up.
But once things calm down, having a feature branch that is put into the trunk only when Plasma (or whatever) feels like it would make sense. Or a separate branch for each feature even. In this way different components could set their own release cycle.
Here's hoping that KDE moves to a revision system that makes branching easy! (Or SVN could be less stupid).
@Ian: yes, i'm all for feature branches. that doesn't really address the issue either though: when do features get pulled in, when do we do integration particularly for non-orthogonal patchsets, how do we manage the core ... etc
having feature sets outside of mainline and saying, "well, we'll just merge them in whenever a 6 month cycle and their maturity coincides" brings us right back to the rapid punting issue where things get delayed more than necessary.
even worse, we now get to track N branches against that 6 month cycle and ask people to either not develop once they hit a certain point of stability and wait for a merge point or to make "releases" of their branch.
all this overhead is really quite inefficient and raises the odds of features languishing in odd states.
and i don't think the above is theoretical at all. we have other projects doing 6 month cycles of similar complexity and topic to learn from.
Why not break Plasma down into 2 development branches. One for six month releases and one for 1 year development. Yes one year is a long time, but right now the releases are perfect for getting them well implemented into distros.
The six month development would be for smaller features and would be merged often with the 1 year branch which in turn would be for the major features.
6 month release cycles no doubt are good for *users* (including distros with the same frequency).
So if 6 months cycles are sub-optimal for *developers*... why don't developers simply use the karma they have to do what they like best?? After all, developers are in command more than users.
Devs'n'users is *not* a chicken'n'egg problem; any good developer with no initial user base at all can start a project on his own. As soon as his product is released in a good enough shape it will attract users; he can't even avoid that.
The contrary isn't true. A user with no developer skills can't start any project... (Wait... he may be able to "convince" a developer to do it for him.)
So, if developers would be using their karma, their developer skills, plus a little bit of additional smartness, they'd come up with the following model:
* Yes, we'll release 4.1, 4.2, 4.3,... every 6 months.
* But... we'll take our time to give you really, really big new features.
* That means for you: with 4.2 we'll give you lots of new features.
* After 4.2 is out, we'll start to work in 2 "branches" in parallel: one will be bugfixing mostly (that's the 4.3 in 6 months), the other one will bring again a big swamp of new features (that's a 4.4 in 12 months).
Think about this, and come up with your own variation of it (like, having two branches permanently: one "stable", one "unstable", similar to Debian. "Unstable" feeds "stable". Only that the "stable" gets packaged released every 6 months, and the "unstable" is a rolling development "release").
Post a Comment