Re: The current hurd development system - or: optimizing for fun

[Alfred M\. Szmidt]

   Of course not change the VCS of a running project. But if we start
   from a mostly new codebase, using a better VCS would not be too
   much work.

That is quite a big `if', isn't it?

   And no, you IMHO cannot realize -Ofun with cvs.

IMHO you can, and it has been achived quite often.  I guess it is
something we will have to agree to disagree about.

   If nearly everyone can change code, it has to be possible to easily
   rollback the complete change of an unixperienced/malicious
   commiter.

CVS already allows for that.

   I guess you only comment on the first statement. Commit rights
   aren't casted far and wide. Doing so would mean giving everyone the
   right to commit who wants to.

It might have to do with nobody contributing much code to warrant them
being given commit access.

   >    o Work on code.
   > 
   > Would you like to work on some code? :-)

   You are quoting me out of context here. Working on Hurd/Mach is no
   alternative if we are speaking about Hurd/Coyotos.

One can work on both at the same time.  Hurd/whatever won't be ready
for who knows how long.  Hurd/Mach works already, and it works quite
well.  Mach has also gained a new interest to alot of hackers.

   >    o Highly integrate the community.
   > 
   > The more people who work, the more people will join...

   I think we have to do more than passively wait for people to join.

True, but not much more.  If there is lots of activity (I think people
would be happy if there was _any_ activity really), people will hear
about it, and join.

Cheers, and happy hacking!