From owner-cvs-all@FreeBSD.ORG Sun May 25 17:03:23 2008 Return-Path: Delivered-To: cvs-all@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 158EC1065672; Sun, 25 May 2008 17:03:23 +0000 (UTC) (envelope-from rwatson@FreeBSD.org) Received: from cyrus.watson.org (cyrus.watson.org [209.31.154.42]) by mx1.freebsd.org (Postfix) with ESMTP id D95618FC0A; Sun, 25 May 2008 17:03:22 +0000 (UTC) (envelope-from rwatson@FreeBSD.org) Received: from fledge.watson.org (fledge.watson.org [209.31.154.41]) by cyrus.watson.org (Postfix) with ESMTP id 5F22A46C2A; Sun, 25 May 2008 13:03:22 -0400 (EDT) Date: Sun, 25 May 2008 18:03:22 +0100 (BST) From: Robert Watson X-X-Sender: robert@fledge.watson.org To: John Birrell In-Reply-To: <200805250248.m4P2mv8U026913@repoman.freebsd.org> Message-ID: <20080525180014.S63463@fledge.watson.org> References: <200805250248.m4P2mv8U026913@repoman.freebsd.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: cvs-src@FreeBSD.org, src-committers@FreeBSD.org, cvs-all@FreeBSD.org Subject: Re: cvs commit: src Makefile X-BeenThere: cvs-all@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: CVS commit messages for the entire tree List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 25 May 2008 17:03:23 -0000 On Sun, 25 May 2008, John Birrell wrote: > Remove sun4v from the list of arches in 'make universe'. There has been > no active development on it for over a year now and it isn't > reliable under a simple buildworld. Developers can't be expected to > test code targeted for it. Having an architecture in make universe isn't about making the code work, it's about encouraging the code to remain compilable even though most developers don't actually work with the architecture. Sun4v is arguably our most edge-case architecture right now, but given that it shares a lot of code with sparc64 and sparc64 is run by a non-trivial number of people (more than arm?), keeping it compiling hasn't proven very difficult. And recent universe breakage has often-as-not been in i386 and amd64, not sun4v. Is there something in your recent work that prevents sun4v from compiling and hence justifies disabling it entirely, and hence guaranteeing it won't compile in the future because it falls off the "make it compile" radar? If so, then a policy decision to drop sun4v support may be called for -- but this is something to discuss with the people who added support for the architecture, the release engineering team, etc, and not to make unilaterally. Robert N M Watson Computer Laboratory University of Cambridge