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.
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@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@reactos.org http://www.reactos.org/mailman/listinfo/ros-dev
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
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@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@reactos.org http://www.reactos.org/mailman/listinfo/ros-dev
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
-----Original Message----- From: ros-dev-bounces@reactos.org [mailto:ros-dev-bounces@reactos.org] 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+coordina...
Where is the mailing list thread of the TC vote?
I can only find the UI Coordinator voting thread.
Casper
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
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.!
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.
-----Original Message----- From: ros-dev-bounces@reactos.org [mailto:ros-dev-bounces@reactos.org] 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
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
Hi Alex
On 10/15/05, Alex Ionescu ionucu@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
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
-----Original Message----- From: ros-dev-bounces@reactos.org [mailto:ros-dev-bounces@reactos.org] 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
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
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...