From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 5586 invoked by alias); 18 May 2003 14:19:08 -0000 Mailing-List: contact gcc-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Archive: List-Post: List-Help: Sender: gcc-owner@gcc.gnu.org Received: (qmail 5528 invoked from network); 18 May 2003 14:19:07 -0000 Received: from unknown (HELO nef.ens.fr) (129.199.96.32) by sources.redhat.com with SMTP; 18 May 2003 14:19:07 -0000 Received: from quatramaran.ens.fr (quatramaran.ens.fr [129.199.129.64]) by nef.ens.fr (8.12.9/1.01.28121999) with ESMTP id h4IEJ68W075446 for ; Sun, 18 May 2003 16:19:06 +0200 (CEST) Received: (from espie@localhost) by quatramaran.ens.fr (8.11.6/8.11.6) id h4IEHbp21625; Sun, 18 May 2003 16:17:37 +0200 Date: Sun, 18 May 2003 14:22:00 -0000 From: Marc Espie Message-Id: <200305181417.h4IEHbp21625@quatramaran.ens.fr> To: zack@codesourcery.com, gcc@gcc.gnu.org Subject: Re: PROPOSAL: Policy for obsoleting targets X-Newsgroups: ens.mailing-lists.egcs.general In-Reply-To: <874r3u27sm.fsf@egil.codesourcery.com> Organization: Ecole Normale Superieure (quatramaran) Cc: X-SW-Source: 2003-05/txt/msg01694.txt.bz2 In article <874r3u27sm.fsf@egil.codesourcery.com> you write: > >The last two times we've been round the release cycle, obsolete target >lists have been assembled ad-hoc. I would post a list based on >intuitive impressions of what was no longer in use, then lots of >people would object to it and it would get pruned. > >In the future I would like to do this more objectively. To that end I >am proposing: > > At the time GCC version 3.n is released, all targets which have not > had a successful build and test report posted to gcc-testresults > for prereleases of minor version n, or releases n-1 and n-2, go on > the obsoletion list for version n+1. "Successful" means minimum > useful functionality: it's okay if only the C compiler works. > > At any time during the development cycle of version n+1, anyone can > request the removal of a target from the obsoletion list, but they > must first post a successful build and test report to gcc-testresults. I'm completely against this. For various reasons, me and other OpenBSD folks tend to lag behind gcc releases quite a bit. For instance, having the compiler slowing down more and more doesn't help. Plus, we have other changes to test that very often conflict with gcc issues. We also have totally different release schedules and demands compared to the gcc mainlines. If you look closely at recent gcc releases, you might be surprised to discover that almost *none* of them build cleanly on any OpenBSD systems. However, this doesn't prevent us from having a functional port of gcc 3.2 (soon to be updated to gcc 3.3, now that the i386 switch to elf is complete), and to have various running targets, including vax and hppa ports (that currently use gcc 2.95.x, but gcc 3.2/3.3 has been somewhat tested since). Simply put, we don't have the manpower, nor the energy, to follow test results very carefully. Writing patches that will be accepted by the SC is often tedious, or downright impossible, because of conflicting policies. It's also one small item in our busy agenda (I'm probably the chief OpenBSD contributor to gcc of late, but by no means the only person working on it... but gcc is definitely not the only thing I'm working on). So, your `automated' policy will very likely put most OpenBSD platform on the obsoletion list very quickly, even though those are quite alive and kicking.