Frank Heckenbach wrote:
Gerrit P. Haase wrote:
Have you tried it? Source managed by CVS is 'standard' and most OS developers are used to use it.
(I've heard of some rather popular OS having switched to a different system. Just a side-note ...)
And yes, I think I mentioned it before, we've tried it once. It didn't attract new contributors (nobody asked us for write access, or sent patches based on a CVS snapshot), and it was just more work for Peter and me.
<snip>
Well, for me it still is a problem. I always have to look things up if I need to get something from CVS, and I still haven't really understood all those strange options. I seem to know that there are different access methods, and they all need their own special options, and there are more parameters than would actually be necessary for an anonymous checkout.
OTOH, I know very well (as probably most people do) how to get a file by HTTP.
<snip>
Getting patches to a slightly older (alpha/beta) version is *really not* a big deal. I can handle some changed contexts, renamed identifiers etc.
Not a big deal for you. But a big deal for me. I need to ask *you* because I cannot ask CVS.
So why would you want to get an instable version from me? When things are stable enough, I make a release anyway.
Frank, I think you are blurring here difference between releases and snapshots. Basically you are telling us: I want show you my code, unless it is ready for release. For me it is a significant problem: I can easily do things as small separate patches, but keeping track of them without a single "master" version is a big pain. Alternatively, I can create my own development line, and submit you a big chunk when ready. You claim that such big chunks are OK, but it seems that they cause you problems.
I am for quality releases, but key to quality is testing. I working on a program rather quickly get to point of diminishing returns: new bugs show from time to time, but it takes long time to find one. The program still has bugs, but it takes new usage pattern to discover them. You may be better at that, but I think that in general in-house testing can give quality compiler only with _huge_ efforts.
So I think we need multi-layer process. For example: development snaphots -- where complete and cleaned features or fixes go, snaphots should build and pass the test suite at least on a single machine beta releases -- when things are stable enough: we have small number of outstanding bugs. Betas should build and do not give unexpected test failures on large variety of systems.
The point here is that snapshots should be ready for semi-automatic testing: knoledgable people can set up build and test scripts to do things with little effort. At the moment GPC benefits from Debian testing, but with regular snapshots we could get more info from Debian and possibly some people would set up similar things for other systems.
I agree with Chief that CVS is a red herring here. What really is needed is open process with fast development cycle (in particular big features should be split into small pieces). And, I see nothing done on GPC in last two years that could not be split into pieces taking at most few days to implement.