Time to Branch for Release

[James Tabor]

FYI,
I've tested Firefox 3.6, SeaMonkey 2.0.3, OOo 2.4.3, AbiWord 2.6.8 and
bot tests are okay with Qemu and Hardware at rev 45734.
James

[Colin Finck]

Hi James,

Thanks for your information. I'm afraid that I currently don't have time to
organize a full new release due to the ongoing preparations for the
Chemnitzer Linux-Tage exhibition in around two weeks.
But of course, such an event benefits much from a stable trunk, especially
because we still need to prepare an ISO for the give-away CDs and
presentation laptops.

Does anybody know of any major hardware/driver problems preventing us from
doing so?
I've lately heard about an Uniata timing problem, which particularly causes
trouble on real hardware systems. Who has details about this problem and can
we get it sorted out till next weekend?

I won't have much time over the next two weeks, so meeting that deadline
would be vital for the CDs.

Best regards,

Colin
> -----Original Message-----
> From: [e-mail] 
> [mailto:[e-mail]] On Behalf Of James Tabor
> Sent: Monday, March 01, 2010 4:47 AM
> To: ReactOS Development List
> Subject: [ros-dev] Time to Branch for Release
>
> FYI,
> I've tested Firefox 3.6, SeaMonkey 2.0.3, OOo 2.4.3, AbiWord 2.6.8 and
> bot tests are okay with Qemu and Hardware at rev 45734.
> James
>
> Ros-dev mailing list
> [e-mail]
> http://www.reactos.org/mailman/listinfo/ros-dev

[Olaf Siejka]

I do strongly believe in releasing before major IT events, to maximize the
potential short-time increase of interest around ReactOS, that could be
combined with the leverage granted by the event. My answer is - yes if we
can make it,

Regarding current trunk issues, i have compiled a small list of the new ones
(or just freshly detected):
-

2010/3/2 Colin Finck [e-mail]
> Hi James,
>
> Thanks for your information. I'm afraid that I currently don't have time to
> organize a full new release due to the ongoing preparations for the
> Chemnitzer Linux-Tage exhibition in around two weeks.
> But of course, such an event benefits much from a stable trunk, especially
> because we still need to prepare an ISO for the give-away CDs and
> presentation laptops.
>
> Does anybody know of any major hardware/driver problems preventing us from
> doing so?
> I've lately heard about an Uniata timing problem, which particularly causes
> trouble on real hardware systems. Who has details about this problem and
> can
> we get it sorted out till next weekend?
>
> I won't have much time over the next two weeks, so meeting that deadline
> would be vital for the CDs.
>
> Best regards,
>
> Colin

[Olaf Siejka]

(previous post was an accident)

I do strongly believe in releasing before major IT events, to maximize the
potential short-time increase of interest around ReactOS, that could be
combined with the leverage granted by the event. My answer is - yes if we
can make it,

Regarding current trunk issues, i have compiled a small list of the new ones
(or just freshly detected):
- general instability when browsing internet on Vbox, bridged (FF 2.x,
K-meleon);
- UNIATA timings issue on Vbox and some real hardware, resulting in random
crashes in 1st stage and freezes in 3rd and later stages (when CDRom is
used);
- UNIATA bug: 7B bugcheck if CDROM is set to any of IDE slave channels
(dreimer lappy suffers from this issue as well);
- HAL: An invalid V86 opcode - in some real hardware
- kdbg bug when attaching to any process/thread manually, resulting in lack
of any debug information (regs, bt);

More may follow

2010/3/2 Colin Finck [e-mail]
> Hi James,
>
> Thanks for your information. I'm afraid that I currently don't have time to
> organize a full new release due to the ongoing preparations for the
> Chemnitzer Linux-Tage exhibition in around two weeks.
> But of course, such an event benefits much from a stable trunk, especially
> because we still need to prepare an ISO for the give-away CDs and
> presentation laptops.
>
> Does anybody know of any major hardware/driver problems preventing us from
> doing so?
> I've lately heard about an Uniata timing problem, which particularly causes
> trouble on real hardware systems. Who has details about this problem and
> can
> we get it sorted out till next weekend?
>
> I won't have much time over the next two weeks, so meeting that deadline
> would be vital for the CDs.
>
> Best regards,
>
> Colin
> > -----Original Message-----
> > From: [e-mail]
> > [mailto:[e-mail]] On Behalf Of James Tabor
> > Sent: Monday, March 01, 2010 4:47 AM
> > To: ReactOS Development List
> > Subject: [ros-dev] Time to Branch for Release
> >
> > FYI,
> > I've tested Firefox 3.6, SeaMonkey 2.0.3, OOo 2.4.3, AbiWord 2.6.8 and
> > bot tests are okay with Qemu and Hardware at rev 45734.
> > James
> >
> > Ros-dev mailing list
> > [e-mail]
> > http://www.reactos.org/mailman/listinfo/ros-dev
>
> Ros-dev mailing list
> [e-mail]
> http://www.reactos.org/mailman/listinfo/ros-dev

[Aleksey Bragin]

What improved over the last release, realuser-wise (not code-wise)?

Kernel side / HAL - still dealing with some regresses (hopefully,  
mostly done)
Networking - definately improved
Drivers - uniata problem mainly (was reverted for 0.3.11).
Sound - improved
Bootvid - improved
Win32 - ?

On Mar 1, 2010, at 6:46 AM, James Tabor wrote:
> FYI,
> I've tested Firefox 3.6, SeaMonkey 2.0.3, OOo 2.4.3, AbiWord 2.6.8 and
> bot tests are okay with Qemu and Hardware at rev 45734.
> James

[Olaf Siejka]

Regressions (more to come):

Freeldr - regression while booting in memory rich environment (>3.6 GB);
Kernel - regression in Vbox guest additions, video driver fails with VRAM
set to 64MB or more;
Ollydbg - regression in both functionalities (process attaching and opening
executable)

As for fixes:

Win32 - region leaked finally fixed;
Cc - arty, when we'll be able to feel its awesomeness?
Networking - aicom's branch needs to be fully merged;

Probably will be more

2010/3/2 Aleksey Bragin [e-mail]
> What improved over the last release, realuser-wise (not code-wise)?
>
> Kernel side / HAL - still dealing with some regresses (hopefully, mostly
> done)
> Networking - definately improved
> Drivers - uniata problem mainly (was reverted for 0.3.11).
> Sound - improved
> Bootvid - improved
> Win32 - ?
>
> On Mar 1, 2010, at 6:46 AM, James Tabor wrote:
>
> FYI,
> > I've tested Firefox 3.6, SeaMonkey 2.0.3, OOo 2.4.3, AbiWord 2.6.8 and
> > bot tests are okay with Qemu and Hardware at rev 45734.
> > James
>
> Ros-dev mailing list
> [e-mail]
> http://www.reactos.org/mailman/listinfo/ros-dev

[James Tabor]

This is very good data!

On Tue, Mar 2, 2010 at 9:08 AM, Olaf Siejka [e-mail] wrote:
> Regressions (more to come):
> Freeldr - regression while booting in memory rich environment (>3.6 GB);
> Kernel - regression in Vbox guest additions, video driver fails with VRAM
> set to 64MB or more;
> Ollydbg - regression in both functionalities (process attaching and opening
> executable)
> As for fixes:
> Win32 - region leaked finally fixed;
> Cc - arty, when we'll be able to feel its awesomeness?
> Networking - aicom's branch needs to be fully merged;
> Probably will be more
> 2010/3/2 Aleksey Bragin [e-mail]
> > What improved over the last release, realuser-wise (not code-wise)?
> >
> > Kernel side / HAL - still dealing with some regresses (hopefully, mostly
> > done)
> > Networking - definately improved
> > Drivers - uniata problem mainly (was reverted for 0.3.11).
> > Sound - improved
> > Bootvid - improved
> > Win32 - ?

I believe Alex, KJK and Timo was making this point. If anyone wants to
handle more than one project, I expect them to be responsible to
handle the work load required of them. To stay up to date on all
issues, verifying and testing as required. To not know is not being
responsible. Due to this, the project has suffered from it. Trunk
freezes are not helping and creates dysfunctional continuities in the
projects progress. As a result I have refrained from any win32k
commits to only have bulk changes after full testing with known stable
kernels. I am also for consideration of a standalone release to set
benchmarks for testing. Since everyone waits for a release to come out
anyway. This would allow our developers to have a wider test bed and
collect more input from the outside.

Fixing win32k is the primary goal of the ReactOS project, if this is
not true why have Arwinss?

Thanks,
James