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.