Date: Mon, 16 Nov 2015 17:57:55 -0800 From: Adrian Chadd <adrian.chadd@gmail.com> To: Alfred Perlstein <bright@mu.org> Cc: Warner Losh <imp@bsdimp.com>, Elizabeth Myers <elizabeth@interlinked.me>, Anna Wilcox <AWilcox@wilcox-tech.com>, freebsd-arch <freebsd-arch@freebsd.org>, Marius Strobl <marius@alchemy.franken.de>, Sean Bruno <sbruno@freebsd.org>, "sparc64@freebsd.org" <sparc64@freebsd.org>, Jordan Hubbard <jkh@mail.turbofuzz.com> Subject: Re: Sparc64 doesn't care about you, and you shouldn't care about Sparc64 Message-ID: <CAJ-VmokbTBqXM0Xg%2BXCo7fMK010Mcp3LB6knVTr1Re8RoqbKMA@mail.gmail.com> 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> <CANCZdfqO-SdjnonGzRr2H0pDon5oALsDGsmG3KOxPGRVdTbHPQ@mail.gmail.com> <39947478-4710-47D8-BAB1-FC93979570B6@mail.turbofuzz.com> <f4d1114833994331bd1fd2273f305abc@XCH-RTP-005.cisco.com> <5646D19C.9010304@interlinked.me> <CANCZdfoH7i9MBxjw1j4Pc3CpiZP=aP5vah2ay38cazkc7%2BreTA@mail.gmail.com> <564A889C.9070209@mu.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On 16 November 2015 at 17:53, Alfred Perlstein <bright@mu.org> wrote: > > > > On 11/14/15 9:16 AM, Warner Losh wrote: >> >> On Fri, Nov 13, 2015 at 11:15 PM, Elizabeth Myers >> <elizabeth@interlinked.me> >> 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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CAJ-VmokbTBqXM0Xg%2BXCo7fMK010Mcp3LB6knVTr1Re8RoqbKMA>