Darn when I was hoping to take a break from lengthy emails!
Ge van Geldorp wrote:
I'm trying to keep this as non-personal and technical as possible. I did include names, most people will guess the names anyway.
Yesterday, Robert announced on the IRC channel that he had put RC1 on SourceForge. Immediately, some people jumped on him, demanding to know why he did that without the approval of the Testing Coordinator.
Ok, that's an exageration and you're using it as an argument. *I* jumped on him because I was angry that a buggy release was made. I made a quick and incorrect statement in the rush ("why didn't this get Andews's approval"). After you left, several people came and complained about the RC1 bug, including on the mailing list, by the way. The users are not happy.
This surprised me very much. Not only do we all of a sudden have a TC (I'm not the only one surprised about that: http://www.reactos.org/pipermail/ros-dev/2005-October/005250.html), but it seems that the TC has veto powers over publishing as well.
I think I've made it clear that's not what I intended. You can see that on the Wiki page there's no such thing. You're making a big story out of someone that was said in a rush on IRC. That's not really profesional. I thought we had said that a new release process would be drafted on and voted, note that you'd send out an email like this that is highly confusing to everyone and higly incorrect, which I now have to set the record straight.
Please don't get me wrong, I think Andrew (WaxDragon) is doing a great job with the testing (much of the increased stability can be attributed to better testing), and I certainly would have voted for him if such a vote had taken place. But that's the problem: Alex put a page on the Wiki (http://www.reactos.org/wiki/index.php/ReactOS_Testing_Coordinator) and appointed Andrew as TC. In my book, that makes him Alex' testing coordinator, not the ReactOS project testing coordinator.
Your book is once again wrong, because you decided to assume that I simply made Andrew the TC. Maybe you should have asked for details instead of assuming... The appointement of the TC was done at a time when the failed ReactOS release and testing model was starting to show cracks all over the place. I realized that the total lack of any real project management was really starting to hurt the project. Bugzilla was almost unused and it didn't really mean anything. Regression testing was done only before releases (the wiki page states this clearly), and releases themselves were following a model which would be laughed at in the real world (again, several people on IRC backed this up when I said it last night). One of the steps I took to save the project from the abyss it was moving to is to discuss with some people the position of a TC. Since time was running short, I made the "vote" quickly on IRC, while I looked for Jason to give the executive seal of approval. Since he wasn't there, I talked to Steven instead. Steven used his board powers to make Andrew TC, but additionnally he posted on the ML telling people about this, and asking if anyone had any objections. None were made.
Naming Andrew TC is only a minor problem as far as I'm concerned
The problem, to put it bluntly, is that you werne't paying attention. Maybe it was during your vacation. Just don't blame me and stir up shit on the mailing list because you're not informed. It's funny that you chose Jason as another example of person that wasn't informed. He too has been gone for 3-4 months and missed a LOT. I never informed him, but I thought Steven would.
, after all, he's the right guy for the job, the only problem is the procedure followed. I do have a major problem with the role definition as presented on the Wiki though. I want to focus on "The TC can decide as his will which bugs to promote to Blocker status (thereby blocking a new release)" for now. This is simply unacceptable to me.
Now this I can accept and deserves some looking into, although it comes extremly late.
End of 2003, beginning of 2004 we've had a long discussion about the release process. In the end, general concencus was reached on the text presented here: http://www.reactos.org/wiki/index.php/Release_Management_Overview. There was no formal vote, since we didn't do those at that time, but at the time it was very clear that everyone agreed to it.
Hmm, sounds familiar. Except this time the appointement was formal.
As far as I know, no ammendments to this document have been approved, so it still stands as a valid, agreed-upon process for the ReactOS project. (To make it absolutely clear: the TC Wiki page is just some text that someone wrote, it does not have the same status.) If you feel that the Release Management Overview is not up to date or otherwise needs to be changed, draft an amendment and put it to vote. Until that happens, we're all bound by the current version.
It's also funny how you mention this document and are suddently so concerned about project management. Do you realize that nobody in this project has been following the guidelines in there? If it's our Bible, then we're all sinners. Let's start with the part about "release often". I have never seen anyone here respecting that rule since I've joined. Instead, it seems like it has been "release when there's something to show". It's ONLY started to been "release often" after Andrew became TC and started prodding people about making more releases. So it's very nice and all that some document on the wiki which was barely added recently is supposedly official, but it wasn't voted on, I was never aware of it (heck, I wasn't even part of the team back then) and it wasn't even respected. In my book, that falls in a very bad category.
At the time, we agreed we should do time-based releases, a new release every two months. Basically it would be a snapshot of the tree at that time, much like the Wine project does with its monthly releases.
Well, there haven't been time-based releases for over 1.5 years. So the validity of that document comes into question.
After branching a RC1 would be put out. Period. No mention of "we put out a RC1 when all blocker bugs have been fixed
This is normal development practice. I wasn't aware we decided to write our own book on it. "Release Candidate" means "CANDIDATE for RELEASE", in other words, "We think this is ready to be released". In product development, the RC stage is used when all blocker bugs have been fixed and you want to find last minute bugs which you are usually not expecting. That's why it's called RC.
and the TC has approved the release".
I'll say it again, you're once again referring to somethign I said by mistake. You probably know this too, but it's a big part of your argument.
On the contrary, the reason to put out a RC1 was to find as much bugs as possible and hopefully fix them before the final release.
That is called a "Beta".
The idea behind the time-based releases is "release early, release often" (see the famous Cathedral/Bazaar article, http://www.catb.org/~esr/writings/cathedral-bazaar/cathedral-bazaar/), you release even if you know about some bugs.
I totally agree with release early, release often. Too bad nobody has been doing it until "I" (sarcastic emphasis) put Andrew as TC.
So, do I think we shouldn't have "blocker" bugs at all? Let me put it this way: if none of the 30 devs feel a bug is important enough to be fixed in the feature freeze period before a release, I do question the severity of the bug.
I wholehearlty agree. The Wiki page you referred to mentions that if only 3 devs feel that way, then the severity should be questionned. But I hope you're not referring to the Alloc Console bug, which started all this. The one that some user on the ML just posted how much it's important to get this fixed. The one that THREE users in the last 12 hours on IRC alone talked about. I certaintly hope 30 devs don't think a bug which basically makes ReactOS useless on real hardware is not a blocker.
The time-based releases started to go wrong at the end of last year.
Probably when I joined.
0.3 seemed around the corner at that moment, so we decided to postpone the release a bit (we did that before with the 0.2 release, which worked out ok). But now, one thing lead to another, and we completely forgot about the release schedule.
Yup...
I was very pleased to see we were picking up the schedule again, with 0.2.8 being released 2-3 months after 0.2.7.
Thanks to Andrew.
I feel very strongly that we should continue this, go back to the original plan of making snapshot releases every two months.
I agree. But I didn't see you fire off an angry email like this when the original plan stopped being "respected". You have however, now that an "official" modification was made through IRC/Andrew: the fact that RCs would start behaving like RCs.
Of course, we should try to stabilize the releases as much as possible, but I would like to remind everyone of this quote from the Wine release announcements, which applies to us equally well: "This is still a developers only release. There are many bugs and unimplemented features. Most applications still do not work correctly.".
I've never seen WINE knowingly make a release which doesn't work for 80% of the userbase.
A final word of support for Robert: He did EXACTLY what he was supposed to do by placing RC1 on SourceForge and I completely back him on his decision.
If he followed the release rules, then yes he did. But here's MY problem:
This whole email is basically criticising the fact that Andrew was put as TC by me alone and that I've changed the release rules. I'll make it clear again. Andrew was made TC by an OFFICIAL means, and there WAS a posting on the ML about it. Some of the board members made the decision, and it was 100% official and people on IRC at the moment were aware of it. It wasn't a one-day thing. If you missed the discussion, that is NOT my fault, or Andrews'.
As for the release rules, I was NEVER aware of that document. Let's see when it was added: 22:40, 14 Oct 2005 http://www.reactos.org/wiki/index.php/Release_Management_Overview GvG http://www.reactos.org/wiki/index.php?title=User:GvG&action=edit
Yesterday!!! How on Earth was I supposed to know about it? It was voted by probably only 5 people that are still working on ReactOS today, over 2 years ago, and never put on the Wiki. How should people which joined only last year know about it? Especially since it hasn't been respected? You are questionning Andrew's appointement because to you it looks like "Alex just wrote the page and decided it that way", since you were gone during the discussion. Well, how would you feel if I posted an email saying "Hey, I don't like those releases rules...a vote was never done on it, they are irrelevant, and it looks ilke GvG just wrote a Wiki page on it, which has no formal approval."? Because it would be quite similar to this one.
Like I thought we had mutually decided last night, I will draft a new release process (one which takes into account what the rest of the world means by "Release candidate"). And it WILL include release often, release early. And thanks to Andrew maybe that can be respected now. The only changes I ever proposed, which other people seemed to have agreed to, is continous regression testing thanks to a TC (the old document states that regression testing is only done before releases. This proved to be a horrible design idea), and that RCs wouldn't be called RCs unless they ARE RCs.
So, I apologize if I was harsh to Robert yesterday, I didn't know he was following rules that I wasn't personally aware about. According to that official document, then the release of RC1 was OK. Yeah, the release which most users can't install and use. That's why the document is broken.
Gé van Geldorp.
Best regards, Alex Ionescu