0.3.12 milestones status

[victor martinez]

I am currently checking our 0.3.12 milestones. And the milestones status is:

**********(Bug 5517)Some icons look wrong (blue background)**********
There is a Hack for the release.

**********(Bug5560): Adobe Acrobat Reader 7.1 throws exception at start****
This is a Wine regression. It is not in our hands.We have to wait for a Fix.

**********(Bug 5472) comctl32: Keyboard shortcuts don't work after winesync***
Not as bad as it sounds. It does not work just in 2nd Installation Stage.
Anyway, there is a Hack for this issue too.

**********(Bug 5314)	REGRESSION: Acrobat Reader: pen leak*******
It is supposed to be fixed, but it is Bug5560 dependant so it is impossible to confirm the Fixed status.

**********(Bug 5598) PATCH: Opera 9.64, FireFox 3.0+ crash when using Russian/Lithuanin/Ukrainian locale****
Reverting the *.nls changes solves the issue.
There is a Hack attached.

**********(Bug 5482)REGRESSION: ExplorerXP: black background on treeview area*****
This is a Wine regression. It is not in our hands. We have to wait for a Fix.

**********(Bug 4106) REGRESSION: Wrong text spacing in popup menus / icons after show a font in control applet / Remote Desktop*******
It is a minor regression since it has been there for a while. Also Yarotows seems to fix some of the issues.

**********(Bug 5591)	REGRESSION: devmgr: wrong icons in the TreeView *****

Updating comctl32 will fix the issues. Or we can revert the comctl32 changes.

**************
*   Summing up   *
**************
There are 8 regressions.
4 has different options to be solved (Hack or Wine update/revert)
2 are current Wine regressions (we have to wait for a fix or revert Ole32/Comctl32 changes)
1 could be fixed (the Acrobar Reader leakage) but we need to fix Acrobat first(reverting?)
1 is a minor regression without a solution ( "Bug 4106")

So we can solve 7/8 regressions. Is it time to think about a 0.3.12 release? It is time to take decisions (reverting/updating/waiting Fixes) since there are solutions.
I don't think having the Trunk frozen is good for the project. 
So, opinions?

[Aleksey Bragin]

Let's branch & release 0.3.12 then, and finally unlock trunk.

WBR,
Aleksey Bragin.

On Sep 21, 2010, at 3:01 PM, victor martinez wrote:
> I am currently checking our 0.3.12 milestones. And the milestones  
> status is:
>
> **********(Bug 5517)Some icons look wrong (blue background)**********
> There is a Hack for the release.
>
> **********(Bug5560): Adobe Acrobat Reader 7.1 throws exception at  
> start****
> This is a Wine regression. It is not in our hands.We have to wait  
> for a Fix.
>
> **********(Bug 5472) comctl32: Keyboard shortcuts don't work after  
> winesync***
> Not as bad as it sounds. It does not work just in 2nd Installation  
> Stage.
> Anyway, there is a Hack for this issue too.
>
> **********(Bug 5314)	REGRESSION: Acrobat Reader: pen leak*******
> It is supposed to be fixed, but it is Bug5560 dependant so it is  
> impossible to confirm the Fixed status.
>
> **********(Bug 5598) PATCH: Opera 9.64, FireFox 3.0+ crash when  
> using Russian/Lithuanin/Ukrainian locale****
> Reverting the *.nls changes solves the issue.
> There is a Hack attached.
>
> **********(Bug 5482)REGRESSION: ExplorerXP: black background on  
> treeview area*****
> This is a Wine regression. It is not in our hands. We have to wait  
> for a Fix.
>
> **********(Bug 4106) REGRESSION: Wrong text spacing in popup  
> menus / icons after show a font in control applet / Remote  
> Desktop*******
> It is a minor regression since it has been there for a while. Also  
> Yarotows seems to fix some of the issues.
>
> **********(Bug 5591)	REGRESSION: devmgr: wrong icons in the  
> TreeView *****
>
> Updating comctl32 will fix the issues. Or we can revert the  
> comctl32 changes.
> Summing up   *
>
> There are 8 regressions.
> 4 has different options to be solved (Hack or Wine update/revert)
> 2 are current Wine regressions (we have to wait for a fix or revert  
> Ole32/Comctl32 changes)
> 1 could be fixed (the Acrobar Reader leakage) but we need to fix  
> Acrobat first(reverting?)
> 1 is a minor regression without a solution ( "Bug 4106")
>
> So we can solve 7/8 regressions. Is it time to think about a 0.3.12  
> release? It is time to take decisions (reverting/updating/waiting  
> Fixes) since there are solutions.
> I don't think having the Trunk frozen is good for the project.
> So, opinions?
>
> Ros-dev mailing list
> [e-mail]
> http://www.reactos.org/mailman/listinfo/ros-dev

[Olaf Siejka]

Translations must be commited first, i would also have as many fix patches
in, as possible. Otherwise, i agree.

2010/9/21 Aleksey Bragin [e-mail]
> Let's branch & release 0.3.12 then, and finally unlock trunk.
>
> WBR,
>  Aleksey Bragin.

[James Tabor]

Just an idea, could we get to release state than sync up with wine (at
least, most of User32) and test again? Testing is the only thing I can
to for now.
James

On Tue, Sep 21, 2010 at 5:37 PM, Olaf Siejka [e-mail] wrote:
> Translations must be commited first, i would also have as many fix patches
> in, as possible. Otherwise, i agree.
>
> 2010/9/21 Aleksey Bragin [e-mail]
> > Let's branch & release 0.3.12 then, and finally unlock trunk.
> >
> > WBR,
> >  Aleksey Bragin.

[Olaf Siejka]

It might be helpful but otoh, it would delay release even futher, two weeks
minimum in my opinion... and even more if serious regressions happen. Is it
worthy to do a winesync before release? We do risk regressions and bugs a
lot.

Best regards

2010/9/22 James Tabor [e-mail]
> Just an idea, could we get to release state than sync up with wine (at
> least, most of User32) and test again? Testing is the only thing I can
> to for now.
> James
>
> On Tue, Sep 21, 2010 at 5:37 PM, Olaf Siejka [e-mail] wrote:
> > Translations must be commited first, i would also have as many fix
>
> patches
> > in, as possible. Otherwise, i agree.
> >
> > 2010/9/21 Aleksey Bragin [e-mail]
> > > Let's branch & release 0.3.12 then, and finally unlock trunk.
> > >
> > > WBR,
> > >  Aleksey Bragin.
>
> Ros-dev mailing list
> [e-mail]
> http://www.reactos.org/mailman/listinfo/ros-dev

[victor martinez]

Completly agree with Caemyr.
Indeed more,imho, we should just sync Wine AFTER each release in a 1-month window. This is quite common in projects that has a big dependence of others. 
I.E:
-We release 0.3.12 at 10-October-2010.
-We can just sync with Wine from 10-October-2010 to 10-November-2010.
-After 10-November we have to forget about Wine Syncs and continue adding features, fixing regressions, bugs and underlying bugs discovered because the sync/own code. 
-Testing and
-Release.
If we found that is quite necesary a sync with Wine, then we have to release first and then AFTER  the release sync with Wine again.

This prevents finding bugs/regressions 1 week before a release. Some are caused because ReactOS bugs but others could be caused by the own Wine regressions.
So with this 1-month window we have time to battle against ours and theirs after the Wine Sync.

As we love structured code, as we have a structured way to branch and release , maybe it is time to structure our sync/release process in order to avoid Frozen Trunks, extra-testers work, Last-minute-changelogs, or 10 months between releases.

In the same way, and imho, I think it is much better to avoid sending critical code one month before the release. Maybe the critical code is perfect/bug-free but it needs deep testing as it can reveal underlying bugs related to other hacked pieces. If a developer needs to follow coding that critical piece during that Quarantine-month before the release he can choose between a Branch or Keeping the critical pieces in his WC (Working Copy) and commiting after the release.

These two problems: Wine Syncs done out of a frame time and adding Critical code without a Quarantine time has been in my opinion the causes of this big delay.

Also, after releasing we should talk /chat/discuss which are the candidate-milestones for the next release.

These are my opinions from the Tester  and the PR (the eternal forgotten) point of view.
Good n8!

Date: Wed, 22 Sep 2010 23:57:43 +0200
From: [e-mail]
To: [e-mail]
Subject: Re: [ros-dev] 0.3.12 milestones status

It might be helpful but otoh, it would delay release even futher, two weeks minimum in my opinion... and even more if serious regressions happen. Is it worthy to do a winesync before release? We do risk regressions and bugs a lot.

Best regards
2010/9/22 James Tabor [e-mail]

Just an idea, could we get to release state than sync up with wine (at

least, most of User32) and test again? Testing is the only thing I can

to for now.

James

On Tue, Sep 21, 2010 at 5:37 PM, Olaf Siejka [e-mail] wrote:
> Translations must be commited first, i would also have as many fix patches
> in, as possible. Otherwise, i agree.
>
> 2010/9/21 Aleksey Bragin [e-mail]
> >
> > Let's branch & release 0.3.12 then, and finally unlock trunk.
> >
> > WBR,
> > Aleksey Bragin.

_______________________________________________

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

[Adam Kachwalla]

If it ain't broke, don't fix it. ;)

I support winesync after the release, so as not to rush into it too much  
or delay the release further.

On Thu, 23 Sep 2010 12:14:13 +1000, victor martinez  
[e-mail] wrote:
> Completly agree with Caemyr.
> Indeed more,imho, we should just sync Wine AFTER each release in a  
> 1-month window. This is quite common in projects that has a big  
> dependence of others.
> I.E:
> -We release 0.3.12 at 10-October-2010.
> -We can just sync with Wine from 10-October-2010 to 10-November-2010.
> -After 10-November we have to forget about Wine Syncs and continue  
> adding features, fixing regressions, bugs and underlying bugs discovered  
> because the sync/own code.
> -Testing and
> -Release.
> If we found that is quite necesary a sync with Wine, then we have to  
> release first and then AFTER  the release sync with Wine again.
> This prevents finding bugs/regressions 1 week before a release. Some are  
> caused because ReactOS bugs but others could be caused by the own Wine  
> regressions.
> So with this 1-month window we have time to battle against ours and  
> theirs after the Wine Sync.
>
> As we love structured code, as we have a structured way to branch and  
> release , maybe it is time to structure our sync/release process in  
> order to avoid Frozen Trunks, extra-testers work,  
> Last-minute-changelogs, or 10 months between releases.
>
> In the same way, and imho, I think it is much better to avoid sending  
> critical code one month before the release. Maybe the critical code is  
> perfect/bug-free but it needs deep testing as it can reveal underlying  
> bugs related to other hacked pieces. If a developer needs to follow  
> coding that critical piece during that Quarantine-month before the  
> release he can choose between a Branch or Keeping the critical pieces in  
> his WC (Working Copy) and commiting after the release.
>
> These two problems: Wine Syncs done out of a frame time and adding  
> Critical code without a Quarantine time has been in my opinion the  
> causes of this big delay.
>
> Also, after releasing we should talk /chat/discuss which are the  
> candidate-milestones for the next release.
>
> These are my opinions from the Tester  and the PR (the eternal  
> forgotten) point of view.
> Good n8!
>
> Date: Wed, 22 Sep 2010 23:57:43 +0200
> From: [e-mail]
> To: [e-mail]
> Subject: Re: [ros-dev] 0.3.12 milestones status
>
> It might be helpful but otoh, it would delay release even futher, two  
> weeks minimum in my opinion... and even more if serious regressions  
> happen. Is it worthy to do a winesync before release? We do risk  
> regressions and bugs a lot.
>
> Best regards
> 2010/9/22 James Tabor [e-mail]
>
> Just an idea, could we get to release state than sync up with wine (at
>
> least, most of User32) and test again? Testing is the only thing I can
>
> to for now.
>
> James
>
> On Tue, Sep 21, 2010 at 5:37 PM, Olaf Siejka [e-mail] wrote:
> > Translations must be commited first, i would also have as many fix  
> > patches
> > in, as possible. Otherwise, i agree.
> >
> > 2010/9/21 Aleksey Bragin [e-mail]
> > >
> > > Let's branch & release 0.3.12 then, and finally unlock trunk.
> > >
> > > WBR,
> > > Aleksey Bragin.
>
> 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
-- 
Give a man a fish and he will eat for a day.
Teach a man to fish and he will eat for a lifetime.
Give a man religion and he will die praying for a fish.

[Ged Murphy]

victor Martinez wrote:
> In the same way, and imho, I think it is much better 
> to avoid sending critical code one month before the release.

This isn't how you release.
The whole point in branching for a release is so you can stabalise the
branch whilst trunk continues to be 'bleeding edge'
What's the point in branching otherwise? We may as well just tag trunk and
do away with branching.

Ged.

[Timo Kreuzer]

Olaf Siejka wrote:
> It might be helpful but otoh, it would delay release even futher, two
> weeks minimum in my opinion... and even more if serious regressions
> happen. Is it worthy to do a winesync before release? We do risk
> regressions and bugs a lot.

I agree that it's a risk.
IMO we should branch first, then we can try a wine-sync in trunk. If all
is well, no regressions happen, then we can merge or rebranch.

[James Tabor]

On Thu, Sep 23, 2010 at 4:40 AM, Timo Kreuzer [e-mail] wrote:
> Olaf Siejka wrote:
> > It might be helpful but otoh, it would delay release even futher, two
> > weeks minimum in my opinion... and even more if serious regressions
> > happen. Is it worthy to do a winesync before release? We do risk
> > regressions and bugs a lot.
>
> I agree that it's a risk.
> IMO we should branch first, then we can try a wine-sync in trunk. If all
> is well, no regressions happen, then we can merge or rebranch.

Good idea...

Expect major wholesale changes from me now on after lengthy testing as
time and resources permits. No more peace mill build up coding, unless
for educational purposes.

Everyone,, Good job on the release, see you all later, thanks,
James

[Bernd Blaauw]

Can the 0.3.12 branch be obtained in some easy way in order to test? 
Trunk has at least an ISO of each revision, testing 0.3.12 branch 
requires a SVN client?

As you've supported VmWare earlier as testing platform for releases, I 
assume you'll release a complete image including an easy way to install 
VmWare Workstation 7's SVGA and audio drivers.
(the vminstall.exe of ReactOS seems a non-functional nice black box 
regarding what it actually expects and does, requiring source code 
studying as there's no documentation)

Also what's the best way of asking questions and passing on (cosmetic?) 
bugs and simple requests? IRC?

with best regards,

Bernd

[Olaf Siejka]

Vmware 7 guest addons do not install currently, due to bug in MSI. ROS
vminstall is no longer working with newer Vmware versions, due to changes in
guest addons iso file structure.

As for bugs, every single one should be reported in bugzilla, but you surely
can ask questions and consult bugs on IRC.

2010/10/10 Bernd Blaauw [e-mail]
> Can the 0.3.12 branch be obtained in some easy way in order to test? Trunk
> has at least an ISO of each revision, testing 0.3.12 branch requires a SVN
> client?
>
> As you've supported VmWare earlier as testing platform for releases, I
> assume you'll release a complete image including an easy way to install
> VmWare Workstation 7's SVGA and audio drivers.
> (the vminstall.exe of ReactOS seems a non-functional nice black box
> regarding what it actually expects and does, requiring source code studying
> as there's no documentation)
>
> Also what's the best way of asking questions and passing on (cosmetic?)
> bugs and simple requests? IRC?
>
> with best regards,
>
> Bernd
>
> Ros-dev mailing list
> [e-mail]
> http://www.reactos.org/mailman/listinfo/ros-dev

[Bernd Blaauw]

Op 11-10-2010 9:06, Olaf Siejka schreef:
> Vmware 7 guest addons do not install currently, due to bug in MSI. ROS 
> vminstall is no longer working with newer Vmware versions, due to 
> changes in guest addons iso file structure.

The MSI installer has never been working anyway due to ReactOS's 
development state, thus the vmwinst.exe program developed by a coder in 
the ReactOS project. I'd have to study its sourcecode to get to know 
which layout it actually expects of a CD/ISOfile (and since using 
Windows 7 and VMware 7, I've got no clue anymore how older guest 
installation tool ISO files are looking internally)
I'd favor quite much if your vmwinst.exe program also allowed to point 
to a directory where you have the extracted (VMware SVGA) driver files. 
After all that's easy enough using 7ZIP to extract files from the MSI 
(which results in .cab files as well), then extract the cab files to 
gain the actual driver files (which require renaming).
The difficult part is actually getting the extracted + renamed files 
into the virtual machine (since floppy is broken in ReactOS since 0.2.5 
or so, USB in development, FileZilla doesn't startup for FTP purposes, I 
was unable to browse network shares using the explorer shell, etc), and 
on top of that finding the correct location to copy all the files 
(C:\REACTOS\SYSTEM32\DRIVERS ?), edit an .inf file to get it working in 
ReactOS, and finding correct/documented registry settings for 
registering the driver to ReactOS.
> As for bugs, every single one should be reported in bugzilla, but you 
> surely can ask questions and consult bugs on IRC.

OK, hopefully some wishfull stuff regarding the download tool will count 
as bug as well (FireFox 4 beta , Chrome, FileZilla).

with best regards,

Bernd Blaauw

[Olaf Siejka]

MSI works well enought with older versions of Windows Installer. It can for
example handle WinDbg msi packacge correctly. It has some problems with
install packages of the newer version. Since those require installing and
running a service, it could be difficult to have them running on ros, but
not impossible.

As for video driver installation, it is quite specific. If dedicated
installer doesnt work, you can only change the video driver by having the
proper files in specific locations at startup of 2nd stage of ROS install.
Anything later is just too late.

By specific, i mean all exe and dll in ReactOS\System32, all sys files
in ReactOS\System32\Drivers and inf file in ReactOS\Inf. You can easily
decipher the proper file list from the inf file. As for inf, you dont need
to hack them, they are being processed quite well by ROS, usually. Having
the driver package separated as i describe above, will not only allow you to
install video driver on 2nd stage, but also to install driver for any device
at a later stages, simply by picking "Automatic" option from New device
wizard.

Please mind that video driver loading is not working properly atm, see:
http://www.reactos.org/bugzilla/show_bug.cgi?id=2286 (to mention, this is
one of my first bugs and longest one still open).

2010/10/11 Bernd Blaauw [e-mail]
> The MSI installer has never been working anyway due to ReactOS's
> development state, thus the vmwinst.exe program developed by a coder in the
> ReactOS project. I'd have to study its sourcecode to get to know which
> layout it actually expects of a CD/ISOfile (and since using Windows 7 and
> VMware 7, I've got no clue anymore how older guest installation tool ISO
> files are looking internally)
> I'd favor quite much if your vmwinst.exe program also allowed to point to a
> directory where you have the extracted (VMware SVGA) driver files. After all
> that's easy enough using 7ZIP to extract files from the MSI (which results
> in .cab files as well), then extract the cab files to gain the actual driver
> files (which require renaming).
> The difficult part is actually getting the extracted + renamed files into
> the virtual machine (since floppy is broken in ReactOS since 0.2.5 or so,
> USB in development, FileZilla doesn't startup for FTP purposes, I was unable
> to browse network shares using the explorer shell, etc), and on top of that
> finding the correct location to copy all the files
> (C:\REACTOS\SYSTEM32\DRIVERS ?), edit an .inf file to get it working in
> ReactOS, and finding correct/documented registry settings for registering
> the driver to ReactOS.
>
> As for bugs, every single one should be reported in bugzilla, but you
> > surely can ask questions and consult bugs on IRC.
>
> OK, hopefully some wishfull stuff regarding the download tool will count as
> bug as well (FireFox 4 beta , Chrome, FileZilla).
>
> with best regards,
>
> Bernd Blaauw
>
> Ros-dev mailing list
> [e-mail]
> http://www.reactos.org/mailman/listinfo/ros-dev

[Bernd Blaauw]

Op 11-10-2010 20:44, Olaf Siejka schreef:
> MSI works well enought with older versions of Windows Installer. It 
> can for example handle WinDbg msi packacge correctly. It has some 
> problems with install packages of the newer version. Since those 
> require installing and running a service, it could be difficult to 
> have them running on ros, but not impossible.

Ah I ment more like the VMware installer (usually .exe or MSI package) 
has never worked, thus your vmwinst.exe
> As for video driver installation, it is quite specific. If dedicated 
> installer doesnt work, you can only change the video driver by having 
> the proper files in specific locations at startup of 2nd stage of ROS 
> install. Anything later is just too late.

That sounds like either modifying the installation CD, or getting a DOS 
bootdisk with driverfiles and using that after phase 1 (partitioning, 
formatting, copying, writing MBR/bootsector, rebooting) but before 
ReactOS installation starts from harddisk, to copy files to proper location.
> By specific, i mean all exe and dll in ReactOS\System32, all sys files 
> in ReactOS\System32\Drivers and inf file in ReactOS\Inf. You can 
> easily decipher the proper file list from the inf file. As for inf, 
> you dont need to hack them, they are being processed quite well by 
> ROS, usually. Having the driver package separated as i describe above, 
> will not only allow you to install video driver on 2nd stage, but also 
> to install driver for any device at a later stages, simply by picking 
> "Automatic" option from New device wizard.

Thanks for the heads-up regarding file location, and .inf processing. 
The 2nd note near bottom of [ 
http://www.reactos.org/wiki/Supported_Hardware/Video_cards ] confused me 
for that.
> Please mind that video driver loading is not working properly atm, 
> see: http://www.reactos.org/bugzilla/show_bug.cgi?id=2286 (to mention, 
> this is one of my first bugs and longest one still open).

No idea if that counts like a regressing as VMware video driver used to 
work fine in older VMware software releases combined with older ReactOS 
versions. Never tried real hardware with Nvidia driver setup as that's a 
massive 200MB driver set rather than some .sys/dll/exe/inf files.

Simply copying the svga.sys over vbemp.sys and vgamp.sys wasn't 
succesfull, nice black screen.

Thanks for all the help so far.

[Olaf Siejka]

> That sounds like either modifying the installation CD, or getting a DOS

bootdisk with
> driverfiles and using that after phase 1 (partitioning, formatting,

copying,
> writing MBR/bootsector, rebooting) but before ReactOS installation starts
> from harddisk, to copy files to proper location.

I admit using Reactos.dff to push whole driver packages to bootcd.
> Thanks for the heads-up regarding file location, and .inf processing.
> The 2nd note near bottom of [ ... ] confused me for that.

That note is still valid, but only for simpler one, like storage and network
drivers. Network drivers especially do come in a package with single INF
file, which is picking drivers for specific OS version/arch.
> No idea if that counts like a regressing as VMware video driver
> used to work fine in older VMware software releases combined
> with older ReactOS versions.

Nope. It just was loaded successfuly. The only driver i know to work, is
Vbox Video driver. A simple test: install the driver of your liking (be it
the old vmware driver or any real-hardware driver) and then delete the
ros-specific driver files (vbemp.sys/framebuf.dll or vgamp.sys/vgaddi.dll),
Usually you need only to delete the pair for the video driver you picked at
ROS 1st stage of install (VBE or VGA). ReactOS will crash at startup after a
reboot. It happens not only with QEMU (and its Cirrus driver) but also in
real hardware (Nvidia TnT 32, ATI Rage, Matrox G400 and few more i managed
to install in ROS).
> Simply copying the svga.sys over vbemp.sys and
> vgamp.sys wasn't succesfull, nice black screen.

Yes, overwriting the default driver gives the same result as deleting it.

Regards