policy on supported platforms

Tom Yu tlyu at MIT.EDU
Mon Oct 20 18:44:40 EDT 2008

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

> 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.

More information about the krbdev mailing list