also, i agree with troy and others that rc1 was not really a candidate for release. there is, however, very good reason why the decision to brand it rc1 was still the best option available. i'll be explaining this on the next linux action show, so if you're interested, tune in to hear my thoughts on the matter. even if you aren't, the linux action guys are worth tuning in to on their own merits. they even manage to make me laugh, which is pretty good for a linux geek show ;)
troy did mention that he feels we were better off with a release dude, as there was less hesitation that way. i empathize with this position, however, i think the counter points to keep in mind are:
- having one release dude means a single point of failure
- as kde grows, it's an ever growing weight for just one person to carry. i think that in the very near future, it'll get to the point that it will be beyond fair and realsitic to expect it of just one person. some might suggest we already passed that point.
- a team allows representation from several areas of kde, not just the "center" consisting of core libs developers but also from all of our app teams
- it gives us more hands to do the more ambitious things we desire, like good coordination with the public communications team
the annoyance with switching to a team is that we've never done it before, and first times usually tend to not be the most graceful or satisfying. but if we need to move to a team, it's better to do it sooner than later so we can get the clumsiness out of the way and start developing the methods we will need now. waiting until we hit that wall where one release dude is simply not able to do it all would be even more messy.
i guess it's kind of like the switch to cmake: holy crap did that suck in the process, but holy crap am i ever glad that we did that now. short term pain for long term gain.
way to improve the release team process are certainly welcome. i know of at least one frustrated extragear app guy that we'll hopefully have in a better place with the next rc.