GCC integration?

Frank Heckenbach ih8mj at fjf.gnu.de
Wed Dec 22 02:07:41 CET 2004


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

-- 
Frank Heckenbach, frank at g-n-u.de, http://fjf.gnu.de/, 7977168E
GPC To-Do list, latest features, fixed bugs:
http://www.gnu-pascal.de/todo.html
GPC download signing key: ACB3 79B2 7EB2 B7A7 EFDE  D101 CD02 4C9D 0FE0 E5E8




More information about the Gpc mailing list