home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #18 / NN_1992_18.iso / spool / comp / os / linux / 8604 < prev    next >
Encoding:
Internet Message Format  |  1992-08-19  |  2.8 KB
  1. Path: sparky!uunet!crdgw1!rdsunx.crd.ge.com!ariel!davidsen
  2. From: davidsen@ariel.crd.GE.COM (william E Davidsen)
  3. Newsgroups: comp.os.linux
  4. Subject: Re: header woes with 2.2.2d
  5. Message-ID: <1992Aug19.124649.206@crd.ge.com>
  6. Date: 19 Aug 92 12:46:49 GMT
  7. References: <1992Aug18.173556.17751@athena.mit.edu>
  8. Sender: usenet@crd.ge.com (Required for NNTP)
  9. Reply-To: davidsen@crd.ge.com (bill davidsen)
  10. Organization: GE Corporate R&D Center, Schenectady NY
  11. Lines: 44
  12. Nntp-Posting-Host: ariel.crd.ge.com
  13.  
  14. In article <1992Aug18.173556.17751@athena.mit.edu>, tytso@ATHENA.MIT.EDU (Theodore Ts'o) writes:
  15. | 
  16. |    From: davidsen@ariel.crd.GE.COM (william E Davidsen)
  17. |    Date: 18 Aug 92 13:51:35 GMT
  18. | 
  19. |      At the risk of sounding as if I'm complaining, I think the "phase
  20. |    errors" betweeen the ps, kernel, and gcc packages is getting to be
  21. |    enough hassle that the various maintainers should get together and agree
  22. |    on something and stick to it. Evertime a new version of one comes out,
  23. |    it seems to be a huge hassle getting it to work with the other two.
  24. | 
  25. | Don't take the newest version then!  Stick with 0.96c, and don't take a
  26. | new version until it's become fully stable.  After all, that's what
  27.  
  28. | Asking Linus, et. al to "stick to it" would mean freezing kernel
  29. | development.  It would mean abandoning new changes to eliminate the 64
  30. | process limit, and to make V86 emulation mode simpler to implement.  
  31. | That would be a Bad Thing.
  32.  
  33.   Having done a good bit of distributed development over the years has
  34. convinced me that this is one place where a little good software
  35. engineering practice is important. We are talking about three people (or
  36. groups) promptly sharing changes to the header file. People who are in
  37. fast communication via network.
  38.  
  39.   It doesn't take much to send a diff back and forth, or even have one
  40. person be the keeper of the headers, as we have a coordinator of
  41. info-zip, a distributed project if ever there was one. That way when a
  42. new item is added to a header file, the other groups can immediately see
  43. the change, and either fix incompatibilities, or ask the originator of
  44. the change to provide a name change to avoid conflicts. In most cases
  45. it's as simple as two groups both adding things to the headers, which a
  46. set of diffs would fix and leave all groups playing with the sam
  47. headers.
  48.  
  49.   Sorry if I can't agree that a simple coordination "would mean freezing
  50. kernel development." I am pretty sure it would save more time than it
  51. took, helping or at least not hindering the people doing the
  52. development, and it would certainly avoid having every person who
  53. packages a Linux release do their own, often incompatible, header
  54. munging. That would be a good thing for Linux development indeed!
  55. -- 
  56. bill davidsen, GE Corp. R&D Center; Box 8; Schenectady NY 12345
  57.     I admit that when I was in school I wrote COBOL. But I didn't compile.
  58.