You could release with the bug, then release an 'r2' when the mm is rewritten?
2011/12/19 Igor Paliychuk <[email protected]>: > This is definetely not new idea but it could make developing more effective. > > > 2011/12/19 Igor Paliychuk <[email protected]> >> >> 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 <[email protected]> >>> >>> 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<[email protected]> wrote: >>>> >>>>> +1 to Caemyr >>>>> >>>>> On Sun, Dec 18, 2011 at 11:15 PM,<[email protected]> 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 >>> [email protected] >>> http://www.reactos.org/mailman/listinfo/ros-dev >> >> > > > _______________________________________________ > Ros-dev mailing list > [email protected] > http://www.reactos.org/mailman/listinfo/ros-dev _______________________________________________ Ros-dev mailing list [email protected] http://www.reactos.org/mailman/listinfo/ros-dev
