Date: Mon, 16 Nov 2015 17:53:32 -0800 From: Alfred Perlstein <bright@mu.org> To: Warner Losh <imp@bsdimp.com>, Elizabeth Myers <elizabeth@interlinked.me> Cc: Anna Wilcox <AWilcox@wilcox-tech.com>, "Brian McGovern (bmcgover)" <bmcgover@cisco.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: <564A889C.9070209@mu.org> In-Reply-To: <CANCZdfoH7i9MBxjw1j4Pc3CpiZP=aP5vah2ay38cazkc7%2BreTA@mail.gmail.com> 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>
next in thread | previous in thread | raw e-mail | index | archive | help
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. -Alfred
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?564A889C.9070209>