Re: State of maturity for gcc 2.95.3 and gcc 2.96

[Marc Espie <espie at quatramaran dot ens dot fr>]

In article <Pine.BSF.4.21.0010150223190.56305-100000@deneb.dbai.tuwien.ac.at> you write:
>On Sat, 14 Oct 2000, Toon Moene wrote:
>> E.g., we define a release branch; hammer on it until it is "bug-free"
>> (hah :-) and subsequently have weekly snapshots from _that branch_
>> called GCC-3.0.n which are our "stable releases".
>
>I see some problems with this approach:
>
> 1. We will have a new release snapshot even if there has been no change.
>
> 2. Consistency: Right now we can assume that most people use one out of a
>    few version of the compiler, as do GNU/Linux distributions.
>
>    If we update once a week, would distribution upgrade every week as
>    well?

You may expect distribution vendors to have a clue.
As far as OpenBSD is concerned, we get *every* patch to gcc stress-tested
before committing (run thru a full make build on at least a reasonable subset
of architectures... since that code is almost entirely different from what
gets built by the linux crowd, this means pretty good coverage).

Also, we can pretty much live with not having an actual formal distribution.
Just have a stable branch on the CVS tree, and lurking around here is enough
to know that a pretty Bad Bug has been fixed...

The only point where we need help is expert help by people like Bernd and
Frank, who actually can figure out when a patch is reasonably Safe to 
backport to the stable branch.

If shit happens, too bad. We can still stress-test the real Stable Branch,
and bang on it almost as much as on an actual release...

beats having to run with a fast moving target like 2.96/2.97... which is
quite suitable for experiments, but not at all for running a serious
distribution, thank you... :-P