----- Original Message ----- > On Tue, Sep 23, 2014 at 01:55:09PM -0400, Kay Sievers wrote: > > ----- Original Message ----- > > > > We are not applying this patch now. It introduces a complete new > > > > scheme and we do not want to extend the current SCSI code, we only > > > > fix obvious bugs. > > > > > > Fine with me, however not sure what our story should be for years to come > > > regarding SCSI stuff downstream. > > > > Simple as: Don't add new features to systemd/udev, only fix bugs. > > > > SCSI code needs to be maintained by someone who understands it and is > > capable and willing to maintain it in the long run. Systemd/udev > > maintainers lack the experience and cannot do that. > > > > New features need to happen in an existing or new storage related-package > > and not in the systemd/udev code base. > > Systemd+udev are supposed to be about providing a fairly complete > basic environment.
No, it is absolutely not. Things like enterprise storage technology is for sure not part of our task. We focus on the basic operating system tasks only. > I don't see why an exception should be made for SAS > disks. If necessary, we can bring additional people in, or maybe just > wait for patches. No, we don't. We will move this out to an external package. > This seems like a better solution than waiting for > a project to be created to create and maintain a tiny amount of code > and one line of udev rules. It is not tiny. It is complicated and has a long history of forth and back. Systemd/udev is just the wrong place to maintain it. > I think that the failure mode is especially ugly here: if you have the > hardware, but don't install this mythical extra package, systemd/udev > provides one set of "stable" names. Then you install the extra > package, and you get a different set. That is how *features* work, they require extra packages. SCSI, SAS, LVM, MD, enterprise storage, ... is _not_ part of systemd's task and should be maintained separately. > > > Kay, any serious objections to applying only > > > downstream for RHEL? > > > > Well, the currently created links will go away and potentially break > > existing users. Not sure what is acceptable here. I personally would > > not apply it to any released product. > Right, so applying the patch as is is probably not OK. But we could provide > the old names as an additional alias. This should be doable. Nope, no new features. Upstream systemd/udev will not apply or ship it. A new place in an externally maintained package is needed to add/improve the current code. Kay _______________________________________________ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
