Path: utzoo!attcan!uunet!lll-winken!ames!mailrus!purdue!bu-cs!encore!bzs From: bzs@Encore.COM (Barry Shein) Newsgroups: comp.windows.x Subject: Re: All that stupid contrib stuff Message-ID: <4665@xenna.Encore.COM> Date: 14 Jan 89 22:38:00 GMT References: <8901131807.AA12344@rand.org> <8901131940.AA06450@EXPO.LCS.MIT.EDU> Organization: Encore Computer Corp, Marlboro, MA Lines: 48 In-reply-to: jim@EXPO.LCS.MIT.EDU's message of 13 Jan 89 19:40:43 GMT Posting-Front-End: GNU Emacs 18.41.15 of Tue Jun 9 1987 on xenna (berkeley-unix) My 2c I certainly appreciate the contrib stuff but I did see one problem that was unavoidable without some change in the distribution practices. A lot of the software released with the R3 tape did not work with R3 due to changes from R2. The reason is obvious, the contrib developers did not have R3 prior to the contrib release (in general, perhaps some had an early release.) Many of the problems were minor (eg. if I change one more reference from to I will spit), others deeper (witness some of the extensive patches that came along after a while.) I suppose the only solution is to split the contrib and core releases into two tapes and begin accepting the contributions some time after the new release is widely available and ask that software be tested on the new release already. The problems I see are two-fold: First, dealing with a second tape might be unmanageable or otherwise undesirable to the Consortium (understandable, but only they can respond to that issue.) Second, for some window (ahem) people putting up the new release will probably feel the strong temptation to port R-1 contrib software themselves which sort of leaves them in the same boat as before. All I can say to that is that "you can spot the pioneers, they're the ones with the arrows in their backs..." I would guess at this point the vast majority of contrib software will stay BINARY (ie. protocol) compatible for at least one release so perhaps this will be less of a problem in the future. As it stands I get this sinking feeling a few dozen of us have done the same porting jobs over and over again (would it really have been useful for me to post every place that Atoms.h->StringDefs.h*??) Staggered distributions seems to be the obvious solution, barring some unforeseen objection. -Barry Shein, ||Encore|| * Yes, I considered symlinking the file name and it does work but I wanted to just clean it up once and for all.