roadmap and priorities

Here you can discuss ReactOS related topics.

Moderator: Moderator Team

Michael Long
Posts: 40
Joined: Wed Oct 25, 2017 7:51 pm

roadmap and priorities

Post by Michael Long » Thu Dec 14, 2017 7:47 pm

Hello,
there was an issue created in JIRA addressing the handling of priorities of issues.

https://jira.reactos.org/browse/CORE-14105

There were reclamations that the focus of development is somewhat misplaced. For example a lot of development resources where flowing into the fancy additional lautus theme while other people complain that because of hardware bugs the whole system does not boot at all. Priorities for issues are being set but developers often ignore them when they choose which issue to tackle next.

A discussion about this priority-issue was not wanted in JIRA but welcome in the forum. So I thought of starting this topic.

There are several ways to respond to this request. For example
  • the project manager could set up a roadmap which issues should be addressed for the next release. In this approach the project manager confers the right to use development resources (time).
  • the project manager could make suggestions for the next release. The community votes.
  • the community makes suggestions and then votes.
  • the community makes the suggestions, the developers vote.
  • the developers decide themselves. (I think that's the current state).
  • the developers make suggestions, the project manager has the final word.
So what's the problem with the current state (everyone decides himself)? Well, for example: If we spend a lot of time into issues with low priorities (like the fancy lautus theme or localization usually has) then we also introduce new bugs. The lautus theme generated a lot of bugs. Those bugs and the initial effords bind a lot of development resources. They also cause a lot of commits. Those few sentences in the commit comment are being read hundreds of times and thereby require development time by just reading what happend. The work on the issue also requires time. We might get an operating system with some features you could expect in a fully matured operating system but the whole system never gets out of it's early development stage because fundamental features don't exist and too much is broken/buggy.

We had a topic about the bug growing problem recently and didn't find a reasonable solution.

http://reactos.org/forum/viewtopic.php?f=2&t=16742

So with this topic I wanted to make aware of the issue and ask for suggestions.
  • Should more attention being paid to priorities?
  • Should the development direction be dictated (by the community/the project manager/or someone or somehow else)?
Image

Smiley
Developer
Posts: 156
Joined: Fri Nov 10, 2006 3:36 pm

Re: roadmap and priorities

Post by Smiley » Thu Dec 14, 2017 8:23 pm

Not looking like windows 95 is a reasonable goal.

reactosfanboy
Posts: 6
Joined: Sun Feb 01, 2015 1:54 pm

Re: roadmap and priorities

Post by reactosfanboy » Thu Dec 14, 2017 8:32 pm

As new release manager my position is the following:

In general developers should always decide what to do next because they know much better than any manager or the wisdom of the masses what makes most sense to do next. They have a good feeling for the next lowest hanging fruit - which means what adds the most value for given amount of work!

That being said, my personal wish would be to increase focus on fixing regressions as fast as possible. That's the best way to guarantee customer satisfaction, because the trust in our product will increase at the users side when they see things continuously improving without breaking too much stuff in release n that did work better in release n-1. That's what causes most frustration at the customers side. More than having to wait a bit longer before a specific feature can be shipped. These considerations will become more and more important over time when reactOS matures and first real use cases will evolve.

Currently some of you guys seem to have too high expectations: Don't forget we are still alpha and the devs offer good quality for this stage of development already.

Regarding themes: I agree, those are not very important (at least to me) to be done at the moment. But as you already noted they have a big regression potential. That's why it was most likely better to implement that now, instead of breaking tons of stuff at a later point in time, when everything is already polished at the user-interface for non-themed.

What are most urgent features from my pov? Stable Memory management, especially surviving big-file-copy, NTFS, USB!
That's because I think first niche of real-world-usage of ros will be rescue-systems from USB-stick/CD-ROM.
But all of those features require a lot of skill and are very low-level, which means their realization depends on availability and engagement of just a few talented guys here! Don't forget that!

Regarding localization:
I don't think the continuous in-flow of commits for localization slows down the project much, because those can and are mostly delivered by external volunteers, so they don't put much pressure on the core-devs.


To sum it up: Fix regressions and otherwise continue like you currently do devs! You are doing a great job!

ThFabba
Developer
Posts: 263
Joined: Sun Jul 11, 2010 11:39 am

Re: roadmap and priorities

Post by ThFabba » Fri Dec 15, 2017 12:10 am

Michael Long wrote: There are several ways to respond to this request. For example
  • the project manager could set up a roadmap which issues should be addressed for the next release. In this approach the project manager confers the right to use development resources (time).
  • the project manager could make suggestions for the next release. The community votes.
  • the community makes suggestions and then votes.
  • the community makes the suggestions, the developers vote.
  • the developers decide themselves. (I think that's the current state).
  • the developers make suggestions, the project manager has the final word.
Michael Long wrote:
  • Should more attention being paid to priorities?
  • Should the development direction be dictated (by the community/the project manager/or someone or somehow else)?
Here's the problem with any and all of the other approaches:
So you go and make a decision on the top priorities. Great! And you decide what to put in the next release. Great!
Now who does it, and when? Do you assign someone?
If not, how do you know it'll get done?
If yes, what if they don't have time? What if they don't want to? What if they initially agree but then don't have time or it ends up much more complicated than expected and they get annoyed by it and want to do something else instead?
If you choose a path in the middle and ask for volunteers, what if nobody volunteers? What if some people always volunteer and others never, and then those who always volunteer get annoyed and stop volunteering; or stop working on the project altogether?
And what do you do about patches from new contributors (which, by the way, take time and effort to review and commit... yet another thing that you need to find/assign/magic someone to take care of)? "Sorry, we're working on USB this month, your valid patch that fixes 20 applications won't be accepted... good luck next release"?

... and in case you think those are all theoretical excuses and if we just tried it, it might work... let's look at some practical examples:
  • There was an Indiegogo campaign in 2014 that allowed people to vote for the top applications they'd like to see working. We all as a project agreed to work on the top three as a priority. 3.5 years later we have one of those three applications working (Unless It Regressed™), one somewhat working after you install an optional download package, and one somewhat working if you supply certain command line arguments... maybe... Unless They Regressed™.
  • If you surveyed the devs over the last couple years about what most needs fixing in ROS, there's a good chance one of the top answers (if not _the_ top answer) you got was the memory manager. And what's happened in that time in that area? Well, a couple minor fixes, and an initial attempt by one dev to implement paging support. And that's a dev who finds time for ROS once every few months. Why so little progress? Because it's an extremely painful area to work on. It requires an understanding of the CPU/MMU's workings and data structures, along with specific Windows-internal data structures. It's hard to test, but has to match the externally visible semantics and internal behaviors of Windows, and of course is a major factor in OS stability and poses huge regression risks. So you must be in the mood for quite a challenge in order to want to be working on it at all.
  • A recent Wine sync caused 3 tests to become "canceled" in testman (e.g. https://jira.reactos.org/browse/CORE-13830). Many people are aware that this greatly impacts tests: it makes them take longer (for each revision committed!), causes unrelated tests to become flaky, and of course hides regressions in those tests (because all you see is "canceled", no numbers). I personally consider this a blocker bug that has higher priority than anything else. And to take myself as an example, it took me a month to make a frustrated hackfix (https://github.com/reactos/reactos/pull/95), another to push some better (but also partially hacky) fixes, and I just fixed the last regression from those fixes today (https://jira.reactos.org/browse/CORE-14103). We're talking three months to fix a set of small, highest priority bugs.
  • Jira has 135 outstanding patches listed: https://jira.reactos.org/issues/?filter=10101 -- this is after we've had numerous discussions over the last 2 years about how bad this is, decided to make it a priority to review patches, and several people have been doing regular bursts of reviews, interrupting whatever else they were working on. GitHub is making review easier, but already we have 36 open pull requests, and rising... https://github.com/reactos/reactos/pulls
  • We have a dedicated developer who's been working on a new USB stack for the last couple months. We have three core devs that are familiar with USB & the existing driver stack, two of whom have not had much (if any) time for ROS over the last couple years. That leaves one (yours truly) to do the necessary code review and help find a sensible approach to integrating the new components. Of course I'm also supposed to fix locking in the PNP manager (so that VMware and a bunch of real hardware doesn't randomly crash on boot), the memory manager (for general system stability, application support, file system support) and, as reactosfanboy rightly mentions, fix regressions as soon as possible. So it's no wonder those code reviews may get no attention for weeks or months.
Having better management in ROS could certainly improve things. But that doesn't mean forcing a roadmap down people's throats (and yes, that includes a democratic vote). And a roadmap that gets completely turned around every other month because the only developer you have who knows a certain area is too busy with their day job and/or family to get any work done... is not very useful anyway.
We already have a few people (e.g. AmineKhaldi and reactosfanboy) who do management tasks in a way that (IMHO) is appropriate to this kind of project: talk to people about specific issues you think are important; file high-quality actionable tickets; draw attention to these issues and convince the right people at the right time that those things are beneficial to work on; and take into account the specific skills and interests of those people so as to get things done as efficiently as possible and without causing people to get annoyed or burned out.
... because you really WANT hobby devs (actually, also employed devs) to work on things they find interesting, and that they feel like working on. You don't exactly have any incentive to make them work on something else anyway. And if you did, they might just quit on you instead, because their hobby stopped being fun. So your choice becomes: they work on things you may find irrelevant, or they work on nothing at all. That's not a hard one.

EmuandCo
Developer
Posts: 4323
Joined: Sun Nov 28, 2004 7:52 pm
Location: Germany, Bavaria, Steinfeld
Contact:

Re: roadmap and priorities

Post by EmuandCo » Fri Dec 15, 2017 9:39 am

Thanks ThFabba for the great explaination. ^^
Image
ReactOS is still in alpha stage, meaning it is not feature-complete and is recommended only for evaluation and testing purposes.

Konata
Posts: 391
Joined: Sun Apr 20, 2014 8:54 pm

Re: roadmap and priorities

Post by Konata » Fri Dec 15, 2017 9:56 am

I think the only real issue is funding. Like what ThFabba said, it really all boils down to who can do what and wants to do what. ReactOS' life blood is volunteers, which, obviously, cannot be controlled. What ReactOS really needs is funding, whether that be donations or actual funds through corporate or government means. If ReactOS actually gets an income through some means, the foundation can actually hire people to work on the project full-time. But that requires a lot of money, something the foundation is scarce on. Unless the project can get actual employees, it's ultimately up to the whims of the few geniuses who can spare a moment of their time to help, which is appreciated, but extremely unreliable. Money makes the world go around.

Adcock
Posts: 231
Joined: Thu Jul 07, 2016 5:37 pm

Re: roadmap and priorities

Post by Adcock » Fri Dec 15, 2017 10:32 am

Hey guys. What about falcoware ?
Did they contact again ?
The falcoware member talked about 12 cpp developers.
I am talking about official cooperation which may not be visible in the forum.

petr-akhlamov
Posts: 55
Joined: Wed Apr 10, 2013 3:23 pm
Location: Russia, Moscow

Re: roadmap and priorities

Post by petr-akhlamov » Fri Dec 15, 2017 4:03 pm


Adcock
Posts: 231
Joined: Thu Jul 07, 2016 5:37 pm

Re: roadmap and priorities

Post by Adcock » Fri Dec 15, 2017 4:49 pm

?
Have you added ReactOS to the project ?

petr-akhlamov
Posts: 55
Joined: Wed Apr 10, 2013 3:23 pm
Location: Russia, Moscow

Re: roadmap and priorities

Post by petr-akhlamov » Fri Dec 15, 2017 5:44 pm

No, i only was proposed for developers. I think what they should solve similar issues.

Fraizeraust
Posts: 228
Joined: Thu Jan 05, 2017 11:46 am
Location: Italy
Contact:

Re: roadmap and priorities

Post by Fraizeraust » Fri Dec 15, 2017 5:45 pm

I double Konata's post. The ReactOS foundation relies mainly through donations to keep the project alive, both paying the developers and spending what's the necessary for the ROS server infrastructure. If ReactOS had all the money I can bet no complains like "why ReactOS development is sooo slow?" and the like would rise like now. It's not rocket science to understand this, really.

Therefore instead of complaining about ROS priorities we should rather help these unfortunate guys. Less words, more action.

Michael Long
Posts: 40
Joined: Wed Oct 25, 2017 7:51 pm

Re: roadmap and priorities

Post by Michael Long » Fri Dec 15, 2017 7:49 pm

reactosfanboy: After I read your comment I was considering if I should completely abandon the ReactOS project and waste no more time with it because it's probably not going to become anything useful anyway. Especially the "continue like you currently do devs! You are doing a great job!" made me sick. By the way, my wish list would be: Being able to boot. The ReactOS project has some serios problems (in the managment area?) which are not easy to fix. Like the bug growing issue which was discussed here in the forum lately and the priority issue. If no reasonable solutions are found then this project might very well never leave it's early development stage no matter how much time passes by and how much development time flows into the project.

ThFabba: I didn't want to offend anyone who contributs. I was aware of the problem that people want to have something back for their contributions. You said "fun", I say "something". There might be other things:
  • Some people can be attracted when they have fun, others are more serious and don't give much about fun.
  • Some people can be attracted with fame, others prefer the anonymity.
  • Some people can be attracted with money, others see their everyday job as their solely income and don't need some financial bonuses here and there.
  • Some people can be attracted by doing the right thing, others don't believe in the afterlife and don't give much about how someone else would judge their life.
Here are some suggestions which might not be well thought out:
fun:
  • easy tasks/don't need to think much
  • short tasks
  • xp collection or something like this, duolingo (a language learning website) works like this to motivate people to continue learning
  • collectable points which can be spent on something
fame:
  • rang list/highscore
  • thanks window when you first boot reactos "John Smith helped fixing several issues and adding these and those new features for this release. It took him approximatly 57 development hours since the last release. You might want to check his website to learn more about him."
  • contributors banner (your banner is displayed for a certain amount of times for contributions; needs to be moderated to prevent misuage/unmoralic banners)
money:
  • developers are payed with the donation money (I think that's what currently happens)
  • small money amounts for each contribution like 50 cents for this, 20 cents for that (needs to be activatable/deactivatable so people who don't want money don't empty the cash box)
doing the right thing:
  • ReactOS trys to save energy to protect the environment
Dictating the direction is no really what I want either. But something reasonable that helps would be nice.

Konata: Thanks. Your comment was a great step in this discussion for a productive outcome.

Fraizeraust
Posts: 228
Joined: Thu Jan 05, 2017 11:46 am
Location: Italy
Contact:

Re: roadmap and priorities

Post by Fraizeraust » Fri Dec 15, 2017 9:38 pm

@Michael Long: I do get your point and understand your frustration. Everyone wants ReactOS to speed up. Even I, would want to. When I see the development progress sometimes I ask myself "will I ever see a stable release of ReactOS on my lifetime?". Heck and I am 18.

Yes, the ReactOS management area has some problems as you implied but that for a very simplistic reason: the ReactOS Team is niche! And that torments the project since the long time.
Michael Long wrote:For example a lot of development resources where flowing into the fancy additional lautus theme while other people complain that because of hardware bugs the whole system does not boot at all. Priorities for issues are being set but developers often ignore them when they choose which issue to tackle next.
To quote this sentence from your original post, I do indeed agree hardware support is more of a critical priority if you want an OS that works on most PCs. However such task is a complete burden and pain in the arse (hopefully the word "arse" is accepted here :shock: ) because hardware are like puzzles. You must know every piece of them and how they interact together. Furthermore we don't have enough guru developers that must cover this job.

My reasonable (or maybe not so reasonable) solution? Helping ReactOS Foundation with every possible help in hand, like funding, bringing attention about the project that can attract developers, testers, etc. If this has been done in the past then this problem would have been solved.

Michael Long
Posts: 40
Joined: Wed Oct 25, 2017 7:51 pm

Re: roadmap and priorities

Post by Michael Long » Fri Dec 15, 2017 10:21 pm

I think you misunderstood one part of my comment. When I said "If no reasonable solutions are found then this project might very well never leave it's early development stage no matter how much time passes by and how much development time flows into the project." I didn't mean that the development is too slow for my opinion. The speed is ok. I ment that it will never leave it's early development stage because while some bugs are fixed other new bugs are introduced like the one ThFabba mentioned "I'm also supposed to fix locking in the PNP manager (so that VMware and a bunch of real hardware doesn't randomly crash on boot)" which prevents ReactOS from booting for me but that worked in the past. I got the impression that more and more is falling apart. I also experienced additional problems with the RS232 sending recently that didn't exist in the past. So debugging is even more difficult than it was.

So just continuing the same way very intensively and very long does not solve the problem. It will probably destroy the whole project by bringing it to a state where nearly nothing works anymore. And on real hardware we already are pretty close to this state. If you think that additional time is the solution then consider that this project exists for about 17 years and ReactOS had never so much bugs than it has today. If you think that intensifying is the solution then consider that people just spend a part of their free time and not their whole life time. Even with good will you probably won't get much more.

But I partially agree on your point, that skilled people are necessary and you can't get them easily. I said "partially" because I still have hope that a good solution in the management could solve the problem but I don't think that it's .necessary to add more and more people (which we probably don't get anyway).

Oh dear, I think this is difficult.

elhoir
Test Team
Posts: 397
Joined: Thu Sep 13, 2007 7:01 pm
Location: Madrid, Spain
Contact:

Re: roadmap and priorities

Post by elhoir » Fri Dec 15, 2017 11:13 pm

@michael,

i take from your words that you are not developer. Neither i am. But i trust in ReactOS, and i know sooner or later i will be installing it in real hardware (and it will be booting! ;) ). Just complaining doesn't help. I can't code, as you also seem to. But i can translate, spread the word, write people, facebook, e-mails.....

Yes, we need more people. More devs, specifically. Try to get them here, donate what you can (if you want to), translate..... In two words, help us!

Post Reply

Who is online

Users browsing this forum: Ahrefs [Bot] and 1 guest