casey@lll-crg.llnl.gov (Casey Leedom) (01/13/89)
I hope you're all as tired seeing all those stupid contrib patches go by as I was making them. You'll note that most of the patches were trivial, many involving a missing three line Imakefile. I'll reiterate my suggestion here: it is my firm recommendation that the X Window System project reject out of hand any contributed software that doesn't have an Imakefile and compile relatively trivially on at least *some* system. Casey
jim@EXPO.LCS.MIT.EDU (Jim Fulton) (01/14/89)
> > I'll reiterate my suggestion here: it is my firm recommendation that > > the X Window System project reject out of hand any contributed software > > that doesn't have an Imakefile and compile relatively trivially on at > > least *some* system. > > I am not one to *flame* anti-social net.bevahiour, but I feel compelled to > do so this time. First off, you're flaming the X Consortium As one of the people foisting imake on the world, I can assure you that no heat was felt at this end. While his manner of distribution left something to be desired, it was useful. I strongly urge people to use imake. Casey's conditions, couched in less draconian wording, were almost the requirements for R3.... We will probably be pickier in R4 than we were in R3. Jim Fulton MIT X Consortium
casey@lll-crg.llnl.gov (Casey Leedom) (01/14/89)
| From: Isaac <salzman@rand.org> | | > I'll reiterate my suggestion here: it is my firm recommendation that | > the X Window System project reject out of hand any contributed software | > that doesn't have an Imakefile and compile relatively trivially on at | > least *some* system. | | I am not one to *flame* anti-social net behavior, but I feel compelled to | do so this time. First off, you're flaming the X Consortium and those that | contributed the software for not being able to just type "make" and have | everything work. I'm sorry, it certainly wasn't intended as a flame. I have complemented the X Consortium several times on the quality of their software engineering. I believe that I complemented them in the message quoted as a matter of fact. In any case, I'm sorry if you took it as a flame. | The X Consortium is not obligated in any way shape or form to even | distribute the contributed software, and the people that created it are | not obligated to make it available to the rest of us. What would you | prefer, having software that takes a little extra time and effort to | build, or not having it at all? I think the gains out weigh the losses | by a wide margin. I'd have to say I'd prefer not to have the software. Bad software is worse than no software in my mind. It wastes my time trying to install it and it wastes everyone's time trying to use it. The general quality of the Free Software that's available is not good. And the terrible thing about it is that most of the faults are trivial things that should be one of the first things dealt with (installation configuration, targetting, and documentation as well as general documentation). I would dearly like to see this situation change. No, the X Consortium is not bound to distribute any contributed software. And I think they should use that freedom to save themselves and everyone else's time by refusing to bundle badly set up software. They have done an incredible job with regard to their own software engineering efforts and have provided the tools for others to do as well with their contributions. | Secondly, you yourself are doing exactly what you're accusing other people | of doing, poorly distributing software (or patches in this case). Each one | in a separate message, some are just the contents of an Imakefile not even | in shar format, some are context diffs, some are shar files. | | Lastly, there is a Newsgroup for the sole purpose of distributing X | sources: comp.sources.x. You're right and I'm sorry. I mentioned in the message that you quoted that I didn't feel the effort was worth it in the end. I probably should have stuck with my original decision not to post any of my contrib fixes. On the other hand, I think that having the messages each apply only to a single application was a good idea. You can use your mailer to delete or keep messages as they apply to packages you're interested in. Casey
bzs@Encore.COM (Barry Shein) (01/15/89)
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 <X11/Atoms.h> to <X11/StringDefs.h> 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.
david@torsqnt.UUCP (David Haynes) (01/15/89)
In article <8901131940.AA06450@EXPO.LCS.MIT.EDU: jim@EXPO.LCS.MIT.EDU (Jim Fulton) writes:
:
: > I'll reiterate my suggestion here: it is my firm recommendation that
: > the X Window System project reject out of hand any contributed software
: > that doesn't have an Imakefile and compile relatively trivially on at
: > least *some* system.
:
:
:As one of the people foisting imake on the world, I can assure you that no heat
:was felt at this end. While his manner of distribution left something to be
:desired, it was useful. I strongly urge people to use imake.
:
:Casey's conditions, couched in less draconian wording, were almost the
:requirements for R3.... We will probably be pickier in R4 than we were in R3.
If we are all going to start adding imakefiles to the system, can
we at least take a second or two to indicate where in the source
tree these new clients are to reside?
Somebody posts the source for, say, xpostit. Is that in contrib/clients?
contrib/demos? clients? Where?
Normally I would assume contrib/clients, and then back up one level and
change the imakefile in contrib, but, these days its getting really
confusing. (Is maze a client or a demo? I have to run it to find out!)
Also, does anyone have a shell for running imake in a totally random
location (ie: one where the ../../../ stuff is meaningless?) I like
to compile the clients well away from my "protected" X source area
in case someone decides to post a nasty or the code does not work on
my architecture. Currently, I have been editing the Makefile (not
the Imakefile) to link -lX11 but this is tedious.
-david-