Gentoo Developers Unhappy, Fork udev

[kigurai]

I still do not understand what is special about GNOME that the GNOME developers feel it necessary to try to force a dependency. They are just giving downstream developers more work to do.

They force dependencies on you all the time, just like all other projects. In this case, it happens to be a dependency that you disagree with.
Yes, I know it "would make GNOME Linux only", but there are some points to consider:
1) Isn't that the de facto case already?
2) The dependency is IIRC on the systemd interface, meaning that you can replace it with other software that provides the same functionality.

[ryao]

I think they plan to support the systemd features but keep some sort of compatibility with systemd free system . But I suppose "solid" needs systemd support first?

I still do not understand what is special about GNOME that the GNOME developers feel it necessary to try to force a dependency. They are just giving downstream developers more work to do.

[Akka]

I am not involved with QEMU maintenance. I suggest that you contact Doug Goldstein for details.

As for systemd, why is it that the GNOME project feels that mandatory dependence on such features is necessary when the KDE project does not? The KDE project seems to have no trouble writing cross platform compatible code. The only instance in which KDE fails to be cross platform involves Network Manager, which is Linux specific. As far as I know, Network Manager is developed primarily by RedHat employees.

I think they plan to support the systemd features but keep some sort of compatibility with systemd free system . But I suppose "solid" needs systemd support first?

[ryao]

As an additional note, I am putting the finishes touches on the kmod work. There are a few additional things that I want to address, but it will be back in HEAD soon.

[ryao]

okay, I already tried this once, but this is way off into the weeds, and I'm not interested in a bash fest. either we get back on the topic of udev or I'm out.

I cannot imagine having a productive conversation with you about eudev until we do our first tag. We are a few weeks away from that. Lets talk then.

[AdamW]

okay, I already tried this once, but this is way off into the weeds, and I'm not interested in a bash fest. either we get back on the topic of udev or I'm out.

[ryao]

Okay, I should qualify that somewhat. Oracle's contributions are significantly smaller than RH's - or, indeed, for instance, SUSE's, or many other projects, even non-commercial ones. And Oracle contributes nothing significant to the development of the precise codebase they ship, i.e. RHEL.

Their Linux port of DTrace seems useful. RedPatch is also rather nice.

With that said, I do not think RedHat gives Oracle much opportunity to contribute to RHEL development. That could change if RedHat were to adopt Canonical's practices of giving commit privileges to people outside their organization and having an open bug tracker.

[ryao]

I have to say that's the first I've heard of any such concerns with qemu. Have these been documented on the appropriate lists? Use of systemd by GNOME has nothing much to do with 'Red Hat influence' and everything to do with the fact that systemd provides capabilities of which GNOME wishes to make use. The whole point of systemd is to provide capabilities that sysv does not provide, after all. If it didn't, there'd be no point to its existence.

I am not involved with QEMU maintenance. I suggest that you contact Doug Goldstein for details.

As for systemd, why is it that the GNOME project feels that mandatory dependence on such features is necessary when the KDE project does not? The KDE project seems to have no trouble writing cross platform compatible code. The only instance in which KDE fails to be cross platform involves Network Manager, which is Linux specific. As far as I know, Network Manager is developed primarily by RedHat employees. They seem to only care about Linux (and quite possibly, only RedHat's version of it). This causes headaches for us because Gentoo encompasses more than just Linux. Unfortunately, our teams dedicated to non-Linux things lack the man power necessary to address that issue.

With that said, Gentoo has its own cross platform solution called OpenRC that runs on top of sysvinit. I do not think that we would be having this conversation had OpenRC been incorporated into Fedora instead of Upstart.

[AdamW]

Last I checked, Oracle still employed people working on X, btrfs, and gcc. Has this changed?

Okay, I should qualify that somewhat. Oracle's contributions are significantly smaller than RH's - or, indeed, for instance, SUSE's, or many other projects, even non-commercial ones. And Oracle contributes nothing significant to the development of the precise codebase they ship, i.e. RHEL.

[AdamW]

I am tired and I appear to have missed this comment. I must thank curaga for highlighting it.

I think that there is an argument to be made the RedHat's involvement in the community causes damage. RedHat has no qualms about sending poorly tested patches upstream and letting the community fix the problems that they cause. I am told by developers on our virtualization team that this is exactly what RedHat has been doing with QEMU and that upstream QEMU was removed from our tree because of it. The increasing dependence of GNOME on systemd is another instance of damage that RedHat's influence has had. It has forced Gentoo, FreeBSD and numerous others to try to fix the damage. I started the eudev project because I noticed changes that RedHat employees have made to udev are harming our tree. There are likely other examples, but three should be sufficient.

The community would be better off if RedHat only contributed production ready changes. That would dramatically reduce the number of commits that Redhat employees make to various projects. However, many of us feel that RedHat is wasting our time on experimental patches and we would appreciate it if Redhat would stop doing things that make us feel that way. Forks such as eudev are what happen when Redhat's QA standards for upstream contributions annoy enough people.

I have to say that's the first I've heard of any such concerns with qemu. Have these been documented on the appropriate lists? Use of systemd by GNOME has nothing much to do with 'Red Hat influence' and everything to do with the fact that systemd provides capabilities of which GNOME wishes to make use. The whole point of systemd is to provide capabilities that sysv does not provide, after all. If it didn't, there'd be no point to its existence.