policy on supported platforms

[Tom Yu]

Russ Allbery <rra at stanford.edu> writes:

> Tom Yu <tlyu at MIT.EDU> writes:
>
>> I have created a K5Wiki page documenting our policy on supported
>> platforms for MIT Kerberos.  You may find it at:
>>
>>     http://k5wiki.kerberos.org/wiki/Supported_platforms
>>
>> We have informally talked about the concept of supported platforms in
>> the past; this article attempts to formally set some expectations
>> based on historical practice.  Please note the section on "Extent of
>> support", which defines the expectations we are establishing.
>
> It's a little ambiguous whether when you say you support Linux, you mean
> all Linux architectures or only the ones listed in parentheses
> afterwards.  None of the parenthesized platform lists specifically mention
> x86_64, which is probably an oversight.

Thanks for the comments.

By x86 we mean to include x86_64, as most of our current Intel
hardware falls in that category.  I can reword things to more
accurately reflect that.

By "Linux" we mean Linux-based operating systems as a family of
platforms, roughly those which are similar to Debian, Ubuntu, or Red
Hat.

> Debian currently auto-builds all packages on the following architectures:
>
>     alpha amd64 arm armel hppa i386 ia64 m68k mips mipsel powerpc s390
>     sparc
>
> although arm and m68k are on their way out as first-class platforms.  I
> expect that few MIT Kerberos features will be sensitive to the
> architecture difference given that the same glibc and compilers are used
> uniformly.

I hope that there would be very few CPU-architecture dependencies.  On
a supported platform, we would give such issues greater attention than
we would on unsupported platforms.

> If there are any such sensitivities, it would be good to iron them out,
> not at the level of a first-class supported platform but maybe something a
> bit better than "a platform-specific problem reported on an unsupported
> platform will get preemptively closed unless accompanied by a very
> well-written patch that poses negligible integration cost for us."  But
> generally we can provide help from the Debian side on detailed error
> messages and debugging, and I doubt this will be much of an issue in
> practice.

On a supported operating system, we would devote more resources to
dealing with CPU-architecture sensitivities than we would on
unsupported operating systems.  I agree that on a modern operating
system, particularly those that strive for high portability,
sensitivities to specific CPU architectures should be minimal and we
should try to resolve them.