0.PI branching

[Aleksey Bragin]

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.

[Aleksey Bragin]

On 18.12.2011 21:08, Aleksey Bragin wrote:
>   Any comments, motivated objections? If not, then
> branching will be 
>  done on Monday, 18th of December 2011. 
Capt. Obvious suggests that Monday is 19th.


WBR,
Aleksey.

[Bernd Blaauw]

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 :)

[Igor Paliychuk]

This bug will not be fixed before release. It needs a lot of new code.

2011/12/18 Bernd Blaauw <bblaauw(a)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(a)reactos.org
>
> http://www.reactos.org/**mailman/listinfo/ros-dev<http://www.reactos.org…
>

[Bernd Blaauw]

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(a)reactos.org
>  http://www.reactos.org/mailman/listinfo/ros-dev
>   

-- 
With best regards
Caemyr

[Igor Paliychuk]

*Bernd Blaauw*
This bug WAS present in 0.3.13, though it as hacked and that hack helped
only partially.
2011/12/18 <caemyr(a)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(a)reactos.org
> >  http://www.reactos.org/mailman/listinfo/ros-dev
> >  
>
>  --
>  With best regards
>  Caemyr
>
>  _______________________________________________
>  Ros-dev mailing list
>  Ros-dev(a)reactos.org
>  http://www.reactos.org/mailman/listinfo/ros-dev
>

[Javier Agustìn Fernàndez Arroyo]

we can always release 0.3.14-rc1, -rc2 and so :P

On Sun, Dec 18, 2011 at 8:25 PM, Igor Paliychuk <mansonigor(a)gmail.com>wrote;wrote:

>   *Bernd Blaauw*
>  This bug WAS present in 0.3.13, though it as hacked and that hack helped
>  only partially.
>  2011/12/18 <caemyr(a)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(a)reactos.org
> > >  http://www.reactos.org/mailman/listinfo/ros-dev
> > >  
> >
> >  --
> >  With best regards
> >  Caemyr
> >
> >  _______________________________________________
> >  Ros-dev mailing list
> >  Ros-dev(a)reactos.org
> >  http://www.reactos.org/mailman/listinfo/ros-dev
> >  
>
>  _______________________________________________
>  Ros-dev mailing list
>  Ros-dev(a)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(a)gmail.com>wrote;wrote:
>  
> >   *Bernd Blaauw*
> >  This bug WAS present in 0.3.13, though it as hacked and that hack helped
> >  only partially.
> >  2011/12/18 <caemyr(a)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(a)reactos.org
> > > >  http://www.reactos.org/mailman/listinfo/ros-dev
> > > >  
> > >
> > >  --
> > >  With best regards
> > >  Caemyr
> > >
> > >  _______________________________________________
> > >  Ros-dev mailing list
> > >  Ros-dev(a)reactos.org
> > >  http://www.reactos.org/mailman/listinfo/ros-dev
> > >  
> >
> >  _______________________________________________
> >  Ros-dev mailing list
> >  Ros-dev(a)reactos.org
> >  http://www.reactos.org/mailman/listinfo/ros-dev
> >  
>  
>  _______________________________________________
>  Ros-dev mailing list
>  Ros-dev(a)reactos.org
>  http://www.reactos.org/mailman/listinfo/ros-dev 

-- 
With best regards
Caemyr

[Pierre Schweitzer]

+#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(a)reactos.org>rg>:
> >   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(a)reactos.org
> >  http://www.reactos.org/mailman/listinfo/ros-dev
> >   
>  -- 
>  С наилучшими пожеланиями, Александр.
>  _______________________________________________
>  Ros-dev mailing list
>  Ros-dev(a)reactos.org
>  http://www.reactos.org/mailman/listinfo/ros-dev

[Aleksey Bragin]

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(a)reactos.org>tos.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.

[Alex Ionescu]

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(a)reactos.org>tos.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(a)reactos.org
>  http://www.reactos.org/mailman/listinfo/ros-dev

[Bernd Blaauw]

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. 
-- 
With best regards
Caemyr

[Javier Agustìn Fernàndez Arroyo]

+1 to Caemyr

On Sun, Dec 18, 2011 at 11:15 PM, <caemyr(a)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(a)reactos.org
>  http://www.reactos.org/mailman/listinfo/ros-dev
>

[Igor Paliychuk]

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(a)gmail.com>

>   +1 to Caemyr
>
>  On Sun, Dec 18, 2011 at 11:15 PM, <caemyr(a)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(a)reactos.org
> >  http://www.reactos.org/mailman/listinfo/ros-dev
> >  
>
>  _______________________________________________
>  Ros-dev mailing list
>  Ros-dev(a)reactos.org
>  http://www.reactos.org/mailman/listinfo/ros-dev
>

[Adam]

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(a)gmail.com> wrote:

>   +1 to Caemyr
>  
>  On Sun, Dec 18, 2011 at 11:15 PM, <caemyr(a)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(a)reactos.org
>  > http://www.reactos.org/mailman/listinfo/ros-dev
>  >

[Pierre Schweitzer]

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

[Cameron Gutman]

On Dec 19, 2011, at 6:33 AM, Pierre Schweitzer <pierre(a)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

[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?

[Igor Paliychuk]

Yeah and if you do'y have  VT-X  support just go and cry ;)

2011/12/19 victor martinez <vicmarcal(a)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(a)reactos.org
>  http://www.reactos.org/mailman/listinfo/ros-dev
>

[Igor Paliychuk]

Adding such messages is useless IMHO...

2011/12/19 Igor Paliychuk <mansonigor(a)gmail.com>

>   Yeah and if you do'y have  VT-X  support just go
> and cry ;)
>
>  2011/12/19 victor martinez <vicmarcal(a)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(a)reactos.org
> >  http://www.reactos.org/mailman/listinfo/ros-dev
> >  
>

[Timo Kreuzer]

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(a)reactos.org
>  http://www.reactos.org/mailman/listinfo/ros-dev 

-- 
With best regards
Caemyr

[Igor Paliychuk]

So? Is there any decision what we are doing? Branching? Releasing? Postponing?

2011/12/20, caemyr(a)myopera.com <caemyr(a)myopera.com>om>:
>   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(a)reactos.org
> >  http://www.reactos.org/mailman/listinfo/ros-dev 
>
>  --
>  With best regards
>  Caemyr
>
>  _______________________________________________
>  Ros-dev mailing list
>  Ros-dev(a)reactos.org
>  http://www.reactos.org/mailman/listinfo/ros-dev
>

[Aleksey Bragin]

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, [e-mail]<[e-mail]>:
> > 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(a)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(a)reactos.org
>  http://www.reactos.org/mailman/listinfo/ros-dev 

-- 
With best regards
Caemyr

[Aleksey Bragin]

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 Arroyo<elhoir(a)gmail.com>  wrote:
>
> > +1 to Caemyr
> >
> > On Sun, Dec 18, 2011 at 11:15 PM,<caemyr(a)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
> >>

[Igor Paliychuk]

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(a)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 Arroyo<elhoir(a)gmail.com>  wrote:
> >
> >   +1 to Caemyr
> > >
> > > On Sun, Dec 18, 2011 at 11:15 PM,<caemyr(a)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(a)reactos.org
>
> http://www.reactos.org/**mailman/listinfo/ros-dev<http://www.reactos.org…
>

[Igor Paliychuk]

This is definetely not new idea but it could make developing more effective.

2011/12/19 Igor Paliychuk <mansonigor(a)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(a)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 Arroyo<elhoir(a)gmail.com>  wrote:
> > >
> > >   +1 to Caemyr
> > > >
> > > > On Sun, Dec 18, 2011 at 11:15 PM,<caemyr(a)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(a)reactos.org
> >
> > http://www.reactos.org/**mailman/listinfo/ros-dev<http://www.reactos.org…
> >  
>

[Magnus Johnsson]

You could release with the bug, then release an 'r2' when the mm is rewritten?

2011/12/19 Igor Paliychuk <mansonigor(a)gmail.com>om>:
>   This is definetely not new idea but it could make
> developing more effective.
>
>
>  2011/12/19 Igor Paliychuk <mansonigor(a)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(a)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 Arroyo<elhoir(a)gmail.com>  wrote:
> > > >
> > > > > +1 to Caemyr
> > > > >
> > > > > On Sun, Dec 18, 2011 at 11:15 PM,<caemyr(a)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(a)reactos.org
> > >  http://www.reactos.org/mailman/listinfo/ros-dev 
> >  
>
>  _______________________________________________
>  Ros-dev mailing list
>  Ros-dev(a)reactos.org
>  http://www.reactos.org/mailman/listinfo/ros-dev

[victor martinez]

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

[Timo Kreuzer]

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

[Cameron Gutman]

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

[Aleksey Bragin]

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 ;)

[Pierre Schweitzer]

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.