Differential D12569 Diff 33639 en_US.ISO8859-1/articles/committers-guide/article.xml

Changeset View

Standalone View

en_US.ISO8859-1/articles/committers-guide/article.xml

Show First 20 Lines • Show All 3,906 Lines • ▼ Show 20 Lines	<sect2>

<para>Tier 1 platforms are fully supported by the security		<para>Tier 1 platforms are fully supported by the security
officer, release engineering, and toolchain maintenance staff.		officer, release engineering, and toolchain maintenance staff.
New features added to the operating system must be fully		New features added to the operating system must be fully
functional across all Tier 1 architectures for every release		functional across all Tier 1 architectures for every release
(features which are inherently architecture-specific, such as		(features which are inherently architecture-specific, such as
support for hardware device drivers, may be exempt from this		support for hardware device drivers, may be exempt from this
requirement). In general, all Tier 1 platforms must have		requirement). In general, all Tier 1 platforms must have
build and Tinderbox support either in the FreeBSD.org cluster,		build and tinderbox support either in the FreeBSD.org cluster,
		emasteUnsubmitted Not Done Inline Actions Probably we should just say "continuous integration" support. emaste: Probably we should just say "continuous integration" support.
		jhbAuthorUnsubmitted Not Done Inline Actions I'm happy to use whatever the right general term is. Perhaps CI is it (I almost used it), I was just worried that it was perhaps overly broad (and maybe it isn't that broad and CI is what we really want to say here). My goal is to just have this cover whatever "official" compile and runtime testing infrastructure the project uses. jhb: I'm happy to use whatever the right general term is. Perhaps CI is it (I almost used it), I…
		emasteUnsubmitted Not Done Inline Actions Maybe just "build and test automation" then? Maybe CI is too broad. emaste: Maybe just "build and test automation" then? Maybe CI is too broad.
or be easily available for all developers. Embedded platforms		or be easily available for all developers. Embedded platforms
may substitute an emulator available in the &os; cluster		may substitute an emulator available in the &os; cluster
for actual hardware.</para>		for actual hardware.</para>

<para>Tier 1 architectures are expected to be Production Quality		<para>Tier 1 architectures are expected to be Production Quality
with respects to all aspects of the &os; operating system,		with respects to all aspects of the &os; operating system,
including installation and development environments.</para>		including installation and development environments.</para>

Show All 17 Lines
packages must be the most relevant for the platform, but may		packages must be the most relevant for the platform, but may
be a non-empty subset of those that build natively.</para>		be a non-empty subset of those that build natively.</para>

<para>Tier 1 architectures must be fully documented. All basic		<para>Tier 1 architectures must be fully documented. All basic
operations need to be covered by the handbook or other		operations need to be covered by the handbook or other
documents. All relevant integration documentation must also		documents. All relevant integration documentation must also
be integrated into the tree, or readily available.</para>		be integrated into the tree, or readily available.</para>

		<para>Tier 1 architectures should avoid ABI changes in userland
		libraries, system calls or supported kernel interfaces within
		a stable branch. Compatability shims that support the
		bcrUnsubmitted Done Inline Actions s/Compatability/Compatibility/ bcr: s/Compatability/Compatibility/
		jhbAuthorUnsubmitted Not Done Inline Actions I think this paragraph probably needs a bit more thought. For example, I think we want to somehow be more broad than just stable branches. Changing i386 time_t to 64-bit without shims wouldn't fly due to Tier 1 (but was ok for Tier 2 for powerpc). Also, I had originally said "ABI breakage" and now it says "don't change the ABI" rather than "avoid breaking the ABI" when the latter is what I really want to say (I just want to say it in a way where that is a bit more concretely defined than "breaking the ABI") jhb: I think this paragraph probably needs a bit more thought. For example, I think we want to…
		existing ABI can be used as a tool to introduce ABI
		changes.</para>

<para>Current Tier 1 platforms are &arch.i386; and		<para>Current Tier 1 platforms are &arch.i386; and
&arch.amd64;.</para>		&arch.amd64;.</para>
</sect2>		</sect2>

<sect2>		<sect2>
<title>Tier 2: Developmental Architectures</title>		<title>Tier 2: Developmental Architectures</title>

<para>Tier 2 platforms are not supported by the security officer		<para>Tier 2 platforms are not supported by the security officer
Show All 40 Lines
handbook. The basics for how to get a system running must be		handbook. The basics for how to get a system running must be
documented, although not necessarily for every single board or		documented, although not necessarily for every single board or
system a Tier 2 architecture supports. The supported hardware		system a Tier 2 architecture supports. The supported hardware
list must exist and be relatively recent. It should be		list must exist and be relatively recent. It should be
integrated into the &os; documentation.</para>		integrated into the &os; documentation.</para>

<para>Current Tier 2 platforms are &arch.arm;, &arch.arm64;,		<para>Current Tier 2 platforms are &arch.arm;, &arch.arm64;,
&arch.ia64; (through &os; 10),		&arch.ia64; (through &os; 10),
&arch.pc98;, &arch.powerpc;, and &arch.sparc64;.</para>		&arch.pc98; (through &os; 11),
		&arch.powerpc;, and &arch.sparc64;.</para>
</sect2>		</sect2>

<sect2>		<sect2>
<title>Tier 3: Experimental Architectures</title>		<title>Tier 3: Experimental Architectures</title>

<para>Tier 3 platforms are not supported by the security officer		<para>Tier 3 platforms are not supported by the security officer
and release engineering teams. At the discretion of the		and release engineering teams. At the discretion of the
toolchain maintainers, they may be supported in the toolchain.		toolchain maintainers, they may be supported in the toolchain.
Show All 25 Lines	&arch.riscv;.</para>

<sect2>		<sect2>
<title>Tier 4: Unsupported Architectures</title>		<title>Tier 4: Unsupported Architectures</title>

<para>Tier 4 systems are not supported in any form by the		<para>Tier 4 systems are not supported in any form by the
project.</para>		project.</para>

<para>All systems not otherwise classified into a support tier		<para>All systems not otherwise classified into a support tier
are Tier 4 systems. The &arch.ia64; platform is transitioning		are Tier 4 systems. The &arch.ia64; platform is transitioning
to Tier 4 status in &os; 11.</para>		to Tier 4 status in &os; 11. The &arch.pc98; platform is
		transitioning to Tier 4 status in &os; 12.</para>
</sect2>		</sect2>

<sect2>		<sect2>
<title>Policy on Changing the Tier of an Architecture</title>		<title>Policy on Changing the Tier of an Architecture</title>

<para>Systems may only be moved from one tier to another by		<para>Systems may only be moved from one tier to another by
approval of the &os; Core Team, which shall make that		approval of the &os; Core Team, which shall make that
decision in collaboration with the Security Officer, Release		decision in collaboration with the Security Officer, Release
▲ Show 20 Lines • Show All 1,245 Lines • Show Last 20 Lines