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<http://www.reactos.org/mailman/listinfo/ros-dev> >> > >
_______________________________________________ Ros-dev mailing list [email protected] http://www.reactos.org/mailman/listinfo/ros-dev
