Trunk Freeze

[WaxDragon]

    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?

[Alex Ionescu]

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

[art yerkes]

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(a)reactos.com
>  http://reactos.com:8080/mailman/listinfo/ros-dev 
I agree.

[Hartmut Birr]

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]

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

[Hartmut Birr]

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

[Hartmut Birr]

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

[Ge van Geldorp]

>   From: WaxDragon
>  According to the rules set forth, I need three developers.
>  Who agrees to a trunk freeze? 
+1

[WaxDragon]

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
--
<arty> don't question it ... it's clearly an optimization

[WaxDragon]

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(a)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
>   
--
<arty> don't question it ... it's clearly an optimization

[Alex Ionescu]

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

[Casper Hornstrup]

>   -----Original Message-----
>  From: ros-dev-bounces(a)reactos.com [mailto:[e-mail]] On Behalf Of Alex
> Ionescu
>  Sent: 17. september 2005 16:25
>  To: waxdragon(a)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