Waldek Hebisch wrote:
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.
The problems weren't so much in the patch itself, or (probably) that it was against 20040516. I simply didn't have the time recently to look into it. My actual jobs kept me quite busy, and of course things like the broken-down server which caused me quite a bit of work to restore didn't help either. In the remaining time that I had for GPC, I could only focus on the changes I needed myself and some particular issues (such as `CInteger' and initializers -- both of which had many more ramifications and were more work in the end than I had expected).
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.
I see your point, though for me it's sometimes the other way around (see below).
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.
I agree, since I might not have the time I'd like to in the future either ...
So I'll try to handle beta versions mostly like now, and in addition try to make more often what you call development snaphots -- I think we can also call them alphas and put them in that directory, which is probably more in line with the usual meaning of alpha (previous GPC "alphas" often were much better tested than alphas elsewhere). (For users this will mean, of course, they can decide to stick with the betas only, or try the alphas, but then be prepared for more failures ...)
One thing I'd like to stress, though, is that we should try not to keep too many "alphaish" features around. That would be much like the situation a few years ago where GPC contained a number of hardly-tested/not-fully-implemented/full-of-known-bugs features which I've at least mostly tried to clean up by now.
Of course, there can always be difficult areas that must be postponed (we still have a few tricky problems with schemata, e.g., but these are becoming more and more exotic situations), but IMHO we shouldn't jump too quickly from one area to another until the first one is reasonably stable (though there can be several alphas on the way there), since for a non-alpha-tester user (including myself as a user of GPC) it's better to have one feature basically working than three features where it's pure luck whether they'll work in any given situation (again, that's the situation some years ago as I experienced it as a user of GPC, and I don't want to get back there).
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.
BTW, implementing is one thing, testing another one. It usually takes me longer to debug a problem from a mailing list bug report (somewhat longer to much much longer, depending on the quality of the report) than one I find myself. So I guess I'll then have to ignore bug reports on new features until I consider them stable enough myself in the first place, because I can't afford the extra debugging time it would cost me. If you like to do it, fine, otherwise users will just have to remember their bugs, test them again, and finally resend them (or, of course preferred, fix them themselves -- but I know that hacking GPC is a bit difficult for many users) ...
Frank