It's only been two weeks since I sent out the August State of the Repository, but the tree has already had 271 revisions. There have been several large commits, and trunk has had several build breakages, and instability in general. Just today we had three commits reversing and unreversing some of Alex's changes. I'm calling for a trunk freeze until several issues have been addressed.
* The release build is broken. So far the string library and the usb code have been fixed. I was working with Alex on a break in the exception handling when this topic came up. * There seems to be a mysterious hang when shutting down ReactOS in qemu. I've seen it personally and heard reports of it, but since it locks up qemu so bad you can't free the mouse, no one has gotten a trace (that I am aware of). * Gunnar's win32k changes introduced several bugs, many of which were fixed, but I still feel unsure about others that may be hiding. * Hartmut fixed the MP build. See, I didn't even know that was broken.
I would like to freeze the tree for 72 hours, over the weekend, allowing bugfixes only. I think we all need to grab a fresh copy and run it under every platform we have, checking all the options.
According to the rules set forth, I need three developers. Who agrees to a trunk freeze?
WaxDragon wrote:
It's only been two weeks since I sent out the August State of the Repository, but the tree has already had 271 revisions. There have been several large commits, and trunk has had several build breakages, and instability in general. Just today we had three commits reversing and unreversing some of Alex's changes.
I'm calling for a trunk freeze until several issues have been addressed.
- The release build is broken. So far the string library and the usb
code have been fixed. I was working with Alex on a break in the exception handling when this topic came up.
There's only that annoying ctype problem in rtl, afaik, which should be fixed by including the modified ctype.h from ntoskrnl.
- There seems to be a mysterious hang when shutting down ReactOS in
qemu. I've seen it personally and heard reports of it, but since it locks up qemu so bad you can't free the mouse, no one has gotten a trace (that I am aware of).
I don't have a hang...I used to have a crash in shell32... but now I have introduced a bug which makes the stack trace printing inside kernel32 crash, which causes a bsod. And yeah, I'm working on fixing this regression. Note however that there is a shutdown crash which I didn't cause though. Reverting prior to my changes should get you a trace.
- Gunnar's win32k changes introduced several bugs, many of which were
fixed, but I still feel unsure about others that may be hiding.
Agreed, there needs to be done a LOT of testing.
- Hartmut fixed the MP build. See, I didn't even know that was broken.
We all need to get VMWare 5.5 and start MP testing :)
I would like to freeze the tree for 72 hours, over the weekend, allowing bugfixes only. I think we all need to grab a fresh copy and run it under every platform we have, checking all the options.
I totally agree.
According to the rules set forth, I need three developers. Who agrees to a trunk freeze?
I do.
Best regards, Alex Ionescu
Alex Ionescu wrote:
WaxDragon wrote:
It's only been two weeks since I sent out the August State of the Repository, but the tree has already had 271 revisions. There have been several large commits, and trunk has had several build breakages, and instability in general. Just today we had three commits reversing and unreversing some of Alex's changes. I'm calling for a trunk freeze until several issues have been addressed.
- The release build is broken. So far the string library and the usb
code have been fixed. I was working with Alex on a break in the exception handling when this topic came up.
There's only that annoying ctype problem in rtl, afaik, which should be fixed by including the modified ctype.h from ntoskrnl.
- There seems to be a mysterious hang when shutting down ReactOS in
qemu. I've seen it personally and heard reports of it, but since it locks up qemu so bad you can't free the mouse, no one has gotten a trace (that I am aware of).
I don't have a hang...I used to have a crash in shell32... but now I have introduced a bug which makes the stack trace printing inside kernel32 crash, which causes a bsod. And yeah, I'm working on fixing this regression. Note however that there is a shutdown crash which I didn't cause though. Reverting prior to my changes should get you a trace.
- Gunnar's win32k changes introduced several bugs, many of which were
fixed, but I still feel unsure about others that may be hiding.
Agreed, there needs to be done a LOT of testing.
- Hartmut fixed the MP build. See, I didn't even know that was broken.
We all need to get VMWare 5.5 and start MP testing :)
I would like to freeze the tree for 72 hours, over the weekend, allowing bugfixes only. I think we all need to grab a fresh copy and run it under every platform we have, checking all the options.
I totally agree.
According to the rules set forth, I need three developers. Who agrees to a trunk freeze?
I do.
Best regards, Alex Ionescu _______________________________________________ Ros-dev mailing list Ros-dev@reactos.com http://reactos.com:8080/mailman/listinfo/ros-dev
I agree.
Alex Ionescu wrote:
- Hartmut fixed the MP build. See, I didn't even know that was broken.
We all need to get VMWare 5.5 and start MP testing :)
The MP build will run on each computer which can run windows in apic mode. It will also run in vmware without smp support if the host is apic capable. It exist one problem. It is always copied halup.dll to hal.dll. I do always change the line with 'nameoncd' in halmp.xml and halup.xml.
- Hartmut
I can't boot ReactOS with MP HAL (but compiled with SMP=0) - it hangs in VMWare 4.5 on the "Loading disk.sys". I remember some time ago it hun on "Loading buslogic.sys" but I just deleted it.
Installation of WinXP in the same virtual machine goes with installing APIC HAL.
I tried investigating these problems, because interrupts are not being delivered to the uhci driver, in VM it's placed either on IRQ 9 if normal HAL is used, and on 0x19 if APIC mode is used. I'm currently out of ideas why it doesn't work.
WBR, Aleksey.
On Sep 16, 2005, at 11:35 AM, Hartmut Birr wrote:
Alex Ionescu wrote:
- Hartmut fixed the MP build. See, I didn't even know that was
broken.
We all need to get VMWare 5.5 and start MP testing :)
The MP build will run on each computer which can run windows in apic mode. It will also run in vmware without smp support if the host is apic capable. It exist one problem. It is always copied halup.dll to hal.dll. I do always change the line with 'nameoncd' in halmp.xml and halup.xml.
- Hartmut
Aleksey Bragin wrote:
I can't boot ReactOS with MP HAL (but compiled with SMP=0) - it hangs in VMWare 4.5 on the "Loading disk.sys". I remember some time ago it hun on "Loading buslogic.sys" but I just deleted it.
Our mp hal will not work with SMP=0, because the generic part from hal must be compile with SMP=1. The mp hal will not work with the up ntoskrnl, because there are some differences in ntoskrnl\ke\irq.c. You have to build a mp system and you have to modify the nameoncd line in halmp.xcl and halup.xcl to copy the correct hal to the boot cd.
- Hartmut
WaxDragon wrote:
- There seems to be a mysterious hang when shutting down ReactOS in
qemu. I've seen it personally and heard reports of it, but since it locks up qemu so bad you can't free the mouse, no one has gotten a trace (that I am aware of).
Do you mean hundrets of lines like this: ... (subsys\win32k\ntuser\window.c:589) Unable to destroy window 0x870d889c at thread cleanup... This is _VERY_ bad! (subsys\win32k\ntuser\window.c:575) thread cleanup: while destroy wnds, wnd=0x870d889c ... (subsys\win32k\ntuser\wintoskrnl\ex\power.c:90
After the last line, the cpu runs in KiHaltProcessorDpcRoutine in an endless loop. The blue screen shows the 'famous last words'.
- Hartmut
Consider TRUNK frozen. Please, no new features/functionality until 1200 GMT Monday. Please use this time to test any patches you will be submitting soon, or help hunt current bugs. I would like to thank everyone for the work already done, the release build has been fixed.
WD
Well, 17891, 17892, and 17893 are NOT bugfixes. Could the committers explain why these changes were checked into a frozen trunk?
Well, after Casper told me that Freeze process was never voted on, I guess this whole excersice is pointless. I was told to maintain my own stable release branch and "work on improving our development processes instead".
Consider TRUNK unfrozen. Have fun with your bugs, I'm going to enjoy my weekend.
WD
On 9/16/05, WaxDragon waxdragon@gmail.com wrote:
Consider TRUNK frozen. Please, no new features/functionality until 1200 GMT Monday. Please use this time to test any patches you will be submitting soon, or help hunt current bugs. I would like to thank everyone for the work already done, the release build has been fixed.
WD
WaxDragon wrote:
Well, 17891, 17892, and 17893 are NOT bugfixes. Could the committers explain why these changes were checked into a frozen trunk?
Probably they were not aware of the freezing. Devs in charge of those revisions, please revert those changes or explain how they are bug fixes.
Well, after Casper told me that Freeze process was never voted on,
It was voted on IRC and through your appointement as TC, as outlined on the Wiki.
I guess this whole excersice is pointless.
No, it just proves that some people are willing to play with your mind and discourage you when they don't like something, even though the ENTIRE team is backing you on this.
I was told to maintain my own stable release branch and "work on improving our development processes instead".
One person's opinion versus 10 others which agree with the freeze.
Consider TRUNK unfrozen. Have fun with your bugs, I'm going to enjoy my weekend.
I'm sorry, but I'm not going to let someone trash you down on IRC and overrule your (and the other devs') decision. TRUNK must remain frozen as decided. You're not the only one who made the decision to freeze it, others backed you, and you can't just unfreeze it like this without everyone else that froze it agreeing. This is a typical rule of common voting, and it's been originally made so that someone couldn't get bribed into making a unilateral decision after a group of people made one :). In your case, you were intimiated.
Best regards, Alex Ionescu
-----Original Message----- From: ros-dev-bounces@reactos.com [mailto:ros-dev-bounces@reactos.com] On Behalf Of Alex Ionescu Sent: 17. september 2005 16:25 To: waxdragon@gmail.com; ReactOS Development List Subject: Re: [ros-dev] Re: Trunk Freeze
One person's opinion versus 10 others which agree with the freeze.
Consider TRUNK unfrozen. Have fun with your bugs, I'm going to enjoy my weekend.
I'm sorry, but I'm not going to let someone trash you down on IRC and overrule your (and the other devs') decision. TRUNK must remain frozen as decided. You're not the only one who made the decision to freeze it, others backed you, and you can't just unfreeze it like this without everyone else that froze it agreeing. This is a typical rule of common voting, and it's been originally made so that someone couldn't get bribed into making a unilateral decision after a group of people made one :). In your case, you were intimiated.
Best regards, Alex Ionescu
Why do you have to be such a drama queen? Pointing out that freezing trunk is fixing symptoms instead of fixing the root cause of the problem (which is the way we develop ReactOS) is hardly "trashing people down". If you freeze trunk for a weekend now, then in a week you will have the exact same problem. What will you do then? Freeze it at every weekend from now on? How about we just stop developing ReactOS for a year, and only test and fix bugs in that time?
If there is a such a freeze rule, why isn't it documented at http://www.reactos.com/wiki/index.php/Voting? I have seen discussions on the mailing list about such a rule, but I've not seen a vote on the subject yet. Why don't you just call for a vote on the subject and document it in wiki? It only requires two weeks of time to instate a new rule, but once it's done, you have the luxury of just pointing people to the wiki whenever you want to use the rule.
Casper
-
Aleksey Bragin -
Alex Ionescu -
art yerkes -
Casper Hornstrup -
Ge van Geldorp -
Hartmut Birr -
WaxDragon