Re: Porter roll call for Debian Bullseye
Hello!
On 11/2/20 9:23 PM, Graham Inggs wrote:
> We are doing a roll call for porters of all release architectures. If
> you are an active porter behind one of the release architectures [1]
> for the entire lifetime of Debian Bullseye (est. end of 2024), please
> respond with a signed email containing the following before Friday,
> November 27:
>
> * Which architectures are you committing to be an active porter for?
> * Please describe recent relevant porter contributions.
> * Are you running/using Debian testing or sid on said port(s)?
> * Are you testing/patching d-i for the port(s)?
>
> Please note that no response is required for amd64 because our
> toolchain maintainers are happy to support amd64 as-is. Also note
> that this waiver no longer applies for i386, where it did in previous
> releases.
Since there haven't been any replies to this call - at least not on the lists
that I am currently on - I would like to make a suggestion to address this
porter issue in the long term.
In Debian Ports, we have many users that would still like to be able to use
stable or testing releases which we can't offer since we don't have a Britney
instance ourselves. We are also missing a proper instance of the Debian Archive
Kit (DAK) meaning that we don't have the possibility to use cruft, see [1].
If we had both Britney and a proper DAK in Debian Ports, we could make Debian Ports
more official by turning Debian's architecture support policy into a tier system
similar to many other projects such as NetBSD [2].
The plan would be that ports can be promoted and demoted between tiers at the
courtesy of the release team. Current release architectures would be Tier I
while ports architectures would be Tier II.
Being Tier I means, port must have a dedicated porter team, Tier II means that
the Debian Ports team takes care of the maintenance of the port, similar to what
the QA team already does for packages.
Tier I is guaranteed to be stable with FTBFS bugs and other QA issues being release
critical while such bugs on Tier II will only be classified as important or normal.
This means that users will still be able to install fresh releases on Tier II
targets, we just don't guarantee that it will work. At the same time, the release
and security teams don't have to deal with ports where finding porters is more
difficult.
The only problem that I see with this approach is that DSA will probably not
be easily transferring administration rights over Tier I buildds to the Debian
Ports team when a port becomes Tier II. Similarly, DSA will probably not agree
to take care of Tier II buildds. So the question over server administration
could be an actual blocker for such a concept, although it would probably less
critical in practice as ports won't be moved between tiers too often.
And we would need to get DAK and Brtiney for Debian Ports, first, of course.
Any comments?
Adrian
> [1] https://lists.debian.org/debian-sparc/2017/12/msg00060.html
> [2] https://www.netbsd.org/ports
--
.''`. John Paul Adrian Glaubitz
: :' : Debian Developer - glaubitz@debian.org
`. `' Freie Universitaet Berlin - glaubitz@physik.fu-berlin.de
`- GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Reply to: