[ros-dev] Release process

Alex Ionescu ionucu at videotron.ca
Sat Oct 15 16:54:52 CEST 2005

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.

> 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
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 

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

More information about the Ros-dev mailing list