Upload Policy for the Hobbes Archive

Purpose

The purpose of this document is to specify how to properly upload a file for processing on the Hobbes archive (henceforth known as Hobbes) so as to minimize the time for it to be processed while maximizing the accuracy of the archival.

This document may be copied and distributed with the permission of the author as long as no modifications are made. Suggestions and feedback are encouraged and appreciated.

What to upload

Hobbes is an archive originally intended for freely-distributable OS/2 programs (kept in /pub/os2). However, in addition to that, the following types of files are accepted:

• DOS and Windows programs for the purpose of interoperability between OS/2 and DOS/Windows (/pub/dos and /pub/windows respectively)
• Java programs of any sort (/pub/java)
• Multimedia files (/pub/multimedia), such as:
  • fonts (/pub/multimedia/fonts)
  • images, including icons (/pub/multimedia/images)
  • freely-distributable music and sound files (/pub/multimedia/music and /pub/multimedia/wave)
  • video (/pub/multimedia/video)
  Artistic files in the multimedia section are arranged by type, then artist, then by filename. Please note that the multimedia section is usually in a state of disorganized disrepair due to visitor disinterest; should more interest accumulate regarding that section of the archive, it will be progressively refined and cleaned up.

For more information, a complete listing of all the directories is available for browsing.

How to upload

File format

First, all files must be compressed in .zip format, except for the following:

• Programs for decompressing archived files (pkunzip.zip makes no sense), which must be inherently stored in a self-extracting .exe
• Multimedia files which are compressed or benefit only marginally from compression (GIF/JPEG/PNG/etc. images, AVI/QT/MOV/etc. videos, IT and MID music files, MP3/RA/etc. compressed waveform data) which aren't to be distributed as a group (such as a "musicdisk")
• Components of an IBM FixPack

Multiple-archive distributions are accepted, provided that some of the archived components are optional (for example, binaries and source code, or compilers with optional frontends).

Descriptive .txt

In the /pub/incoming directory is a file called README.TEMPLATE which is a template for describing files in the incoming directory. Along with every upload, you must include a .txt file with the same base name as the archive (for example, abc123.zip needs abc123.txt, def456.mp3 needs def456.txt, and so forth). It should be filled out in a normal text editor, with the default values removed if they are not used. This file is a plain text file with the following fields, all of which are required unless otherwise specified and must start after the : or ? character, on the same or next line. (Note that this file uses the term "program" to mean "program or file;" a multimedia file, for example, is still referred to as a "program" in this context.)

• Archive Filename: This the filename of the upload. It is only for a sanity-check measure, to be sure that you haven't uploaded a .txt file under the wrong name. So, in abc123.txt accompanying abc123.zip, this field should read abc123.zip.
• Short Description: This is the short description of the file; normally it is the program name and version and a brief description of what it does. It should be less than 60 characters long.
• Long Description (optional): This is a more detailed description of the file. Typically it contains changes since the previous version, more detailed information, and the like. It should not be or contain a duplication of the short description, as everywhere that the long description is visible, it is stated after the short description. If there is no long description, leave it as the default value of (none).
• Proposed directory for placement: This is the directory in which you think the program should be placed. If you are unsure, search the archive for similar programs (or older versions of the current program), or browse the directory structure for an appropriate directory. Do not use the deprecated directory structure from many years ago, and do not use the directory structure from another archive. It is also preferrable that you use the exact and full path (i.e. /pub/os2/apps/internet/ftp/client), rather than an approximation of it (such as /os2/pub/internet/app/clients/ftp). Under rare occasions an appropriate directory may not exist; if this is the case, email the archiver to ask that an appriopriate directory be made, describing the program in question.
• Your name (optional): This is the name (or, rarely, pseudonym) of the person uploading the program. If you prefer to only have your email address listed, leave this field blank.
• Your email address: This is the email address of the person uploading the program. It is so that the archiver can contact the uploader in case that there is a problem with the upload, usually by form letter. If you are paranoid about spammers, you may use spam-trash in it (such as writing "email@NOSPAM.my.isp" or "email at my dot isp").
• Contact name (optional): This is the name/pseudonym of the person to contact regarding the program. If it is the same as the uploader name, leave it at the default value of (same). If you would not like a name listed for contact, blank the field out.
• Contact email (optional): This is the email address to contact regarding the file. As with the contact name, if it is the same as the uploader email address, leave it as (same), and if you wouldn't like one listed, blank the field out.
• Program URL (optional): This is a URL to point to a site from which to get more information about the file. It should normally be a webpage, but any standard URL (in standard URL format, i.e. ftp://hobbes.nmsu.edu/pub/os2) is acceptable. If no protocol is specified, http is assumed. Please do not simply link to the file, as that isn't very useful.
• Would you like...included in listings? (optional) This is an additional measure for allowing the email address to be listed in the .txt file while not being published in the archive. If this field reads "no," the contact email address will be removed. If this field reads "yes," it will follow whatever behavior is given by the Contact Email field.
• Operating System/Version (optional): If only a specific version of an operating system will work (such as OS/2 Warp 4.0 or Java 1.1.6), or there is support for operating systems other than the one specified by the section of the archive it is in, this should list the operating system(s) it runs on. Otherwise, leave it blank; if it is in /pub/os2 it will be assumed to be an OS/2 program, and so forth.
• Additional requirements (optional): This is where you list what other programs, hardware, etc. are needed for the operation of the file. For example, if it requires XFree86 and EMX, this field should say something like "XFree86 and EMX." Note that this is not where to say that it requires Java; Java is considered, for the purpose of this archive, to be an operating system, and so if it requires a specific version of Java, that information is put in the Operating System field, above.
• Replaces (optional): If there is an older version of this program/file on the archive, list the filename(s) of the older version here. Giving a wildcard (such as abc*.zip) is fine. It is preferred that the full path to the previous version is given, as well (for example, /pub/os2/apps/internet/ftp/client/abc*.zip), particularly if the older version is in a different directory.

Most of this file (except for the placement directory and replacement fields) is automatically-processed by a program, which tries to be intelligent about mapping a file to its components. However, this isn't always possible, particularly if you use a format other than the one given. The database is updated twice daily, so a few hours after uploading the file (12 hours at the most), please check the database, the extended information (the 'More Info') link, to be sure that it appears how you want. Please note that, as a necessity, no formatting is preserved in the file, and the long description is truncated to the first paragraph.

Please always use the latest README.TEMPLATE file. It can change from time to time, and older formats may not necessarily be supported.

Upload Procedure

Uploaded files are only accepted via FTP. I cannot accept submissions via email, for a variety of reasons, and I will not be implementing any web-based upload facility. Do not email files to me (even the .txt files); it's very easy to find an FTP client (OS/2 even comes with two of them, and there's plenty on Hobbes), and it is much simpler for everyone involved.

If a file needs to be re-uploaded

There are a variety of reasons for a file needing to be re-uploaded; for example, an upload may have failed, or a .txt file may not have produced the correct results. If this is the case, you will have to rename the old file (most FTP clients, including the ones which come with OS/2, let you do this) to filename.delete and then reupload the file under its original name. For example, if abc123.zip fails on upload, rename the old one to abc123.zip.delete and then reupload abc123.zip. If the upload fails a second time, you can rename the file to any variation of filename.delete, such as abc123.zip.delete2. The same goes for textfiles.

If you're uploading a new version of a file still in /pub/incoming

If you're uploading a new version of a file still in /pub/incoming, please treat the previous version of the program and its filename as a failed upload. For example, if you upload abc124.zip while abc123.zip is still in /pub/incoming, please rename abc123.zip and abc123.txt to abc123.zip.delete and abc123.txt.delete, respectively. This makes things much easier for the archiver.

After the upload

After it is uploaded, the file will sit in /pub/incoming until it is either archived or rejected. If it is archived, it is in the archive until the file is superceded by a newer version or the archive itself suffers a dire fatality. If it is rejected, it is usually for one of the following reasons with the listed consequences.

Missing/incomplete/malformed textfile

This is the most common reason for rejection. If there is an email address available in the textfile, the uploader will receive a form letter stating the nature of the rejection and giving general instructions on rectifying the situation. The rejected file will be stored in /pub/incoming/delayed until either a week has passed (at which point it will be deleted) or the uploader fixes the situation. Normally, uploading a corrected .txt file will automatically move the file out of delayed on the next database update (12 hours at the most). Its listing within the delayed directory will include the reason for its rejection.

The file was corrupt or in the wrong format

When this happens, the uploader should receive a form letter indicating that the file was bad for whatever reason. The file will be deleted, and the .txt file placed in the delayed directory, and will be automatically moved back into the incoming directory at the next database update after the file is reuploaded (or until a week has passed, at which point it is deleted). Uploading the .txt file again shouldn't be necessary, unless it is not in the delayed directory.

The description is not in English

Although Hobbes is an international archive, it is run in America, by English speakers, and most of the users speak English. As such, it is inappropriate to assume that the archiver will understand German/Spanish/Swahili/Esperanto/Basque/etc., as is it inappropriate to make such assumptions about other users. Having a German description along with a short English description is appropriate, but in general it's better to describe the program in English and, if the program itself is in a language other than English, put the language in the short description. For example,

Archive Filename: abc123.zip
Short Description: Learn to count numbers (Spanish)
Long Description: Esta programma es muy bien si usted querra que usar los numeros que son muy dificil.

The file was not appropriate for Hobbes

This is generally due to a DOS or Windows program unrelated to OS/2 being uploaded to Hobbes. It can also be due to inappropriate content (Hobbes, being run by the New Mexico State University, cannot carry any sexually-explicit material, among other things). The uploader will get a message stating the problem, and the file and .txt file will be deleted. If the uploader is able to correct the problem in some way (such as by removing adult-oriented content), they can feel free to upload the corrected file.

The file was pirated material or an attempt to undermine Hobbes

Hobbes is for freely-distributable material only. Pirated programs, music, and images are specifically prohibited. If such material is found on Hobbes, it will be deleted, the uploader's ISP will be contacted, and, depending on the seriousness and repetition of the offense, possibly temporarily banned from making FTP connections to Hobbes. (For example, some ISPs have been banned due to users uploading a homepage to /pub/incoming and attempting to make the index of /pub/incoming appear to be that homepage, thus also confusing users.) Note that attempts to upload pirated material, as well as attacks on Hobbes, are taken very seriously and as many measures as necessary will be taken to track down the offending user. No remorse is given to people who "didn't know better" or "thought it'd be fun[ny]."

If you, as a user, discover such material on Hobbes, please don't hesitate to email the archiver so the situation can be taken care of soon enough to minimize damage.

Regarding such happenings: I have had many users suggest to me that, in order to prevent future attacks from happening, I should set /pub/incoming write-only. I refuse to do this for several reasons:

• To do so would to be to give in to those who abuse Hobbes, and makes things horribly difficult for legitimate users. There are many more legitimate users than abusers, and I do not want to punish the many (by taking away the right to download bleeding-edge new programs) simply because of the few.
• To do so makes things horribly difficult for everyone involved. When an upload fails, the uploader can't rename the file and upload a new copy in such a way that the automated scripts can intelligently decide which version to keep and which to discard.
• It shows a complete lack of faith in Hobbes users and the Internet as a whole.
• It is a last-ditch effort to curb abuse; it's just not something I want to do.

Contacting the archiver

If you have any questions, suggestions, or warm fuzzies regarding these policies, feel free to contact the archiver. Intelligent discussion is appreciated.