GCC integration?

Waldek Hebisch hebisch at math.uni.wroc.pl
Sun Dec 19 20:36:01 CET 2004


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.

-- 
                              Waldek Hebisch
hebisch at math.uni.wroc.pl 




More information about the Gpc mailing list