>>>>> "Russ" == Russ Allbery <rra@debian.org> writes:
Russ> Helmut Grohne <helmut@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.
Attachment:
signature.asc
Description: PGP signature