>>>>> "Luca" == Luca Boccassi <bl...@debian.org> writes:
Luca> With the provision that I know next to nothing about pam - if
Luca> I understood correctly how it works, why not simply do both?
Luca> Ship the default file in the package under both /usr and
Luca> /etc. Then, you get the semantics you want with local changes
Luca> tracking, and /etc wins over the defaults.
I honestly had not considered this.
It's a bit more tricky than you imply because it's not just pam that is
involved with this but also all pam applications.
We'd have to do active work to get every pam application to ship in both
places.
But as I said I had not considered this, and so it's something that I'm
open to thinking more about.
Luca> And we can have a
Luca> working, bootable Debian container with only /usr.
I'm not actually convinced this is a good thing.
(I don't think it's a bad thing--I just am not convinced it's something
we should be working toward).
I'd rather see project level discussion of this and a decision that is
something we want.
I have significant discomfort aligning what you say (pam is the last
blocker) with what several people said earlier in the week.
What I heard is that there was no project consensus to do this, and that
people were running experiments to see what is possible.
If I make a change in pam and we're suddenly at a place where there are
no blockers and we're moving forward, I think people in the project
would understandably feel disenfranchised.
To bystanders, "we're running experiments to see what's possible," means
a decision is far off.
I feel like if I were to fall in on this, I might be helping cause
something to happen at a technical level, bypassing discussion that I
believe would be healthy for the project.
I appreciate the value of doing work and having people who are willing
to do the work have a larger share of power in the decision making.
And yet I feel like especially for project level things, it's valuable
to present an idea, give people an opportunity to start working on
alternatives, give people an opportunity for their objections to be
heard, and see where we are *before* it's all but done technically.
I think we've not done such a great job of the above in the past. Oh,
we've had the discussions and the flame wars, but I think our past
discussions have had a number of problems in common:
* Because things were effectively close to done technically in the minds
of those driving the change, they had a degree of power that made
others feel disadvantaged and defensive in the discussions.
* Sometimes when people have raised objections, they haven't understood
the goals of people driving change. So while their objections might
in principle be valid, they were not actionable because they didn't
understand what the goals were. We've done a bad job of bringing
those people into the discussion. Doing better would probably be part
clearly articulating why the proposed fix doesn't meet the goals, and
clearly articulating that if the person with the objection will do the
work to understand the goal, then the rest of us will do the work to
bring them into the discussions.
* We have sometimes not done a job of giving people a chance to build
alternatives--somehow saying that we've gotten to a place where there
is interest in some particular goal, and it's serious enough that
people need to either fall in on the plan that currently has momentum
or quickly start putting energy into alternatives. Finding the point
for this is tricky; it's important that if people really are motivated
to find another solution they still have time to do so, but it's also
important to realize that people may not focus on something until they
see that an approach they do not like has momentum. ( Init systems
are not an example where I think we had this problem; people knew that
decision was coming and had a chance to explore alternatives.)
* Sometimes people have walked away from our discussions confused about
the outcome or feeling like their opinion/input was not considered.
We've actually be improving significantly on this lately. I think the
recent usrmerge discussions (say last two years) have been much better
than earlier discussions at considering input and making it clear
where the discussion ended up.
signature.asc
Description: PGP signature
