In article <1992Aug18.173556.17751@athena.mit.edu>, tytso@ATHENA.MIT.EDU (Theodore Ts'o) writes: | | From: davidsen@ariel.crd.GE.COM (william E Davidsen) | Date: 18 Aug 92 13:51:35 GMT | | At the risk of sounding as if I'm complaining, I think the "phase | errors" betweeen the ps, kernel, and gcc packages is getting to be | enough hassle that the various maintainers should get together and agree | on something and stick to it. Evertime a new version of one comes out, | it seems to be a huge hassle getting it to work with the other two. | | Don't take the newest version then! Stick with 0.96c, and don't take a | new version until it's become fully stable. After all, that's what | Asking Linus, et. al to "stick to it" would mean freezing kernel | development. It would mean abandoning new changes to eliminate the 64 | process limit, and to make V86 emulation mode simpler to implement. | That would be a Bad Thing. Having done a good bit of distributed development over the years has convinced me that this is one place where a little good software engineering practice is important. We are talking about three people (or groups) promptly sharing changes to the header file. People who are in fast communication via network. It doesn't take much to send a diff back and forth, or even have one person be the keeper of the headers, as we have a coordinator of info-zip, a distributed project if ever there was one. That way when a new item is added to a header file, the other groups can immediately see the change, and either fix incompatibilities, or ask the originator of the change to provide a name change to avoid conflicts. In most cases it's as simple as two groups both adding things to the headers, which a set of diffs would fix and leave all groups playing with the sam headers. Sorry if I can't agree that a simple coordination "would mean freezing kernel development." I am pretty sure it would save more time than it took, helping or at least not hindering the people doing the development, and it would certainly avoid having every person who packages a Linux release do their own, often incompatible, header munging. That would be a good thing for Linux development indeed! -- bill davidsen, GE Corp. R&D Center; Box 8; Schenectady NY 12345 I admit that when I was in school I wrote COBOL. But I didn't compile.
| Rene Herman | [PATCH] x86: provide a DMI based port 0x80 I/O delay override |
| Greg KH | [02/50] DVB: get_dvb_firmware: update script for new location of sp8870 firmware |
| Linus Torvalds | Linux 2.6.26-rc4 |
| Daniel Walker | Re: [PATCH 3/3] net: wireless: bcm43xx: big_buffer_sem semaphore to mutex |
git: | |
| Junio C Hamano | Re: [RFC] Cache negative delta pairs |
| Stefan Richter | Re: [kernel.org users] [RFD] On deprecating "git-foo" for builtins |
| Martin Langhoff | Handling large files with GIT |
| David Symonds | Re: git and binary files |
| Rémi Denis-Courmont | [PATCH 09/14] Phonet: allocate and initialize new sockets |
| David Miller | [GIT]: Networking |
| David Miller | Re: sockets affected by IPsec always block (2.6.23) |
| Stephen Hemminger | Re: [PATCH 1/2] IPV4: remove addresses and routes when carrier is lost |
| Richard Stallman | Real men don't attack straw men |
| Leon Dippenaar | New tcp stack attack |
| Chris Tankersley | Dell PERC 3/Di - No Disks Found |
| Anselm R. Garbe | OpenBSD 4.0 / Xorg -> vesa 1920x1200 widescreen resolution |
