From owner-freebsd-sparc64@FreeBSD.ORG Tue Jun 10 01:53:47 2008 Return-Path: Delivered-To: freebsd-sparc64@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id DB71F1065703 for ; Tue, 10 Jun 2008 01:53:47 +0000 (UTC) (envelope-from royce@alaska.net) Received: from malik.acsalaska.net (malik.acsalaska.net [209.112.173.227]) by mx1.freebsd.org (Postfix) with ESMTP id 8F72E8FC12 for ; Tue, 10 Jun 2008 01:53:46 +0000 (UTC) (envelope-from royce@alaska.net) Received: from [10.0.102.101] (209-112-156-36-adslb0fh.acsalaska.net [209.112.156.36]) by malik.acsalaska.net (8.14.1/8.14.1) with ESMTP id m5A1P6n6002718; Mon, 9 Jun 2008 17:25:06 -0800 (AKDT) (envelope-from royce@alaska.net) Message-ID: <484DD7F1.9000003@alaska.net> Date: Mon, 09 Jun 2008 17:25:05 -0800 From: Royce Williams User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.8.1.14) Gecko/20080421 Thunderbird/2.0.0.14 Mnenhy/0.7.5.0 MIME-Version: 1.0 To: Mark Linimon References: <6e5cf6a70806051341x95eb814j6222c04dbfd7fb2d@mail.gmail.com> <20080609211208.GA66541@alchemy.franken.de> <20080609231419.F13655@ury.york.ac.uk> <484DBB64.5050607@FreeBSD.org> <20080609234022.GA18959@soaustin.net> In-Reply-To: <20080609234022.GA18959@soaustin.net> X-Enigmail-Version: 0.95.6 OpenPGP: url=http://www.tycho.org/royce/royce@alaska.net.asc X-Face: ">19[ShfDD9'g", GrH$'v:=qBVZdg.kXSBR6*ZC$am:D Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-ACS-Spam-Status: no X-ACS-Scanned-By: MD 2.63; SA 3.2.3; spamdefang 1.122 Cc: freebsd-sparc64@freebsd.org Subject: Re: status of freebsd on ultrasparc? X-BeenThere: freebsd-sparc64@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Porting FreeBSD to the Sparc List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Jun 2008 01:53:47 -0000 Mark Linimon wrote, on 6/9/2008 3:40 PM: > On Tue, Jun 10, 2008 at 01:23:16AM +0200, Pietro Cerutti wrote: >> |> It's Tier 2, core@ silently demoted it when updating the tier >> |> document last February. >> | >> | This is now updated. >> >> too bad... :-( sigh > > We need more people using and testing on sparc64 and contributing > fixes back. It's as simple as that. (When I last asked for more > testers, back in November, a few people did respond, but we need more.) Wow ... did I miss an announcement about this somewhere? Unfortunately, neither dropping sparc64 to Tier 2, nor doing so without notifying the user community (if that's really what happened), is likely to inspire more usage or testing - in fact, quite the opposite. It's a chicken-and-egg problem, except we've put the egg back in the chicken. :-) I understand the reasoning, though. I suspect that folks would help more if it was easy to turn a spare box into a 'tester'. Anything that we can do to reduce time/effort for developers and testers would help. Off of the top of my head, with varying degrees of pipe-dreaminess: - Volunteer list: Start a list of volunteers (and their associated hardware). The wiki might be a good place for this, except it makes it harder for non-committer testers to self-organize. - Howto: A howto for novice testers might be helpful. Suggestions for content welcome. - Developer-tester matching: Make it easier for testers to find patches needing testing. (Combing through a mailing list can be time-consuming; how else could we do this?). This is wild pie-in-the-sky, but what if we created a portaudit-like tool to match up developers with testers, that would work like: - Developer adds their patch with applicable branch information to the DEVXML (or whatever). It has information on where to pull the patch from (like port makefiles) and how to apply them (like the security advisories do). Some of this could be automatically generated from a developer dropping a patch into a directory with a couple of tags/comments/whatever. - Tester runs patchmatch(8) (or whatever) to check for patches that need testing on their hardware/setup/whatever. patchmatch.conf could configure what sorts of things they want to help test. patchmatch displays a pre-patch README or something that says "This is supposed to fix fxp watchdog timeouts on hardware X. To see if you are affected by this issue, do X." and then "Apply patch?" and then "Did it fix the problem or not?" that sends the output back to the developer semi-automatically. - Incremental version rollback/forward: People tracking -HEAD or a -STABLE often update and make world at widely different times. A patch is only useful for a certain window of time on a certain branch. If I could patch my system (like freebsd-update) to a particular point in time (like portsnap), I could quickly prepare a system to test a given patch. This isn't just "gee, I wish someone would do this"; I find these ideas interesting and will tinker with the concepts a bit. Suggestions welcome. Royce -- Royce D. Williams - http://royce.ws/ And yet I pity those they torture not. - Percy Bysshe Shelley