All together now: let’s kill the Release Team
The past view days I’ve witnessed some blogs and remarks on IRC-channels which are talking about a failure of the release team. As planets in general are the source of using more and more firm language, let me join the club: I don’t like them. Especially not the one which suggested to replace the release-team with the one doing the koffice releases (refering to the fact that they are labeling their release as alfa-release). Even though it was probably meant to be funny or something. It was not.
Troy indicates that we would be better of with a single release dude. I’m sorry but that is plain silly. In the lines above his statement he is blaming Ruurd to not say ‘plasma sucks, give me the old panel back’ with some very convincing arguments. In that light it is amazing that he ends his blog with ‘release team sucks, give me the (old) release dude back’. I wonder why this should be any different? Tell me exactly what the release-team did wrong and what the better alternative is, but please don’t forget to mention how the process can be improved. To be clear: I do agree it could be improved, but I’m not sure how to do it. But going back to a single release dude is a simplistic solution. Aaron already touched the subject in a recent blog.
The only reason I see mentioned in Troys blog is ‘there was less hesitation during decision making processes’. Sure. If one guy gets to decide, it’s pretty easy. If a group has to decide something there needs to be a discussion. Don’t confuse that discussion with ‘hesitation’, it’s simply not the case. It also does not say anything about the quality of the decision. Would the single release dude make better decisions than a group? A group can discuss pros and cons of a decision seen through the eyes of different people, which should lead to a bigger list of pros and cons and should lead to a better informed outcome. Or is it that people simply like firm statements better: this is how we are going to do it, no discussion possible.
It is true that the process of naming the releases is a bit difficult. We are constantly giving weight to the current state of KDE4 and what we want to reach and how to motivate people to do their part of The Job. One year ago there was no planning at all for KDE4. Since that moment we have decided on a planning, got people out of the ‘waiting’/'tinkering’-mode and we are now relatively close to a release. I believe that without a release team that would not have happened. Would it have happened with a single release-dude? We don’t know.
The release-team has answered a lot of questions on IRC (which is very difficult for a single release dude, considering contributions are made 24/7), kept the wiki up-to-date so everyone knows what freeze is active, which modules are problematic and discussed the inclusion/exclusion of some applications, coordinated with the marketing & promo & tagging team/persons about the release announcements, and all in coordination with the people doing the actual work on KDE4. The release-team is not a clearly defined group of people. It’s a mailinglist with people who discuss things, sometime people join a particular discussion and sometimes not. In my huble opinion this is working beyond my expectations, also considering this it the first time we try this.
I think it’s really demotivating to read that troy wants to return to a single release dude. I see this ‘careless demotivation’ happen a lot. People making simple, cheap remarks, but in the meanwhile hurting and demotivating others. Ruurd made a blog about Plasma – not so nice to read if it’s your code and you read that as the first thing in the morning. Troy about the Release Team. And it also has happened with some webkit remarks. Think twice.
+1 :) I completely agree with you. From my point of view as mostly an observer of the release team, I don’t think it’s a complete faillure. Nor a faillure at all. Sure the naming wasn’t quiet adequate. But in the end, KDE4 is going to be released, and that what matter. I also would like to point out, that the release-team is an open group where everyone is free to express his opinion, so if you are unhappy with the process, subscribe to the list and help it to improve !
Ok, i am just an average KDE user following the posts on the planet. I guess a lot of users feel like I do about the development process of KDE 4. We do not care if the current build is called beta or release candidate. We really admire all you people who spend a huge amount of time on KDE, many without even being paid for. Maybe you all should relax and step back a little for a moment.
There will be a great product in the end, thats the important bit. You are 90% there, its not the time to make people lose there motivation by excited , needlessly rude comments.
Great Project powered by many great people. Be proud erveryone!
By
Johannes
As somebody who’s purely an observer, the signs of “last mile” fatigue are somewhat apparent when reading PlanetKDE, the list archives, and even in some of the comments by high profile KDE people on sites such as OSNews. But all of the developers and other contributors should take head. I’ve used KDE since the 1.0 (Maybe pre-1.0) era, and I remember the 1 -> 2 transition, and the “Kurrent KDE Krew” are doing well. Most ‘actual’ KDE users are really cheering for ‘the team’ and want to see a decent KDE 4.0 release. Perfect, no, but decent. If it slips to January, but makes for a decent release, who cares? Your users will still be here and they’ll understand. It’s not like you sliding to Jan 2009. Even people who aren’t KDE users, but are even slightly ‘open minded’ (or not a partisan of some sort) should be able to appreciate the amount of seer effort going into this, and the great promise the KDE 4 holds. Keep your spirits up, don’t sweat the little stuff, and get it out sooinish… But don’t kill yourselves or each other in the process. You’re all doing great work! Thanks!
That’s “take heart” not “take head”, albeit I suspect a certain subset of developers would take either… :)
Disclaimer: my impressions are gathered by reading the release-team mailing list and core-devel, I am not involved in developing but a long time kde user (since 1.x days). I do not know what has been discussed via irc or on other channels, so I am most likely missing important parts of the big picture. Nonetheless, this is what I gathered from it, and since you asked for improvements and can think of none, I will offer my views here. Please disregard the things that I got wrong.
I personally think the truth lies somewhere between you and Troy. I do not think that one person should do all the release team work, but neither am I sure that is what Troy wanted to say. What I do think though, is that there should be someone choosen by those in the release team that acts as a spokesperson for the release team. He should not decide on his own, the team should decide. But he should be someone who says stop to people still planning changes after certain freeze dates, and does so with some authority. Someone who tries to rally the developers towards the main goal (a good release, and as soon as possible). I guess that is more work than a single person on the release team currently does, but probably much less than a single release dude would have to do.
I was quite surprised to read a planned refactoring in the libs on the day before they should be tagged as a rc. That was one of those times where I thought: what is happening here, is there some release coordination at all? It is quite amusing (sorry) by now to read about planned changes on core.devel, some 5-10 people replying and actually discussing the change before finally someone steps up and says, that this should not happen, the people should be in release mode. Since this happened more than once, it seemed as if quite a lot, if not most of the developers are not really been aware about the release state, the freezes that are supposed to be effective.
Some of the more fundamental questions (string freeze, when?) seem to have been discussed a little late. Probably because teams do have disadvantages as well: often no one feels the responsibility for something. If everyone does everything, then often no one steps up and starts a discussion, or at least it happenes a lot later than if someone knows he/she alone is responsible for that. So maybe, in addition to a spokesperson the team should also name certain areas for the members of the release team that they are responsible for. Say e.g. one general spokesperson with authority, one responsible for translation, documents and string freezes, one for modules, one for a list of showstoppers, … Those people should not decide on their own, but those people should be the ones that can answer questions of the other release team members, those should be the ones that raise certain questions as soon as they appear, and make sure things are discussed and decided as soon as possible.
As a user, I did (and still do) feel bullshitted about the release naming. It did start with the first betas, that in my eyes were alphas. By the time the last release was called rc1, I thought: well, thats still bullshitting everyone, but by that time I was used to it. Nevertheless I still consider it bad marketing. I even thought it would be pleasant if someone not following kde development closely would write a preview about kde and considering the last release candidate would write what he thinks of the state of the next kde (4.0, not 4) considering that release what you named it: a release candidate. I am quite sure a lot of people make their assumptions based on the name that the release is called, and they do so rightly. I am looking forward to Aarons explanation of why that was the best route still, but I am highly sceptical that it merits lying to the community (that is what I consider it, quite frankly – and by the amount of bitching e.g. on the dot or on the planet, I feel quite assured I am not the only one).
I would really have appreciated a more honest stand on the state of kde. Yes, I know release announcements are somewhat an advertisment, but those are good places to communicate what is supposed to work (that was done), but even more important, report some of the more important known issues, rather doing expectation management instead of adding to the hype that was built up.
As someone willing to test, I always wonder what I should report, as most things seem rather obvious. If there are rather obvious bugs all over the place, I am wondering if I am wasting my (and the developers) time by reporting it, or even by considering to report it and find out that it has been reported – assuming this must be well known by the developer. Yes, one could probably check out the sources and have a look at the TODO, but that is not really a convenient way for non-developers and should not be expected from community members. A page describing the current state would be nice, could probably be done by some community members (just not a single one) and would probably have helped a lot. Oh, a gerenal dot article on krush days would have been nice, it was “only” mentioned in the commit digest and some blogs, that article including a link to the bug list at techbase/Contribute/Bugsquad/KrushDays
Keep it up. I’m not all that involved in KDE, but I will say I’m looking forward very much to using screensavers and looping videos as my desktop background without all the hassle.
James, the release *can’t* slip to jan. If not for anything else, at least because everyone has booked their flights and accommodation for the release party already. That’s the curse of being a mastodont-sized project.