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.
-RUST Status Settings
+{section: RUST Status Settings}
We handle a lot of RUST. It's much easier to view the status of a ticket and get a sense of the deal than to have to read through the whole ticket log to figure out what's going on. So, it's very important that everyone working with RUST make a big effort to set the appropriate status for tickets assigned to them. This will make everyone's life easier.
@@ -241,24 +241,30 @@
The main status settings:
new
- Only the user has sent email. No staff has ever responded.
+_:Only the user has sent email. No staff has ever responded.
+
open
- Staff has responded, but the ball is still in our court. This status change is automatic whenever staff sends email on a new ticket, or the user sends email back on a pending ticket. pending Staff has responded, and now the ball is in the user's court. You have to manually set a ticket to pending (either with command-line actions or with a "X-Rust: set status pending" line somewhere in the message you send out).
+_:Staff has responded, but the ball is still in our court. This status change is automatic whenever staff sends email on a new ticket, or the user sends email back on a pending ticket. pending Staff has responded, and now the ball is in the user's court. You have to manually set a ticket to pending (either with command-line actions or with a "X-Rust: set status pending" line somewhere in the message you send out).
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 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).
+
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).
+_: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 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.
+
manual
- The ticket is pointing out unclarity, an error, or an omission in the manual.
+_:The ticket is pointing out unclarity, an error, or an omission in the manual.
+
port
- A request for a port to a new platform.
+_:A request for a port to a new platform.
+
source
- A source request.
+_:A source request.
1 foot view (ticket lock files, editing header files, etc)
