On 2022-09-08 13:00:11 +0200, Paul Gevers wrote: > Hi all, > > On 01-09-2022 14:18, Paul Gevers wrote: > > Of course there are details to figure out and agree on, but before > > diving into those I'd like to hear if you are open to support the idea > > (hopefully even in time for bookworm) or if there are already deep > > concerns (that would take long to resolve if at all). > > Although I wasn't expecting a big wave of enthousiasme from this audience, I > was expecting at least some reply with concerns. Given that there hasn't > been any reply, I don't know how you feel about this. > > To be able to proceed before the bookworm freeze, I'm going to assume that > in general this split (that shouldn't really impact DSA and ftp-master work > [1]) is acceptable by you if there's no reply in two weeks. I'll work out > more details after that. > > Paul > > [1] I predict it may even reduce the amount of architecture specific removal > requests in unstable, where the porters have a chance to fix broken > packages.
To be honest, I'm not sure I understand what's the plan with this and that's why I refrained from replying. The notes from the BoF do not make that clear (at least to me). The feeling that I get from the notes and your initial mail is that we (as the release team) don't want to make a decision with respect to release architectures so we push that to somebody else by somehow keeping them half supported with a separately managed "ports-testing". Yes, there are release architectures with issues. I think we should think of moving them to ports rather than a half-supported state somewhere in between. Alternatively, for some of them (like i386) we could also discuss raising the baseline to get rid of some of the issues. So, maybe my main question is: if we don't consider issues on these semi-supported architectures RC but they have a testing equivalent, why don't the other ports architectures get the same treatment? Cheers -- Sebastian Ramacher
