However in this case its not only one. They are quite a few that came to the position they are not because someone placed them there but because of their merits.
If anyone believes that copyright notices were removed, I would like to see solid evidence to collaborate those beliefs. Otherwise, such accusations are nonsense.
The Fallacy Files entry on the subject.
As you correctly point out, most of us don't actually operate in this domain most of the time. If Dave tells me 'this is how graphics driver development works', it's fine for me to trust Dave. We're not engaged in a strictly logic-based debate about how graphics driver development works, so the concept of 'appeal to authority' just isn't really valid. Unless you spend your entire life trying to ensure that absolutely everything you do has a foundation in rigorous logic-based argumentation, which you probably don't, you should be careful before dismissing things as an 'appeal to authority'.
I mean, they clearly have no clue about copyright law. They say stuff like:
"I am afraid that I have to disappoint you. If we were using the waterfall model, I could outline some very nice long term goals for you, but we are doing AGILE development, so long term goals have not been well defined. Some short term goals have been defined, but I imagine that you are already familiar with them. I suggest asking again after our first tag."
which is a fundamental misunderstanding of what waterfall and agile actually *are*, and more to the point, boils down to 'we refuse to tell you what our plans for udev are and we don't actually really know ourselves, we're just poking stuff it feels like a good idea to poke'. This doesn't seem like a great maintenance plan for a core infrastructure component.
And then they commit stuff like https://github.com/gentoo/eudev/comm...4dc81c0589c8cb , which is just...well, Greg explains: http://thread.gmane.org/gmane.linux....26/focus=81281
A fork of udev in and of itself is not an invalid thing to do. This, however, appears to be a fork maintained by Laurel and Hardy. It is clearly doomed unless it gets taken over by people with clue. I'm not even a developer and I can see that they don't really have any idea what they're doing.
All of the changes to eudev are developed in the open and none of our work is currently considered production ready. I wrote the commit that you cited because the kmod dependency broke things on Gentoo stable (think RHEL6) and keeping it in HEAD was problematic for development. We have observed situations in systemd where things committed to HEAD in systemd are be non-functional when first committed, only to be fixed with additional patches later. You could claim that it would be natural for things to look like this because of how merges work, but when we snapshotted systemd, we obtained a new builtin called hwdb that was clearly broken. It was later fixed in a slew of commits made before the 196 tag. We believe that new features should be introduced to HEAD in after multiple developers have verified it as working, not before. We are working toward a repository in which that is the case. However, we literally just started. I am currently reworking the kmod builtin in a branch. It will be merged after it has been verified to be working well on all target system configurations.
By the way, I see that you are a GNOME developer. Please enlighten us about how the GNOME project would have approached this. I believe that many people would like to know.