From owner-cvs-all@FreeBSD.ORG Mon May 26 02:01:04 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 ECA101065675; Mon, 26 May 2008 02:01:04 +0000 (UTC) (envelope-from imp@bsdimp.com) Received: from harmony.bsdimp.com (bsdimp.com [199.45.160.85]) by mx1.freebsd.org (Postfix) with ESMTP id 9973B8FC19; Mon, 26 May 2008 02:01:04 +0000 (UTC) (envelope-from imp@bsdimp.com) Received: from localhost (localhost [127.0.0.1]) by harmony.bsdimp.com (8.14.2/8.14.1) with ESMTP id m4Q2048f060804; Sun, 25 May 2008 20:00:04 -0600 (MDT) (envelope-from imp@bsdimp.com) Date: Sun, 25 May 2008 20:01:30 -0600 (MDT) Message-Id: <20080525.200130.246265403.imp@bsdimp.com> To: rwatson@FreeBSD.ORG From: "M. Warner Losh" In-Reply-To: <20080525180014.S63463@fledge.watson.org> References: <200805250248.m4P2mv8U026913@repoman.freebsd.org> <20080525180014.S63463@fledge.watson.org> X-Mailer: Mew version 5.2 on Emacs 21.3 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: cvs-src@FreeBSD.ORG, jb@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: Mon, 26 May 2008 02:01:05 -0000 In message: <20080525180014.S63463@fledge.watson.org> Robert Watson writes: : 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. Yes. It may be the right decision, but it needs to be properly "socialized" before pulling the trigger. Warner