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?
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 Ros-dev@reactos.org http://www.reactos.org/mailman/listinfo/ros-dev
Translations must be commited first, i would also have as many fix patches in, as possible. Otherwise, i agree.
2010/9/21 Aleksey Bragin aleksey@reactos.org
Let's branch & release 0.3.12 then, and finally unlock trunk.
WBR, Aleksey Bragin.
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 caemyr@gmail.com 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 aleksey@reactos.org
Let's branch & release 0.3.12 then, and finally unlock trunk.
WBR, Aleksey Bragin.
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 jimtabor.rosdev@gmail.com
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 caemyr@gmail.com 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 aleksey@reactos.org
Let's branch & release 0.3.12 then, and finally unlock trunk.
WBR, Aleksey Bragin.
Ros-dev mailing list Ros-dev@reactos.org http://www.reactos.org/mailman/listinfo/ros-dev
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: caemyr@gmail.com To: ros-dev@reactos.org 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 jimtabor.rosdev@gmail.com
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 caemyr@gmail.com 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 aleksey@reactos.org
Let's branch & release 0.3.12 then, and finally unlock trunk.
WBR,
Aleksey Bragin.
_______________________________________________
Ros-dev mailing list
Ros-dev@reactos.org
http://www.reactos.org/mailman/listinfo/ros-dev
_______________________________________________ Ros-dev mailing list Ros-dev@reactos.org http://www.reactos.org/mailman/listinfo/ros-dev
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 vicmarcal@hotmail.com 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: caemyr@gmail.com To: ros-dev@reactos.org 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 jimtabor.rosdev@gmail.com
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 caemyr@gmail.com 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 aleksey@reactos.org
Let's branch & release 0.3.12 then, and finally unlock trunk.
WBR,
Aleksey Bragin.
Ros-dev mailing list
Ros-dev@reactos.org
http://www.reactos.org/mailman/listinfo/ros-dev
Ros-dev mailing list Ros-dev@reactos.org http://www.reactos.org/mailman/listinfo/ros-dev
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.
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.
On Thu, Sep 23, 2010 at 4:40 AM, Timo Kreuzer timo.kreuzer@web.de 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
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
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 bblaauw@home.nl
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 Ros-dev@reactos.org http://www.reactos.org/mailman/listinfo/ros-dev
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
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 bblaauw@home.nl
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 Ros-dev@reactos.org http://www.reactos.org/mailman/listinfo/ros-dev
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.
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