[ros-dev] Release process

[Jason Filby]

Hi

Yes, I'm also not happy about how this has all turned out. I too was
unaware of WaxDragon being the Testing Coordinator until recently
myself! Apparently it was all organized back in the 0.2.7 release in
the middle of a thread where a few individuals decided it should
happen. I have no problem with WaxDragon being Testing Coordinator,
but am not really happy with the way it was done. Apparently Steven
used his 'executive override' to put Wax in the position, and Alex was
going to talk to me about it later (which he never did). I eventually
emailed Andrew to figure out for myself what was going on (just this
last week). I really don't think it's too much to ask to consider
everyone else in the project and our existing processes.

Nobody appears to disagree with Andrew being Testing Coordinator (if
you do, now's the time to object). What is a problem, as Ge has said,
is that the role of the this coordinator has not been agreed upon.

I would say that the main concern of the TC is the formation of a
testing team. Until that happens, the TC is the testing team.

The Testing Team's responsibilities could include:
- Overseeing the BugZilla repository
- Working with developers to identify bugs, useful information
regarding them and confirmation of resolution
- Working with the release manager concerning blocker bugs
- Working with developers to maintain CIS and its tests (future)

We need to lay down some guidelines as to what constitutes a blocker
bug for a release. I would say these should be voted on if people
don't agree, not vetoed.

These are just some starting points for discussion - and really what
we should have done in the first place.

Regards
Jason

On 10/15/05, Ge van Geldorp <gvg at reactos.org> 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. 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.
>
>
> _______________________________________________
> Ros-dev mailing list
> Ros-dev at reactos.org
> http://www.reactos.org/mailman/listinfo/ros-dev
>