jik@athena.mit.edu (Jonathan I. Kamens) (04/26/91)
In article <1991Apr25.145012.25954@msuinfo.cl.msu.edu>, elliss@kira.egr.msu.edu (Stew Ellis) writes: |> I think that all posters of any sourcecode ought to |> include complete information on all particulars of hardware and software |> configuration of the systems that they have actually brought the package up |> on, and the difficulty of configuring for the known good targets, then a list |> of suspected or known difficult targets. All packages posted to comp.sources.reviewed will have an introductory posting with certain required information in it. Supported platforms is one of the required sections. Furthermore, the summary of reviewers' comments will probably mention any platforms on which bringing the package up was particular difficult. Perhaps the other source newsgroups can learn something from the new kid on the block. :-) -- Jonathan Kamens USnail: MIT Project Athena 11 Ashford Terrace jik@Athena.MIT.EDU Allston, MA 02134 Office: 617-253-8085 Home: 617-782-0710
kent@sparky.IMD.Sterling.COM (Kent Landfield) (04/26/91)
In article <1991Apr25.201646.13689@athena.mit.edu> jik@athena.mit.edu (Jonathan I. Kamens) writes: >In article <1991Apr25.145012.25954@msuinfo.cl.msu.edu>, elliss@kira.egr.msu.edu (Stew Ellis) writes: >|> I think that all posters of any sourcecode ought to >|> include complete information on all particulars of hardware and software >|> configuration of the systems that they have actually brought the package up >|> on, and the difficulty of configuring for the known good targets, then a list >|> of suspected or known difficult targets. > > Perhaps the other source newsgroups can learn something from the new kid on >the block. :-) This is being done with the Environment: header line in comp.sources.games. The Keywords: line has been used in the past but certain saves from rn can drop the Keywords: header. I have considered using the Environment: line in comp.sources.misc. It would have been useful in this situation had I known the limitation. My questions are one of use. Should the Environment: line be adopted by comp.sources.misc ? This question has probably been answered but I would like to get some additional comments. Next, when should the Environment: header be used ? Always or just when the moderator is alerted to a limiting condition ? Something in between ? Anyone want to take a stab at a list of standard keywords to be contained within this line ? If there is something that I as moderator can do to format the postings to make it easier for the users to deal with then let me know. I don't think that you will get much disagreement from me. We just need to hash out its usage and I will incorporate it into future postings to comp.sources.misc. -Kent+ -- Kent Landfield INTERNET: kent@sparky.IMD.Sterling.COM Sterling Software, IMD UUCP: uunet!sparky!kent Phone: (402) 291-8300 FAX: (402) 291-4362 Please send comp.sources.misc-related mail to kent@uunet.uu.net.
jik@athena.mit.edu (Jonathan I. Kamens) (04/28/91)
In article <1991Apr26.155106.10943@sparky.IMD.Sterling.COM> kent@sparky.IMD.Sterling.COM (Kent Landfield) writes:
This is being done with the Environment: header line in comp.sources.games.
When we were discussing how to do things in c.s.r, we discussed
putting the environment information in a header line. However, we
decided in the end not to do this for a few reasons (and I'm sure that
if I forget any of them, someone else who was involved in the
discussion will pipe up):
1. Non-standard header lines are, in general, a bad idea. For
example, the header lines that rn is capable of manipulating (i.e.
showing vs. hiding) are hard-coded, and it can't deal with any
lines that aren't in its hard-coded list (obviously, this is a
major lose, and some newsreaders {such as xrn} have overcome this
difficulty, but it's still a problem).
2. The environment information often takes more than one line. Or, in
order to fit it on one line confusing abbreviations sometimes have
to be used.
3. Archives are often kept of shar files without saving the headers of
the messages that came with the shars. If important information is
in the header, that information ca be lost.
So, the end result of our discussion was the conclusion that the
environment restrictions on packages would be described in the text of
its introductory posting, rather than in a header line.
Of course, if comp.sources.games has been using a header line, and
they haven't had any problems, perhaps we should reconsider our
decision. But I think I'll hold off on suggesting that until we do it
the way we've decided to for a while so that we have something we can
compare against how comp.sources.games does things.
Jonathan Kamens USnail:
MIT Project Athena 11 Ashford Terrace
jik@Athena.MIT.EDU Allston, MA 02134
Office: 617-253-8085 Home: 617-782-0710peter@ficc.ferranti.com (Peter da Silva) (04/30/91)
You can always do what all the sources groups do with new header lines: put them in a sub-header at the top of the article body. -- Peter da Silva. `-_-' peter@ferranti.com +1 713 274 5180. 'U` "Have you hugged your wolf today?"
billr@saab.CNA.TEK.COM (Bill Randle) (05/02/91)
In article <JIK.91Apr28012246@pit-manager.mit.edu> jik@athena.mit.edu (Jonathan I. Kamens) writes: >In article <1991Apr26.155106.10943@sparky.IMD.Sterling.COM> kent@sparky.IMD.Sterling.COM (Kent Landfield) writes: > > This is being done with the Environment: header line in comp.sources.games. > >1. Non-standard header lines are, in general, a bad idea. For > example, the header lines that rn is capable of manipulating (i.e. > showing vs. hiding) are hard-coded, and it can't deal with any > lines that aren't in its hard-coded list (obviously, this is a > major lose, and some newsreaders {such as xrn} have overcome this > difficulty, but it's still a problem). That's why the c.s.g. Environment: header isn't a news header, but rather a package/archive header. That is, it is included with the Archive-name: and Submitted-by: headers. This way, it should be saved by any newsreader as long as the article is saved, rather than exploded in place (w| unshar). It is true that it limits you to only one line, but if the list of limitations is longer than that, I would suggest that either a better keyword could be used tha encompasses everything or else the package is really specific to a single machine/OS. Don't get me wrong - I think for c.s.reviewed it makes sense to include the limitations in with the other introductory material that is being generated. -Bill Randle Moderator, comp.sources.games Tektronix, Inc. billr@saab.CNA.TEK.COM