From owner-freebsd-sparc64@freebsd.org Tue Nov 17 01:57:56 2015 Return-Path: Delivered-To: freebsd-sparc64@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 557F4A307CE for ; Tue, 17 Nov 2015 01:57:56 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Received: from mailman.ysv.freebsd.org (mailman.ysv.freebsd.org [IPv6:2001:1900:2254:206a::50:5]) by mx1.freebsd.org (Postfix) with ESMTP id 2FD9219D4 for ; Tue, 17 Nov 2015 01:57:56 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Received: by mailman.ysv.freebsd.org (Postfix) id 2C50EA307CB; Tue, 17 Nov 2015 01:57:56 +0000 (UTC) Delivered-To: sparc64@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 1202EA307CA; Tue, 17 Nov 2015 01:57:56 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Received: from mail-io0-x241.google.com (mail-io0-x241.google.com [IPv6:2607:f8b0:4001:c06::241]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id CC91819D2; Tue, 17 Nov 2015 01:57:55 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Received: by ioek191 with SMTP id k191so455577ioe.3; Mon, 16 Nov 2015 17:57:55 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=NI7EEh4VpBKHkd5+JpRrOXqI/61eSad3bf0PIxd3ixc=; b=DJu01wTD+vXJLGDMph4XRamNd/su46mY2FfR29M2OmUKh9Dom8TLDzIJs2z8drL/ua 55pYYbW3nKvUzF8f4U2hj6ho2X5z1SUQfTlz3ZUa1R/kp8Hn90MW4k+bU0scvr0e+ePK 0LqXZBRUheuPw5rm/jGEMRzhZyGx63znYXZ/UZPud04ETQ0Nie+RInoB7w3gpKvV5A7q l4KnP3X+eZ75KvOXKUi3uDWVth1qWacIsvuwkk4OmvJDWctcFEa6A+GuUMUZTKnXwpDo VyKcAd4NLa4syAW0tmwINSu1qxa+E3tOG4pCWHhM0zoLTN+ksi5VlLbo0V7NmrqVGx6y y3tA== MIME-Version: 1.0 X-Received: by 10.107.162.21 with SMTP id l21mr7575815ioe.123.1447725475279; Mon, 16 Nov 2015 17:57:55 -0800 (PST) Received: by 10.36.217.196 with HTTP; Mon, 16 Nov 2015 17:57:55 -0800 (PST) In-Reply-To: <564A889C.9070209@mu.org> References: <563A5893.1030607@freebsd.org> <2AAC0EF3-528B-476F-BA9C-CDC3004465D0@bsdimp.com> <20151108155501.GA1901@alchemy.franken.de> <563F8385.3090603@freebsd.org> <56417100.5050600@Wilcox-Tech.com> <39947478-4710-47D8-BAB1-FC93979570B6@mail.turbofuzz.com> <5646D19C.9010304@interlinked.me> <564A889C.9070209@mu.org> Date: Mon, 16 Nov 2015 17:57:55 -0800 Message-ID: Subject: Re: Sparc64 doesn't care about you, and you shouldn't care about Sparc64 From: Adrian Chadd To: Alfred Perlstein Cc: Warner Losh , Elizabeth Myers , Anna Wilcox , freebsd-arch , Marius Strobl , Sean Bruno , "sparc64@freebsd.org" , Jordan Hubbard Content-Type: text/plain; charset=UTF-8 X-BeenThere: freebsd-sparc64@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Porting FreeBSD to the Sparc List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Nov 2015 01:57:56 -0000 On 16 November 2015 at 17:53, Alfred Perlstein wrote: > > > > On 11/14/15 9:16 AM, Warner Losh wrote: >> >> On Fri, Nov 13, 2015 at 11:15 PM, Elizabeth Myers >> >> wrote: >> >>> You are seriously going to use "we're not NetBSD" as an argument? >> >> >> You noticed I didn't reply to it. The argument is completely lame. FreeBSD >> runs >> today in a variety of markets. Some new, some not so new. The thing that >> makes >> each of these areas unique is that there's a thriving community around >> them, >> FreeBSD still runs well enough on these machines to get something done, >> and >> when things break, they get fixed in a timely manner. >> >> Alpha was removed because it got broken by some changes, and stayed broken >> for a long time despite repeated requests to fix it. Sparc64 is on the >> cusp >> of that: >> some minor things are broken, but have been fixed. The current crisis is >> due to >> the end of life of gcc in the tree and its fallout coupled with some >> neglect of the >> port due to time constraints. >> >> At first I was all for removal. With more data, I'm less sure. If the >> promises are kept >> made in this thread, it looks to remain viable for a while, though the >> lack >> of a >> qemu-user solution means that packages for a slow platform (where they are >> really quite useful) will remain limited. Maybe there's enough hardware >> around >> that third-party pkg repos can fill the gap, maybe not. I think we should >> experiment >> with this model and see what it produces. Give the branching of 11 as the >> deadline >> to show something viable... > > > One of the things I never understood about FreeBSD's method of maintaining a > port was the way the platform porting was done. We really do things in a > different manner than what my perception of other OSes is. > > My impression (please do correct me if I'm wrong) was that other OSes such > as NetBSD and Linux had "platform maintainers". > > These maintainers were around to: > 1) keep the ship sailing on those platforms > 2) guide the general code base from becoming non-portable to other > architectures (within reason). > 3) drive the release of the architecture in question, helping the release > engineer with image building and release testing. > > For point 1 above, what that meant to me was that let's say Linus or NetBSD > in general wanted to do a major or minor change on a tier 1 platform, then > it was the responsibility of the *platform maintainers* to do the work on > the non tier-1 platforms to keep them up to date. Those "platform > maintainers" kept those ships sailing and in return they got to be called > "the $arch maintainer" which looks plenty good on a resume and also feels > good for those that get excited for status. > > For point 2, let's say someone had a change that pushed some form of > *completely* non-portable code into the base which would break a reasonable > to support platform, then the "platform maintainer" would speak up and tell > the general community "uh no, you can't do X on this platform, we need to > rethink this". > > For point 3, there may be a lag between release of the OS for tier 1 > (x86/x64) and the secondary architectures, but that is OK because the > maintainer will eventually provide images themselves or in collaboration > with the release engineer. > > FreeBSD seems to take a different approach. This approach is that someone > (or some people) form a team to port to a platform. These "platform porter" > groups sole responsibility is to get a new architecture running. After it's > mostly running they are mostly without responsibility, however we tend to > give them the right of change-set veto in perpetuity of the marginal > relevance of the ported to platform. > > What this means is that instead of a assigning a title and ownership of the > platform to someone, who maintains the status as "maintainer" by keeping > that platform working. By keeping the platform working I am saying that > they would do items 1, 2 and 3 from the NetBSD/Linux list. However, instead > nearly immediately hoist the "platform maintenance" onto the general > community of people that may not have access to the hardware in question. > > Maybe this is just my perception, but it would seem to make a ton more sense > to follow the NetBSD/Linux model which implies a somewhat decoupled release > model (not all arches must come out on the same day) and assigning ownership > and responsibility in exchange for status based on being the "platform > maintainer". > > Finally it would be pretty obvious when everyone steps down or just doesn't > participate in the release process that it may be time to sunset a platform. +1 -a