HTCondorWiki: Using Rust

 
 {section: 10 foot view}
 
-You can access the Condor RUST queue from any dept. linux workstation. To setup, add /p/condor/home/rust/bin/sys to your PATH. If you don't have it already, you probably also want to add /p/condor/home/bin to your PATH, since there are some handy scripts in there to help deal with RUST.
+You can access the HTCondor RUST queue from any dept. linux workstation. To setup, add /p/condor/home/rust/bin/sys to your PATH. If you don't have it already, you probably also want to add /p/condor/home/bin to your PATH, since there are some handy scripts in there to help deal with RUST.
 
 To manage the RUST queues from a consolidated GUI tool, fire up /p/condor/home/bin/xrust. The rest of this section details the RUST command line interface, which is ultimately more powerful.
 
@@ -90,7 +90,7 @@
   acta <number>	<other action flags>
   acts <number>	<other action flags>
 
-You can also add comments to a ticket from the command line. This allows you to enter text into the ticket without it being sent to the ticket user. For example, when I was going through RUST, discovering old tickets, I sent email to various Condor folks asking them where a ticket stood, since I couldn't tell from the ticket itself. I've just entered their responses into the appropriate tickets as a comment. It's pretty slick.
+You can also add comments to a ticket from the command line. This allows you to enter text into the ticket without it being sent to the ticket user. For example, when I was going through RUST, discovering old tickets, I sent email to various HTCondor folks asking them where a ticket stood, since I couldn't tell from the ticket itself. I've just entered their responses into the appropriate tickets as a comment. It's pretty slick.
 
 Here's how it works: You either need to use the acta/acts scripts, or provide --queue and --num arguments to "action", but the last thing is just "--comment". After that, it reads from stdin whatever comment you want, until it sees an EOF. So, you can either type it in right there, and hit ^D, or you can redirect stdin from a file, pipe, whatever.
 
@@ -232,7 +232,7 @@
 
 {subsection: 6) Dealing with LCG Savannah tickets}
 
-As of 5/2005 tickets, Condor related tickets from the LCG Savannah (think Bugzilla) server are re-posted into RUST. Our RUST server keeps things in sync with Savannah using the savannah_repost and savannah_tag scripts in /p/condor/home/rust/scripts. The only thing you need to do differently is update the states in both RUST and Savannah. They have a much more complex state model and there's no good way to do a 1->1 mapping. All changes can be made by following the URL in the ticket. If you don't have an LCG Savannah account you can sign up for one (should be a link on the left) and email Erwin Laure (Erwin.Laure@cern.ch) to get write access.
+As of 5/2005 tickets, HTCondor related tickets from the LCG Savannah (think Bugzilla) server are re-posted into RUST. Our RUST server keeps things in sync with Savannah using the savannah_repost and savannah_tag scripts in /p/condor/home/rust/scripts. The only thing you need to do differently is update the states in both RUST and Savannah. They have a much more complex state model and there's no good way to do a 1->1 mapping. All changes can be made by following the URL in the ticket. If you don't have an LCG Savannah account you can sign up for one (should be a link on the left) and email Erwin Laure (Erwin.Laure@cern.ch) to get write access.
 
 When a Savannah ticket comes in (it should say it's from LCG Savannah in the first line) it's in the "none" state. After taking a quick look you should change the state to either "accepted" or "rejected". If you accept the ticket, move it to "in progress" when you start working on it. Don't do this too soon -- if tickets are in progress for a long time people will start asking questions. When everything's done you mark the ticket "ready for integration" and resolve the RUST.
 
@@ -256,13 +256,13 @@
 Special status settings (all of these require human intervention to get a ticket into one of these states):
 
 bug
-_:You've found a real bug in Condor and we still have to fix it and/or check the fixes into CVS before we change the status. Tickets shouldn't be resolved from the bug status, instead, when the fix is ready and the changes checked into CVS, the status should be set to "release" (see below).
+_:You've found a real bug in HTCondor and we still have to fix it and/or check the fixes into CVS before we change the status. Tickets shouldn't be resolved from the bug status, instead, when the fix is ready and the changes checked into CVS, the status should be set to "release" (see below).
 
 feature
 _:A ticket is requesting a new feature. It might be in the next version, or it might takes months or years before we do it. Once the feature is actually implemented and checked into CVS, please change the status to "release" (see below).
 
 release
-_:A ticket that is now just waiting for the next release of Condor before it can be resolved. Tickets about bugs or features that were fixed or implemented, and checked into CVS, can then be put into the "release" status. This way, we'll know when a new version is ready for release. Plus, once the new release is on the web, we can easily go back and resolve all the "release" tickets with an email announcing the new version.
+_:A ticket that is now just waiting for the next release of HTCondor before it can be resolved. Tickets about bugs or features that were fixed or implemented, and checked into CVS, can then be put into the "release" status. This way, we'll know when a new version is ready for release. Plus, once the new release is on the web, we can easily go back and resolve all the "release" tickets with an email announcing the new version.
 
 manual
 _:The ticket is pointing out unclarity, an error, or an omission in the manual.
@@ -388,7 +388,7 @@
   condor-admin aliased to:
           "|/p/condor/home/rust/scripts/filter_mail"
 
-filter_mail is a script that Nate M wrote. It steers mail into either the condor-admin, condor-support, the vdt-support queues. It also pulls out the download logs from the binary CGIs and the Condor pool reports (one of the data sources for the condor world maps). It also runs spamassasin on the incoming mail and drops spam. It logs to /tmp/filter_mail.log on chopin.
+filter_mail is a script that Nate M wrote. It steers mail into either the condor-admin, condor-support, the vdt-support queues. It also pulls out the download logs from the binary CGIs and the HTCondor pool reports (one of the data sources for the HTCondor world maps). It also runs spamassasin on the incoming mail and drops spam. It logs to /tmp/filter_mail.log on chopin.
 
 A broken filter_mail is very bad.  Rust will bounce.  Always test your changes.  You can test that it compiles at all by using "perl -c filter_mail"; if that fails complaining about Mail::Audit, temporarily uncomment the line "use lib 'test-lib/site-perl';".  You can also try sending message to condor-admin from a non-CS address and verify that it creates a new ticket.