Alfred M. Szmidt wrote:
o Use a better revision control system.
Cvs is outdated in several aspects. Most notably truly atomic
commits and file moving are missed, thus not allowing -Ofun to
be relized. Easy merging and branching are also required.
This implies that -Ofun was never possible for any project using CVS.
Thing is that CVS is actually quite good, despite its small quirks,
none of which are so immensly important that it is crucial to change
VCS (not to mention the huge job of converting history!).
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.
And no, you IMHO cannot realize -Ofun with cvs. If nearly everyone can
change code, it has to be possible to easily rollback the complete
change of an unixperienced/malicious commiter.
o Make commits easy and straight forward.
Revising all code by a handful of core developers is a serious
bottleneck and source of frustation.
The reason why it is frustrating is because the set of develoeprs who
can actually do anything is zero. Not because one has to vet things
through them, which is quite a quick job in almost all cases.
For the beginning it might be OK to give all frequent users of
the list that ask for direct access to the repo (possibly in
different branches), but commit rights must be casted far and
wide.
That is how it already works.
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.
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.
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.
Cheers!
--
-ness-
_______________________________________________
L4-hurd mailing list
[email protected]
http://lists.gnu.org/mailman/listinfo/l4-hurd
