On 2023-02-16 11:44:25 -0700, Sam Hartman wrote: > >>>>> "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.
Thanks for this mail. The discussion on SC#4 is not helping us to reach a decission on this issue. Cheers -- Sebastian Ramacher
