>>>>> "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
