login
Header Space

 
 

Re: header woes with 2.2.2d

Score:
Previous message: [thread] [date] [author]
Next message: [thread] [date] [author]
Date: Wednesday, August 19, 1992 - 8:46 am

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.
Previous message: [thread] [date] [author]
Next message: [thread] [date] [author]

Messages in current thread:
Re: header woes with 2.2.2d, william E Davidsen, (Wed Aug 19, 8:46 am)
speck-geostationary