Christos Zoulas wrote:
> On Jun 24,  7:57pm, e@murder.org (Elad Efrat) wrote:
> -- Subject: Re: CVS commit: src/sys
> 
> | > The only reason the 16 group limit was brought up is because dsl's new
> | > functions hide it inside kauth, whereas before it was exposed. Since the
> | > limit is not visible anymore, it is conceivable that it will be easier
> | > to remove the limit in the future.
> | 
> | you know very well that the 16 group thing is a side effect and not a
> | goal of dsl's changes. I think you are trying to justify the commit
> | after the fact, rather than focus on the issue that kauth is now broken
> | because of it.
> | 
> | that is unprofessional, weak, and I'm disappointed that this is what you
> | choose to do.
> 
> I don't understand why you choose to interpret what I wrote this way. I just
> tried to explain that "the only reason the 16 group limit was brought up"
> which means that the 16 group limit was not the focus of the change, it was
> a side effect as you say above. 
> 
> | like I said, there are two issues here that are orthogonal: simplifying
> | the compat code, and removing the 16 group limit. if the 16 group limit
> | is suddenly the biggest problem for netbsd (ridiculous), please back out
> | the changes and start a thread pointing out:
> | 
> |    - why it is a problem,
> |    - how you solved it in the past 20 years,
> |    - why it has become so critical as of yesterday,
> |    - why exposing kauth internals is the only way to solve it
> 
> I don't care to solve the 16 group limit right now this is why I wrote:
> "it is conceivable that it will be easier to remove the limit in the future."
> As for exposing kauth internals, I don't like that and I would like to fix it.
> 
> Did you read what I wrote, or you just decided to reply without reading?

I did. I think you, dsl, and anyone else who claims the limit is not
visible anymore is not very familiar with the associated code. :)

> | > | and, I'm asking again: why didn't the changes in question go up for
> | > | public discussion? and assuming they would have, what do you think would
> | > | be the consensus?
> | > 
> | > Because this is not a perfect world. In retrospect they should have. 
> | 
> | you *still* avoid answering my question of what you think would be the
> | consensus assuming they would have been discussed. :)
> 
> I don't know what the consensus would have been, but if I had to guess
> this change would have been done differently.
> 
> | > It
> | > is not like we post every diff in tech-* before it gets committed. This
> | > is why we have source-changes; to review the commits and catch issues
> | > like this one and fix them.
> | 
> | then please change the commit guidelines, and make it clear that commits
> | that go into the netbsd tree are not peer reviewed and discussed. this
> | will help people make smarter choices about the operating system they
> | rely on.
> 
> Seriously, instead of flaming each other and spend time replying to e-mail
> we should be thinking about how to fix the problem...

how about investing time in thinking about how to avoid the creation of
problems altogether, so the focus can be purely on advancing forward,
rather than a step forward and two steps back? :)

-e.