Table of Contents

Sysadmin tracker for roundup

Welcome to the sysadmin tracker for Roundup. This tracker is designed to handle issues generated in a system administration or help desk environment. It is released under the GPL license see the Tracker License section for details.

It is more complex than the classic tracker, but has things that I have wanted in my trackers. Some of the functions were inspired by equivalent functionality in rt while some other things I have wanted in various trackers (req, reqng, queuemh, rt1, clearquest, remedy) through the years.

Features

Compared to the classic tracker, this tracker has:

Using the sysadmin tracker

This section describes general usage of the tracker and explains the attributes and related entries. It assumes that you have read, or can read the roundup user documentation.

Example use

A requestor sends email to the sysadmin tracker email address. The people responsible for watching the tracker and its queues are automatically sent a new issue email.

Then the queue wrangler for the week uses the web interface to set the issue priority and to assign somebody to the issue. This assigned person is called the assignee. The assignee automatically receives a "this issue is assigned to you email", and the issue will occur on the assignee's issues list. The assignee then replies to the assignment email and asks the requestor for some additional information. The issue is automatically moved to the open state.

The assignee then uses the web interface to add a few other technical people to the Technical (verynosy) list and creates a "comment" message asking for ideas on the best way to solve the problem. The technical people receiving this comment reply to it creating more comments until somebody realizes that they need input from the issue creator. The assignee sends a "reply" message using the web interface and asks the requestor (who is automatically put on the Watcher list) for the information. All of the people on the Technical list see the email and its response. One of the technical people replies to this email and solicits further info from the requestor.

Then some more conversations occur using "comment" messages until a solution is reached. The assignee realizes that he needs help from another group and creates a new dependson issue to assign part of the work to another person. The assignee then stalls the issue.

Once the other work is done, and the depended issue is resolved, the issue is automatically moved from stalled to open, and our assignee finishes the issue, adds a comment detailing how the issue was solved and passes it off to another (QA) person in the group by reassigning the issue which moves it off his list of open issues.

Then the new assignee creates a reply to the issue creator telling him that the problem is solved, and asking him to verify the fix. He also moves the issue to the testing status. The requestor sends email saying that the issue is resolved, the assignee then changes the status to resolved and it is automatically removed from his list of open issues.

In this example we see there are two ways to interact with the issue:

with a few exceptions, all of the features of the tracker can be accessed via either interface. We will discuss the web interface first than the email interface.

Logging in, or submitting your first issue by email

If you send email to the tracker email address, an entry in the user database is made for your email address. If the administrator has set the MESSAGES_TO_AUTHOR to include new, or yes, you will receive a return email that verifies the creation of the issue and will provide you an easy way to add information to this issue by replying to the return email.

You can also register for the web interface if you wish by using the register link. If you have forgotten your password, a new randomly generated one will be sent to you by following the process from the "Forgotten your password?" link. Both of these mechanisms send email to the registered address and use a web link in the email to verify the account creation or resetting of the password.

The Web Interface

We will discuss using the web interface.

The left hand menu

The left hand menu has a number of items in it including:

The AutoRefresh box should be part of the actions box, but because of issues with HTML, it needs to be a separate box.

The Issue Views

When you log in, you will see a list of open issues. You can click on the "My Issues" link in the User box to see all issues assigned to you. You can view an issue by clicking on its title or entering its ID number using the goto box.

Using either of these methods will bring up the default issue view. There is also a view for advanced administration of the issue including assigning a scheduled action, storing billing info etc. This advanced administration view is called the edit fields view. These two views are discussed below.

The default issue view

This view shows the basic fields, message entry fields, total time log (if times have been entered for the issue), message list, files list and history list.

The basic fields include:

See Attribute Descriptions for full information on these fields. The message entry fields are:

The Time Log Total section is shown only if one of the messages was entered with time information. The display consists of three columns:

The messages section displays the full text of any messages that are linked to this issue. Each issue has a header. The header consists of:

Next is the list of files that are associated with the messages in the issue. It is displayed only if there are files associated with the messages in the issue.

[Admins take note: earlier versions of roundup had a bug where file attachments sent via the email interface were linked into the messages, but were not linked into the issue. You can create a shell script using the roundup-admin command to fix this. See the admin chapter below.]

Then at the very bottom of the page is the history of all the changes made to the issue.

Since you can change multiple items in a single modification of the issue, only one Date/user line is shown for each modification. There can be multiple action/args entries that were done with only a single modification transaction.

The edit fields issue view

In this view, you have access to more fields, and also some embedded searches to provide a better feel for how the issue relates to other issues. It does not provide a message entry box, nor does is show the message associated with the issue or a history of changes to the issue.

The fields shown are the basic fields shown in the main issue view:

Below that is the "Additional Fields" section including:

Below that is the "Action Fields" section that implements some basic actions that can be scheduled for a future time. This section consists of the fields:

See the section Attribute Descriptions for full details on these fields.

Below this section is the Issue Relationships section that provides a five column summary of related issues. The columns are:

Email interface

The email interface uses specially formatted tags on the subject line to link a given email to a message. This tag occurs first on the subject line (words like Re:, Fwd: preceding the tag are ignored) and looks like '[issue345]'. The tag consists of an open left square bracket, the word 'issue' the issue number (with no space between the word issue and the number) and a closing right square bracket.

When you reply to an email, it preserves the subject line. Your reply email will be addressed to one of the trackers email addresses. There are two addresses associated with a sysadmin tracker. They correspond to the two types of messages: reply and comment.

The comment address usually has the phrase '_comment' just before the at '@' sign in the email address. When you reply goes to this address, only people on the Technical List will see it. By default, the requestor is not on this list. If you want to send an email that the requestor will see, just remove the '_comment' from the to address and it will go the the reply address that includes the people on the Watcher list (where the requestor is) and the Technical List.

You can also set the attributes of the issue by including a tag of the form '[attributename1=value;attributename2=value2]' at the end of the subject line. If you are using Microsoft Outlook, this may not work because of a significant bug in that product. See the roundup documentation for more information on setting attributes via the email interface.

Any text you type in the body of the message will be saved as a message in the issue. The message type is determined from the address you send the email to as described above. Attached files will be recorded as attachments in the issue and will be forwarded to the Watcher or Technical lists depending on the message type.

You can send your email to real people by adding them on the Cc or To or Bcc lines of your mail program. These people will not receive an email message from the tracker. For their replies to be recorded, they will have to include the tracker email address in their replies. Usually this can be done by selecting the "reply to all" functionality of their mailer.

The RSS announcement interface

Thanks to http://markpasc.org/code/rsswriter (missing as of 12/2011) the sysadmin tracker has an XML rss 2.0 feed at TRACKER_WEB/_file/rss.xml. You can point Bottomfeeder, Feedreader, Liferea, or any other RSS reader including those available for TWiki as a plugin to get up to the minute info on the top 30 newly changed issues.

Working with Issues

This section discusses how to work with issues and the attributes of those issues.

Issue Priority

There are 6 issue priorities available in the shipped tracker. Some of the ideas below are taken from the rt user's guide.

critical
This needs to be fixed immediately, stop whatever else you are doing and fix it. It has a high severity and high impact with no workaround. Lots of people are affected, or a critical person can't do their job. E.G. the main file server is down and nobody can work till it is functioning again.
urgent
High severity and moderate impact with no workaround. E.G. the only mail server is down, no email can be sent/received.
high
moderate severity, and moderate impact there may or may not be a workaround. e.g. the source code control system is down. People can still compile, test they just can't check the code in, the next scheduled check-in/release to test is still 4 days away.
routine
priority of the routine day to day issues. Low severity, moderate impact, there may or may not be a workaround for these issues.
low
Low severity, low impact, should have a workaround, or no workaround is needed.
minimum
Low severity, no impact, no workaround is needed.

The priorities above are defined in terms of severity and impact. I tried (and may have failed 8-)) to create a relatively simple single entry priority rating. Severity is a measure of how bad the problem is, and how difficult it will be to solve. Impact is a measure of how it interferes with people getting their jobs done.

The total failure of a mail server is pretty severe, but it may not be a high priority if you have three redundant mail server, and email is still flowing. So that one mail server being down is moderate impact, and there is a workaround in place (i.e. mail is still flowing). So this would be a high priority.

Also you may want to look at the workingorder attribute to further order the outstanding issues.

Issue Status

There are 9 defined statuses in the default sysadmin tracker they are:

Issue Status Indicators

When looking at related issues, it is very useful to know what state the related issues are in. To do this compactly, the issue numbers are displayed with a final letter that indicates the state of the issue. These letters can be set by the administrator, but by default are:

Letter Status
N new
O open
S stalled
H hold
T testing
R resolved
C duplicate (copy)
D dead
d delete

Automatic actions

The four action attributes:

provide a limited mechanism for scheduling an action on an issue. It allows setting an actiondate, actionstatus and actioncomment that are cleared after the actiondate has occurred. The actionclearonmessage attribute will cause the actiondate to be cleared if a message is submitted to the issue. This is useful for resolving a message after say three days if there is no activity. If there is activity, the automatic resolution is disabled. Actions will not be performed for resolved, duplicate, or deleted issues.

If an action is pending, you will see an "action pending" link next to the issue number at the top of the [[#DefaultIssueView][default issue view]] screen. Clicking on that link will take to you to the edit fields view at the action fields section.

For this to work, your roundup administrator must run a script daily to actually perform the actions.

Example actions

To automatically resolve an issue on a given date, set the actionstatus to resolved and the actiondate to the date you wish to resolve the ticket on. This is useful if you state that you will resolve a ticket in N days if there is no response. Note that you are still responsible for clearing the action if there is a response and you don't want the ticket to resolve. It may also be a good idea to set the actioncomment to "issue 345 automatically closed after N days without a response." This way you will get the email and can reopen the ticket by replying, or by manually setting its status in the web interface.

To remind you about a ticket on its start date, set the actiondate attribute to the start date, and add an actioncomment of "Start issue 345 today", and leave the actionstatus as '- no selection -'. On the given day, the actioncomment will be added to the issue, and an email will be sent to everybody on the Technical List (which included you the assignee by default).

These fields can also be assigned in the subject line of an email to the issue if you don't have access to the web interface.

Using comment and reply messages

The sysadmin tracker uses two types of change notes/messages. These two types are replies and comments. The reason for this is to reduce the amount of email that people get on an issue. On a given issue, only 1 or two messages may have to go to the requestor, but there may be dozens of messages recording how the work was done and intermediate steps taken in finishing it. By recording this intermediate info, the issue can be referred to later if a similar problem crops up. Then the issue can be used as the standard way of solving (or not solving) the problem. Message types are used as follows:

Associated with a message of any type are the following attributes:

Issue relations

This tracker defines three different relationships between issues:

Either the dependson or groups relation replaces the classic tracker "superseder" property whose meaning seems to be incompletely defined. The sections below define each type.

Dependson Relationship

If issue A has issue B listed in issue A's dependson multilink property, issue A can't be resolved until B is resolved.

When the last unresolved issue in A's dependson property is resolved, issue A will have its state changed to open. In this case a comment is added to the issue that it is being opened so verynosy (technical list) notifications are sent out since assigned to people are on the technical list.

If one of issue A's dependson issues is unresolved, issue A will be reopened if issue A is resolved.

Groups Relationship

If issue A has issue B and issue C listed in issue A's group it means that updates (messages, status changes etc) to issue A should be applied to issues B and C. You would use it when you have multiple issues that are all solved by the same solution. Think of it as a merging of issues that preserves the individuality of the issues and permits un-merging if issue C turns out to not be solved by the solution to issue B.

It implements forwards and backwards (downward and upward) message propagation. This will make sure that the grouping issues will get the message so that their nosy people can be notified of changed.

It should work like: 

  A -----+--------- B --------+------- C --------+------- D
         |                    |                  +------- E
         |                    +-------- F
         |                    +-------- G --------+--------- H
         |                                        +--------- I
         +--------- J ---+-- K
                         +-- L

email sent to H should go up the grouping chain to G, B, A. Email sent to G will go down to H, I and up to B, A. Email sent to A will go down to all issues A-L. This means that an issue that groups another issue will see all the messages made to its groupees. Also all the groupees will see the messages sent to the grouping issue.

Seealso Relationship

A general grouping solution. Since issues can be hyperlinked in the message bodies, this is somewhat redundant, but it is useful in that programs can easily find the links to publish an issue and all related issues without having to grovel through all of the messages.

Working with Users

On the left hand pane in the Administration section, you can access a index page of users with the "User List" link. Then use your browser's search capability to find the right user. When you click on the username link, you will transfer to the user's page. If you click on the tickets link in the username column, you will see a list of open tickets grouped by status. This is a standard issue index page so you can sort and group then differently. This is useful to find out what the caller is submitting, what is currently open etc.

If you chose to go the user's page, you will be able to view the following fields:

Displayed at the top of the page is a link to the same view as the tickets link in the user index page so that you can quickly see prior ticket by this user.

In the future other searches including issues where the user is nosy on the ticket etc will also be supported.

The fields

Even though you may not be able to view all of the fields on another user's page, you can view your own by selecting the "My Details" link in the left hand column. The fields are:

Below these fields a table of your available/assigned queries is displayed. This table provides the ability to edit, display or remove the query from your list of queries. At the bottom of the page is shown a history of changes to the user.

Time zone

The timezone is a pure number. It is not a timezone like EST5EDT. You will have to change your offset when the clocks change.

Also the timezone is added to all times regardess of the date. E.G. If I look at an issue with messages from December, which should be -4 hours from GMT in July when its -5 hours from GMT, the time will be modified by -5 hours (my current timezone setting) rather then the -4 hours that it should be modified by.

Finding issues requested by the user

Clicking on the link at the top of a user's page, or on the (tickets) link next to the user's name in the user list will provide a list of tickets that the user has requested.

Issue Attribute Reference

The attributes shown in issue and message views are listed in alphabetic order below. For each attribute, the display title is given first, and the internal attribute name is given in parenthesis after the display name. The internal attribute name is what is displayed in pull down lists. After that is the type of attribute for which you should look at the standard roundup documentation to find out how to interact with that attribute type.

Action Clear on Message (actionclearonmessage)

The actionclearonmessage attribute is a boolean value that if set will cause the actiondate to be cleared if a message is submitted to the issue.

Action Comment (actioncomment)

The comment to be sent when the action occurs. It will be added to the issue. Note that there is no actionreply, so the text entered here will not be sent to people on the Watcher list.

Action Date (actiondate)

A date whose time is ignored, only the date portion is used. On that day the action will occur.

Action Status (actionstatus)

The issue will be changed to this status when the action triggers.

Assigned To (assignedto)

The name of the person currently working or responsible for this issue. If you want to have multiple people responsible, you can group issues together, of use the dependson relation to divide the issue into multiple parts.

Billing info (billinginfo)

Store billing info for this issue.

Cc

This field is only shown in the web interface. It DOES NOT exist in the database. It provides a way to send a message to people not on a nosy list for the issue. It is equivalent to sending email to the tracker with other recipients on the To or Cc lines of the email. Enter a comma separated list of valid email addresses. It will not accept user names, you must use email addresses. This is also a fast way of creating a new user at the given email address.

Depends On (dependson)

The list of issues that this issue depends on. The issues will be listed with a letter after their names. See #IssueStatusIndicators for information on the letters. Also see #IssueRelationshipsDependson for further details.

Due Date (duedate)

The date the issue should be completed on.

FYI (fyi)

Used to record summary notes and details that get buried in the issue trail. Useful for noting ticket Id's for phone calls, serial numbers of equipment etc.

Groups (group)

The list of issues that this issue depends on. The issues will be listed with a letter after their names. See #IssueStatusIndicators for information on the letters. Also see #IssueRelationshipsGroups for further details.

Lead Time (leadtime)

The estimated amount of time that solving this issue will take. In theory, the due date - the lead time is the theoretical start date for the issue.

So in theory this is the same as the difference between the Start Date and the Due Date. However, it may be advantageous to have an issue done before the due date. In this case, the math won't work out, but the actual completion date will be the start date plus the lead time.

With a suitable escalation program, (not yet written), this can be used with the due date to escalate the priority of the issue.

Message Type

When creating a new note/message you need to select the message type. If you select 'reply - to all', it will be emailed to all the users on the Technical and Watchers lists. If you select 'comment - to technical', the new message will be emailed only to the people on the technical list.

Note that right now both types of messages are visible to all users in the web interface. This will change in the future with the comment messages being shown to a more restricted group of people.

Needs Reply (needsreply)

Set to true if issue is not new and the last person to add a message is not the assignedto person. If there is no assignedto person, then set to true if last message addition not done by person on technical (verynosy) list. This causes different display of issues that need to be responded to. It is useful if you are working in the field, and have a browser, but no email access to be notified of responses to issues.

Priority (priority)

Used to set the priority of the issue. The defined priorities are defined in #IssuePriority.

Queue (queue)

Categorizing an issue to be handled by a particular group of people. Associated with each queue is a default announcement list that is independent of the Watcher or Technical lists. This default list is used to announce the issue if nobody is assigned to the issue.

Requested by (requestedby)

Used to record the person who requested this issue. It's auditor sets it to the creator of issue by default. It is useful for help desk purposes, where the person creating the issue is not the person requesting the issue.

Unlike the creator attribute associated with an issue, this can be changed to reflect the person actually requesting the issue rather than the person who physically created the issue.

See Also (seealso)

Used to link issues that are related in some way. E.G. an issue is created because the printing subsystem, is backed up. The first line support person can't clear the problem because he doesn't know how. So he passes it to the second line person. The second line person finds an issue that describes how to solve this problem and put the ID of this issue into the See Also attribute, and reassigns it to the first line support person.

It can also be used to link related issues for justifying purchase of a new disk. Every problem that comes in that can be solved by purchasing a new disk can be put into the seealso attribute so that a report can be generated of all the additional work caused by the lack of disk space. Also see #IssueRelationshipsSeeAlso for further odetails.

Start Date (startdate)

Enter the day the task should be started. If you wish the issue to be automatically opened on this date, see the Action Date attribute.

Status (status)

Set the status of the issue. The defined statuses and their meanings are defined in #IssueStatus.

Superseder (superseder)

This is only visible on the edit fields or default issue view if it is not empty. It is left in place for compatibility with the classic trackers, but should not be used in the sysadmin tracker. Use the dependson, groups and seealso attributes/fields instead.

Technical List (verynosy)

People in this list receive forwarded email for both comment AND reply messages.

Time Spent (timelog)

Enter the amount of time worked on the issue here. This is actually linked to both the issue and any message that is created with it. Thus you can look at a message (that documents a particular phase of solving the issue) and find out how much time it took to perform the phase.

This is useful for future planning.

This can not be access via the email interface at this time.

Title (title)

The title for the issue. It should be descriptive and easily distinguishable from others. For example use: "Build computer system for Joan Jetty" rather then just "Build computer system". This line will be shown in issue lists under the Title field.

Topics (topic)

This is used to categorize the issue. E.G. keywords like hardware, software user_error can be assigned to the issue. This allows statistics gathering in the future.

Watcher List (nosy)

People in this list receive forwarded email for ONLY reply messages.

Working Order (workingorder)

Used to assign a working order to items. Useful when you have lots of things at the same priority.

Administering the tracker

This section assumes that you have read the roundup documention on installing a tracker.

System level tasks

These tasks need to be done by somebody with access to a user or administrtor interface on the computer hosting the tracker. They can't be done through the web interface.

Setting up the email interface

If you are using the email interface, you will need to set up (at least) two mail aliases for each tracker. The first alias is used for issue creation and replies to the issues. If you are not using queus, or you don't want a separate email address per queue, the sendmail alias file looks like 

  tracker: |/tools/roundup/bin/roundup-mailgw -C msg
             -S "messagetype=reply - to all" /var/roundup/sysadmin

(the lines are split for readability. In the alias file they will be on the same line). Replace /tools/roundup/bin/roundup-mailgw by your path to the roundup-mailgw. This creates the alias tracker. All messages sent to it have their messagetype attribute set to "reply - to all". The roundup tracker instance is located at /var/roundup/sysadmin.

Then the comment alias is created and looks like: 

  tracker_comment: |/tools/roundup/bin/roundup-mailgw -C msg 
             -S "messagetype=comment - to technical" /var/roundup/sysadmin

(the lines are split for readability. In the alias file they will be on the same line). Replace /tools/roundup/bin/roundup-mailgw by your path to the roundup-mailgw. This creates the alias tracker_comment. All messages sent to it have their messagetype attribute set to "comment - to technical". The roundup tracker instance is still located at /var/roundup/sysadmin.

If you are not using queues, or do not wish to have queue specific addresses, then you are done with the special email setup for the sysadmin tracker. You still have to handle the email setup specified in the roundup documentation.

If you would like to have queue specific email addresses, say one for each department: sales_tracker, development_tracker... per problem queue: networking_tracker, email_tracker, web_tracker... etc. Then we look at the following aliases: 

  sales_tracker: |/tools/roundup/bin/roundup-mailgw 
             -C msg -S "messagetype=reply - to all" 
             -C issue -S queue=sales 
             /var/roundup/sysadmin
  sales_tracker_comment: |/tools/roundup/bin/roundup-mailgw
           -C msg -S "messagetype=comment - to technical"
           -C issue -S queue=sales /var/roundup/sysadmin

The major difference between these aliases and the ones above is the setting of the queue attribute to "sales" for the issue class. You would set up one email address pair for every queue that you use.

Modifying config.py

There are some settings in config.py that are unique to the sysadmin tracker.

Set the NEW_ISSUE_ANNOUNCE_DEFAULT variable to an email address where you want all new issues without an assigned queue or assignedto person to be announced. If it is set to None (the default) no email will be sent if queue is unassigned. If queue is assigned the email address(es) associated with the queue will be used.

Multiple email addresses can be specified using a , between them. No space is allowed in the string. A couple of examples are: 

  NEW_ISSUE_ANNOUNCE_DEFAULT = "sysadmin@example.com,sysadmin2@example.com"

  NEW_ISSUE_ANNOUNCE_DEFAULT = "sysadmins"

Set the DEFAULT_PRIORITY variable to assign the priority to issues arriving via email that don't have a priority. This is the way to force a priority on email'ed issues. For the web, setting a priority is enforced in the cgi. You can create a "Needs priority" priority and use that as the default as an indicator that somebody need to look at the issue and assign it a real priority. This is used in the default_priority.py detector/auditor. The default priority is routine. 

DEFAULT_PRIORITY = 'routine'

Set COMMENT_TRACKER_EMAIL to the alias used for handling comment emails. This is usually the same as TRACKER_EMAIL except for comment messages rather then reply messages. If you choose the default with the _comment suffix, then there is no need to set this value, it is calculated automatically. 

COMMENT_TRACKER_EMAIL = 'tracker_c@%s'%MAIL_DOMAIN

Setting up cron jobs

There are some functions that are carried out on a scheduled basis. On Unix, you can use cron, or self submitting at jobs to do this. On windows you may be able to use the at command or other scheduler. The two jobs done on a scheduled basis are to send daily (weekly) reminders to all assigned people about the issues they have open. Also the automatic action feature is carried out by a daily cron job.

Issue status reminders

Edit the cronjobs/roundup-reminder script to set the path to the roundup install directory.

Add the script cronjobs/roundup-reminder to the crontab of the user your cgi and mail gateways run as. Run the script daily (or weekly or any other schedule you want) in the early morning. It is called with the path to the roundup tracker home directory just like the roundup-admin command.

Automatic actions

Edit the cronjobs/roundup-action script to set the path to the roundup install directory.

Add the script cronjobs/roundup-action to the crontab of the user your cgi and mail gateways run as. Run the script daily in the early morning. It is called with the path to the roundup tracker home directory just like the roundup-admin command.

Tracker administrator tasks

You can customize the tracker classes as well. However some detectors may need to be modified since they will often embed the names of priorities and statuses in them. So you can change it in the web interface, but you may also need to get access to the system command line to fully implment the change.

Setting up supplementary classes in the HyperDB

There are a number of supplimentary classes in the hyperdb.

Priority

Query

Queue

queue.create(name="Integration", email="donotsend", order="1")

Status

Status items have 6 attributes:

The name, order and help attributes are self explanatory.

The abbreviation attribute is used to indicate the issue status. See Issue Status Indicators for more information.

The transitions attribute specifies what the current state of an issue must be in order for the new state to be selected. E.G. if the testing state had its transitions attribute set to: "open,hold,stalled" then an issue that was in the new state couldn't be transitioned to the testing state. The issue would have to be moved from new to one of the open, hold or stalled states before it could be moved to the testing state. The value for this is the comma separated list of states. If you are changing this in the CSV interface, you must enclose the string in double quotes if you specify more than one state. If this field is empty, the state can be selected from any prior state.

The requiredpermissions attribute lists the permissions the user must have to select this status. E.G. you may only want managers to be able to resolve an issue, or you may want to stop regular users (i.e. people who generate the issues rather then the people who solve the issues.) from selecting any state except new and resolved. This attribute takes a comma separated list of required permissions. You can include spaces as well as comma's to increase readability. If changing this in the CSV view, you must include the string of permissions inside of double quote (") marks if you specify more than one permission. If this attribute is empty, anybody is able to select this state.

Changing the names of the status will require detector changes.

Transitioning from the classic tracker

If you are starting with a fresh tracker, you can skip this section. If you want to import data from a classic tracker into a sysadmin tracker, you should read this section.

Many items (topics, nosy etc) will translate without a problem. The superseder relation will be displayed as needed.

  1. create a new initialized sysadmin tracker with the same database type as your classic tracker. (**FIXME fix what?? Fix the page file as described above.)
  2. shutdown classic tracker.
  3. backup classic tracker.
  4. copy the detectors and html directories from the newly initialized sysadmin tracker to the classic tracker's directory.
  5. copy the database files for new objects into the db directory. don't overwrite any of the class .db files that already exist. I don't know how to do this with anything other then the dbm or db databases. (e.g. mysql, or sqllite)
  6. merge settings in classic config.py into sysadmin tracker config.py and use the sysadmin config.py.
  7. Copy the dbinit.py and interfaces.py file from the sysadmin tracker into the classic tracker.
  8. Bring up the classic tracker.
  9. Add the 3 searches (Note: they are wrapped for readability, leading spaces on following lines should be removed.): 
    klass="issue" name="WatcherTechnical"
      url=":columns=title,id,status,queue,topic,duedate,
      creator,assignedto,activity,nosy,verynosy&
      :pagesize=50&:startwith=0"
   
    klass="issue" name="Relationships"
    url=":columns=title,id,status,queue,duedate,assignedto,
       activity,dependson,group,seealso&:filter=status&
       status=-1,1,2,3,4,5&:pagesize=50&:startwith=0"
   
    klass="issue" name="Schedule"
    url=":columns=title,id,status,queue,duedate,leadtime,startdate,
       creator,assignedto,activity&:sort=-duedate&:pagesize=50&
       :startwith=0&filter=status&status=-1,1,2,3,4,5&
       @sort=-leadtime&@group=duedate"
using the CSV interface.
  1. remove the leading ?'s from the url fields in the tracker queries using the CSV interface.
  2. set status class abbreviation property otherwise you don't get abbrevs on issue links. Change description/names of states so that resolved, new (unread) and open (chatting) exist.
  3. set default announce email for new issues. Change from sysadmin.
  4. set email addresses for per queue announcements if needed.
  5. run scripts to link files associated with issues to the issue so they are displayed in the gui interface. A Bourne shell script like: 
       #! /bin/sh

   PATH=/tools/roundup:$PATH

   roundup_home=/data/roundup/admin

   for i in "$@"
   do
     case $i in
       [0-9]*) issues="$issues $i"
      ;;
       /*) roundup_home=$i
     esac
   done

   for issue in ${issues:-`roundup-admin -s -i ${roundup_home} list issue`}
   do
     echo "Running over issue $issue"
     files=""
     for msg in `roundup-admin -s -i ${roundup_home} get messages issue$issue`
     do
       echo "Scanning message $msg"
       files="$files,`roundup-admin -c -i ${roundup_home} get files msg$msg`"
     done
     if echo "$files" | grep "[0-9]" > /dev/null; then
       files=`echo $files | sed -e 's/[,],*/,/g' -e 's/^,//' -e 's/,$//'`
       echo "Files are $files"
       roundup-admin -s -i ${roundup_home} set issue$issue files=$files
     fi
   done
    This will take a while, but it runs over all issues making sure to set the files attribute of the issue to the union of the files attributes for all the issues messages.
  6. You will be able to see your superseder field unless it is empty. At which point you can forget it exists.

Customizing the tracker

See the roundup customization document for technical issues.

One idea that may be useful is to have an auditor that puts items in the dependson list on the blockers list if the item is not resolved. The auditor would also remove issues from the blocked list when they are resolved. This would allow you to suppress display of issues that are blocked because they have unresolved issues. While the blockedby field exists, and is displayed at this time (7/2003) the detector is not written since the plan is not to change the blocker field directly, but to change it in sync with the dependson field.

In the sysadmin tracker, currently the preferred way to handle this is to stall the depender issue until all the depended on issues are resolved. Then the detector automatically opens the depending issue.

Enhance the tracker to include asset tracking by creating a new hyperdb issue like object called asset. This asset can be linked to messages to record repairs, changes of ownership, etc. Also these assets can be linked into a hardware field of an issue to record the issues caused by this hardware.

Testing the tracker

(Note: I use a Bourne like shell, so where you see SENDMAILDEBUG=... before a command invocation, you should set the environment variable SENDMAILDEBUG before running the command, and remove the SENDMAILDEBUG=...[space] stuff from the command line if you you a csh like shell.)

Create new tracker: 

 /tools/roundup/bin/roundup-admin -i /var/roundup/testing \
      install sysadmin bsddb admin
edit the config.py to set url to point to testing rather than sysadmin. 
 /tools/roundup/bin/roundup-admin -i /var/roundup/testing \
      initialise admin
run 
   roundup-server -p 8080 -n 127.0.0.1 testing=/var/roundup/testing

test the following: 

From: "rouilj" 
Content-Type: text/plain
Subject: test 4a
To: issue_tracker@example.org
MIME-Version: 1.0
Message-Id: <1034901317.14.0.292086518234.issue@example.org>
Content-Transfer-Encoding: quoted-printable

New issue via email.

to stdin of: 

     SENDMAILDEBUG=/tmp/smd.email roundup-mailgw -C msg \
           -S "messagetype=reply - to all" /var/roundup/testing
msg should be created with an email to rouilj@exampleSTOPSPAM.org. The created issue should have: 
   nosy: rouilj@example.org
   priority: routine
   status: new
   title: test 4a

An email should be sent out to rouilj@exampleSTOPSPAM.org with a reply address of: issue_tracker@exampleSTOPSPAM.org. The subject line of the email should include the proper issue tag. An identical message should be sent to sysadmins.

Also the created message should have type reply. 

From: "d1" 
Content-Type: text/plain
Subject: [issue4] test 4a
To: issue_tracker@example.org
MIME-Version: 1.0
Message-Id: <1034901317.14.0.292086518234.issue@example.org>
Content-Transfer-Encoding: quoted-printable

New issue via email.

where issue4 is REPLACED by the issue just created in the last step. Send this email to: 

  SENDMAILDEBUG=/tmp/smd.email roundup-mailgw -C msg \
      -S "messagetype=comment - to technical" /var/roundup/testing

An email should be sent out to roundup-admin@exampleSTOPSPAM.org with a reply address of: issue_tracker_comment@exampleSTOPSPAM.org. The subject line of the email should include the proper issue tag.

This finishes basic test of mailgw setting message type (or any prop) verynosy and nosy message processing as well as default_priority.py 

From: "d1" 
Content-Type: text/plain
Subject: test 4a [queue=Support]
To: issue_tracker@example.org
MIME-Version: 1.0
Message-Id: <1034901317.14.0.292086518234.issue@example.org>
Content-Transfer-Encoding: quoted-printable

New issue via email.

to 
  SENDMAILDEBUG=/tmp/smd.email roundup-mailgw -C msg \
    -S "messagetype=reply - to all" /var/roundup/testing
testing automatic actions: 

      SENDMAILDEBUG=/tmp/mail crontabs/roundup-action $PWD

Gotchas, bugs and warnings

As with all new software there are some gotchas or bugs that can't be worked around.

Ticket won't resolve when status is resolved and a message is entered

You set resolved on an issue, and enter a message. You submit the change and see that the message has been entered, but the ticket is not resolved.

This occurs when the issue is groupedby another issue. What happens is that the message you enter is propigated to the parent issue (the grouper). Then the parent issue has been changed and it tries to propagate its status to its child issues. This overrides the status set in the web interface.

This could be considered a bug. I am not really sure how it should work. To solve the problem, enter a message, then set the status without a message. This should stop the upward propagation that occurs for messages and clobbers the set status.

Now is the fact that you can set the status of a grouped issue independently of its grouper a bug??

Ticket won't resolve because of depends and group issues

It is possible to create a loop of issues such that a depends on issue is also a group issue of some parent issue. In this case, you will not be able to resolve the issue because:

The detectors do detect using the same issue on an issues dependson and groups attribute, or assigning the issue to its own dependson or groups attributes. They just don't walk the entire tree looking for loops.

The solution is to get rid of the group or depends link that is causing the loop.

Setting fields via email fails when using Microsoft Outlook.

Microsoft Outlook does not follow the standard for creating continuation header lines in email. Outlook will fold the subject line in the middle of a word rather than folding only at whitespace as specified by RFC822 and later RFC2822. When the line is rejoined, whitespace is inserted at the point of the fold as specified by the RFC's. This can cause unintended white space to be added to the subject line which prevents the subject line parser from recognizing the [] enclosed attribute settings. E.G. it can turn "[status=resolved]" into "[statu s=resolved]". Because of this, it can be difficult to set attributes using []'d commands at the end of the subject line. Until Microsoft manages to fix their software, this problem will continue to exist, but by judicious padding of the subject line with spaces the issue can be worked around although its a major pain in the a**.

Todo

There are many areas for enhancement. A few open ideas include:

Enhancements to roundup

Here are some roundup core enhancements that this tracker would benefit from. 

** Support multiple sorts - eg. first by due date and the subsort by
lead time.

** Email gateway arguments to -S (set) should do lookup by key field or
id number, so messagetype=2 works.

MULTIPLE DATE FORMATS:
** Create dictionary of date formats. Select with us, uk etc country
code. E.G.

        local_date_re={
            'us': ( re.compile(r'''
            ((?P<m>\d\d?)/(?P<d>\d\d?)(/(?P<y>\d\d\d\d))?)? # mm/dd/yyyy
            (?P<n>[. ])?                                    # . space
            (((?P<H>\d?\d):(?P<M>\d\d))?(:(?P<S>\d\d))?)?   # hh:mm:ss
            (?P<o>.+)?                                      # offset
        ''', re.VERBOSE), _("format mm/dd/yyyy not found") ),
            'uk': (re.compile(r'''
            ((?P<m>\d\d?)\.(?P<d>\d\d?)(\.(?P<y>\d\d))?)?   # mm.dd.yyyy
            (?P<n>[. ])?                                    # . space
            (((?P<H>\d?\d):(?P<M>\d\d))?(:(?P<S>\d\d))?)?  # hh:mm:ss
            (?P<o>.+)?                                     # offset
        ''', re.VERBOSE), _("format mm/dd/yy not found") )
        }

  then loop using something like:
       if config != None :
            date_match_error = ''
            for country in config.COUNTRY_DATE_FORMATS:
                m=local_date_re[country][0].match(spec)
                if m is not None:
                    break
                date_match_error = date_match_error + local_date_re[country][1]

  where COUNTRY_DATE_FORMATS is in config.py  and looks like:

     COUNTRY_DATE_FORMATS = ['us', 'uk' ...]

  The first tried format is always serial format and the last format
  is roundup standard format.
  sourceforge feature tracker 2/22/2003

**Show who last did the activity on the issue. To go along with the
last activity date field. It should be a request in the sourceforge
feature tracker. This can be implemented in the tracker, but really
should be in the core.

**Need bulk update functionality.

Glossary

attribute
a property of a roundup HyperDB item such as title, priority, email address etc.
blocker
An depended issue that is not resolved and is preventing a depending issue from being worked on. A manual implementation of this can be found in the roundup customization document.
groups
A relationship between issues. If issue A groups issue B, then issue B appears in issue A's groups attribute. Issue a is the grouping issue and issue B is the grouped issue.
grouped
The target of the groups relationship. I.E. a grouped issue is one that is listed in another issues groups attribute.
grouping
an issue that has a non empty groups attribute.
change notification email
email that is sent out in response to a new message being received by an issue. Depending on the type of email (comment, or reply) it is sent to different lists of people. comment messages:these messages are used to interact with other technical people, and are forwarded only to the Technical list.
depended
The target of the dependson relationship. I.E. a depended issue is one that is listed in another issues dependson attribute.
depending
an issue that has a non empty dependson attribute.
dependson
A relationship between issues. If issue A depends on issue B then issue A can not be resolved until issue B is resolved. Issue A is the depending issue and issue B is the depended issues (target of the depends on relationship) issue.
field
the entry mechanism for an attribute in the web interface. Also has the same meaning as attribute or value of the attribute.
requestor
A user who is requesting an issue to be solved. Usually the same as the issue creator if the requestor has access to the tracker via email or web.
reply messages
these messages are used to interact with the requestor via the Watcher list and are forwarded to both the the Watcher and Technical lists.
roundup administrator
the person who sets up the sysadmin tracker, and establishes the web interface, email addresses and automatic tasks (cron jobs) required for the tracker to work.
seealso
a relationship between issues with no defined requirements.
staff
A person with the Repair user role. This person is expected to resolve jobs in the tracker.
tracker
An instance of a roundup database, rules for handling issues and associated web and email interfaces.
tracker administrator
the person who is responsible for adding user to the tracker, establishing the priorities, statuses, edits keywords and handles day to day operation of the tracker. Most of these tasks can be done via the web interface with no other system access.
user
Anybody who uses the system. This includes:
requestor
person asking that something be done
staff
person solving the requesters problem
manager
person managing the staff

License

This tracker is released under GPL version 2 

          GNU GENERAL PUBLIC LICENSE
             Version 2, June 1991

 Copyright (C) 1989, 1991 Free Software Foundation, Inc.
                          675 Mass Ave, Cambridge, MA 02139, USA
 Everyone is permitted to copy and distribute verbatim copies
 of this license document, but changing it is not allowed.

             Preamble

  The licenses for most software are designed to take away your
freedom to share and change it.  By contrast, the GNU General Public
License is intended to guarantee your freedom to share and change free
software--to make sure the software is free for all its users.  This
General Public License applies to most of the Free Software
Foundation's software and to any other program whose authors commit to
using it.  (Some other Free Software Foundation software is covered by
the GNU Library General Public License instead.)  You can apply it to
your programs, too.

  When we speak of free software, we are referring to freedom, not
price.  Our General Public Licenses are designed to make sure that you
have the freedom to distribute copies of free software (and charge for
this service if you wish), that you receive source code or can get it
if you want it, that you can change the software or use pieces of it
in new free programs; and that you know you can do these things.

  To protect your rights, we need to make restrictions that forbid
anyone to deny you these rights or to ask you to surrender the rights.
These restrictions translate to certain responsibilities for you if you
distribute copies of the software, or if you modify it.

  For example, if you distribute copies of such a program, whether
gratis or for a fee, you must give the recipients all the rights that
you have.  You must make sure that they, too, receive or can get the
source code.  And you must show them these terms so they know their
rights.

  We protect your rights with two steps: (1) copyright the software, and
(2) offer you this license which gives you legal permission to copy,
distribute and/or modify the software.

  Also, for each author's protection and ours, we want to make certain
that everyone understands that there is no warranty for this free
software.  If the software is modified by someone else and passed on, we
want its recipients to know that what they have is not the original, so
that any problems introduced by others will not reflect on the original
authors' reputations.

  Finally, any free program is threatened constantly by software
patents.  We wish to avoid the danger that redistributors of a free
program will individually obtain patent licenses, in effect making the
program proprietary.  To prevent this, we have made it clear that any
patent must be licensed for everyone's free use or not licensed at all.

  The precise terms and conditions for copying, distribution and
modification follow.

          GNU GENERAL PUBLIC LICENSE
   TERMS AND CONDITIONS FOR COPYING, DISTRIBUTION AND MODIFICATION

  0. This License applies to any program or other work which contains
a notice placed by the copyright holder saying it may be distributed
under the terms of this General Public License.  The "Program", below,
refers to any such program or work, and a "work based on the Program"
means either the Program or any derivative work under copyright law:
that is to say, a work containing the Program or a portion of it,
either verbatim or with modifications and/or translated into another
language.  (Hereinafter, translation is included without limitation in
the term "modification".)  Each licensee is addressed as "you".

Activities other than copying, distribution and modification are not
covered by this License; they are outside its scope.  The act of
running the Program is not restricted, and the output from the Program
is covered only if its contents constitute a work based on the
Program (independent of having been made by running the Program).
Whether that is true depends on what the Program does.

  1. You may copy and distribute verbatim copies of the Program's
source code as you receive it, in any medium, provided that you
conspicuously and appropriately publish on each copy an appropriate
copyright notice and disclaimer of warranty; keep intact all the
notices that refer to this License and to the absence of any warranty;
and give any other recipients of the Program a copy of this License
along with the Program.

You may charge a fee for the physical act of transferring a copy, and
you may at your option offer warranty protection in exchange for a fee.

  2. You may modify your copy or copies of the Program or any portion
of it, thus forming a work based on the Program, and copy and
distribute such modifications or work under the terms of Section 1
above, provided that you also meet all of these conditions:

    a) You must cause the modified files to carry prominent notices
    stating that you changed the files and the date of any change.

    b) You must cause any work that you distribute or publish, that in
    whole or in part contains or is derived from the Program or any
    part thereof, to be licensed as a whole at no charge to all third
    parties under the terms of this License.

    c) If the modified program normally reads commands interactively
    when run, you must cause it, when started running for such
    interactive use in the most ordinary way, to print or display an
    announcement including an appropriate copyright notice and a
    notice that there is no warranty (or else, saying that you provide
    a warranty) and that users may redistribute the program under
    these conditions, and telling the user how to view a copy of this
    License.  (Exception: if the Program itself is interactive but
    does not normally print such an announcement, your work based on
    the Program is not required to print an announcement.)

These requirements apply to the modified work as a whole.  If
identifiable sections of that work are not derived from the Program,
and can be reasonably considered independent and separate works in
themselves, then this License, and its terms, do not apply to those
sections when you distribute them as separate works.  But when you
distribute the same sections as part of a whole which is a work based
on the Program, the distribution of the whole must be on the terms of
this License, whose permissions for other licensees extend to the
entire whole, and thus to each and every part regardless of who wrote it.

Thus, it is not the intent of this section to claim rights or contest
your rights to work written entirely by you; rather, the intent is to
exercise the right to control the distribution of derivative or
collective works based on the Program.

In addition, mere aggregation of another work not based on the Program
with the Program (or with a work based on the Program) on a volume of
a storage or distribution medium does not bring the other work under
the scope of this License.

  3. You may copy and distribute the Program (or a work based on it,
under Section 2) in object code or executable form under the terms of
Sections 1 and 2 above provided that you also do one of the following:

    a) Accompany it with the complete corresponding machine-readable
    source code, which must be distributed under the terms of Sections
    1 and 2 above on a medium customarily used for software interchange; or,

    b) Accompany it with a written offer, valid for at least three
    years, to give any third party, for a charge no more than your
    cost of physically performing source distribution, a complete
    machine-readable copy of the corresponding source code, to be
    distributed under the terms of Sections 1 and 2 above on a medium
    customarily used for software interchange; or,

    c) Accompany it with the information you received as to the offer
    to distribute corresponding source code.  (This alternative is
    allowed only for noncommercial distribution and only if you
    received the program in object code or executable form with such
    an offer, in accord with Subsection b above.)

The source code for a work means the preferred form of the work for
making modifications to it.  For an executable work, complete source
code means all the source code for all modules it contains, plus any
associated interface definition files, plus the scripts used to
control compilation and installation of the executable.  However, as a
special exception, the source code distributed need not include
anything that is normally distributed (in either source or binary
form) with the major components (compiler, kernel, and so on) of the
operating system on which the executable runs, unless that component
itself accompanies the executable.

If distribution of executable or object code is made by offering
access to copy from a designated place, then offering equivalent
access to copy the source code from the same place counts as
distribution of the source code, even though third parties are not
compelled to copy the source along with the object code.

  4. You may not copy, modify, sublicense, or distribute the Program
except as expressly provided under this License.  Any attempt
otherwise to copy, modify, sublicense or distribute the Program is
void, and will automatically terminate your rights under this License.
However, parties who have received copies, or rights, from you under
this License will not have their licenses terminated so long as such
parties remain in full compliance.

  5. You are not required to accept this License, since you have not
signed it.  However, nothing else grants you permission to modify or
distribute the Program or its derivative works.  These actions are
prohibited by law if you do not accept this License.  Therefore, by
modifying or distributing the Program (or any work based on the
Program), you indicate your acceptance of this License to do so, and
all its terms and conditions for copying, distributing or modifying
the Program or works based on it.

  6. Each time you redistribute the Program (or any work based on the
Program), the recipient automatically receives a license from the
original licensor to copy, distribute or modify the Program subject to
these terms and conditions.  You may not impose any further
restrictions on the recipients' exercise of the rights granted herein.
You are not responsible for enforcing compliance by third parties to
this License.

  7. If, as a consequence of a court judgment or allegation of patent
infringement or for any other reason (not limited to patent issues),
conditions are imposed on you (whether by court order, agreement or
otherwise) that contradict the conditions of this License, they do not
excuse you from the conditions of this License.  If you cannot
distribute so as to satisfy simultaneously your obligations under this
License and any other pertinent obligations, then as a consequence you
may not distribute the Program at all.  For example, if a patent
license would not permit royalty-free redistribution of the Program by
all those who receive copies directly or indirectly through you, then
the only way you could satisfy both it and this License would be to
refrain entirely from distribution of the Program.

If any portion of this section is held invalid or unenforceable under
any particular circumstance, the balance of the section is intended to
apply and the section as a whole is intended to apply in other
circumstances.

It is not the purpose of this section to induce you to infringe any
patents or other property right claims or to contest validity of any
such claims; this section has the sole purpose of protecting the
integrity of the free software distribution system, which is
implemented by public license practices.  Many people have made
generous contributions to the wide range of software distributed
through that system in reliance on consistent application of that
system; it is up to the author/donor to decide if he or she is willing
to distribute software through any other system and a licensee cannot
impose that choice.

This section is intended to make thoroughly clear what is believed to
be a consequence of the rest of this License.

  8. If the distribution and/or use of the Program is restricted in
certain countries either by patents or by copyrighted interfaces, the
original copyright holder who places the Program under this License
may add an explicit geographical distribution limitation excluding
those countries, so that distribution is permitted only in or among
countries not thus excluded.  In such case, this License incorporates
the limitation as if written in the body of this License.

  9. The Free Software Foundation may publish revised and/or new versions
of the General Public License from time to time.  Such new versions will
be similar in spirit to the present version, but may differ in detail to
address new problems or concerns.

Each version is given a distinguishing version number.  If the Program
specifies a version number of this License which applies to it and "any
later version", you have the option of following the terms and conditions
either of that version or of any later version published by the Free
Software Foundation.  If the Program does not specify a version number of
this License, you may choose any version ever published by the Free Software
Foundation.

  10. If you wish to incorporate parts of the Program into other free
programs whose distribution conditions are different, write to the author
to ask for permission.  For software which is copyrighted by the Free
Software Foundation, write to the Free Software Foundation; we sometimes
make exceptions for this.  Our decision will be guided by the two goals
of preserving the free status of all derivatives of our free software and
of promoting the sharing and reuse of software generally.

             NO WARRANTY

  11. BECAUSE THE PROGRAM IS LICENSED FREE OF CHARGE, THERE IS NO WARRANTY
FOR THE PROGRAM, TO THE EXTENT PERMITTED BY APPLICABLE LAW.  EXCEPT WHEN
OTHERWISE STATED IN WRITING THE COPYRIGHT HOLDERS AND/OR OTHER PARTIES
PROVIDE THE PROGRAM "AS IS" WITHOUT WARRANTY OF ANY KIND, EITHER EXPRESSED
OR IMPLIED, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF
MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE.  THE ENTIRE RISK AS
TO THE QUALITY AND PERFORMANCE OF THE PROGRAM IS WITH YOU.  SHOULD THE
PROGRAM PROVE DEFECTIVE, YOU ASSUME THE COST OF ALL NECESSARY SERVICING,
REPAIR OR CORRECTION.

  12. IN NO EVENT UNLESS REQUIRED BY APPLICABLE LAW OR AGREED TO IN WRITING
WILL ANY COPYRIGHT HOLDER, OR ANY OTHER PARTY WHO MAY MODIFY AND/OR
REDISTRIBUTE THE PROGRAM AS PERMITTED ABOVE, BE LIABLE TO YOU FOR DAMAGES,
INCLUDING ANY GENERAL, SPECIAL, INCIDENTAL OR CONSEQUENTIAL DAMAGES ARISING
OUT OF THE USE OR INABILITY TO USE THE PROGRAM (INCLUDING BUT NOT LIMITED
TO LOSS OF DATA OR DATA BEING RENDERED INACCURATE OR LOSSES SUSTAINED BY
YOU OR THIRD PARTIES OR A FAILURE OF THE PROGRAM TO OPERATE WITH ANY OTHER
PROGRAMS), EVEN IF SUCH HOLDER OR OTHER PARTY HAS BEEN ADVISED OF THE
POSSIBILITY OF SUCH DAMAGES.

           END OF TERMS AND CONDITIONS

   Appendix: How to Apply These Terms to Your New Programs

  If you develop a new program, and you want it to be of the greatest
possible use to the public, the best way to achieve this is to make it
free software which everyone can redistribute and change under these terms.

  To do so, attach the following notices to the program.  It is safest
to attach them to the start of each source file to most effectively
convey the exclusion of warranty; and each file should have at least
the "copyright" line and a pointer to where the full notice is found.

    
    Copyright (C) 19yy  

    This program is free software; you can redistribute it and/or modify
    it under the terms of the GNU General Public License as published by
    the Free Software Foundation; either version 2 of the License, or
    (at your option) any later version.

    This program is distributed in the hope that it will be useful,
    but WITHOUT ANY WARRANTY; without even the implied warranty of
    MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
    GNU General Public License for more details.

    You should have received a copy of the GNU General Public License
    along with this program; if not, write to the Free Software
    Foundation, Inc., 675 Mass Ave, Cambridge, MA 02139, USA.

Also add information on how to contact you by electronic and paper mail.

If the program is interactive, make it output a short notice like this
when it starts in an interactive mode:

    Gnomovision version 69, Copyright (C) 19yy name of author
    Gnomovision comes with ABSOLUTELY NO WARRANTY; for details type `show w'.
    This is free software, and you are welcome to redistribute it
    under certain conditions; type `show c' for details.

The hypothetical commands `show w' and `show c' should show the appropriate
parts of the General Public License.  Of course, the commands you use may
be called something other than `show w' and `show c'; they could even be
mouse-clicks or menu items--whatever suits your program.

You should also get your employer (if you work as a programmer) or your
school, if any, to sign a "copyright disclaimer" for the program, if
necessary.  Here is a sample; alter the names:

  Yoyodyne, Inc., hereby disclaims all copyright interest in the program
  `Gnomovision' (which makes passes at compilers) written by James Hacker.

  , 1 April 1989
  Ty Coon, President of Vice

This General Public License does not permit incorporating your program into
proprietary programs.  If your program is a subroutine library, you may
consider it more useful to permit linking proprietary applications with the
library.  If this is what you want to do, use the GNU Library General
Public License instead of this License.

Comments here

Quick List