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