Hi, as the results of the trunk testing depict, there are no major problems/regressions (compared to the previous release). Thus I propose to branch the 0.3.14 release.
Any comments, motivated objections? If not, then branching will be done on Monday, 18th of December 2011.
WBR, Aleksey Bragin.
Op 18-12-2011 18:08, Aleksey Bragin schreef:
as the results of the trunk testing depict, there are no major problems/regressions (compared to the previous release). Thus I propose
Those tests were only related to installing & running/using applications on an installed ReactOS?
Any comments, motivated objections? If not, then branching will be done on Monday, 18th of December 2011.
bug 5857 is still present in trunk, and should be considered a blocker for release but not for branching?
Best wishes for 0.3.14 and Christmas :)
This bug will not be fixed before release. It needs a lot of new code.
2011/12/18 Bernd Blaauw bblaauw@home.nl
Op 18-12-2011 18:08, Aleksey Bragin schreef:
as the results of the trunk testing depict, there are no major
problems/regressions (compared to the previous release). Thus I propose
Those tests were only related to installing & running/using applications on an installed ReactOS?
Any comments, motivated objections? If not, then branching will be done
on Monday, 18th of December 2011.
bug 5857 is still present in trunk, and should be considered a blocker for release but not for branching?
Best wishes for 0.3.14 and Christmas :)
______________________________**_________________ Ros-dev mailing list Ros-dev@reactos.org http://www.reactos.org/**mailman/listinfo/ros-devhttp://www.reactos.org/mailman/listinfo/ros-dev
Op 18-12-2011 18:57, Igor Paliychuk schreef:
This bug will not be fixed before release. It needs a lot of new code.
That kinda contradicts the earlier statement "there are no major problems/regressions (compared to the previous release)"
as 0.3.13 didn't suffer from such an issue. I guess it's OK as long as no related complaints come in after release. Or skip Gecko alltogether.
Gecko is not a problem. This bug is not happening with mshtml only, but with other libs alltogether. I am still against releasing with this bug unfixed. Since it will probably happen anyway, can we postpone it at least until tuesday?
There is another issue that should be looked into, copying of a large (>1.5GB) file will fail on ROS with more than 923 MB ram available.
Cameron is looking into it, but he should speak up about it before RC is created.
On Sun, Dec 18, 2011, at 07:34 PM, Bernd Blaauw wrote:
Op 18-12-2011 18:57, Igor Paliychuk schreef:
This bug will not be fixed before release. It needs a lot of new code.
That kinda contradicts the earlier statement "there are no major problems/regressions (compared to the previous release)"
as 0.3.13 didn't suffer from such an issue. I guess it's OK as long as no related complaints come in after release. Or skip Gecko alltogether.
Ros-dev mailing list Ros-dev@reactos.org http://www.reactos.org/mailman/listinfo/ros-dev
*Bernd Blaauw* This bug WAS present in 0.3.13, though it as hacked and that hack helped only partially. 2011/12/18 caemyr@myopera.com
Gecko is not a problem. This bug is not happening with mshtml only, but with other libs alltogether. I am still against releasing with this bug unfixed. Since it will probably happen anyway, can we postpone it at least until tuesday?
There is another issue that should be looked into, copying of a large (>1.5GB) file will fail on ROS with more than 923 MB ram available.
Cameron is looking into it, but he should speak up about it before RC is created.
On Sun, Dec 18, 2011, at 07:34 PM, Bernd Blaauw wrote:
Op 18-12-2011 18:57, Igor Paliychuk schreef:
This bug will not be fixed before release. It needs a lot of new code.
That kinda contradicts the earlier statement "there are no major problems/regressions (compared to the previous release)"
as 0.3.13 didn't suffer from such an issue. I guess it's OK as long as no related complaints come in after release. Or skip Gecko alltogether.
Ros-dev mailing list Ros-dev@reactos.org http://www.reactos.org/mailman/listinfo/ros-dev
-- With best regards Caemyr
Ros-dev mailing list Ros-dev@reactos.org http://www.reactos.org/mailman/listinfo/ros-dev
we can always release 0.3.14-rc1, -rc2 and so :P
On Sun, Dec 18, 2011 at 8:25 PM, Igor Paliychuk mansonigor@gmail.comwrote:
*Bernd Blaauw* This bug WAS present in 0.3.13, though it as hacked and that hack helped only partially. 2011/12/18 caemyr@myopera.com
Gecko is not a problem. This bug is not happening with mshtml only, but
with other libs alltogether. I am still against releasing with this bug unfixed. Since it will probably happen anyway, can we postpone it at least until tuesday?
There is another issue that should be looked into, copying of a large (>1.5GB) file will fail on ROS with more than 923 MB ram available.
Cameron is looking into it, but he should speak up about it before RC is created.
On Sun, Dec 18, 2011, at 07:34 PM, Bernd Blaauw wrote:
Op 18-12-2011 18:57, Igor Paliychuk schreef:
This bug will not be fixed before release. It needs a lot of new code.
That kinda contradicts the earlier statement "there are no major problems/regressions (compared to the previous release)"
as 0.3.13 didn't suffer from such an issue. I guess it's OK as long as no related complaints come in after release. Or skip Gecko alltogether.
Ros-dev mailing list Ros-dev@reactos.org http://www.reactos.org/mailman/listinfo/ros-dev
-- With best regards Caemyr
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
We dont have much time if we'd want 0.3.14 out by the end of the year.
On Sun, Dec 18, 2011, at 10:15 PM, Javier Agustìn Fernàndez Arroyo wrote:
we can always release 0.3.14-rc1, -rc2 and so :P
On Sun, Dec 18, 2011 at 8:25 PM, Igor Paliychuk mansonigor@gmail.comwrote:
*Bernd Blaauw* This bug WAS present in 0.3.13, though it as hacked and that hack helped only partially. 2011/12/18 caemyr@myopera.com
Gecko is not a problem. This bug is not happening with mshtml only, but
with other libs alltogether. I am still against releasing with this bug unfixed. Since it will probably happen anyway, can we postpone it at least until tuesday?
There is another issue that should be looked into, copying of a large (>1.5GB) file will fail on ROS with more than 923 MB ram available.
Cameron is looking into it, but he should speak up about it before RC is created.
On Sun, Dec 18, 2011, at 07:34 PM, Bernd Blaauw wrote:
Op 18-12-2011 18:57, Igor Paliychuk schreef:
This bug will not be fixed before release. It needs a lot of new code.
That kinda contradicts the earlier statement "there are no major problems/regressions (compared to the previous release)"
as 0.3.13 didn't suffer from such an issue. I guess it's OK as long as no related complaints come in after release. Or skip Gecko alltogether.
Ros-dev mailing list Ros-dev@reactos.org http://www.reactos.org/mailman/listinfo/ros-dev
-- With best regards Caemyr
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
Ros-dev mailing list Ros-dev@reactos.org http://www.reactos.org/mailman/listinfo/ros-dev
+#5857.
I still can't use ReactOS. This is a major regression. This is a motivated objection by the agreement we got during the last meeting.
Le lundi 19 décembre 2011 à 01:15 +0400, Александр a écrit :
Bugs #6672, 6281, 5802, 5477 18.12.2011, 21:08, "Aleksey Bragin" aleksey@reactos.org:
Hi, as the results of the trunk testing depict, there are no major problems/regressions (compared to the previous release). Thus I propose to branch the 0.3.14 release.
Any comments, motivated objections? If not, then branching will be done on Monday, 18th of December 2011.
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
Try other virtual machines for now, this is the only thing I can advise until it's fixed. VMWare Workstation (Player), Parallels Workstation, they don't exhibit the bug.
On 19.12.2011 1:40, Pierre Schweitzer wrote:
+#5857.
I still can't use ReactOS. This is a major regression. This is a motivated objection by the agreement we got during the last meeting.
Le lundi 19 décembre 2011 à 01:15 +0400, Александр a écrit :
Bugs #6672, 6281, 5802, 5477 18.12.2011, 21:08, "Aleksey Bragin"aleksey@reactos.org:
Hi, as the results of the trunk testing depict, there are no major problems/regressions (compared to the previous release). Thus I propose to branch the 0.3.14 release.
Any comments, motivated objections? If not, then branching will be done on Monday, 18th of December 2011.
WBR, Aleksey Bragin.
Old versions of VirtualBox work as well.
On 2011-12-18, at 1:49 PM, Aleksey Bragin wrote:
Try other virtual machines for now, this is the only thing I can advise until it's fixed. VMWare Workstation (Player), Parallels Workstation, they don't exhibit the bug.
On 19.12.2011 1:40, Pierre Schweitzer wrote:
+#5857.
I still can't use ReactOS. This is a major regression. This is a motivated objection by the agreement we got during the last meeting.
Le lundi 19 décembre 2011 à 01:15 +0400, Александр a écrit :
Bugs #6672, 6281, 5802, 5477 18.12.2011, 21:08, "Aleksey Bragin"aleksey@reactos.org:
Hi, as the results of the trunk testing depict, there are no major problems/regressions (compared to the previous release). Thus I propose to branch the 0.3.14 release.
Any comments, motivated objections? If not, then branching will be done on Monday, 18th of December 2011.
WBR, Aleksey Bragin.
Ros-dev mailing list Ros-dev@reactos.org http://www.reactos.org/mailman/listinfo/ros-dev
Op 18-12-2011 22:49, Aleksey Bragin schreef:
Try other virtual machines for now, this is the only thing I can advise until it's fixed. VMWare Workstation (Player), Parallels Workstation, they don't exhibit the bug.
64MB VMware Workstation 8 (64bit, Win7-ultimate x64) guest hangs all the same, on MSHTML.DLL. Takes a while though :)
It implies: - if your machine has low memory you'll run into this issue - if your machine has enough memory you might run into this issue, depending on the machine/emulator/virtualiser.
As p1 runs with 32MB and p3 runs with 40MB it's a shame to see p2 require about double this memory (or up to 512MB in some cases). On the other hand, it allows ROS to actually run apps in p3 instead of only looking at a nice system tray and desktop picture.
Best of luck releasing 0.3.14, developers.
It is NOT a vbox issue. If we release with this bug, it will bite us back for long. Sometimes, its better to delay than to release a bugger.
On Sun, Dec 18, 2011, at 11:08 PM, Bernd Blaauw wrote:
Op 18-12-2011 22:49, Aleksey Bragin schreef:
Try other virtual machines for now, this is the only thing I can advise until it's fixed. VMWare Workstation (Player), Parallels Workstation, they don't exhibit the bug.
64MB VMware Workstation 8 (64bit, Win7-ultimate x64) guest hangs all the same, on MSHTML.DLL. Takes a while though :)
It implies:
- if your machine has low memory you'll run into this issue
- if your machine has enough memory you might run into this issue,
depending on the machine/emulator/virtualiser.
As p1 runs with 32MB and p3 runs with 40MB it's a shame to see p2 require about double this memory (or up to 512MB in some cases). On the other hand, it allows ROS to actually run apps in p3 instead of only looking at a nice system tray and desktop picture.
Best of luck releasing 0.3.14, developers.
+1 to Caemyr
On Sun, Dec 18, 2011 at 11:15 PM, caemyr@myopera.com wrote:
It is NOT a vbox issue. If we release with this bug, it will bite us back for long. Sometimes, its better to delay than to release a bugger.
On Sun, Dec 18, 2011, at 11:08 PM, Bernd Blaauw wrote:
Op 18-12-2011 22:49, Aleksey Bragin schreef:
Try other virtual machines for now, this is the only thing I can advise until it's fixed. VMWare Workstation (Player), Parallels Workstation, they don't exhibit the bug.
64MB VMware Workstation 8 (64bit, Win7-ultimate x64) guest hangs all the same, on MSHTML.DLL. Takes a while though :)
It implies:
- if your machine has low memory you'll run into this issue
- if your machine has enough memory you might run into this issue,
depending on the machine/emulator/virtualiser.
As p1 runs with 32MB and p3 runs with 40MB it's a shame to see p2 require about double this memory (or up to 512MB in some cases). On the other hand, it allows ROS to actually run apps in p3 instead of only looking at a nice system tray and desktop picture.
Best of luck releasing 0.3.14, developers.
-- With best regards Caemyr
Ros-dev mailing list Ros-dev@reactos.org http://www.reactos.org/mailman/listinfo/ros-dev
Are you suggesting to start mm rewrite before release? Don't think this would be fast.
2011/12/19 Javier Agustìn Fernàndez Arroyo elhoir@gmail.com
+1 to Caemyr
On Sun, Dec 18, 2011 at 11:15 PM, caemyr@myopera.com wrote:
It is NOT a vbox issue. If we release with this bug, it will bite us back for long. Sometimes, its better to delay than to release a bugger.
On Sun, Dec 18, 2011, at 11:08 PM, Bernd Blaauw wrote:
Op 18-12-2011 22:49, Aleksey Bragin schreef:
Try other virtual machines for now, this is the only thing I can
advise
until it's fixed. VMWare Workstation (Player), Parallels Workstation, they don't exhibit the bug.
64MB VMware Workstation 8 (64bit, Win7-ultimate x64) guest hangs all the same, on MSHTML.DLL. Takes a while though :)
It implies:
- if your machine has low memory you'll run into this issue
- if your machine has enough memory you might run into this issue,
depending on the machine/emulator/virtualiser.
As p1 runs with 32MB and p3 runs with 40MB it's a shame to see p2 require about double this memory (or up to 512MB in some cases). On the other hand, it allows ROS to actually run apps in p3 instead of only looking at a nice system tray and desktop picture.
Best of luck releasing 0.3.14, developers.
-- With best regards Caemyr
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
Thing is that this is a pre-alpha operating system. The "0.x" basically indicates it is not finished. Sure the release should be special but strictly speaking it should be done. The new MM can wait (IMO) up until 0.3.15 - there's little point worrying about it in the next release.
So long as this isn't a blocker (ie. one can just use 128MB instead of 64MB to resolve this) then you may as well release it.
I remember 0.3.11 well. Networking on it was horrible and often I had trouble trying to get the cards to work on VBox and QEMU - it was still release wasn't it?
If one was to wait until every little bug was fixed before releasing, then one should review the purpose of a release. Especially a *pre-alpha* release. There should (IMO) be a "Known Issues" for situations like this.
As a result I have no objection branching now.
On Mon, 19 Dec 2011 09:22:24 +0100 Javier Agustìn Fernàndez Arroyo elhoir@gmail.com wrote:
+1 to Caemyr
On Sun, Dec 18, 2011 at 11:15 PM, caemyr@myopera.com wrote:
It is NOT a vbox issue. If we release with this bug, it will bite us back for long. Sometimes, its better to delay than to release a bugger.
On Sun, Dec 18, 2011, at 11:08 PM, Bernd Blaauw wrote:
Op 18-12-2011 22:49, Aleksey Bragin schreef:
Try other virtual machines for now, this is the only thing I can advise until it's fixed. VMWare Workstation (Player), Parallels Workstation, they don't exhibit the bug.
64MB VMware Workstation 8 (64bit, Win7-ultimate x64) guest hangs all the same, on MSHTML.DLL. Takes a while though :)
It implies:
- if your machine has low memory you'll run into this issue
- if your machine has enough memory you might run into this issue,
depending on the machine/emulator/virtualiser.
As p1 runs with 32MB and p3 runs with 40MB it's a shame to see p2 require about double this memory (or up to 512MB in some cases). On the other hand, it allows ROS to actually run apps in p3 instead of only looking at a nice system tray and desktop picture.
Best of luck releasing 0.3.14, developers.
-- With best regards Caemyr
Ros-dev mailing list Ros-dev@reactos.org http://www.reactos.org/mailman/listinfo/ros-dev
On Dec 19, 2011, at 6:33 AM, Pierre Schweitzer pierre@reactos.org wrote:
Le lundi 19 décembre 2011 à 22:08 +1100, Adam a écrit :
So long as this isn't a blocker (ie. one can just use 128MB instead of 64MB to resolve this) then you may as well release it.
And when it doesn't work with 256MB, we try 512MB? Your workaround appears not to work
I'm not sure where people keep getting that idea. It isn't and never was a RAM size issue and balancer has nothing to do with it.
Regards, Cameron
Wasn't the best way to avoid the issue just to disable VT-X in the VM configuration under VBOX?Or doesn't this trick work always? We can add a explicit message as "Ey,you!If you are using VboX greater than 4.0 and you face this issue, just disable VT-X for now and done!" If there is a way that any tester can use the VM...where is the big drama?
Yeah and if you do'y have VT-X support just go and cry ;)
2011/12/19 victor martinez vicmarcal@hotmail.com
Wasn't the best way to avoid the issue just to disable VT-X in the VM configuration under VBOX?Or doesn't this trick work always? We can add a explicit message as "Ey,you!If you are using VboX greater than 4.0 and you face this issue, just disable VT-X for now and done!" If there is a way that any tester can use the VM...where is the big drama?
Ros-dev mailing list Ros-dev@reactos.org http://www.reactos.org/mailman/listinfo/ros-dev
Adding such messages is useless IMHO...
2011/12/19 Igor Paliychuk mansonigor@gmail.com
Yeah and if you do'y have VT-X support just go and cry ;)
2011/12/19 victor martinez vicmarcal@hotmail.com
Wasn't the best way to avoid the issue just to disable VT-X in the VM configuration under VBOX?Or doesn't this trick work always? We can add a explicit message as "Ey,you!If you are using VboX greater than 4.0 and you face this issue, just disable VT-X for now and done!" If there is a way that any tester can use the VM...where is the big drama?
Ros-dev mailing list Ros-dev@reactos.org http://www.reactos.org/mailman/listinfo/ros-dev
Am 19.12.2011 17:30, schrieb victor martinez:
Wasn't the best way to avoid the issue just to disable VT-X in the VM configuration under VBOX?Or doesn't this trick work always? We can add a explicit message as "Ey,you!If you are using VboX greater than 4.0 and you face this issue, just disable VT-X for now and done!" If there is a way that any tester can use the VM...where is the big drama?
Nope, it was to *enable* vt-x, but not everyone has a CPU that supports that.
Please DO NOT tie this bug with VT-x. On iCore series CPU host, this bug will happen even with VT-x is enabled. In this case, only nested paging enabled will mitigate the bug.
If nested paging will stop helping in this case for any reason, my testbot machine is out of business.
On Mon, Dec 19, 2011, at 04:30 PM, victor martinez wrote:
Wasn't the best way to avoid the issue just to disable VT-X in the VM configuration under VBOX?Or doesn't this trick work always? We can add a explicit message as "Ey,you!If you are using VboX greater than 4.0 and you face this issue, just disable VT-X for now and done!" If there is a way that any tester can use the VM...where is the big drama?
Ros-dev mailing list Ros-dev@reactos.org http://www.reactos.org/mailman/listinfo/ros-dev
So? Is there any decision what we are doing? Branching? Releasing? Postponing?
2011/12/20, caemyr@myopera.com caemyr@myopera.com:
Please DO NOT tie this bug with VT-x. On iCore series CPU host, this bug will happen even with VT-x is enabled. In this case, only nested paging enabled will mitigate the bug.
If nested paging will stop helping in this case for any reason, my testbot machine is out of business.
On Mon, Dec 19, 2011, at 04:30 PM, victor martinez wrote:
Wasn't the best way to avoid the issue just to disable VT-X in the VM configuration under VBOX?Or doesn't this trick work always? We can add a explicit message as "Ey,you!If you are using VboX greater than 4.0 and you face this issue, just disable VT-X for now and done!" If there is a way that any tester can use the VM...where is the big drama?
Ros-dev mailing list Ros-dev@reactos.org http://www.reactos.org/mailman/listinfo/ros-dev
-- With best regards Caemyr
Ros-dev mailing list Ros-dev@reactos.org http://www.reactos.org/mailman/listinfo/ros-dev
I propose to branch right today (unless there are strong reasons not to) and wait till time decided on the meeting for the fix/hackfix expires.
When the (hack)fix is found it would just be merged in to the release branch, or when the time expires the branch is going to be released as is (as decided on the meeting).
WBR, Aleksey Bragin.
On 21.12.2011 17:43, Igor Paliychuk wrote:
So? Is there any decision what we are doing? Branching? Releasing? Postponing?
2011/12/20, caemyr@myopera.comcaemyr@myopera.com:
Please DO NOT tie this bug with VT-x. On iCore series CPU host, this bug will happen even with VT-x is enabled. In this case, only nested paging enabled will mitigate the bug.
If nested paging will stop helping in this case for any reason, my testbot machine is out of business.
On Mon, Dec 19, 2011, at 04:30 PM, victor martinez wrote:
Wasn't the best way to avoid the issue just to disable VT-X in the VM configuration under VBOX?Or doesn't this trick work always? We can add a explicit message as "Ey,you!If you are using VboX greater than 4.0 and you face this issue, just disable VT-X for now and done!" If there is a way that any tester can use the VM...where is the big drama?
Ros-dev mailing list Ros-dev@reactos.org http://www.reactos.org/mailman/listinfo/ros-dev
-- With best regards Caemyr
Cameron
I think this is a general retort about how blockers should be treated (aka ignore it, just increase the RAM in VM).
On Mon, Dec 19, 2011, at 10:22 AM, Cameron Gutman wrote:
I'm not sure where people keep getting that idea. It isn't and never was a RAM size issue and balancer has nothing to do with it.
Regards, Cameron _______________________________________________ Ros-dev mailing list Ros-dev@reactos.org http://www.reactos.org/mailman/listinfo/ros-dev
Yes, that's what I'm appealing to. Though I really wish our OS becomes mature enough, 0.3.14 is not a release advised for production usage.
I highly appreciate Olaf's efforts to raise the quality of every release, though. And whenever possible I agree with his arguments and just sit down and chase bugs myself if noone else wants to. It's just that remaining mm code can't be rewritten within a short period of time. That's why I propose to release with a known bug.
WBR, Aleksey Bragin.
On 19.12.2011 15:08, Adam wrote:
Thing is that this is a pre-alpha operating system. The "0.x" basically indicates it is not finished. Sure the release should be special but strictly speaking it should be done. The new MM can wait (IMO) up until 0.3.15 - there's little point worrying about it in the next release.
So long as this isn't a blocker (ie. one can just use 128MB instead of 64MB to resolve this) then you may as well release it.
I remember 0.3.11 well. Networking on it was horrible and often I had trouble trying to get the cards to work on VBox and QEMU - it was still release wasn't it?
If one was to wait until every little bug was fixed before releasing, then one should review the purpose of a release. Especially a *pre-alpha* release. There should (IMO) be a "Known Issues" for situations like this.
As a result I have no objection branching now.
On Mon, 19 Dec 2011 09:22:24 +0100 Javier Agustìn Fernàndez Arroyoelhoir@gmail.com wrote:
+1 to Caemyr
On Sun, Dec 18, 2011 at 11:15 PM,caemyr@myopera.com wrote:
It is NOT a vbox issue. If we release with this bug, it will bite us back for long. Sometimes, its better to delay than to release a bugger.
On Sun, Dec 18, 2011, at 11:08 PM, Bernd Blaauw wrote:
Op 18-12-2011 22:49, Aleksey Bragin schreef:
Try other virtual machines for now, this is the only thing I can advise until it's fixed. VMWare Workstation (Player), Parallels Workstation, they don't exhibit the bug.
64MB VMware Workstation 8 (64bit, Win7-ultimate x64) guest hangs all the same, on MSHTML.DLL. Takes a while though :)
It implies:
- if your machine has low memory you'll run into this issue
- if your machine has enough memory you might run into this issue,
depending on the machine/emulator/virtualiser.
As p1 runs with 32MB and p3 runs with 40MB it's a shame to see p2 require about double this memory (or up to 512MB in some cases). On the other hand, it allows ROS to actually run apps in p3 instead of only looking at a nice system tray and desktop picture.
Best of luck releasing 0.3.14, developers.
-- With best regards Caemyr
I have purpose: we should create a plan of features/fixes after release that should be done before the next release and assign every point to some devs. This would make developing more coordinate and avoid in future such cases that we have now(i mean people began to test/investigate mshtml bug only when we began to talk about release and all the rest of time before it was untouched) Sorry for long sentence :)
2011/12/19 Aleksey Bragin aleksey@reactos.org
Yes, that's what I'm appealing to. Though I really wish our OS becomes mature enough, 0.3.14 is not a release advised for production usage.
I highly appreciate Olaf's efforts to raise the quality of every release, though. And whenever possible I agree with his arguments and just sit down and chase bugs myself if noone else wants to. It's just that remaining mm code can't be rewritten within a short period of time. That's why I propose to release with a known bug.
WBR, Aleksey Bragin.
On 19.12.2011 15:08, Adam wrote:
Thing is that this is a pre-alpha operating system. The "0.x" basically indicates it is not finished. Sure the release should be special but strictly speaking it should be done. The new MM can wait (IMO) up until 0.3.15 - there's little point worrying about it in the next release.
So long as this isn't a blocker (ie. one can just use 128MB instead of 64MB to resolve this) then you may as well release it.
I remember 0.3.11 well. Networking on it was horrible and often I had trouble trying to get the cards to work on VBox and QEMU - it was still release wasn't it?
If one was to wait until every little bug was fixed before releasing, then one should review the purpose of a release. Especially a *pre-alpha* release. There should (IMO) be a "Known Issues" for situations like this.
As a result I have no objection branching now.
On Mon, 19 Dec 2011 09:22:24 +0100 Javier Agustìn Fernàndez Arroyoelhoir@gmail.com wrote:
+1 to Caemyr
On Sun, Dec 18, 2011 at 11:15 PM,caemyr@myopera.com wrote:
It is NOT a vbox issue. If we release with this bug, it will bite
us back for long. Sometimes, its better to delay than to release a bugger.
On Sun, Dec 18, 2011, at 11:08 PM, Bernd Blaauw wrote:
Op 18-12-2011 22:49, Aleksey Bragin schreef:
Try other virtual machines for now, this is the only thing I can advise until it's fixed. VMWare Workstation (Player), Parallels Workstation, they don't exhibit the bug.
64MB VMware Workstation 8 (64bit, Win7-ultimate x64) guest hangs all the same, on MSHTML.DLL. Takes a while though :)
It implies:
- if your machine has low memory you'll run into this issue
- if your machine has enough memory you might run into this issue,
depending on the machine/emulator/virtualiser.
As p1 runs with 32MB and p3 runs with 40MB it's a shame to see p2 require about double this memory (or up to 512MB in some cases). On the other hand, it allows ROS to actually run apps in p3 instead of only looking at a nice system tray and desktop picture.
Best of luck releasing 0.3.14, developers.
-- With best regards Caemyr
______________________________**_________________ Ros-dev mailing list Ros-dev@reactos.org http://www.reactos.org/**mailman/listinfo/ros-devhttp://www.reactos.org/mailman/listinfo/ros-dev
This is definetely not new idea but it could make developing more effective.
2011/12/19 Igor Paliychuk mansonigor@gmail.com
I have purpose: we should create a plan of features/fixes after release that should be done before the next release and assign every point to some devs. This would make developing more coordinate and avoid in future such cases that we have now(i mean people began to test/investigate mshtml bug only when we began to talk about release and all the rest of time before it was untouched) Sorry for long sentence :)
2011/12/19 Aleksey Bragin aleksey@reactos.org
Yes, that's what I'm appealing to. Though I really wish our OS becomes mature enough, 0.3.14 is not a release advised for production usage.
I highly appreciate Olaf's efforts to raise the quality of every release, though. And whenever possible I agree with his arguments and just sit down and chase bugs myself if noone else wants to. It's just that remaining mm code can't be rewritten within a short period of time. That's why I propose to release with a known bug.
WBR, Aleksey Bragin.
On 19.12.2011 15:08, Adam wrote:
Thing is that this is a pre-alpha operating system. The "0.x" basically indicates it is not finished. Sure the release should be special but strictly speaking it should be done. The new MM can wait (IMO) up until 0.3.15 - there's little point worrying about it in the next release.
So long as this isn't a blocker (ie. one can just use 128MB instead of 64MB to resolve this) then you may as well release it.
I remember 0.3.11 well. Networking on it was horrible and often I had trouble trying to get the cards to work on VBox and QEMU - it was still release wasn't it?
If one was to wait until every little bug was fixed before releasing, then one should review the purpose of a release. Especially a *pre-alpha* release. There should (IMO) be a "Known Issues" for situations like this.
As a result I have no objection branching now.
On Mon, 19 Dec 2011 09:22:24 +0100 Javier Agustìn Fernàndez Arroyoelhoir@gmail.com wrote:
+1 to Caemyr
On Sun, Dec 18, 2011 at 11:15 PM,caemyr@myopera.com wrote:
It is NOT a vbox issue. If we release with this bug, it will bite
us back for long. Sometimes, its better to delay than to release a bugger.
On Sun, Dec 18, 2011, at 11:08 PM, Bernd Blaauw wrote:
Op 18-12-2011 22:49, Aleksey Bragin schreef:
> Try other virtual machines for now, this is the only thing I > can advise until it's fixed. > VMWare Workstation (Player), Parallels Workstation, they don't > exhibit the bug. > 64MB VMware Workstation 8 (64bit, Win7-ultimate x64) guest hangs all the same, on MSHTML.DLL. Takes a while though :)
It implies:
- if your machine has low memory you'll run into this issue
- if your machine has enough memory you might run into this issue,
depending on the machine/emulator/virtualiser.
As p1 runs with 32MB and p3 runs with 40MB it's a shame to see p2 require about double this memory (or up to 512MB in some cases). On the other hand, it allows ROS to actually run apps in p3 instead of only looking at a nice system tray and desktop picture.
Best of luck releasing 0.3.14, developers.
-- With best regards Caemyr
______________________________**_________________ Ros-dev mailing list Ros-dev@reactos.org http://www.reactos.org/**mailman/listinfo/ros-devhttp://www.reactos.org/mailman/listinfo/ros-dev
You could release with the bug, then release an 'r2' when the mm is rewritten?
2011/12/19 Igor Paliychuk mansonigor@gmail.com:
This is definetely not new idea but it could make developing more effective.
2011/12/19 Igor Paliychuk mansonigor@gmail.com
I have purpose: we should create a plan of features/fixes after release that should be done before the next release and assign every point to some devs. This would make developing more coordinate and avoid in future such cases that we have now(i mean people began to test/investigate mshtml bug only when we began to talk about release and all the rest of time before it was untouched) Sorry for long sentence :)
2011/12/19 Aleksey Bragin aleksey@reactos.org
Yes, that's what I'm appealing to. Though I really wish our OS becomes mature enough, 0.3.14 is not a release advised for production usage.
I highly appreciate Olaf's efforts to raise the quality of every release, though. And whenever possible I agree with his arguments and just sit down and chase bugs myself if noone else wants to. It's just that remaining mm code can't be rewritten within a short period of time. That's why I propose to release with a known bug.
WBR, Aleksey Bragin.
On 19.12.2011 15:08, Adam wrote:
Thing is that this is a pre-alpha operating system. The "0.x" basically indicates it is not finished. Sure the release should be special but strictly speaking it should be done. The new MM can wait (IMO) up until 0.3.15 - there's little point worrying about it in the next release.
So long as this isn't a blocker (ie. one can just use 128MB instead of 64MB to resolve this) then you may as well release it.
I remember 0.3.11 well. Networking on it was horrible and often I had trouble trying to get the cards to work on VBox and QEMU - it was still release wasn't it?
If one was to wait until every little bug was fixed before releasing, then one should review the purpose of a release. Especially a *pre-alpha* release. There should (IMO) be a "Known Issues" for situations like this.
As a result I have no objection branching now.
On Mon, 19 Dec 2011 09:22:24 +0100 Javier Agustìn Fernàndez Arroyoelhoir@gmail.com wrote:
+1 to Caemyr
On Sun, Dec 18, 2011 at 11:15 PM,caemyr@myopera.com wrote:
It is NOT a vbox issue. If we release with this bug, it will bite us back for long. Sometimes, its better to delay than to release a bugger.
On Sun, Dec 18, 2011, at 11:08 PM, Bernd Blaauw wrote: > > Op 18-12-2011 22:49, Aleksey Bragin schreef: >> >> Try other virtual machines for now, this is the only thing I >> can advise until it's fixed. >> VMWare Workstation (Player), Parallels Workstation, they don't >> exhibit the bug. > > 64MB VMware Workstation 8 (64bit, Win7-ultimate x64) guest hangs > all the same, on MSHTML.DLL. Takes a while though :) > > It implies: > - if your machine has low memory you'll run into this issue > - if your machine has enough memory you might run into this issue, > depending on the machine/emulator/virtualiser. > > As p1 runs with 32MB and p3 runs with 40MB it's a shame to see p2 > require about double this memory (or up to 512MB in some cases). > On the other hand, it allows ROS to actually run apps in p3 > instead of only looking at a nice system tray and desktop picture. > > Best of luck releasing 0.3.14, developers.
-- With best regards Caemyr
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
Hi! I've been against releasing in this current state mainly because the bad PR related to this action. In one pan of the scales we have the "Bad PR because releasing with a noticeable bug", in the other pan "Bad PR because not releasing since more than X months ago". Not releasing affects the PR but also the stability/compatibility of the OS since just during the release time intensive app testings are performed. Since ReactOS devs have been trying to fix the issue, with no results, the "X" factor, which is now 8, can grow to "sine die". Also those who were able to test ReactOS, as the Total Commander developer, have suggested to release because the "great performance and stability of current trunk compared to 0.3.13"
Because all of these, I am agree with releasing but just, and only just, if the next actions are done in order to mitigate the bad PR impact that we will suffer for sure:
1)Adding a message,during 1st stage or before running 2nd stage, warning the user that a known bug is present which can appear when copying mshtml file and pointing him to www.reactos.org to find a solution: "This release is known to rise a potential bug due to our MM extensive rewrite. If the installation stucks in mshtml or later, please visit www.reactos.org, there you will find several ways to solve it. The ReactOS Team is working to have the MM ready as soon as possible.This rewrite is needed to ensure the best compatibility and performance. Sorry for the inconvenience and thanks for your patience. "(or similar)
2)Adding an "Are you suffering the MSHTML bug?" banner in the frontpage which redirects to a Wiki page explaining the ways to circumvent the issue and politely asking for Debug Logs.
3)Adding a massive DPRINTing in the MM and friends to find a clue about why MM is going nuts.
After releasing:
4)Working actively in the MM issue. If in 3 months there is no solution, then we should seriously freeze the development trunk.Sadly.
5)The revision that definitly fix the issue will be branched, tested and fastly released as "0.4.0 RC". 0.PI must be removed asap.
6)The next official release after "0.4.0 RC" will be "0.4.0" after fixing any potential regression.
All these actions have a reason related to our public image, PR impact and community motivation. If anyone has a doubt about any of them, I'll be glad of answering them.
If these conditions are not accepted then I'd be totally against releasing 0.3.14.
Víctor
Am 19.12.2011 15:15, schrieb victor martinez:
Because all of these, I am agree with releasing but just, and only just, if the next actions are done in order to mitigate the bad PR impact that we will suffer for sure:
1)Adding a message,during 1st stage or before running 2nd stage, warning the user that a known bug is present which can appear when copying mshtml file and pointing him to www.reactos.org to find a solution: "This release is known to rise a potential bug due to our MM extensive rewrite. If the installation stucks in mshtml or later, please visit www.reactos.org, there you will find several ways to solve it. The ReactOS Team is working to have the MM ready as soon as possible.This rewrite is needed to ensure the best compatibility and performance. Sorry for the inconvenience and thanks for your patience. "(or similar)
2)Adding an "Are you suffering the MSHTML bug?" banner in the frontpage which redirects to a Wiki page explaining the ways to circumvent the issue and politely asking for Debug Logs.
Sounds good to me.
3)Adding a massive DPRINTing in the MM and friends to find a clue about why MM is going nuts.
Doesn't sound good to me. Massive DPRINTs just make the system slow and usually don't give a clue, unless you are actively debugging it. Also our debuglog is already full of spam.
I'm personally against releasing with this bug. It will affect a huge number of people who want to test the new release and the first thing they encounter is the inability to install. Delaying the release for another month or 2 on the other hand doesn't make thing much worse than they are now already.
Instead we could put a note on the frontpage that we are planning to release soon, but one annoying bug keeps us from doing so. For everyone who can't wait, we might link a recent build with the appropriate notes about the mshtml bug.
And regarding the Mm "rewrite": I have doubts it will be done anytime soon. So fixing the old code should be worth it.
Just my 2 cents, Timo
On Dec 19, 2011, at 11:31 AM, Timo Kreuzer wrote:
Am 19.12.2011 15:15, schrieb victor martinez:
3)Adding a massive DPRINTing in the MM and friends to find a clue about why MM is going nuts.
Doesn't sound good to me. Massive DPRINTs just make the system slow and usually don't give a clue, unless you are actively debugging it. Also our debuglog is already full of spam.
The trouble is that we don't know where the corruption is taking place in the code.
I'm personally against releasing with this bug. It will affect a huge number of people who want to test the new release and the first thing they encounter is the inability to install. Delaying the release for another month or 2 on the other hand doesn't make thing much worse than they are now already.
The only problem I have with delaying the release is that we're getting more and more out of date with Wine and some great patches are waiting on the release. My vote would be to branch now, run 0.3.14 tests on the branch, then resume trunk development as if we had just released (Winesyncs, big patches, etc). After the Mm bug is found, we can either rebranch 0.3.14 if trunk is stable or merge the fix back and release the previous branch.
And regarding the Mm "rewrite": I have doubts it will be done anytime soon. So fixing the old code should be worth it.
I agree, and as a result RosMm sucks considerably less now ;)
Regards, Cameron
On 19.12.2011 21:02, Cameron Gutman wrote:
The only problem I have with delaying the release is that we're getting more and more out of date with Wine and some great patches are waiting on the release. My vote would be to branch now, run 0.3.14 tests on the branch, then resume trunk development as if we had just released (Winesyncs, big patches, etc). After the Mm bug is found, we can either rebranch 0.3.14 if trunk is stable or merge the fix back and release the previous branch.
What's the point of branching then, if it's going to be abandoned (you didn't specify a scenario when the branch gets released)?
I agree, and as a result RosMm sucks considerably less now ;)
Good work ;)
Le lundi 19 décembre 2011 à 21:24 +0400, Aleksey Bragin a écrit :
On 19.12.2011 21:02, Cameron Gutman wrote:
The only problem I have with delaying the release is that we're getting more and more out of date with Wine and some great patches are waiting on the release. My vote would be to branch now, run 0.3.14 tests on the branch, then resume trunk development as if we had just released (Winesyncs, big patches, etc). After the Mm bug is found, we can either rebranch 0.3.14 if trunk is stable or merge the fix back and release the previous branch.
What's the point of branching then, if it's going to be abandoned (you didn't specify a scenario when the branch gets released)?
The same for many branches: having a snapshot of ReactOS state at a revision. So, if after the bug is fixed, but other stuff got broken due to sync, patches, implementations, whatever, we can just backport the fix to the branch and release 0.3.14 with the branch.
And if trunk is stable enough, then, we drop the branch, and start again with something fresh.
So, I support this idea.
And once more: I don't agree with a release shipped with mshtml bug.
-
Adam -
Aleksey Bragin -
Alex Ionescu -
Bernd Blaauw -
caemyr＠myopera.com -
Cameron Gutman -
Igor Paliychuk -
Javier Agustìn Fernàndez Arroyo -
Magnus Johnsson -
Pierre Schweitzer -
Timo Kreuzer -
victor martinez -
Александр