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
+1 to Caemyr
On Sun, Dec 18, 2011 at 11:15 PM, cae...@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,
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 elh...@gmail.com
+1 to Caemyr
On Sun, Dec 18, 2011 at 11:15 PM, cae...@myopera.com wrote:
It is NOT a vbox issue. If we release with this bug, it will bite us
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
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
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
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
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
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
Yeah and if you do'y have VT-X support just go and cry ;)
2011/12/19 victor martinez vicmar...@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
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
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
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
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
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
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
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
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
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.
___
Ros-dev mailing list
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
This bug will not be fixed before release. It needs a lot of new code.
2011/12/18 Bernd Blaauw bbla...@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
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
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
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
mansoni...@gmail.comwrote:
*Bernd Blaauw*
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
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
26 matches
Mail list logo
