[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Do not plan to support /usr/lib/pam.d for Debian pam

>>>>> "Luca" == Luca Boccassi <bluca@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

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.

Attachment: signature.asc
Description: PGP signature

Reply to: