Hi, Well..I have been here just for a year and a half, and it is pretty obvious that we are not following any "direction" to achieve something in common.We are making progress in our own,sometimes without telling to the others and sometimes introducing regressions 1week before a release thanks to a critical rewrite. Or We are disappearing without telling to anyone. We==Testers&&Developers&&Translators&&Designers&&TheCommunity. I will use this email to state,mainly, that i want to be part of a team with an objective, so i offer all my testing help (including those parts i hate to test) to achieve a common goal.I offer my Testing time as Real Testing time and not as a Hobbie. Maybe we should try to discuss how to reach that goal,and decide(all of us) which is the best way to have something working. I dont know if the correct approach is called Arwinss,Yarotows,WTF!(Want To Finish!) or whatever.The real approach is the final User. And the final User "demands" a workable OS asap.We are making this as a hobbie, but also trying to give a product to the mass(I hope). We are not acting as a Community,neither me. The time to find a way has arrived imo.It´s quite discouraging finding this mess. Discouraging for testers and Discouraging for Devs. In the latest half year we have lost some Testers because lack of motivation.And it is called "Road to Nowhere". Devs arrives to ReactOS Project and they seem to leave quite easy,why?. I hope this time we can all sit and try to find a real solution,deciding which is the Goal (a Hobbie,an OS?),which is the way(comfortable?difficult?no way?hiring internal devs?hiring external devs?knocking sponsors doors?),and which things are needed to complete it(money?motivation?a Bugzilla Testing Week?a RSOC(ReactOS Summer Of Code)?). Summing up, finding a WHOLE solution to this project called ReactOS.
I think it is not just matter of a Roadmap. No having a Roadmap(or Milestones) is just the result, not the root of the problems.
Thanks for the 3 minutes.
_________________________________________________________________ Recibe un SMS de tu Hotmail vayas donde vayas. ¡Date de alta! http://home.mobile.live.com/MobileAttach.mvc/?mkt=es-es
I already said all that half a year ago. Let's move on to actually making a usable OS. Otherwise it's gonna be another chapter in the history of ReactOS called "Endless Debates" about what way is better :-)
WBR, Aleksey.
On Apr 8, 2010, at 10:27 PM, victor martinez wrote:
Hi, Well..I have been here just for a year and a half, and it is pretty obvious that we are not following any "direction" to achieve something in common.We are making progress in our own,sometimes without telling to the others and sometimes introducing regressions 1week before a release thanks to a critical rewrite. Or We are disappearing without telling to anyone. We==Testers&&Developers&&Translators&&Designers&&TheCommunity. I will use this email to state,mainly, that i want to be part of a team with an objective, so i offer all my testing help (including those parts i hate to test) to achieve a common goal.I offer my Testing time as Real Testing time and not as a Hobbie. Maybe we should try to discuss how to reach that goal,and decide (all of us) which is the best way to have something working. I dont know if the correct approach is called Arwinss,Yarotows,WTF!(Want To Finish!) or whatever.The real approach is the final User. And the final User "demands" a workable OS asap.We are making this as a hobbie, but also trying to give a product to the mass(I hope). We are not acting as a Community,neither me. The time to find a way has arrived imo.It´s quite discouraging finding this mess. Discouraging for testers and Discouraging for Devs. In the latest half year we have lost some Testers because lack of motivation.And it is called "Road to Nowhere". Devs arrives to ReactOS Project and they seem to leave quite easy,why?. I hope this time we can all sit and try to find a real solution,deciding which is the Goal (a Hobbie,an OS?),which is the way(comfortable?difficult?no way?hiring internal devs?hiring external devs?knocking sponsors doors?),and which things are needed to complete it(money?motivation?a Bugzilla Testing Week?a RSOC (ReactOS Summer Of Code)?). Summing up, finding a WHOLE solution to this project called ReactOS.
I think it is not just matter of a Roadmap. No having a Roadmap(or Milestones) is just the result, not the root of the problems.
Thanks for the 3 minutes.
¡Lucha por tus ídolos o hunde al personajes que quieras! ¡Vota a favor o en contra de los más famosos! ¡Nuevo MSN Populus! _______________________________________________ Ros-dev mailing list Ros-dev@reactos.org http://www.reactos.org/mailman/listinfo/ros-dev
On Thu, Apr 8, 2010 at 3:26 PM, Aleksey Bragin aleksey@reactos.org wrote:
I already said all that half a year ago. Let's move on to actually making a usable OS.
The debate seems to be what constitutes 'usable'. If Xming could run and be stable for hours+ on end then it could be a usable thin client. I think this would be a good first target.
Hi Aleksey!
On Thu, Apr 8, 2010 at 3:26 PM, Aleksey Bragin aleksey@reactos.org wrote:
I already said all that half a year ago. Let's move on to actually making a usable OS.
What have we learn?
What I have seen so far, is the same issues with porting wine over to ReactOS being addresses again with arwinss. Still using the rest of ReactOS other than the "Big Three" is still using ReactOS. There are minor drawing enhancements, but understanding the drawing interface we already have is still X based so this is not a big "Look See! ReactOS Sux" thing. Working with this type of glue logic is not surprising to me at all,,, I predicted it, didn't I?
What we really need to do with Win32k!
Other than the current developers starting to suffer under the HBS (Hartmut Birr Syndrome), this project needs to go back to 2006 and re-look, rethink, repent or just change your mind about where ReactOS is going. Go back and do what Alex asked us to do from the start and not allow anyone else to interfere with the process. I personally allowed Magnus to derail the objectives I had laded out to reach the goal we had set out , and I am responsible for that with the thought it was going to work. Now looking back at my mistake I know how to fix these issues with ReactOS. Getting it close to but not the same with glue logic emulations, is good enough for me and still today this is how I develop and write the interface. With little knows (structures and public symbols) it can and has been done and what has been written is prof of principle.
Today on the phone, I had a colleague ask me "why ReactOS was in so much disarray"? "Did any microsoft guys get access to the project and started to break things"? "You know this is what they do". This was his evaluation from testing the current trunk I had built for him last night.
We have a choice and when you make it, stay on that side, James
hi, i have a little idea, probably stupid :P
i see that we are syncying with Wine in every release... shouldnt´t we take one of those releases (1.1.42 currently), fix all winetests for that, and then move to the next release available when we finish the work?
i mean, lets think we start with current release 1.1.42. Okay, then fix all winetests for it. Probable when you devs finish doing so , wine has released 1.1.89. Well, lets sync with it, see what winetests crashes, and fix them again... and so, and so, and so....
On Fri, Apr 9, 2010 at 4:20 AM, James Tabor jimtabor.rosdev@gmail.comwrote:
Hi Aleksey!
On Thu, Apr 8, 2010 at 3:26 PM, Aleksey Bragin aleksey@reactos.org wrote:
I already said all that half a year ago. Let's move on to actually making
a
usable OS.
What have we learn?
What I have seen so far, is the same issues with porting wine over to ReactOS being addresses again with arwinss. Still using the rest of ReactOS other than the "Big Three" is still using ReactOS. There are minor drawing enhancements, but understanding the drawing interface we already have is still X based so this is not a big "Look See! ReactOS Sux" thing. Working with this type of glue logic is not surprising to me at all,,, I predicted it, didn't I?
What we really need to do with Win32k!
Other than the current developers starting to suffer under the HBS (Hartmut Birr Syndrome), this project needs to go back to 2006 and re-look, rethink, repent or just change your mind about where ReactOS is going. Go back and do what Alex asked us to do from the start and not allow anyone else to interfere with the process. I personally allowed Magnus to derail the objectives I had laded out to reach the goal we had set out , and I am responsible for that with the thought it was going to work. Now looking back at my mistake I know how to fix these issues with ReactOS. Getting it close to but not the same with glue logic emulations, is good enough for me and still today this is how I develop and write the interface. With little knows (structures and public symbols) it can and has been done and what has been written is prof of principle.
Today on the phone, I had a colleague ask me "why ReactOS was in so much disarray"? "Did any microsoft guys get access to the project and started to break things"? "You know this is what they do". This was his evaluation from testing the current trunk I had built for him last night.
We have a choice and when you make it, stay on that side, James
Ros-dev mailing list Ros-dev@reactos.org http://www.reactos.org/mailman/listinfo/ros-dev
Hi!
2010/4/9 Javier Agustìn Fernàndez Arroyo elhoir@gmail.com:
hi, i have a little idea, probably stupid :P
i see that we are syncying with Wine in every release... shouldnt´t we take one of those releases (1.1.42 currently), fix all winetests for that, and then move to the next release available when we finish the work?
i mean, lets think we start with current release 1.1.42. Okay, then fix all winetests for it. Probable when you devs finish doing so , wine has released 1.1.89. Well, lets sync with it, see what winetests crashes, and fix them again... and so, and so, and so....
This is not a stupid idea! 8^) This is exactly the thing I'm doing and keeping track of the tests I disable so the build test bot does not hang. Thanks, James
That's probably a good Idea, but I still like to point out, you cannot tell anyone what to do.
You can put up a list of what's important/required and I'm likely to pick something from it from time to time. You can ask me to do something and I might be like *sigh*, well ok... (halfassed attempt to help out) Or you can tell me to do something, and I might be like... sorry, got no time. Very busy, RL issues, you know... ;p
That's the way we all work, isn't it? We do it for the fun. If it's no fun we don't do it or not do it very enthusiastically, which means halfassed and ineffective. Of cause success is fun. But we all decide for ourselves what is success and how we can achieve success.
If I don't like to fix some winetests, but like to fix amd64 branch instead, or implement mode switching, do you want to keep me from doing that? Probably not.
So a roadmap might point out what is important to be done and what is not. But it cannot make people work on a specific part at a specific time.
Timo
No, you can't tell people what to do. However, we should be able to get together as a team and discuss what's really important for the project, lay down some common goals and deliver them.
It's nice to have an acpi battery module, or digital video broadcasting support, or a new isapnp driver, but what are we actually gaining from this as a project? What we really need is a stable win32k, we need a shell that doesn't belong in the dark ages, we need USB, we need to be able to run apps without bringing the whole OS down to its knees.
As a group of intelligent people, we should be able to discuss what's really important, prioritize the work and commit to doing it. We all surely have the same goal, to see reactos become usable and valuable to the public, so why can't we work towards this as a team??
It's all well and good being a project that allows people to work on whatever they want, but when that work ethic is essentially killing the project, you have to wonder if it's the best way of doing things.
What's taken the fun out of reactos is that people work on what they want, and that's usually unimportant things. I want to see an operating system mature and become usable but our current eithic of "work on whatever the hell you want to" is killing the project.
Open source sucks for this exact reason, there's no real management, no structure and no goals. Hence 99% of open source project fail. The only open source projects which do succeed have management, structure and goals and not this "Anyone can work on whatever the hell they want to".
Ged.
-----Original Message----- From: ros-dev-bounces@reactos.org [mailto:ros-dev-bounces@reactos.org] On Behalf Of Timo Kreuzer Sent: 09 April 2010 10:50 To: ReactOS Development List Subject: Re: [ros-dev] Roadmap I'm sticking to
That's probably a good Idea, but I still like to point out, you cannot tell anyone what to do.
You can put up a list of what's important/required and I'm likely to pick something from it from time to time. You can ask me to do something and I might be like *sigh*, well ok... (halfassed attempt to help out) Or you can tell me to do something, and I might be like... sorry, got no time. Very busy, RL issues, you know... ;p
That's the way we all work, isn't it? We do it for the fun. If it's no fun we don't do it or not do it very enthusiastically, which means halfassed and ineffective. Of cause success is fun. But we all decide for ourselves what is success and how we can achieve success.
If I don't like to fix some winetests, but like to fix amd64 branch instead, or implement mode switching, do you want to keep me from doing that? Probably not.
So a roadmap might point out what is important to be done and what is not. But it cannot make people work on a specific part at a specific time.
Timo
_______________________________________________ Ros-dev mailing list Ros-dev@reactos.org http://www.reactos.org/mailman/listinfo/ros-dev
I'm just a lurker but I wanted to respond to Ged - I hope that's ok!
The "work on what you want" ethic works well for lots of open source projects, and I can see it starting to work well for ReactOS too. The way I see it (i.e. from an outsider's point of view), ReactOS's management structure is slowly changing into a something more successful like Linux's. I'll explain what I mean below.
Linux is successful as an open-source operating system project because Linus Torvalds works on whatever the hell he wants to, which is "his" version of the kernel. He accepts patches he likes, and refuses ones he doesn't. He doesn't care what other people work on, but if they send him nice patches he'll incorporate them. People use Linus's kernel because it's good and high quality.
The analogous situation here is arwinss, which for us is (roughly) equivalent to the Linux kernel. Aleksey works on it just because he wants to - it's his "do whatever the hell you want" project. Gabriel Ilardi then acts as a rough equivalent of a distro like Ubuntu - he takes Aleksey's arwinss, packages it up with various other ReactOS bits and pieces and makes nice ISOs of it for people to download.
This kind of work ethic is what has made Linux into a successful project, and I see no reason why it won't make ReactOS successful too. Aleksey's roadmap is where he says "hey, this is what I'm going to do, help me if you find it fun to help". And that is GOOD, that's how Linus Torvalds works.
Likewise with Gabriel's ISOs - they work better than the normal ReactOS ISOs, and that again is good. People have fun making better "distros" of ReactOS, and that is great for all of us as it pushes the project forwards.
As a relative outsider to the project, I feel very positive to see developments like this! I think it shows that ReactOS will be a success. We should celebrate the "do what you want" ethic, not try to destroy it!
Pete.
On 9 April 2010 11:38, Ged Murphy gedmurphy@gmail.com wrote:
No, you can't tell people what to do. However, we should be able to get together as a team and discuss what's really important for the project, lay down some common goals and deliver them.
It's nice to have an acpi battery module, or digital video broadcasting support, or a new isapnp driver, but what are we actually gaining from this as a project? What we really need is a stable win32k, we need a shell that doesn't belong in the dark ages, we need USB, we need to be able to run apps without bringing the whole OS down to its knees.
As a group of intelligent people, we should be able to discuss what's really important, prioritize the work and commit to doing it. We all surely have the same goal, to see reactos become usable and valuable to the public, so why can't we work towards this as a team??
It's all well and good being a project that allows people to work on whatever they want, but when that work ethic is essentially killing the project, you have to wonder if it's the best way of doing things.
What's taken the fun out of reactos is that people work on what they want, and that's usually unimportant things. I want to see an operating system mature and become usable but our current eithic of "work on whatever the hell you want to" is killing the project.
Open source sucks for this exact reason, there's no real management, no structure and no goals. Hence 99% of open source project fail. The only open source projects which do succeed have management, structure and goals and not this "Anyone can work on whatever the hell they want to".
Ged.
-----Original Message----- From: ros-dev-bounces@reactos.org [mailto:ros-dev-bounces@reactos.org] On Behalf Of Timo Kreuzer Sent: 09 April 2010 10:50 To: ReactOS Development List Subject: Re: [ros-dev] Roadmap I'm sticking to
That's probably a good Idea, but I still like to point out, you cannot tell anyone what to do.
You can put up a list of what's important/required and I'm likely to pick something from it from time to time. You can ask me to do something and I might be like *sigh*, well ok... (halfassed attempt to help out) Or you can tell me to do something, and I might be like... sorry, got no time. Very busy, RL issues, you know... ;p
That's the way we all work, isn't it? We do it for the fun. If it's no fun we don't do it or not do it very enthusiastically, which means halfassed and ineffective. Of cause success is fun. But we all decide for ourselves what is success and how we can achieve success.
If I don't like to fix some winetests, but like to fix amd64 branch instead, or implement mode switching, do you want to keep me from doing that? Probably not.
So a roadmap might point out what is important to be done and what is not. But it cannot make people work on a specific part at a specific time.
Timo
Ros-dev mailing list Ros-dev@reactos.org http://www.reactos.org/mailman/listinfo/ros-dev
Ros-dev mailing list Ros-dev@reactos.org http://www.reactos.org/mailman/listinfo/ros-dev
That isn't how linux works _at all_.
I'm not going into it in any depth as we'll be here all day, but you should go and read how their development model works. Basically, there's many branches, stable and experimental, and many teams to look after these branches. These people are experts in the areas which their branch targets, e.g. scheduler, memory manager, etc.
All patches, no matter which branch you send it to, goes through various stages. If it's irrelevant it gets dumped straight away. If it's deemed relevant then it's heavily vetted by various members of the team, usually argued about and modified, then added to that particular branch.
It's also worth considering that whatever makes it into each release of the official kernel is then taken by distros and modified again, sometimes parts are removed, sometimes replaced and sometimes improved.
The chances of you "working on whatever you want" and getting it into the mainline linux tree are virtually zero.
You really can't compare reactos to linux. Linux has a _vast_ number of developers and testers, we have about 10.
Ged.
-----Original Message----- From: ros-dev-bounces@reactos.org [mailto:ros-dev-bounces@reactos.org] On Behalf Of Peter Millerchip Sent: 09 April 2010 12:23 To: ReactOS Development List Subject: Re: [ros-dev] Roadmap I'm sticking to
I'm just a lurker but I wanted to respond to Ged - I hope that's ok!
The "work on what you want" ethic works well for lots of open source projects, and I can see it starting to work well for ReactOS too. The way I see it (i.e. from an outsider's point of view), ReactOS's management structure is slowly changing into a something more successful like Linux's. I'll explain what I mean below.
Linux is successful as an open-source operating system project because Linus Torvalds works on whatever the hell he wants to, which is "his" version of the kernel. He accepts patches he likes, and refuses ones he doesn't. He doesn't care what other people work on, but if they send him nice patches he'll incorporate them. People use Linus's kernel because it's good and high quality.
The analogous situation here is arwinss, which for us is (roughly) equivalent to the Linux kernel. Aleksey works on it just because he wants to - it's his "do whatever the hell you want" project. Gabriel Ilardi then acts as a rough equivalent of a distro like Ubuntu - he takes Aleksey's arwinss, packages it up with various other ReactOS bits and pieces and makes nice ISOs of it for people to download.
This kind of work ethic is what has made Linux into a successful project, and I see no reason why it won't make ReactOS successful too. Aleksey's roadmap is where he says "hey, this is what I'm going to do, help me if you find it fun to help". And that is GOOD, that's how Linus Torvalds works.
Likewise with Gabriel's ISOs - they work better than the normal ReactOS ISOs, and that again is good. People have fun making better "distros" of ReactOS, and that is great for all of us as it pushes the project forwards.
As a relative outsider to the project, I feel very positive to see developments like this! I think it shows that ReactOS will be a success. We should celebrate the "do what you want" ethic, not try to destroy it!
Pete.
On 9 April 2010 11:38, Ged Murphy gedmurphy@gmail.com wrote:
No, you can't tell people what to do. However, we should be able to get together as a team and discuss what's really important for the project,
lay
down some common goals and deliver them.
It's nice to have an acpi battery module, or digital video broadcasting support, or a new isapnp driver, but what are we actually gaining from
this
as a project? What we really need is a stable win32k, we need a shell that doesn't belong in the dark ages, we need USB, we need to be able to run
apps
without bringing the whole OS down to its knees.
As a group of intelligent people, we should be able to discuss what's
really
important, prioritize the work and commit to doing it. We all surely have the same goal, to see reactos become usable and valuable to the public, so why can't we work towards this as a team??
It's all well and good being a project that allows people to work on whatever they want, but when that work ethic is essentially killing the project, you have to wonder if it's the best way of doing things.
What's taken the fun out of reactos is that people work on what they want, and that's usually unimportant things. I want to see an operating system mature and become usable but our current eithic of "work on whatever the hell you want to" is killing the project.
Open source sucks for this exact reason, there's no real management, no structure and no goals. Hence 99% of open source project fail. The only
open
source projects which do succeed have management, structure and goals and not this "Anyone can work on whatever the hell they want to".
Ged.
-----Original Message----- From: ros-dev-bounces@reactos.org [mailto:ros-dev-bounces@reactos.org] On Behalf Of Timo Kreuzer Sent: 09 April 2010 10:50 To: ReactOS Development List Subject: Re: [ros-dev] Roadmap I'm sticking to
That's probably a good Idea, but I still like to point out, you cannot tell anyone what to do.
You can put up a list of what's important/required and I'm likely to pick something from it from time to time. You can ask me to do something and I might be like *sigh*, well ok... (halfassed attempt to help out) Or you can tell me to do something, and I might be like... sorry, got no time. Very busy, RL issues, you know... ;p
That's the way we all work, isn't it? We do it for the fun. If it's no fun we don't do it or not do it very enthusiastically, which means halfassed and ineffective. Of cause success is fun. But we all decide for ourselves what is success and how we can achieve success.
If I don't like to fix some winetests, but like to fix amd64 branch instead, or implement mode switching, do you want to keep me from doing that? Probably not.
So a roadmap might point out what is important to be done and what is not. But it cannot make people work on a specific part at a specific time.
Timo
Ros-dev mailing list Ros-dev@reactos.org http://www.reactos.org/mailman/listinfo/ros-dev
Ros-dev mailing list Ros-dev@reactos.org http://www.reactos.org/mailman/listinfo/ros-dev
_______________________________________________ Ros-dev mailing list Ros-dev@reactos.org http://www.reactos.org/mailman/listinfo/ros-dev
Ged - I actually agree with everything you're saying! However, I see it as a "do what you want" ethic - I'll explain inline below:
On 9 April 2010 12:45, Ged Murphy gedmurphy@gmail.com wrote:
Basically, there's many branches, stable and experimental, and many teams to look after these branches. These people are experts in the areas which their branch targets, e.g. scheduler, memory manager, etc.
Yes, these people are "doing what they want" in that they maintain a branch which is of interest to them. These branches started because someone would say "you know, I want to improve Linux's memory manager, that's my kind of fun", and they just did it in a branch. Nobody told them to, nobody held a big meeting and assigned this task to them - they just did it because they wanted to.
All patches, no matter which branch you send it to, goes through various stages. If it's irrelevant it gets dumped straight away. If it's deemed relevant then it's heavily vetted by various members of the team, usually argued about and modified, then added to that particular branch.
You're of course totally right here. People who are "doing what they want" in their own branch will not want to accept bad quality patches from people - and why should they? This branch is their "fun thing" and they don't want it ruined. Because the maintainer feels like that branch is "theirs", it makes for good code quality.
It's also worth considering that whatever makes it into each release of the official kernel is then taken by distros and modified again, sometimes parts are removed, sometimes replaced and sometimes improved.
Exactly! People do what they want. Distro maintainers may have a different focus than upstream (for example, Debian with their packaging and legal policies), and so they are quite free to make changes. This is good! Because distro maintainers are able to do what they want, they are more happy doing it and their work is higher quality. Competition with different distros gives them further incentive to do good work.
The chances of you "working on whatever you want" and getting it into the mainline linux tree are virtually zero.
This is true, but not really relevant to this discussion because that's only due to Linux's greater size. The point is that when Linux was the size of ReactOS, Linus Torvalds did not try to get a team to agree on what to do - he just went ahead and did it. We can learn from what Linus did when Linux was as small as we are.
You really can't compare reactos to linux. Linux has a _vast_ number of developers and testers, we have about 10.
Sure you can! ReactOS and Linux are directly comparable because they're both open source operating systems. Linux's management style seems to work well and so we can certainly talk about whether it would work for us and move the project forwards.
Pete.
Peter Millerchip wrote:
Basically, there's many branches, stable and experimental, and many
teams to
look after these branches. These people are experts in the areas which
their
branch targets, e.g. scheduler, memory manager, etc.
Yes, these people are "doing what they want" in that they maintain a branch which is of interest to them. These branches started because someone would say "you know, I want to improve Linux's memory manager, that's my kind of fun", and they just did it in a branch. Nobody told them to, nobody held a big meeting and assigned this task to them - they just did it because they wanted to.
This is different.
These people have a vested interest in a particular area. They look after it and perfect it. In reactos we don't have anyone looking after a particular area. Even if we did, it's higly likely that they would get bored within a few weeks, drop it (in an incomplete state) and move on to something else.
All patches, no matter which branch you send it to, goes through various stages. If it's irrelevant it gets dumped straight away. If it's deemed relevant then it's heavily vetted by various members of the team,
usually
argued about and modified, then added to that particular branch.
You're of course totally right here. People who are "doing what they want" in their own branch will not want to accept bad quality patches from people - and why should they? This branch is their "fun thing" and they don't want it ruined. Because the maintainer feels like that branch is "theirs", it makes for good code quality.
We don't really have anyone looking after a branch / area. They generally move on and 'do whatever they want', leaving that area incomplete, unstable and buggy.
It's also worth considering that whatever makes it into each release of
the
official kernel is then taken by distros and modified again, sometimes
parts
are removed, sometimes replaced and sometimes improved.
Exactly! People do what they want. Distro maintainers may have a different focus than upstream (for example, Debian with their packaging and legal policies), and so they are quite free to make changes. This is good! Because distro maintainers are able to do what they want, they are more happy doing it and their work is higher quality. Competition with different distros gives them further incentive to do good work.
This is higher up the chain. Considering we don't have anyone interested at this level I'll leave this one.
The chances of you "working on whatever you want" and getting it into
the
mainline linux tree are virtually zero.
This is true, but not really relevant to this discussion because that's only due to Linux's greater size. The point is that when Linux was the size of ReactOS, Linus Torvalds did not try to get a team to agree on what to do - he just went ahead and did it. We can learn from what Linus did when Linux was as small as we are.
Reactos isn't far off being the same size of the linux kernel. The 2.6 kernel started off with about 5 million sloc, reactos probably has about 4/5 million at the moment. We have about 8 devs, linux has n times this. How can we possibly have the same development model?
You really can't compare reactos to linux. Linux has a _vast_ number of developers and testers, we have about 10.
Sure you can! ReactOS and Linux are directly comparable because they're both open source operating systems. Linux's management style seems to work well and so we can certainly talk about whether it would work for us and move the project forwards.
On your premise, all open source projects are comparable and can be managed in the same way. It really makes no sense at all. It's like saying joe blogg's 20 man software house should be managed in the same way as Microsoft
I suggest you join the team and try to put your ideas into practice. You'll soon realise why it can't be done.
Ged.
Timo told me some of you asked about me. I should have droped a line here before. In february I signed a contract that will keep me very busy until the end of july. During this period I'll have very little time for reactos, but I intend to keep working in the kernel whenever possible. It would be nice if we could earn our living with this. Since I need the money, I have to work in a less interesting but well paid project.
Jose Catena
Its good to hear from you. Good luck on your project and we hope you'll visit us from time to time.
Cheers
2010/4/10 Jose Catena jc1@diwaves.com
Timo told me some of you asked about me. I should have droped a line here before. In february I signed a contract that will keep me very busy until the end of july. During this period I'll have very little time for reactos, but I intend to keep working in the kernel whenever possible. It would be nice if we could earn our living with this. Since I need the money, I have to work in a less interesting but well paid project.
Jose Catena
Ros-dev mailing list Ros-dev@reactos.org http://www.reactos.org/mailman/listinfo/ros-dev
You seem to forget that linux is just the kernel. They let the graphics side to X.org/Xfree, the shell to KDE/Gnome, the C library to GNU, etc... You can't really compare ReactOS and Linux!
Peter Millerchip wrote:
Ged - I actually agree with everything you're saying! However, I see it as a "do what you want" ethic - I'll explain inline below:
On 9 April 2010 12:45, Ged Murphygedmurphy@gmail.com wrote:
Basically, there's many branches, stable and experimental, and many teams to look after these branches. These people are experts in the areas which their branch targets, e.g. scheduler, memory manager, etc.
Yes, these people are "doing what they want" in that they maintain a branch which is of interest to them. These branches started because someone would say "you know, I want to improve Linux's memory manager, that's my kind of fun", and they just did it in a branch. Nobody told them to, nobody held a big meeting and assigned this task to them - they just did it because they wanted to.
All patches, no matter which branch you send it to, goes through various stages. If it's irrelevant it gets dumped straight away. If it's deemed relevant then it's heavily vetted by various members of the team, usually argued about and modified, then added to that particular branch.
You're of course totally right here. People who are "doing what they want" in their own branch will not want to accept bad quality patches from people - and why should they? This branch is their "fun thing" and they don't want it ruined. Because the maintainer feels like that branch is "theirs", it makes for good code quality.
It's also worth considering that whatever makes it into each release of the official kernel is then taken by distros and modified again, sometimes parts are removed, sometimes replaced and sometimes improved.
Exactly! People do what they want. Distro maintainers may have a different focus than upstream (for example, Debian with their packaging and legal policies), and so they are quite free to make changes. This is good! Because distro maintainers are able to do what they want, they are more happy doing it and their work is higher quality. Competition with different distros gives them further incentive to do good work.
The chances of you "working on whatever you want" and getting it into the mainline linux tree are virtually zero.
This is true, but not really relevant to this discussion because that's only due to Linux's greater size. The point is that when Linux was the size of ReactOS, Linus Torvalds did not try to get a team to agree on what to do - he just went ahead and did it. We can learn from what Linus did when Linux was as small as we are.
You really can't compare reactos to linux. Linux has a _vast_ number of developers and testers, we have about 10.
Sure you can! ReactOS and Linux are directly comparable because they're both open source operating systems. Linux's management style seems to work well and so we can certainly talk about whether it would work for us and move the project forwards.
Pete.
Ros-dev mailing list Ros-dev@reactos.org http://www.reactos.org/mailman/listinfo/ros-dev
On Apr 9, 2010, at 2:38 PM, Ged Murphy wrote:
What we really need is a stable win32k, we need a shell that doesn't belong in the dark ages, we need USB, we need to be able to run apps without bringing the whole OS down to its knees.
Exactly what I thought. I got slightly dismotivated from improving the kernel when it doesn't result in any visible user-wise improvement. Look: kernel was rewritten, quite a few things added, storage stack improved, all those great things done during these years. Even bootloader got rewritten to be great, cool and compatible. And? Yes, kernel is cool, architecturally beautiful, is more stable and a lot more compatible and faster. But average user can't see all this beauty! What that user sees (I will use Ged's comparison) is that Firefox works even worse than it worked when GvG first made it run!
That was the reason why I thought there is an urge need to fix things in Win32 area, and after thoroughly analyzing all possible options (including total rewrite, and studying existing user32/gdi32/win32k code) I decided to go with the Wine-based way (codenamed "arwinss"). If more people could join this effort, it would possible to achieve a usable state in a less amount of time.
WBR, Aleksey.
-
Aleksey Bragin -
Ged Murphy -
James Tabor -
Javier Agustìn Fernàndez Arroyo -
Jose Catena -
Jérôme Gardou -
Olaf Siejka -
Peter Millerchip -
Steven Edwards -
Timo Kreuzer -
victor martinez