Re: [ros-dev] Roadmap I'm sticking to

[victor martinez]

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

[Aleksey Bragin]

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(a)reactos.org
>  http://www.reactos.org/mailman/listinfo/ros-dev

[Steven Edwards]

On Thu, Apr 8, 2010 at 3:26 PM, Aleksey Bragin <aleksey(a)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.

-- 
Steven Edwards

"There is one thing stronger than all the armies in the world, and
that is an idea whose time has come." - Victor Hugo

[James Tabor]

Hi Aleksey!

 On Thu, Apr 8, 2010 at 3:26 PM, Aleksey Bragin <aleksey(a)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

[Javier Agustìn Fernàndez Arroyo]

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(a)gmail.com>wrote;wrote:

>   Hi Aleksey!
>
>   On Thu, Apr 8, 2010 at 3:26 PM, Aleksey Bragin <aleksey(a)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(a)reactos.org
>  http://www.reactos.org/mailman/listinfo/ros-dev
>

[James Tabor]

Hi!

2010/4/9 Javier Agustìn Fernàndez Arroyo <elhoir(a)gmail.com>om>:
>   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

[Timo Kreuzer]

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

[Ged Murphy]

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(a)reactos.org [mailto:[e-mail]] 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(a)reactos.org
http://www.reactos.org/mailman/listinfo/ros-dev

[Peter Millerchip]

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(a)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(a)reactos.org [mailto:[e-mail]] 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(a)reactos.org
>  http://www.reactos.org/mailman/listinfo/ros-dev
>
>
>  _______________________________________________
>  Ros-dev mailing list
>  Ros-dev(a)reactos.org
>  http://www.reactos.org/mailman/listinfo/ros-dev
>

[Ged Murphy]

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(a)reactos.org [mailto:[e-mail]] 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(a)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(a)reactos.org [mailto:[e-mail]] 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(a)reactos.org
>  http://www.reactos.org/mailman/listinfo/ros-dev
>
>
>  _______________________________________________
>  Ros-dev mailing list
>  Ros-dev(a)reactos.org
>  http://www.reactos.org/mailman/listinfo/ros-dev
>  
_______________________________________________
Ros-dev mailing list
Ros-dev(a)reactos.org
http://www.reactos.org/mailman/listinfo/ros-dev

[Peter Millerchip]

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(a)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.

[Ged Murphy]

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.

[Jose Catena]

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

[Olaf Siejka]

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(a)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(a)reactos.org
>  http://www.reactos.org/mailman/listinfo/ros-dev
>

[Jérôme Gardou]

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 Murphy<gedmurphy(a)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(a)reactos.org
>  http://www.reactos.org/mailman/listinfo/ros-dev
>
>
>

[Aleksey Bragin]

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.