I in some ways don't get the release cycle when it is at times all over the place. It feels like a burden on the dev's as they gear up for it
I am greatful that they do it. I would rather they moved to something like 2 months of development and 1 month of regression testing, change log commits and that's it grab a nightly at the end of that month. What's the point of applying hack fixes at a release for some programs if the OS is not stable to use at the moment anyway.
In saying that thou I can understand applying hack fixes if your gearing up to go to a major open source conference to showcase the potential of Reactos
Although I don't participate in ROS development, my full time job is development at a Fortune 10 company. I also used to teach music in public schools. What I have learned is this.
If you don't schedule a concert or other performance for the kids to work to, they don't have a goal in mind and will keep working on whatever has their attention. Not what needs to be done.
If you commit to a release date, some features are going to be pushed off into the next quarter/release/milestone. Usually that means whoever wants to work on it can't, or at least can't contribute to the main branch(es). If they keep working on future things and not whatever is holding the release up, they look like the slacker.
In a school or Fortune 10 setting, these are easily controlled. All of the developers have to have the same perspective and priority, whether enforced through grades or a manager. With a volunteer army, it is not easy. Especially when a lot of the documentation you are working towards is incomplete or wrong. For these reasons, anything that is decided will be violated, on a regular basis.
One the many rewrites have been completed or are close enough, a routine might be possible.
A user-centric feature release sounds like it would be "Now this works. Now this works. Even nower, this worksier." In reality it would be "This now works, but we broke these two things." Even if one is major and the other two are minor. I understand the reason for wanting this, and I support it. The result would be to undermine casual users' faith in the application, since the feature set changes. I used to be able to use this application, now it just makes a BSOD, that's what people will see. Alpha means don't expect it to work, so this fits right in. But it doesn't fulfill the request of showing progress as it is meant to.
There is only one way to have a user feature release cycle, not dates or modules or bunches of changes. ReactOS actually started out that way, with attention paid to visible progress instead of correctness. That's what led to the list of rewrites Smiley had. If you've ever read Joel on Software (of Fogbugz), you'll know that a rewrite carries more expense than just the effort itself. It will break things, and you'll have to go re-fix some bugs when you're done. That means the user-centric features are not going to work just right, in fact they will at times regress until the correctness of the new functionality is proven. Every enhancement like alpha blending causes problems like smurfs. The one way involves many branches, and a dedicated team who decides which commits go in which branches. Something that causes a regression would have to be eliminated from the release trunk, and all related patches would have to be carefully merged to ensure the regression features stay out while progress gets in. This is like the Linux model, with many people maintaining trees to ensure it is working as a whole, but doing little or no work themselves. Too few people for this, and it keeps the possibility that something will be incompatible with something else, and a lot of effort wasted when they get merged later. Re-work ensues. Perfect documentation would help, but it doesn't exist.
In short, there is no one able to enforce rigidity. Only pleas for sanity and developers agreeing on priority. You want to see progress? Download trunk. If something doesn't work, especially if it used to, you can help by learning to file bugs and test other trunk versions to see where it started to go wrong. This is the type of continuous feedback that will keep people from straying too far. Sometimes it can't be helped, but when soemthing breaks someone needs to know now, not 2 months from now.
As an aside, it seems that a lot of problems are caused by using Wine code. They try to be as correct as possible, so I'm not knocking them, but a bug in their code will make ROS look like it works, then a sync blows everything up and ROS has to figure out if Wine is right or where the bug is. There is no person who understands both codebases and can identify problems, so many bugs are simply "caused by wine sync" and no one knows. ReactOS does not have a way to make Wine devs focus on certain bugs either, so a bug report might sit for a while until Wine feels like fixing it. So even if ReactOS had enough developers for its components and a ringleader deciding what gets worked on, the dependency on Wine re-introduces the same problems on a larger scale.
There are things that can be tweaked, and testing plus bug reports helps the developers a lot, but there are too many unknowns to be able to stick to something. Try yes, but it won't work immediately.
What you say is essentially right, alas you know well enough that theories rarely can fit every day's life. In our situation, this project is undermanned, which makes any goal-setting and enforcing even more difficult.
"Undermanned" is precisely the point. - It is a devious circle, to the biggest degree, but breaking out of it is THE hurdle that needs to be taken for ReactOS to ever be anything more than a... very successful hobby project (what it is now - really, very very impressive for what is possible with so few people, but nothing you would rely on in production.. yet). I do believe this hurdle cannot be merely observed forever, though. Sooner or later we will need to consider to do something to break out of it.
