Release process

[Ge van Geldorp]

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.

[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(a)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(a)reactos.org
>  http://www.reactos.org/mailman/listinfo/ros-dev
>

[Alex Ionescu]

I think this explains it clearly and backs up my story:

[13:43] <@GreatLord> if I rember right  about TC
[13:43] <@GreatLord> I, Alex, Steven, and more more devlopper did say it 
was okay for wax be TC
[13:44] <@GreatLord> and a mail was sending out on mailing list about it
[13:44] <@GreatLord> and that time if I rember we did try getting hold 
on jasson
[13:45] <@GreatLord> for the tree was so instable
[13:45] <@GreatLord> something needed to be done
[13:46] <@GreatLord> at that time
[13:46] <@GreatLord> thx to WaxDragon we manger getting stable tree

You know, it kind of sucks when Jason was unavailable for months and GvG 
was on vacation, and we had to scramble quickly to save the project, and 
now I get the blame. Remind me not to do that again.

Best regards,
Alex Ionescu

[Jason Filby]

Hi Alex

Of course your contributions are appreciated. Of course nobody has a
complaint about Andrews work regarding testing. I have been somewhat
unavailable - due to factors outside of my control - but have still
tried to keep track of what's going on.

The complaint has been about how the TC was set up. I'm also sorry
that the Foundation and Project has been mixed up - this isn't your
fault. I share part of the blame with not clarifying this enough.

Regards
Jason

On 10/15/05, Alex Ionescu <ionucu(a)videotron.ca> wrote:
>   I think this explains it clearly and backs up my
> story:
>
>  [13:43] <@GreatLord> if I rember right  about TC
>  [13:43] <@GreatLord> I, Alex, Steven, and more more devlopper did say it
>  was okay for wax be TC
>  [13:44] <@GreatLord> and a mail was sending out on mailing list about it
>  [13:44] <@GreatLord> and that time if I rember we did try getting hold
>  on jasson
>  [13:45] <@GreatLord> for the tree was so instable
>  [13:45] <@GreatLord> something needed to be done
>  [13:46] <@GreatLord> at that time
>  [13:46] <@GreatLord> thx to WaxDragon we manger getting stable tree
>
>  You know, it kind of sucks when Jason was unavailable for months and GvG
>  was on vacation, and we had to scramble quickly to save the project, and
>  now I get the blame. Remind me not to do that again.
>
>  Best regards,
>  Alex Ionescu
>  _______________________________________________
>  Ros-dev mailing list
>  Ros-dev(a)reactos.org
>  http://www.reactos.org/mailman/listinfo/ros-dev
>

[James Tabor]

Hi Alex!

Alex Ionescu wrote:
>   I think this explains it clearly and backs up my
> story:
>  
>  [13:43] <@GreatLord> if I rember right  about TC
>  [13:43] <@GreatLord> I, Alex, Steven, and more more devlopper did say it 
>  was okay for wax be TC
>  [13:44] <@GreatLord> and a mail was sending out on mailing list about it
>  [13:44] <@GreatLord> and that time if I rember we did try getting hold 
>  on jasson
>  [13:45] <@GreatLord> for the tree was so instable
>  [13:45] <@GreatLord> something needed to be done
>  [13:46] <@GreatLord> at that time
>  [13:46] <@GreatLord> thx to WaxDragon we manger getting stable tree
>  
>  You know, it kind of sucks when Jason was unavailable for months and GvG 
>  was on vacation, and we had to scramble quickly to save the project, and 
>  now I get the blame. Remind me not to do that again. 
NOOOOO! You better not get the blame! I voted for Wax! I too should have
some say in this!

This was not some phuc-ing coup or anything like it. We needed someone who was already
testing and doing good work for the project. Wax knows the Ros tree just like the
rest of us. ATT Wax was able to find problems and fix them.

>   
>  Best regards,
>  Alex Ionescu 
This project has progress more than ever before. Debate is a good thing, monday
night quarter-back'en is BS!


Thanks,
James

[Casper Hornstrup]

>   -----Original Message-----
>  From: ros-dev-bounces(a)reactos.org [mailto:[e-mail]] On Behalf Of James
> Tabor
>  Sent: 16. oktober 2005 07:34
>  To: ReactOS Development List
>  Subject: Re: [ros-dev] Release process
>  
>  Hi Alex!
>  
>  Alex Ionescu wrote:
> >   I think this explains it clearly and backs up my
> > story:
> >
> >  [13:43] <@GreatLord> if I rember right  about TC
> >  [13:43] <@GreatLord> I, Alex, Steven, and more more devlopper did say it
> >  was okay for wax be TC
> >  [13:44] <@GreatLord> and a mail was sending out on mailing list about it
> >  [13:44] <@GreatLord> and that time if I rember we did try getting hold
> >  on jasson
> >  [13:45] <@GreatLord> for the tree was so instable
> >  [13:45] <@GreatLord> something needed to be done
> >  [13:46] <@GreatLord> at that time
> >  [13:46] <@GreatLord> thx to WaxDragon we manger getting stable tree
> >
> >  You know, it kind of sucks when Jason was unavailable for months and GvG
> >  was on vacation, and we had to scramble quickly to save the project, and
> >  now I get the blame. Remind me not to do that again. 
>  
>  NOOOOO! You better not get the blame! I voted for Wax! I too should have
>  some say in this! 
Google can't find the thread.

http://www.google.com/search?hl=en&q=site%3Areactos.org+testing+coordin…

Where is the mailing list thread of the TC vote?

I can only find the UI Coordinator voting thread.

Casper

[James Marjie]

Casper Hornstrup wrote:

>   Where is the mailing list thread of the TC vote?
>  
>  I can only find the UI Coordinator voting thread.
>  
>  Casper
>   
Casper,
	Below is the link to the message from Steven that looks to be the first 
about the TC. The thread is entitled Blockers. There may be more 
messages about the subject lying around thou'.


James Marjie

http://www.reactos.org/archives/public/ros-dev/2005-July/004245.html

[James Tabor]

Hi!
James Marjie wrote:
>   Casper Hornstrup wrote:
>  
> >   Where is the mailing list thread of the TC vote?
> >
> >  I can only find the UI Coordinator voting thread.
> >
> >  Casper
> >  
>  
>  Casper,
>      Below is the link to the message from Steven that looks to be the 
>  first about the TC. The thread is entitled Blockers. There may be more 
>  messages about the subject lying around thou'.
>  
>  
>  James Marjie
>  
>  http://www.reactos.org/archives/public/ros-dev/2005-July/004245.html
>  
>   
That is it!
My email,
http://www.reactos.org/archives/public/ros-dev/2005-July/004248.html

Thanks James M.!

[Royce Mitchell III]

James Marjie wrote:

>   Casper Hornstrup wrote:
>
> >   Where is the mailing list thread of the TC vote?
> >
> >  I can only find the UI Coordinator voting thread.
> >
> >  Casper
> >  
>  Casper,
>      Below is the link to the message from Steven that looks to be the 
>  first about the TC. The thread is entitled Blockers. There may be more 
>  messages about the subject lying around thou'.
>
>
>  James Marjie
>
>  http://www.reactos.org/archives/public/ros-dev/2005-July/004245.html  
Having looked at these messages, I remember seeing them.

However, no actual vote was instituted that I can see. Steven merely 
asked for thoughts.

Some ppl chimed in as thought it were already a vote, which is okay ( 
it's never a problem to advertise your position prematurely ), but the 
"comments" just kinda faded off and it wasn't picked back up again.

As is the case with most situations, it boils down to a lack of 
communication ( maybe we need a communication coordinator :P ). Then, 
being as we're all programmers, our egos flare up ( I'm guilty of this 
too ) and we start throwing stones because someone accidentally stepped 
on our toes.

The long and short of it is that there was an informal near concencus, 
Casper had some concerns about how and where to document the issues 
Steven was raising, but apparently everybody was too busy to follow this 
through, so the ball was dropped.

Hopefully we can move on now.

[Casper Hornstrup]

>   -----Original Message-----
>  From: ros-dev-bounces(a)reactos.org [mailto:[e-mail]] On Behalf Of James
> Marjie
>  Sent: 17. oktober 2005 02:26
>  To: ReactOS Development List
>  Subject: Re: [ros-dev] Release process
>  
>  Casper Hornstrup wrote:
>  
> >   Where is the mailing list thread of the TC vote?
> >
> >  I can only find the UI Coordinator voting thread.
> >
> >  Casper
> >  
>  
>  Casper,
>  	Below is the link to the message from Steven that looks to be the first
>  about the TC. The thread is entitled Blockers. There may be more
>  messages about the subject lying around thou'.
>  
>  
>  James Marjie
>  
>  http://www.reactos.org/archives/public/ros-dev/2005-July/004245.html 
But, where is the TC voting thread?

Casper

[Alex Ionescu]

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

[Jason Filby]

Hi Alex

On 10/15/05, Alex Ionescu <ionucu(a)videotron.ca> wrote:
>   cracks all over the place. I realized that the total
> lack of any real
>  project management was really starting to hurt the project. 
Well you can apply for project coordinator position when it's opened
up to vote before year end.

>   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. 
Board powers?? What are these board powers you're talking about?

>   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. 
I haven't really been gone, I've been watching, but have been really
short on time. I have especially looked out for any email directly to
me.

>   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'. 
I don't know which project you're talking about that has board
members, so I must be in the wrong place!

Regards
Jason

[Freworld]

Jason Filby wrote:

>  I don't know which project you're talking about
> that has board
>
> members, so I must be in the wrong place!
>   
>  
http://www.reactos.org/archives/public/ros-dev/2005-April/002723.html

Quote:

Currently our board of directors consists of long time
developers to ReactOS and Wine

Steven Edwards, Jason Filby, Alexandre Julliard, Brian Palmer and Rex Jolliff.


I think these people could be called "board members"?


>  Regards
> Jason
>   
>  
Greetings
Michael

[Casper Hornstrup]

>   -----Original Message-----
>  From: ros-dev-bounces(a)reactos.org [mailto:[e-mail]] On Behalf Of
> Freworld
>  Sent: 15. oktober 2005 17:54
>  To: ReactOS Development List
>  Subject: Re: [ros-dev] Release process
>  
>  Jason Filby wrote:
>  
> >  I don't know which project you're talking
> > about that has board
> >
> > members, so I must be in the wrong place!
> >
> >  
>  http://www.reactos.org/archives/public/ros-dev/2005-April/002723.html
>  
>  Quote:
>  
>  Currently our board of directors consists of long time
>  developers to ReactOS and Wine
>  
>  Steven Edwards, Jason Filby, Alexandre Julliard, Brian Palmer and Rex Jolliff.
>  
>  
>  I think these people could be called "board members"? 
Board of directors of the ReactOS Foundation, not the ReactOS Project.

Casper

[James Tabor]

Casper Hornstrup wrote:
>   
> >  Jason Filby wrote:
> >
> >
> > >  I don't know which project you're talking
> > > about that has board
> > >
> > > members, so I must be in the wrong place!
> > >
> > >  
> > http://www.reactos.org/archives/public/ros-dev/2005-April/002723.html
> >
> > Quote:
> >
> > Currently our board of directors consists of long time
> > developers to ReactOS and Wine
> >
> > Steven Edwards, Jason Filby, Alexandre Julliard, Brian Palmer and Rex Jolliff.
> >
> >
> > I think these people could be called "board members"? 
>  
>  
>  Board of directors of the ReactOS Foundation, not the ReactOS Project.
>  
>  Casper
>  
>   
I agree,
James

[Robert Köpferl]

I as the one who released the build can say the following:

As GvG, also I didn't know about the mentioned documents, nor about 
wheter they were agreed or something else. Off course, I might have 
informed myself, but it was not the first time I did a release. Since I 
see it the same way GvG does "release often" (and also with bugs) I did 
it that way. I have to admit, that I did't put any eye into bugzilla to 
look for blockers, but in my backmind this seemed not so necessary. So 
decided mechanical to not look out for blockers and just release. Of 
couse just after I had a little test in qemu.

So far.
At least: The release works (but shutdown) and ist testable. As I think 
exactly what "release often" means...