In article <15520611-7273-9567-33a4-ff2490b2e...@m00nbsd.net>, Maxime Villard <m...@m00nbsd.net> wrote: >Le 21/12/2019 Ã 00:05, Taylor R Campbell a Ã©crit : >> Security-team is not perfect. We're happy to discuss a better way to >> disable filemon provisionally, and/or how to better address the >> existing users if we are to delete it -- after you do as core asked >> you to do to resolve the interim dispute by restoring the tree. >> >> This is a social process. We can work together to make it better for >> everyone, but you have to be willing to work with the community, >> including accepting rulings by core to resolve disputes. > >I'm afraid you, Taylor, don't have a monopoly on representing the community.
He does represent the community since he represents core. If you are unhappy with core@ talk to board@. If you are unhappy with core@ and board@, get the community to vote for you in the next elections, or get signatures to impeach them. They are the elected leadership of the project. >It just so happens that I, too, as a regular member and also as a main >kernel developer, represent the community; and I don't think the community >is really happy with how secteam disabled filemon without discussion. The >community is likely even less happy with how it was disabled, considering >that a quick discussion has already highlighted two apparent better ways >to disable it. > >It appears that core and secteam failed to work properly with the >community. See above. >To resolve this dispute, I have proposed to revert both my removal, and >secteam's broken disabling. This gives a clear basis to start a discussion >on what to do with filemon exactly. > >Is core fine with that? Or are there double standards at play here? Core has been very clear. They've asked you to revert your commits, not other commits. If they had been unhappy with other commits they would have asked the committers of the other commits to revert them. christos