>>>>> "Adrian" == Adrian Bunk <b...@debian.org> writes:
Adrian> On Thu, Feb 16, 2023 at 05:48:22PM +0100, Daniel Leidert wrote: >> Am Donnerstag, dem 16.02.2023 um 18:37 +0200 schrieb Adrian Bunk: >> > On Wed, Feb 15, 2023 at 12:05:41AM +0100, Daniel Leidert wrote: >> > > ... > > Reasons: > > ... > > - - the change makes it >> impossible to create filesystems with this version of > > >> e2fsprogs and then run a grub-install from a target system that >> does not cope > > with that feature; basically breaking the >> debootstrap method of installing > > Debian or Ubuntu onto a >> server (violating #4 of the Debian social contract) > > ... > > >> Instead, turning on this feature should be postponed for the next >> release cycle > > where a proper transition can be done. > > ... >> > >> > Daniel, you are contradicting yourself when claiming that a >> change that > would allegedly violate the Debian social contract >> could be done in the > next release cycle. >> >> Actually, I'm not. ... Adrian> If not being able to install bullseye from bookworm is a Adrian> violation of the Debian social contract, then the same Adrian> rationale applies to not being able to install bullseye from Adrian> trixie being a violation of the Debian social contract. I don't think that arguing about whether this is a social contract violation makes a lot of sense. It seems fairly clear there is not a consensus about that. But if we're going to do that, I suggest that Adrian is putting words into Daniel's mouth a bit. Daniel has said he believes this situation violates the Social Contract #4, but has not explained why. Adrian has taken one interpretation. I'll propose another: "This violates the social contract because we are not prioritizing our users. Prioritizing users requires that we give them notice of incompatible changes." I personally think that prioritizing users requires no such thing, and that this change is not a violation of the SC. But you don't need to take the straw man position Adrian is assuming Daniel implies to believe this is a SC violation. But seriously, let's give up the whole is this an SC violation part of the discussion and move on with constructive aspects: * The RT has asked to understand the impact of the change. * Several people have proposed better documentation because it's clear that user (and image builder) expectations are not aligned with filesystem maintainer expectations. * Anyone could prepare patches to image building software to use mkfs options that will work with bullseye. You could also try to prepare patches to run mkfs out of a chroot or container of the guest OS for the image. I appreciate Russ strongly favors this solution, but as someone who has dug into image building tools a fair bit over the years, I think there are significant complexity and performance downsides to that approach. I also think that changing the mkfs options is more likely to get an unblock than changing the structure of how the tool works. * People could try to judge consensus on debian-devel or debian-policy about whether we want a stability guarantee ?+/- 1 release on issues like this. My suspicion is that you will not find a consensus, and that if the RT decides they don't want this change in bookworm, Ted will change the defaults, and if the RT is unwilling to block, we're left with documentation. I think all the above is more productive than arguing about whether this is or is not an SC violation.
signature.asc
Description: PGP signature