(Unfinished as of June 4 when Alain released his prototype: 1. Move the index into AFS? It's big and AFS might by slow. 2. Regenerate the index nightly, probably through cron. The indexing takes an hour or so.)
-RUST etiquette
-1) When to respond:
+{section: RUST etiquette}
+{subsection: 1) When to respond}
If you have a condor-support ticket assigned to you, that pretty much means you need to stop everything you're doing and deal with that RUST. We're under contract to reply within a day or something, and have a solution or work-around within 3 days. So, if you have condor-support RUST, that has to be the highest priority thing on your plate. Condor-admin tickets are generally a little more low-key, but you should at least try to respond ASAP and let people know the status of their request. Condor-admin RUST from local users in CS should be highest priority. After that, there are some important sites for us, via the Alliance, PACS, etc. Then, the lowest priority are all the other random users and pools out there.
-2) How to respond:
+
+{subsection: 2) How to respond}
RUST includes a lot of extra stuff in messages when it gets sent to ticket owners for their own info. This is potentially confusing for users, and certainly lots of noise, so _PLEASE_ delete that stuff if you include an original message in your reply. B/c all email in and out of RUST is stored in an archive, and sent to lots of people, it's a good idea to trim out extra junk. In particular, users will often send their entire config file, or log files, etc. DO NOT include the whole thing in your reply, only site the important part they need to look at to solve their problem. In general, include AS LITTLE from the original message as you can to make your point.
-3) Resolve as you go:
+
+{subsection: 3) Resolve as you go}
Once you're done with a ticket, please resolve it, so we don't have to go back through old RUST, trying to resolve old tickets that no longer need to be open. It's much easier that way, for everyone.
-4) If you can't resolve, set the status accordingly.
+
+{subsection:4) If you can't resolve, set the status accordingly}
We have a lot of valid status settings we use, to help keep our tickets sorted. If you can't resolve a ticket relatively quickly, please set its status to the appropriate one described in the section below.
-5) Don't hesitate to reply with "RTFM" (Read The Friggin' Manual).
+
+{subsection: 5) Don't hesitate to reply with "RTFM" (Read The Friggin' Manual)}
The only things to watch out for here are try to be nice about it, and try to point people to the specific section of the manual they need to read. We put a lot of work into our docs so that we don't have to spend as much time writing RUST about the same things over and over again. We should probably put a FAQ in the manual, too, but that's another story.
-6) Dealing with LCG Savannah tickets.
+
+{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.
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.
-7) Handling source code requests (as of 2006-02-02):
-
-(This is largely irrelevant. If someone wants 7.0.0 or later, it's available for download from the public download page.)
-
-The RUST queue frequently receives Condor source code requests. Here is the official policy for handling these requests [paraphrasing Alain Roy]:
-
- * Change the RUST status to "source".
- * If you are certain that it is some random yokel tell them "we are working on it, it will be announced on our web site, http://www.cs.wisc.edu/condor/ ,when it is available." Alternatively, interested users may subscribe to the condor-world mailing list, http://www.cs.wisc.edu/condor/mail-lists/ .
- * If you think it might be a random yokel but you aren't sure, ask another Condor staff member to double-check your yokelometer results.
- * Requests from known collaborators, or sites with a support agreement (see http://www.cs.wisc.edu/condor/developers/important_rust_people.html) get source code immediately, no questions asked. Assign these tickets to "kludwig". Kristine Ludwig will take care of the rest.
- * If you think there is a chance that this might be someone important to Condor/Miron, then ask Miron if we should give the person source. Do not just assign him the Rust: direct email is a better channel. You may need to monitor these requests to complete the final disposition.
- * We respectfully decline requests to redistribute our source code within third party distributions.
- * We respectfully decline requests to agree to third party source code license agreements.
RUST Status Settings
