On 12/20/06, Jan Engelhardt <[EMAIL PROTECTED]> wrote:
>> I've originally thought about util-linux upstream fork, >> but as usually an fork is bad step. So.. I'd like to start >> some discussion before this step. > ... >> after few weeks I'm pleased to announce a new "util-linux-ng" >> project. This project is a fork of the original util-linux (2.13-pre7). > > Well, how about giving me a chunk of it? I'd like /bin/kill please. > I already ship a nicer one in procps anyway, so you can just delete > the files and call that done. (just today I was working on a Fedora > system and /bin/kill annoyed me) How can you ship a "nicer" kill, given that its sole purpose is to accept kill { -l | -t | {-s SIGNUM | -SIGNAME } somepid [morepids] } ?
I checked compatibility with Solaris, Tru64, probably a few BSDs, and man pages of many others. Fedora Core 5 doesn't seem to like this command: /bin/kill -l 17 19 (which reminds me, I need to add sigqueue support and maybe tgkill support)
What about merging util-linux and procps?
How? Which way? As I mentioned before, I was twice disappointed in missing announcements of util-linux maintainership being up for grabs. I certainly have a track record for keeping things stable. Prior to me, procps has a history of being abandoned and broken. Procps is a fork of the long-dead kmem-ps project. Procps was then passed to someone who added color and then disappeared. The prior maintainer picked up the old code again, no doubt under influence of his employer Red Hat. I rewrote much of it then, but had trouble getting in all of my changes. Debian started using my code, which slowly turned into a fork. Maintainership was passed to somebody else, without even telling me. That person and his immediate successor added numerous serious bugs. Inexperience with the code and the lack of a test suite soon led to that group being bogged down in problems. One by one, the various Linux distributions switched over to my version of the code. So as you may imagine, I'd be rather nervous about letting procps get into that situation again. Bugs are yucky. Having multiple committers and no testing is a sure path to ruin. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/