Versions release frequency

[bz00mmer]

...yes, I know, you cannot hear more questions about DATE of new release.
But there is not question, it is proposition.

What we have now:
- many people who are complaints release long delay;
- when release is ready, all of them began to wait and ask about next one;
- when release is ready, almost nobody happy, because active users know about features from newsletters;
- too silent news about new version because sooo many changes and most of them already was announced.

What I propose:
frequent releases for each feature which is important for users

What it gives:
- short delay from one release to anoter (one newsletter, for example,
usually describes few new features - i.e. releases often than twice in month);
- anybody can see real steps of project, which often hidden in background and stay unknown;
- users can be happy with seeing new features, which they count as important;
- such scheme will push Community Funded Ideas action;
- more buzz in shared news: there will be significant actions to be useful product;
- of cource, developers also receive promotion for their changes, for example:

18-01-2011. Version 0.3.27: Cameron Gutman implemented hooks, which are enables hotkeys support
28-01-2011. Version 0.3.28: Timo Kreuzer and Michael Martin significantly reworked our Explorer
05-02-2011. Version 0.3.29: Alexey Bragin says about serious improvements in Devices Manager & New Hardware Wizard

[bz00mmer]

What do you think about all that?
I found one more agreement against defining your plans:

Here’s a shocker: the product you send out the door will probably come later, and with fewer features, than you intended. Time runs out. Unexpected complications arise. Bugs overwhelm the team. Your partner invalidates your plans. Something’s got to give. You need to either take something out, or wait longer. But if you’ve spent months blowing smoke, now everyone is waiting longer.

The problem with talking smack is you immediately put yourself on the clock. You almost guarantee public disappointment when the product does not ship as (or when) promised. If you just shut your mouth and let the product speak for itself—once you actually have a product—then there’s a much better chance for people to be pleasantly surprised. Some companies understand this. Others clearly do not.

[EmuandCo]

I think we should not make too much releases. i propose to make a list with good nightlies for the ppl to test and if theres a REALLY big new thing, then make a release.

[Haos]

Let me address your points:

- short delay from one release to anoter (one newsletter, for example, usually describes few new features - i.e. releases often than twice in month);

This is the most important point, how long should the delay be. You are not specifying any precise values, just asking to do it more often.

- anybody can see real steps of project, which often hidden in background and stay unknown;
- users can be happy with seeing new features, which they count as important;
- such scheme will push Community Funded Ideas action;

Those commited features are available in trunk iso versions, built for every revision, but not fussed about.

- more buzz in shared news: there will be significant actions to be useful product;

Quite contrary, releases that happen too often are decreasing the public interest.

- of cource, developers also receive promotion for their changes

Perhaps, i dont know how effective would that be.

Now a word of explanation: why releases cant happen too often. Please note that i`m not saying that current delays are ok, they are not.
The most often overlooked issue of releasing is the time it takes to do one. When planning for release, we are trying to stabilise the trunk a bit, this is, to focus mostly on fixing bugs and regressions rather than introducing new code and functionalities that might contain new bugs. The extreme measure in this area is trunk lock, like the one we had recently. Its an aggresive measure and should be only used in rare circumstances, as its alienating and atomizing the dev team, but still necessary if persuasion and requests do not help. When trunk is stabilized enough for the release, the branch may finally be created. The trunk from now on will roam freely, but there is job to be done: testing, hacking the last-minute found bugs or the ones not dealt with during the trunk stabilisation period. There are also release-specific commits, changelog is to be written. To sum up, it will always take a good deal of time. This time is usually around 1/4th to 1/3rd of the time spent since the previous release... BUT.. it will not take less than three weeks up to month. Its physically impossible for us to release properly any faster.

Hence, there must be a balance. Releasing too often will require more time spent on testing/preparing the release and this time will have to be taken from actual development. So the proper question should not be if we should release more often - we should, one release per year is simpl not enough. The real problem is how many releases should we have each year.

[bz00mmer]

Question:

i propose to make a list with good nightlies for the ppl to test and if theres a REALLY big new thing, then make a release.

Answer:
Agree with your point, plus also usually developer ALREADY know which feature is important for user - so just give it to testers, for half-week-testing.

Question:

- short delay from one release to anoter (one newsletter, for example, usually describes few new features - i.e. releases often than twice in month);

This is the most important point, how long should the delay be. You are not specifying any precise values, just asking to do it more often.

Answer:

short delay from one release to anoter (one newsletter, for example,
usually describes few new features - i.e. releases often than twice in month)

But also I want to say: when user-significant feature is ready.
I.e. releases not by date, but by finishing issue.

Question:

Now a word of explanation: why releases cant happen too often...

Answer:
Yes, I fully agree with your point about regression tests and trunk freezing,
but if trunk tested more often - bugs(regressions) can be fixed early:
by detecting commit(binary search through revisions), which made a regression and whats wrong with it.
It is easier to fix - soon after comitting change (for both author and fixer).

The main thought of topic:
to make releases not DATE-oriented, not BUNDLE-OF-CHANGES-oriented, not MODULE-oriented,
but user-oriented (for each observed, significant feature)

[Geoz]

If I understand your proposition correctly, you would like more user orientated features, and you would like these user orientated features to be released to the public faster.

This is not going to happen. Firstly there are more important aspects of ReactOS that need to be developed first, of which the vast majority are invisible to user, but have cumulative effect and purpose of increasing stability and compatibility with applications and drivers.

Secondly, ReactOS consists of a comparatively small team when compared to other teams developing a similar project; both in terms of size and complexity. I am not sure what the benefit would be in focusing the limited resources of the team towards superfluous user features when the core of the OS needs a significant amount of time, energy and resources already.

Thirdly, you assume that releases can be done any faster than they already are with the things you would like to see done, this is not necessarily the case, sorry.

I agree with pushing the "Community Funded Ideas." A poll could be called to vote for the most wanted community feature(s), with donations being collected for the winning feature(s).

That would be a nice idea.

[Haos]

This approach might as well lead to increasing the delay between releases, even futher than the last one. Work on single feature might take even months, including start by researching and proper testing at the end.

[Smiley]

This approach might as well lead to increasing the delay between releases, even further than the last one. Work on single feature might take even months, including start by researching and proper testing at the end.

Exactly that's exactly our problem. See some examples of 'sub projects' below:
- Proper loading of graphics drivers aka yarotows (more than a year, still incomplete )
- Memory manager rewrite aka arm3 (more than a year, still incomplete)
- Proper implementation of basic user-mode networking components ( 4 years, still ongoing )
- Proper handling of internal structures in user32 ( 2 years, still ongoing)
- Rewrite the old FAT driver (almost 2 years, still ongoing) (anyone asked for ntfs? lol)
- New Explorer ( more than 3 years, still incomplete)
- New Kernel Common Cache aka arty-newcc (2 years, incomplete)

As you can see none of these examples can be completeded in a few weeks. They take YEARS. Of course most of these are partly done and we already see some advantages as a result of this work. However it still is MASSIVE work and can not be completed or annownced in the way you suggest

EDIT: in the above list you can of course add all Community funded Ideas. They take YEARS

[Aeneas]

All well, but then the question naturally arises:

What do you DO to get new developers?

Features attract people, not only in software engineering. When you see that something is "going to work", you actually want to be part of it. Think of arts: in fact, paintings are nothing but molecules and minerals on paper. But as people LIKE them, or even AGREE TO LIKE them (Picasso?), some of them become PRECIOUS. There is a social context behind them.

Ironically, that has been the very problem of Linux for the last ten years or so: Linux is interesting in many respects (and is for me my main OS), but they never could quite get a hold on Windows users who bluntly declare "my Office-CD does not want to install there". It thus lacks the social context. This, naturally, seems narrow-minded. But PEOPLE ARE narrow-minded! - Actually, I have had some interesting experience lately: I have installed and configured Linux to several friends, mostly non-geeky girls and guys in their early to mid 20s. I did EVERYTHING I could think of, including installing Word & Excel in Wine, if they had the CD. Result? People kept it! And enjoyed it!Why? - Because these ethnologists, psychologists, linguists etc. simply used it like that Macintosh advertisement says: "it just works". That, really, is in my view the only way to gain popular support.

[EmuandCo]

Sorry to sound harsh, but if a "developer" is not able to load a nightly or build ros himself, then we dont need him.

[greenie]

Look at all other projects in existence. They all have goals for a release dates. Examples like ubuntu,blender and so on. Reactos is also realistically not even usable at the moment.
It could be used as a tech demo but that is really it at the moment.

In the download section maybe have a direct link to nightly builds. With an explanation. I think that is the best solution.

The questions "What do you DO to get new developers?" is very important as users are not really important and will more than likely be confused and upset when something goes wrong.

Features will attract people sure. Only if it works. and it doesn't reliably run many windows apps let alone drivers at the moment.

Linux has MANY reasons it has been hard for normal users(which also made it popular for other groups). The list is huge. Driver issues,billions of distros,app compatibility issues,not many apps,lack of GUI apps, so on and so forth.Though big efforts are changing a lot of things. i could go on for ever about pro's and con's(Also i am a Linux supporter. so don't jump the gun)
Linux is a kernel. reactos is an entire OS with 100% binary compatibility target. Anyway i gotta get away from this.

Getting new devs is hard. Also the supporting systems of reactos are a bit of a mess. Finding a submitted patches in bugzilla is a nightmare with patches that months and years old. Unless there is something I've missed. Plus bugzilla is filled with so many bugs it seems unmanageable.

At the moment there are really only devs with svn commit access that can contribute.

[Haos]

What do you DO to get new developers?

We buy them at slavery market or organise war bands inland to catch them ourselves. What do YOU do to get us new developers?

Features attract people, not only in software engineering.

I dont dare to disagree with you here. You are, alas, forgetting a simple fact that before most of the features can shine and attract users and developers alike, someone has to do all the background, dull, highly specific and difficult work. Do you see a way to advertise our brand new paged pool, that is way more correct than the old one and not allowing any dumb operations, like allocating zero memory, or crashing properly when something is corrupting pool memory? What would be your reaction to it, when you learn that commiting it broke all the shiny features, drastically reduced the stability and indirectly caused random crashes? Yet it was something so basic and necessary it would be stupidity to revert it.

Look at all other projects in existence. They all have goals for a release dates. Examples like ubuntu,blender and so on. Reactos is also realistically not even usable at the moment. It could be used as a tech demo but that is really it at the moment.

Only Ubuntu and Blender is backed up by some serious money. You can expect delivering certain goals if your team is paid to reach them. Ever tried to do the same thing with people spending their free time to do the same thing?

Getting new devs is hard. Also the supporting systems of reactos are a bit of a mess. Finding a submitted patches in bugzilla is a nightmare with patches that months and years old. Unless there is something I've missed. Plus bugzilla is filled with so many bugs it seems unmanageable.

This is an area i claimed to fight for. The problem is that i`m on my own and its kind of massive task. My priority at the moment is to sort out all remaining patches, whose i`m currently pushing to devs for review. You can see some of the new order here:
http://www.reactos.org/wiki/Bug_Filters
http://www.reactos.org/wiki/Buglist

Anyone willing to help will be greatly appreciated.

[greenie]

Woops Haos.
I typed that wrong.
I meant blender has goals for releases. Not dates for releases. They don't actually make dates and stick to them. Which you do now anyway. You have a list of of things that needed to work for next release.(well for last one anyway i assume thats still on)

So I actually meant don't just churn out a new release because it's that time of the month.



As for the patch thing. I don't know if it's just me. There is no easy way to find submitted patches. Unless they have "PATCH" in the subject. which is a bit weird when you have a bug then someone puts a patch in there but not in the subject.

Blender I think had the same issue. They seem to have made two systems(both using the same bug tracker program)
Bugtracker system.
patchtracker system

I don't know but I may be completely wrong.


I'm not trying to be critical. I think it's unbelievably amazing what you guys have produced. especially with so few developers.

Now go get me NTFS support (just joking)


EDIT:
O I know your wiki page with patches and stuff exists(which u linked to) I just mean an automated way to make it easier.

[Aeneas]

@Haos:

The question how to attract people is actually something I DID think about. I thought boards like this one:

http://www.informatikerboard.de/

might be interesting. I mean, places where you can find a LOT of people's attention. But WHAT would you say there? That is why I did not actually say anything about ReactOS there - I would not dare to speak for ReactOS in public. In particular, I would not want to do something which the project leaders would disapprove of. (However, please take it as an idea to discuss with whomever would be in charge.)

As a start, however - and this indeed deserves some POSITIVE criticism as well - I find that event in Spain very good (and, once again, bravo for getting in there). It at least shows that ReactOS, while slow to develop, is not quite sharing the fate of e.g. FreeVMS (apparently dead).

And I also DO mention ReactOS to my friends. I do it certainly with all caveats, yet at least they know it EXISTS. I believe the word of mouth to be not unimportant, too.

My personal opinion of when you should consider yourself ready is: when you have USB support for data carriers (sticks or disks). - People need to be able to save their stuff.

[DukeNukemCZ]

i think that more devs will come after some Beta version will be released (something what works somehow for basic using (Internet, video, music, documents...)) and main break point after some DX8-9 games will run (run old DX8 WoW, Counter-Strike, Quake III... and you will have half win )... but even for basic using its feel like long shot... (2 years?)

and question is how far will be Windows 8... and how obsolete and old will ros be.

Again i see only 2 main points how attract new devs 1.BETA - Basic Using; 2. DX8-9 functions for runing most demanded older games

Next issue is that i dont see much about ReactOS on IT webzines, just few of them ever wrote about ROS and they will not inform about ros if there will be only 1 release per year... (4 month = 1 release sounds like good idea)

//ah i remember how in 2007 i was in delusion that in 2010 ros will be in BETA stage