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 Bra
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
Ros-dev@reactos.o
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
This bug will not be fixed before release. It needs a lot of new code.
2011/12/18 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
>>
>
> Thos
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
*Bernd Blaauw*
This bug WAS present in 0.3.13, though it as hacked and that hack helped
only partially.
2011/12/18
> 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
Bugs #6672, 6281, 5802, 547718.12.2011, 21:08, "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
we can always release 0.3.14-rc1, -rc2 and so :P
On Sun, Dec 18, 2011 at 8:25 PM, Igor Paliychuk wrote:
> *Bernd Blaauw*
> This bug WAS present in 0.3.13, though it as hacked and that hack helped
> only partially.
> 2011/12/18
>
> Gecko is not a problem. This bug is not happening with mshtml onl
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
> wrote:
>
> > *Bernd Blaauw*
> > This bug WAS p
+#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" :
> > Hi,
> > as the resu
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 motiv
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, Pi
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,
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 on
+1 to Caemyr
On Sun, Dec 18, 2011 at 11:15 PM, 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 Bragi
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
> +1 to Caemyr
>
> On Sun, Dec 18, 2011 at 11:15 PM, wrote:
>
>> It is NOT a vbox issue. If we release with this bug, it will bite us back
>> for long. Sometimes, it
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 c
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
This is definetely not new idea but it could make developing more effective.
2011/12/19 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 co
You could release with the bug, then release an 'r2' when the mm is rewritten?
2011/12/19 Igor Paliychuk :
> This is definetely not new idea but it could make developing more effective.
>
>
> 2011/12/19 Igor Paliychuk
>>
>> I have purpose: we should create a plan of features/fixes after release
>
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
On Dec 19, 2011, at 6:33 AM, Pierre Schweitzer 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 51
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
>
> 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
Adding such messages is useless IMHO...
2011/12/19 Igor Paliychuk
> Yeah and if you do'y have VT-X support just go and cry ;)
>
> 2011/12/19 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 alw
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 t
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
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 developmen
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 b
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 ha
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
So? Is there any decision what we are doing? Branching? Releasing? Postponing?
2011/12/20, cae...@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.
>
>
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 de
37 matches
Mail list logo
