[ros-dev] Roadmap I'm sticking to

Ged Murphy gedmurphy at gmail.com
Fri Apr 9 15:51:06 CEST 2010


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.




More information about the Ros-dev mailing list