Release process - Ros-dev

15 Oct 2005


      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. 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.
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.
Naming Andrew TC is only a minor problem as far as I'm concerned, 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.
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. 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.
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. After branching a RC1
would be put out. Period. No mention of "we put out a RC1 when all blocker
bugs have been fixed and the TC has approved the release". 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.
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. 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.
The time-based releases started to go wrong at the end of last year. 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. I feel very
strongly that we should continue this, go back to the original plan of
making snapshot releases every two months. 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.".
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.
Gé van Geldorp.