Sparc64 doesn't care about you, and you shouldn't care about Sparc64

[Adrian Chadd]

On 16 November 2015 at 17:53, Alfred Perlstein <bright at 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 at 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