Page 1 of 2

0.3.15 launch suggestion

Posted: Sat Jan 28, 2012 10:36 am
by jonaspm
this is a personal comment:

i agree to launch 0.3.15 when the main two or three Blocking Bugs, are fixed, this to have a full installable and bootable OS....


hope you give your suggestions too!

Re: 0.3.15 launch suggestion

Posted: Sat Jan 28, 2012 5:19 pm
by FlyingIsFun1217
My suggestion to the dev team is to focus on 0.3.14 first :)

FlyingIsFun1217

Re: 0.3.15 launch suggestion

Posted: Sat Jan 28, 2012 5:29 pm
by g_hansrueck
AFAIK they will release 0.3.14 even with the mshtml-bug if it isn't (hack)fixed in the deadline of two weeks.
There is another thred on this subject already.

ghans

Re: 0.3.15 launch suggestion

Posted: Tue Jan 31, 2012 11:35 pm
by jonaspm
Of course they are focused on 0.3.14, but after finding the needed bug fixes, then launch 0.3.15 so the beta would come out after 0.3.15

Re: 0.3.15 launch suggestion

Posted: Tue Jan 31, 2012 11:43 pm
by FlyingIsFun1217
I believe the developers have already stated that simply fixing the mshtml bug will not warrant a 0.3.15 release.

FlyingIsFun1217

Re: 0.3.15 launch suggestion

Posted: Wed Feb 01, 2012 8:10 am
by jonaspm
the 0.3.15 would be alpha stage, and many commits would come out, others than mshtml bug...

So i think they will find the fix, by june, by the way, many commits with other fixes should had appeared, so no problem if they release 0.3.15 after the bug fix, there will be much more alpha versions ;)

Re: 0.3.15 launch suggestion

Posted: Wed Feb 01, 2012 7:01 pm
by Z98
It is a very bad idea to presume anything about ROS development cycles.

Re: 0.3.15 launch suggestion

Posted: Wed Feb 01, 2012 7:35 pm
by The123king
You cannot simply force ReactOS developers to fix bugs. Generally what happens in RwactOS development, if the developers will work on an aspect that they find interesting or useful to them. Eventually, a change will be commited that will change how a bug manifests itself, allowing a solution to the bug to be created. Sometimes, a change will inadvertently fix a bug.

What is common though, if there is not enough debug info to work out where in the code the bug is being caused.

Re: 0.3.15 launch suggestion

Posted: Thu Feb 02, 2012 8:14 am
by PurpleGurl
The123king wrote:You cannot simply force ReactOS developers to fix bugs. Generally what happens in RwactOS development, if the developers will work on an aspect that they find interesting or useful to them. Eventually, a change will be commited that will change how a bug manifests itself, allowing a solution to the bug to be created. Sometimes, a change will inadvertently fix a bug.

What is common though, if there is not enough debug info to work out where in the code the bug is being caused.
Agreed. Many fixes are adventitious (fixed in the course of fixing something else). I really hope they find the mshtml bug and other blockers so they can be clear to add other functionality, but it may take adding other functionality or rewriting portions for other reasons to help find such bugs. I saw that with the recent NTOSKRNL/SMSS/mm fixes.

The bugs are often partnered with other bugs, and they work well together in a sick sort of way. In the human realm, that is called codependency, where the failings of one person cover for the failings of another (or fuel the weaknesses of the other), and vice-versa. Just like with humans, intertwined bugs requires fixing the entire unit. Fixing just one will make matters seem worse, and sometimes that makes the rest of the problem stand out.

Posted: Thu Feb 02, 2012 5:41 pm
by hto
Fixing just one will make matters seem worse, and sometimes that makes the rest of the problem stand out.
And some people complain that ReactOS gets worse and worse with each new revision…

Re: 0.3.15 launch suggestion

Posted: Fri Feb 03, 2012 4:36 am
by jonaspm
Im sorry if you misunderstanded my comment, i just was showing my estimated date... I should close the mouth next time :/

Re: 0.3.15 launch suggestion

Posted: Fri Feb 03, 2012 5:09 am
by vicmarcal
No problem JonasPM.
Sadly without having a permanent developer team(understand permanent as paid and working 8 hours at day) stimations are impossible to be given. There are 2 main variables:

1)Murphy's Law. Coding is prone to bugs, and killing bugs eats a lot of time. This time is unmeasurable since you don't know how many bugs you are going to commit. Murphy's is our big friend here: "Set a schedule and you will never accomplish the task in the desired time"

2)Real life strike. Since devs have their own work and real life(sons, daughters, dogs, cats,...) they can not measure the impact of this real life to the coding. Real life is a mix of problems that noone knows when are going to test our patience :)


So these are the reasons which explains why trying to set a date is almost impossible.

Now think in Sam&Max game, it was developed by a Game company and developers being paid at the end of the month. It wasn't enough. Most of the games suffers the same issue.And their devs are being paid!
So neither paying them will ensure a perfect release date.

:)

Re:

Posted: Sat Feb 04, 2012 10:46 am
by PurpleGurl
hto wrote:And some people complain that ReactOS gets worse and worse with each new revision…
Sometimes it has to. As you add more functionality or rewrite a section, hack fixes have to be removed. That either shows that the new code is buggy, or highlights a longstanding bug that was hidden by previously broken code. So you might have bad version even though the code is more structurally sound and correct. A few years back when I first started dabbling with Reactos, I used to feel the way you mention. But now I understand why there are times when it seems more broken than some previous time. Sometimes adding functionality and removing hack fixes means you lose fake functionality to a section of immature code or code that is incompatible with something buggy elsewhere. But when that is fixed, it is better than what the hack fix did.

An example of this sort of code is with the old USB code. Well, it was broken, but it let the machine come up without CMOS changes to disable USB. But, once a few changes to other code were made, maybe the mouse and/or keyboard code, the old USB code became even more broken and interfered with booting for some to the point it was eventually removed for a time. But with a complete overhaul of the mouse, keyboard, and USB stuff, it seems time to merge the new USB code in (which I haven't tested).

Re: 0.3.15 launch suggestion

Posted: Wed May 16, 2012 11:10 pm
by Webunny
USB doesn't seem to function properly on real hardware, though (and yes, I'm talking trunk here, and yes, it's switched on in the bios).

At least, not on my machine. It doesn't get recognised, and when I try to start it with the usb attached, the start-up seems to hang, and when I remove it, it immediately resumes.

Re: 0.3.15 launch suggestion

Posted: Fri May 18, 2012 8:38 pm
by PurpleGurl
Webunny wrote:USB doesn't seem to function properly on real hardware, though (and yes, I'm talking trunk here, and yes, it's switched on in the bios).

At least, not on my machine. It doesn't get recognised, and when I try to start it with the usb attached, the start-up seems to hang, and when I remove it, it immediately resumes.
Back then, I was referring to branch. I think the same is true here now as what you find, but I haven't tested in a long while. I might have to hang onto my older machine for testing.