RISC-V architecture is marked as "unofficial"

[Dimitri John Ledkov]

In the past said nomenclature had some external meanings w.r.t. split
mirroring, native builders, commercial support.

However over the years all of these things have been externalised - split
mirroring is defined elsewhere; builder technology has moved to fully
private cloud; and commercial support is subject to separate terms of
services that no longer reference this label.

Most recently we flipped such a label once there was a hardware
relationship with hardware OEM, the port was self hosting, and used native
hardware for builds (instead of an emulator).

However there is no reason to believe that riscv64 binaries are somehow
inferior when compiled under qemu versus on a hw accelerated KVM given the
toolchain improvements over the years.

Thus this label is largely cosmetic and inconsequential at this point. And
if it deters one from using the port or hinders its marketability, it
should be flipped to official.

Regards,

Dimitri.

On Tue, 29 Apr 2025, 12:42 Robie Basak, <robie.basak at ubuntu.com> wrote:

> [adding ubuntu-release@]
>
> On Wed, Apr 23, 2025 at 04:53:32PM +0200, Heinrich Schuchardt wrote:
> > On pages like https://launchpad.net/ubuntu/plucky the riscv64
> architecture
> > is marked as "unofficial".
>
> Looks like this corresponds to the "official" attribute of the
> underlying distro_arch_series API object in Launchpad, which presumably
> the TB can adjust as required.
>
> I think you're implying a request to changing the value of this
> attribute to True?
>
> If so, that sounds like something for the Release Team to decide, having
> consulted the teams they consider relevant. I imagine they'll want to
> ensure that there aren't any implied expectations that won't be met, or
> any technical failures due to implied assumptions about the meaning of
> that field.
>
> Presumably we'd also make this change only in the development release,
> rather than trying to change history in existing stable releases?
>
> In the past we had people like Steve who would immediately know the
> implications and we'd all trust to make the right call, but now we
> don't, so we have to be more careful :-/
>
> Release Team: could you make a recommendation here please, for the
> Technical Board to consider?
>
> Thanks,
>
> Robie
> --
> technical-board mailing list
> technical-board at lists.ubuntu.com
> https://lists.ubuntu.com/mailman/listinfo/technical-board
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.ubuntu.com/archives/ubuntu-release/attachments/20250429/64f1b018/attachment.html>