policy on supported platforms
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:
>> 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
> 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
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
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