Re: Lifting the moratorium
Re: Timo Röhling > * Helmut Grohne [2023-08-26 11:39]: > > > Who is this going to be? Do you, Helmut, feel comfortable as driver? > > > > Yes, though I'm not opposed to sharing the load. Thanks Helmut! > It does not even have to be much, maybe a > short paragraph such as > > "Please monitor the document at for the current transition > status. Helmut has graciously agreed to coordinate the transition. > Please reach out to him if you want to help with the effort, or if > you have affected packages and are unsure how you should proceed." > > in the CTTE announcement is sufficient. I like this very much. Christoph
Re: Lifting the moratorium
Hi Helmut, * Helmut Grohne [2023-08-26 11:39]: Who is this going to be? Do you, Helmut, feel comfortable as driver? Yes, though I'm not opposed to sharing the load. Ack. Do you prefer if the Release Team takes over with you in an advisory role? If you continue as main driver, should the DPL formally delegate that role somehow? On a micro level, the Release Team will be involved. The plan is for me to file RC bugs. There will be disagreement about such bugs and the Release Team is the arbiter of severities and testing migration here. Ack. I'm surprised. We did have some contentious questions such as whether changing dpkg would be part of the solution and how the bootstrap protocol should look like. These seem settled now. Beyond these, the feedback mostly was that we should simply get it done. We will still see individual disagreements on particular packages, but those cannot be settled by some form of delegation as in effect they touch the package ownership and overriding that currently requires CTTE involvement. I'd rather see us not using the constitution hammer just because we see a nail and hope that I'm right about the expected cooperation. Maybe DPL delegation invokes the wrong kind of image here. I'm not asking for some dictator who pushes the transition through no matter what. What I do like to see is transparent commmunication about the process; we should be upfront about the fact that you drive this transition and not just kind of let it happen (which is what it has felt like to me at times). It does not even have to be much, maybe a short paragraph such as "Please monitor the document at for the current transition status. Helmut has graciously agreed to coordinate the transition. Please reach out to him if you want to help with the effort, or if you have affected packages and are unsure how you should proceed." in the CTTE announcement is sufficient. All the usual channels for dispute resolution remain available, but everyone is brought to the same page, even if they missed (or ignored) the d-devel discussion up this point. Also, any developer who just wants to "get it done" but does not have the time or energy to fully grok DEP-17 has the option to defer to you / the developers coordinating the transition, similar to what has happened with the debhelper NMU. Cheers Timo -- ⢀⣴⠾⠻⢶⣦⠀ ╭╮ ⣾⠁⢠⠒⠀⣿⡁ │ Timo Röhling │ ⢿⡄⠘⠷⠚⠋⠀ │ 9B03 EBB9 8300 DF97 C2B1 23BF CC8C 6BDD 1403 F4CA │ ⠈⠳⣄ ╰╯ signature.asc Description: PGP signature
Re: Lifting the moratorium
Hi Timo, On Sat, Aug 26, 2023 at 01:32:25AM +0200, Timo Röhling wrote: > Practically, lifting the moratorium means that the CTTE relinquishes > control of the /usr-merge transition to whoever drives the > transition, i.e., maintains that living document and thereby makes > decisions on how to proceed. Yes. > Who is this going to be? Do you, Helmut, feel comfortable as driver? Yes, though I'm not opposed to sharing the load. > Do you prefer if the Release Team takes over with you in an advisory > role? If you continue as main driver, should the DPL formally > delegate that role somehow? Isn't this "just" a transition? I mean it's a larger one spanning multiple releases and it's one that will not migrate to testing in one step, but other than that, it is a change affecting many packages in a coordinated way which is what we usually call transition. A transition bug probably is a good idea, but other than that, transitions are usually managed by those doing the work without exercising constitutional powers. I sincerely hope that we as a project can get this done in a consensual way without requiring the use of constitutional mechanisms to make it work. Yes, there have been a lot of bad feelings and even questionable actions and so forth about this, but on a lot of sides I also see an interest to listen to each other and cooperation. People who formerly have indicated to be too annoyed by this matter to consider discussing it start doing so again. Why not try another time to put trust in our community? The worst thing that could happen seems to be us messing up the transition and making some systems unbootable until we figure out a solution. Given dumat, we can likely keep that out of trixie. If things fail that way, we can still consider the use of more constitutional powers, but I'd rather see us getting done without needing them. On a micro level, the Release Team will be involved. The plan is for me to file RC bugs. There will be disagreement about such bugs and the Release Team is the arbiter of severities and testing migration here. > I think these are questions we need answered, because it would be > advisable to have someone with clearly defined responsibilities at > the wheel for the transition. Otherwise, we risk stale-mating > ourselves with endless debates on how to finish the transition > "properly". I'm surprised. We did have some contentious questions such as whether changing dpkg would be part of the solution and how the bootstrap protocol should look like. These seem settled now. Beyond these, the feedback mostly was that we should simply get it done. We will still see individual disagreements on particular packages, but those cannot be settled by some form of delegation as in effect they touch the package ownership and overriding that currently requires CTTE involvement. I'd rather see us not using the constitution hammer just because we see a nail and hope that I'm right about the expected cooperation. Helmut
Re: Lifting the moratorium
Timo Röhling writes: > I think these are questions we need answered, because it would be > advisable to have someone with clearly defined responsibilities at > the wheel for the transition. Otherwise, we risk stale-mating > ourselves with endless debates on how to finish the transition > "properly". +1 Bdale signature.asc Description: PGP signature
Re: Lifting the moratorium
Hi, * Helmut Grohne [2023-08-25 13:40]: You see that this goes into very much detail and having the CTTE decide upon the precise way of lifting this seems suboptimal. That would amount to micro-managing the transition. In effect, the most sensible way I see forward is trusting our developers to the right things by formally lifting the moratorium entirely and still asking them to be careful about what they do. Then we could have a living document (not authored by CTTE) describing what careful means precisely. With dumat being in operation as a detection mechanism (though not yet performing unsupervised RC bug filings), we've got the means to see what goes wrong at least. Does this make sense to you? Do you have other thoughts on how to move forward on the CTTE side? Practically, lifting the moratorium means that the CTTE relinquishes control of the /usr-merge transition to whoever drives the transition, i.e., maintains that living document and thereby makes decisions on how to proceed. Who is this going to be? Do you, Helmut, feel comfortable as driver? Do you prefer if the Release Team takes over with you in an advisory role? If you continue as main driver, should the DPL formally delegate that role somehow? I think these are questions we need answered, because it would be advisable to have someone with clearly defined responsibilities at the wheel for the transition. Otherwise, we risk stale-mating ourselves with endless debates on how to finish the transition "properly". Cheers Timo -- ⢀⣴⠾⠻⢶⣦⠀ ╭╮ ⣾⠁⢠⠒⠀⣿⡁ │ Timo Röhling │ ⢿⡄⠘⠷⠚⠋⠀ │ 9B03 EBB9 8300 DF97 C2B1 23BF CC8C 6BDD 1403 F4CA │ ⠈⠳⣄ ╰╯ signature.asc Description: PGP signature
Re: Lifting the moratorium
Hi Helmut (2023.08.25_11:40:33_+) > You see that this goes into very much detail and having the CTTE decide > upon the precise way of lifting this seems suboptimal. That would amount > to micro-managing the transition. In effect, the most sensible way I see > forward is trusting our developers to the right things by formally > lifting the moratorium entirely and still asking them to be careful > about what they do. Then we could have a living document (not authored > by CTTE) describing what careful means precisely. With dumat being in > operation as a detection mechanism (though not yet performing > unsupervised RC bug filings), we've got the means to see what goes wrong > at least. Yeah, that sounds reasonable to me. It's obvious that we have to lift the moratorium at some point soon, and it doesn't really make sense for us to have to vote on each stage of lifting it. With you actively working on pushing /usr-merge forward, you're in a position to coordinate some of the next steps (to the degree that maintainers follow your advice). We are in a very different position now (with dumat in place and a concrete plan) than we were in when the moratorium was first imposed. But I'm interested to see if there are other approaches suggested. Stefano -- Stefano Rivera http://tumbleweed.org.za/ +1 415 683 3272
Lifting the moratorium
Hi, after bookworm, we extended the moratorium, because we saw that lifting it would cause problems. We have a better understanding of those problems now and are into preparations for actually moving files. I'd like to initiate a discussion on how the moratorium is to be lifted. DEP17 tells us about known problem classes. Let me go through them with a focus on how they interact with the moratorium. P1 file loss due to concurrent canonicalization and move. The moratorium currently prevents this. There is little we can do about this class before lifting the moratorium as the intention is to mitigate this case by case by upgrading Replaces to Conflicts (M7) or employing protective diversions (M8). I note that since bookworm no packages have been restructured in a way that would cause an immediate P1 problem for systemd units just yet. P2 ineffective trigger interest This is not mitigated, but the moratorium keeps the practical effects low. Patches for all affected packages in Debian have been filed. They should be upgraded to RC severity before lifting the moratorium. The only two instances not yet fixed in unstable are #1043419 and #1043420. P3 ineffective diversions The moratorium currently prevents this. We don't quite have agreement as to whether this should be mitigated centrally (by doing something to dpkg-divert M6) or decentrally (by duplicating all of the diversions in packages M18). If the decentral approach is chosen, we will handle this case by case. I note that since bookworm, there are no P3 instances for systemd units left. P4 disagreeing alternatives The moratorium currently prevents this and the idea is that we continue to use aliased paths for update-alternatives where they already are used in such a way (M13). P5 ineffective dpkg-statoverride The moratorium currently prevents this, but this is an aspect that maintainers will have to handle on a per-package basis anyway. P6 Empty directory loss This is not prevented by the moratorium, but lifting it will make it worse. Bugs for all current issues have been filed and as packages move, there will likely be five more instances. The idea is to handle them case by case. P7 Shared multiarch file loss This is prevented by the moratorium. Lifting is likely to spawn a two-digit number of such losses. Thus far, the idea is to handle these case by case using protective diversions (M10). I note that no systemd units are currently affected by this problem though a number of udev rules will be. P8 bootstrapping The moratorium currently keeps bootstrapping working. debootstrap in trixie is forwards compatible with what we're heading to. Moving files in transitively essential packages from / to /usr is prone to breaking mmdebstrap or cdebootstrap though. As such a limited moratorium should be retained for now. P9 Loss of aliasing links The moratorium currently prevents them from being lost. Once large amounts of packages are converted, aliasing symlinks may vanish. Such a failure is prone to making end user systems unbootable. As long as essential packages are not converted, this cannot be practically experienced. P10 debian-installer The debian-installer is still unmerged. If the moratorium were lifted, files could move to /usr (even in udebs) and thereby break the installer. There is a MR trying to make it use a merged layout. Beyond the numbered problems, keep in mind that buildds are not yet /usr-merged. This also depends on a SPU of debootstrap for bullseye. Takeaway If you read through this list, we should recognize two recurring ideas. Much of the preparation has been done or initiated and what's left in large part is doing mitigations after having lifted the moratorium. Lifting the moratorium isn't exactly boolean. More than half of the packages that ship files in aliased locations only do so due to containing a systemd unit. For essential packages, we want to do the conversion at a later time. This gives rise to the question of how to lift the moratorium. I suggest that simply saying "no moratorium anymore" is prone to causing breakage. Lifting the flood gates could cause uncontrollable fallout. A more sensible approach could be lifting it for certain categories (e.g. systemd units once debhelper is updated to recognize units below /usr) or performing targeted uploads specifically aimed to resolving the resulting problems (e.g. canonicalizing specific m-a:same packages while simultaneously adding the necessary diversions or canonicalizing packages containing dpkg-statoverrides while specifically handling them). You see that this goes into very much detail and having the CTTE decide upon the precise way of lifting this seems suboptimal. That would amount to micro-managing the transition. In effect, the most sensible way I see forward is trusting our developers to the right things by formally lifting the moratorium entirely and still asking them to be careful about what they do. Then we could have a livin
