ReactOS Newsletter: Volume 3, Issue 24

Volume 3, Issue 24

Release Plans
Registry Structure
Bugzilla Activity

Newsletter Archive

by Z98 on 2007-05-20

When exam time comes, my priorities shift to real life obviously. As such, the newsletter is a week late. Whether the next newsletter is a week away or two will be up to Samuel when he gets around to it.

top

Release Plans

When the new release cycle was announced, the idea was that releases would happen every two months. This was a theoretical timeline that was dependent on several factors. First was the state of trunk. The actual branching was likely to take place within a day of the actual release, meaning trunk had to be in good shape in order to release. This also tries to avoid putting in hacks so that the releases will look like it works. However, if trunk has major issues, like right now, the release will obviously be delayed. This way, the releases will be more in sync with the actual state of ReactOS and any bugs found in it might actually be relevant to development. In the past, bugs in releases were more often than not caused by hacks used in branch and were not pertinent to trunk, so reporting them did little good.

That said, people keep seeming to misunderstand why a faster release schedule was adopted. The state of ReactOS means that from a user standpoint, the releases don't do much. There's no easy upgrade path short of wiping the harddrive and reinstalling and while stability has improved, ROS remains unusable for day to day activities. It just won't hold under the strain. All the releases are more for publicity, to attract people's attention to ReactOS and give them something to play with. The virtual machine releases are especially good for demo purposes.

The developers chose the two month cycle as a way to motivate themselves. When a release was half a year away or possibly even further, motivation to work out issues became lacking. Feature creep actually became an issue, as people began implementing new things and broke more of the system. With a tighter release schedule, developers are forced to do a better job of avoiding major and minor breakages or risk getting chewed out by their fellow programmers, specifically Aleksey Bragin, the project coordinator, or Alex Ionescu, the kernel lead. This will hopefully reduce the number of bugs that are allowed to wallow and linger.
top

Registry Structure

Alex Ionescu has been going nuts with the registry code, trying to make it more compatible with Windows. He's been doing some of the work in the CM(Configuration Manager) branch and has recently begun merging the changes in. This has resulted in the replacement of a lot of old code, which people watching the SVN commits can see. Getting the registry right is another step in becoming compatible with Windows, since so much system information is stored in there. Drivers, applications, and user data are all stored in there.
top

Bugzilla Activity

55 bugs were active in the period from 2007-05-01 to 2007-05-20.

34 new bugs
A total of 13 bugs fixed
Oldest bug fixed was 1991 "Format partition doesn't work"

top