[ros-dev] Prelude to voting for the Testing Coordinator Roles andResponsibilities.

[Ge van Geldorp]

> From: WaxDragon
> 
> I understand it's your time, I've always tried to keep that 
> in mind when talking with the developers about bugs.  That is 
> also why I spend some of my own time trying to comprehend and 
> document the bug beforehand.

And I understand and appreciate that. After all, that's YOUR time :-)

> Again, I understand.  I take breaks from bugzilla and work on 
> other pet projects too.  The SBIT problem is an old one, and 
> wierd_w had been on the channel several times asking about 
> it, without much response, but he pressed on and kept coming 
> back.  After hearing his findings several times, I pressed 
> him to file a specific bug

Yeah, that's somewhat of a problem. People notify us of bugs all over the
place (IRC, mailing list, forum), it's difficult to keep track of them that
way. You have been doing a superb job of getting them into Bugzilla where we
can keep track of them.

> I've appreciated the work you have done for me

No no, please don't think of it as work I did for YOU, implying you should
be grateful or something like that. I do the work for the project. 

> I have tried to not hassle you.

Feel free to hassle me every now and then. I need a kick under the butt as
much as anyone else sometimes. I just wanted to explain that sometimes I
won't react (hmm, that's funny, I actually typed "reactos" there and had to
go back and change it <g>) to requests immediately, I just might be working
on something else at that moment.

> We let two specific blockers ship in the last release after 
> discussing with with the devs on IRC. There are "big" bugs 
> still in the tree, and I under stand that some of them will 
> take a long time to get fixed.  I understand we cannot force 
> people to work on anything.  I sent out a
> *tentative* blocker list for 0.2.8 and all I got was attacks.

Not entirely true. You listed 5 bugs:

805 - Shutdown issues
Hartmutt has provided a fix which I think takes the "blocker" status away
from it (it doesn't solve the root cause, but I think it fixes the stack
overflow which made Qemu hang so hard). I think I found a final solution,
it's attached to the bug, just waiting for comments by you and/or Gunnar.

493 - excessive repainting in tree-view controls
I don't agree this is a major/critical bug, but I do intend to commit the
fixes attached to the bug.

688 - AllocConsole fails on real hardware due to i8042prt
I've tried very hard to reproduce this, and I understand at least Martin
tried that too. It is obviously a real bug, multiple people have reported
it, but when you can't reproduce it it's very hard to even try to fix it
(especially since this is in a part of the code I haven't worked on before).

703 - ReactOS is a fat big. Minimum mem reqs exceeded.
At least some work has been done on this.

880 - Some dlls stop display output when starting in CLI
I'll fix it this week

I'd say your list did spur a lot of action. It just might not be immediately
visible. 

> I was just trying to prompt discussion about the next 
> release, but here we are.

>From my point of view, entering feature freeze for 0.2.8 made me switch from
"pet project" mode to "bug fixing" mode. I argue that starting a release is
the kick under the butt we sometimes need to get long-standing bugs
squashed.

> The main issue from my standpoint is that the Release 
> Coordinator should work with the Testing Coordinator.  
> Brandon and I were trying to work with Robert to train 
> another on doing releases, and when I got back that afternoon 
> from shopping, RC1 was built and up on sourceforge with a 
> rather large bug.

Yes, that is what RC1 is for. It is supposed to be made immediately after
branching, when entering feature freeze. It's status is basically no more
than that of a random svn version. Perhaps "RC1" is a misnomer. The problem
we had when deciding on the name is that calling it "Beta" would create
great confusion too: "What, has the ReactOS project switched from Alpha
status to Beta now? Wow, they must be almost done". Perhaps we should call
it "FF" (Feature Freeze) instead and rename RC2 to "CF" (Code Freeze)?

> Had we simply waited a day, we would have 
> been able to ship an RC1 without that single bug.  I just 
> wanted us to look good.

The point is to make the final release look as good as possible. RC1 is just
a throw-away snapshot. I'm not sure which "single bug" you are referring to,
AFAIK none of the bugs listed above was closed yesterday (one day after RC1
shipment).

> I think the TC is an important position that ReactOS needs, 
> due to it's complexity.

You have certainly convinced me of that, by setting the example what a TC is
capable of.

> However, I have decided to no longer 
> continue as TC, if I was even TC to start with.

I am really sorry to hear this and hope you will reconsider.

> It's arguments like these that hurt ReactOS more than anything.

I'd say not having arguments like these is going to hurt far more in the
long term. I expect the outcome of this discussion to be that everyone
involved is clear about the roles of TC, RC and developers during a release
cycle and exactly how our release process works. If we don't discuss it, we
will have mismatched expectations on every release to come.
Discussions tend to get heated sometimes, that just shows how much the
people involved care about the project. The one thing that does hurt ReactOS
is discussions not being conducted in a civilized, rational way, instead
being a flame war of personal attacks. And yes, I realize that I have been
guilty of those personal attacks too. That's why I started my original mail
"I'm trying to keep this as non-personal and technical as possible."
Obviously I failed in that (again) and I very much regret that.

Gé van Geldorp.