Gentoo Developers Unhappy, Fork udev

[log0]

Well on technical matters people that have knowledge on the subject are more likely to tell you the right thing. It's not something like gay marriage or something. I wouldn't listen to airlied for something like ie cooking (don't know if he has any cooking skills, just use it as an example) but if it was something related to linux graphics he would probably be one of the first persons to ask.

This sounds like appeal to authority. Even if someone has knowledge on the subject, what exactly makes you think that he is more likely to tell you the right thing?

[ryao]

The thing is RH doesn't drive developer directions really. I know its probably hard to understand unless you work here.

Its not personal, or blaming Canonical. Its just that people seem to think that the way C work on stuff, with Mark setting the direction is how every company works.

The RH "agenda" is mostly set by what its developer chose to work on. We hire developers because they work on stuff that interests the company and we want them to continue doing so. There isn't some internal memo directing everyone to work on things like systemd, if someone else hired people to work on this stuff to increase the maintainership, we'd be happier a lot of the time. udev was started by a Novell employee, maintained by another Novell employee, the Novell employee moved to Red Hat, the person hasn't changed agenda. When they worked for Novell they worked closely with Lennart, and now they work for RH they work closely with Lennart. RH isn't forcing them to do anything, which is what your posting reads like.

Dave.

Would you elaborate on what you mean by working closely with Lennart? Lennart Poettering's first commit occurred in 2006 and his second commit occurred in 2009. His participation seems to be fairly recent given that udev is 9 years old.

[89c51]

This sounds like appeal to authority. Even if someone has knowledge on the subject, what exactly makes you think that he is more likely to tell you the right thing?

Because he has knowledge. You wouldn't trust your grandmother on something computer related would you?.

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.

[ryao]

+1

A quote from http://thread.gmane.org/gmane.linux....26/focus=81281:



A thread on Google+ about this, started by Lennart Poettering:
https://plus.google.com/115547683951...ts/dARyF4UbXzf

Most who responded to the g+ thread above, agree that removing the previous copyright notices is not right.

Copyright notices remained intact in all commits pushed to any branch in the repository. The issue that gregkh had was that a developer who did not understand how copyright notices worked used a branch to propose the addition of Gentoo Foundation copyright notices to various files. This does not constitute removal.

If anyone believes that copyright notices were removed, I would like to see solid evidence to collaborate those beliefs. Otherwise, such accusations are nonsense.

[Fenrin]

Copyright notices remained intact in all commits pushed to any branch in the repository. The issue that gregkh had was that a developer who did not understand how copyright notices worked used a branch to propose the addition of Gentoo Foundation copyright notices to various files. This does not constitute removal.

If anyone believes that copyright notices were removed, I would like to see solid evidence to collaborate those beliefs. Otherwise, such accusations are nonsense.

ok fair enough! Some people interpreted his sentence "None of those conditions included keeping the copyright line intact." that some Gentoo developers would like to remove certain Copyright notices. So this was probably a misunderstanding then.

[TheBlackCat]

This sounds like appeal to authority. Even if someone has knowledge on the subject, what exactly makes you think that he is more likely to tell you the right thing?

Appeal to authority is not always a fallacy. Trusting relevant experts on a subject we do not know enough about to make an informed opinion is not a fallacy. See The Fallacy Files entry on the subject.

[AdamW]

Appeal to authority is not always a fallacy. Trusting relevant experts on a subject we do not know enough about to make an informed opinion is not a fallacy. See The Fallacy Files entry on the subject.

It's basically a domain problem. The concept that 'an appeal to authority is a fallacy' is a concept from the realm of strict logic-based argumentation, the kind of stuff you learn in philosophy class. If you are attempting to have a rigorous logic-based debate about a specific idea or argument with someone, then you can whack them with the 'appeal to authority' bat if they start saying stuff like 'well, Aristotle said X, so it must be true'. In the context in which you're operating, that is a fallacy.

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'.

[AdamW]

Would you elaborate on what you mean by working closely with Lennart? Lennart Poettering's first commit occurred in 2006 and his second commit occurred in 2009. His participation seems to be fairly recent given that udev is 9 years old.

Kay, who maintains udev, works closely with lennart, who maintains systemd, in the areas where the two components overlap.

[AdamW]

Oh, come on. It was just a pull request from a dude who did it without understanding the implications. It wasn't even accepted afaik and I don't see how this would make "Gentoo as awhole look bad". All I see is a few dudes being seriously pissed due to the fork and looking for something to bitch at. Which is kinda entertaining on its own.

the fact of a fork doesn't make Gentoo as a whole look bad, but the fact that it's a fork by a bunch of guys who clearly don't have a clue what they're doing did make Gentoo as a whole look bad for a bit. And probably still does to those who don't understand that it isn't really an official Gentoo-blessed project, just a small group of Gentoo devs.

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.

[ryao]

the fact of a fork doesn't make Gentoo as a whole look bad, but the fact that it's a fork by a bunch of guys who clearly don't have a clue what they're doing did make Gentoo as a whole look bad for a bit. And probably still does to those who don't understand that it isn't really an official Gentoo-blessed project, just a small group of Gentoo devs.

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.

eudev is "an official Gentoo-blessed project", but I do not think that you understand what that means. Unlike developers in other organizations, any Gentoo developer can start a project for any reason. It does not need approval and it is as official as any other project. eudev would have been almost certainly developed behind closed doors for the first few months of its existence had it been a RedHat project. If I recall, your company did that with KVM. Your company also makes it difficult for independent review of changes its makes to GPL code in monolithic patches. If it weren't for Oracle's RedPatch (which is awesome), it would be impossible for most of us to audit your company's changes. When RedHat doesn't provide monolithic patches, we see single line commit messages in pull requests to various projects. The only exception to this that I have seen is Linus' tree, where Linus rejects pull requests containing such commit messages.

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.