>>>>> "Russ" == Russ Allbery <r...@debian.org> writes:
Russ> Helmut Grohne <hel...@subdivi.de> writes: Russ> What Sam is trying to Russ> say, I think, is that a different phrasing offers a way to Russ> avoid that discussion and agree to disagree on the best Russ> architecture in the abstract by pointing out an additional Russ> constraint: how long we're willing to wait and how Russ> uncomfortable we're willing to make things for ourselves to Russ> try to force the dpkg changes to appear. Exactly. For example, in response to my rephrasing Helmut asserted (correctly of course) that there is no patch ready today. If we go down that road, we can repeat the discussion about whether the politics are a significant factor in why we have no patches today. I appreciate Helmut has a strong position on that issue, but some of us disagree with Helmut strongly on that point. BUT I don't think it matters. If we have a consensus we're unwilling to wait for a patch, it doesn't matter whether that's because: 1) Some of us think the patch would be a bad idea 2) Some of us think the patch will not happen because of politics 3) Some of us think the patch won't happen because no one cares enough to write it 4) Some of us think the patch will eventually get done 5) Some of us think the problem is too constrained and if we really wanted to make progress we could incrementally move toward it. Helmut effectively asked us to agree with 1. And I don't think there is a consensus on this. ---------------------------------------- I have reviewed the DEP 17 draft at https://subdivi.de/~helmut/dep17.html Helmut asked for consensus on the problems and mitigations or at least I think he did. I think we don't need that. I think we need consensus on decisions and confirmation that everyone feels heard. WRT the problems, I confirm that the list of problems does (in my reading) accurately describe the problems people have brought up. I don't think we have (or should try to get) a consensus on which problems need to be fixed except in so far as that affects our consensus on a proposal. I will admit that even though I've followed the discussion fairly closely, I don't have a good feeling about the mitigations. I think that once a reasonable set of the mitigations have been applied, we'll be in a reasonably good place. My concern is about upgrades and about unstable. I would like to see a set of instructions that I could follow for moving files in my packages in the data.tar to their canonical locations. I'd like instructions that clearly allowed me to reason about upgrades, and about how my packages interact with other packages during the transition. Because several of the problems look kind of serious, and my reading of the mitigations is that hey, by the time we get done, it'll all be okay. Implicit is the idea that because of the moratorium these problems are rare. Except during the transition, there will be no moratorium, so perhaps these problems will not be rare. There are two many mitigations, and the interactions matter for me to think about safety. Proposed way to address this concern: A) Develop a proposal assuming no dpkg changes for moving files too canonical locations in data.tar. Assume bootstrap protocol 3B (assume bootstrap creates the initial symlinks). I will talk about expanding to bootstrap protocol 3C in a bit. B) Develop an argument for the safety of that proposal. C) Let's review and agree to that. D) Then think about bootstrap protocol 3C; see below. ---------------------------------------- Regarding bootstrapping. I think Helmut and Josh have convinced me that my proposal for bootstrap protocol 3B is viable. We could do that if we want to. I do not find having more complexity for bootstrapping pre-stretch, or for having the bootstrap tools be required to have a bit of special knowledge to be blocking bugs. If we could make 3C work, I would not object to it. I think Josh has argued that 3C is a nice to have--some day. I do not see an argument that 3C is safe though. Luca is right that if it breaks unstable or breaks upgrades, it will be really bad. So I think that to argue for 3C you need a specific proposal about what happens. And you need a really strong argument that implementing that proposal is safe for upgrades and safe during the transition. It sounds like part of the argument of safety during transitions is that you will coordinate with ftpmaster to do some essential packages in lock-step. If you can show why that can be implemented and is safe, that's fine. But because we have another option (3B) that is viable, the safety argument needs to meet a high bar. If people like Luca are saying they are not convinced after reading it, even if they cannot articulate specific concerns, I would consider that blocking. Put another way. We have to do something about moving most data to canonical paths. We need a safety argument for that of course. The review criteria there would be at least some people have said "yeah, I review, understand and it looks good." But to block, someone needs to have a concrete issue to resolve. But for the safety argument for bootstrapping 3C, having someone who is familiar with the issues, has read the safety argument, and says they have a bad feeling should be blocking. My current reading of bootstrap consensus is: * I think everyone now agrees 3B is viable. Helmut and Josh explain why they do not prefer that option. * Several people have been convinced by Josh's message that 3C is a nice to have. * Luca thinks 3C is too risky to support. I think he's close to in the rough on going that far. * I agree with Luca that 3C has risk and complexity, but am willing to consider a safety argument. * If a few more people write in and support Luca's position, you may have a very rough consensus that 3C is too risky even given a safety argument. * If you come up with a safety argument that several people read and support you may develop a consensus for 3C.
signature.asc
Description: PGP signature