From: Greg Ercolano <erco@(email surpressed)>
Subject: Rush 102.42a7 minor maintenance release
   Date: Fri, 29 Sep 2006 20:34:42 -0400

Rush 102.42a7 is a minor maintenance release; minor features + fixes
to 102.42a6. The upgrade is *free* to all customers.

If you're already at 102.42a6, don't feel motivated to upgrade unless
you see a feature or fix you really need.

But if you are running a release older than 102.42a6, you should consider
upgrading, as a6/a7 have many good features/fixes over older releases.

IRUSH FEATURE HIGHLIGHTS IN A7
The most interesting features in 102.42a7 are in irush:

    o Switching jobs in irush now updates the Irush title bar with the job title.

    o Added 'Upper:AllCpus' option to the 'Edit Hotkeys' menu
      This way one can make hotkeys for 'rush -lac' that includes color-coded reports.

    o Added ability for 'Hotkeys' to be 'repeatable'.
      You can just hit 'REP', then hit one of the pre-programmed hotkeys
      or an Irush|Hotkey menu item, and it will repeat that operation.

    o Enabled better autodetection when new columns are added to reports.
      Helps custom generated reports work as expected as 'hotkey' scripts.

    o Control buttons now remain a fixed size during irush window resizing.
      (Replaced Fl_Group with FixedSizeGroup)

MAYA SUBMIT SCRIPT NAMING CHANGE IN A7
    In 102.42a7, the newer Maya submit script will now always be called 'submit-maya'.
    The older 'mayabatch' style script has been demoted to 'submit-maya-old'.
    The name changes are simple:

	The old style 'mayabatch' script has been renamed to 'submit-maya-old'.
	(it used to be called submit-maya)

	The new style 'Render -r [sw|mr]' script is now called 'submit-maya'.
	(it used to be called submit-maya6)

    So basically the newest Maya script is 'submit-maya'.

FIXES IN A7
    Fixes in this version are nothing critical to most users.
    See the release notes for specifics.

    Customers with large networks of linux machines (>100 machines)
    may want to upgrade a6 to a7 for an optimizations added to prevent
    per-frame rendering DNS lookups.

MIXING RELEASES
    If you are already running a 102.42* release, you can mix this release
    with your existing 102.42* version for testing purposes; the 102.42* series
    are all network inter-compatible.

    Only if you have a release older than 102.42 (eg. 102.41 or 102.40..)
    is it an issue to mix versions.

HOW TO UPGRADE
    To upgrade to 102.42a7, you can contact me directly via email,
    erco [at] seriss.com from your business email address, and I'll
    supply you with the download info for the upgrade.

Hi Greg;

A couple of quick questions:

Cheers,

Dan

	(Apparently Dan meant to send this on private email instead of the group.
	I'll redact the post from the newsgroup if he requests me to)

	We've been talking about adding a feature in irush that would allow
	reports to be limited to certain criteria, similar to searches in
	email browsers, in addition to the current 'Hotkey' approach, but
	I'll make a few replies here.


Dan Murray wrote:

[posted to rush.general]
Hi Greg;

So we've finally had some time to put our thoughts together on what we'd like to discuss with you re: Rush.

Our main focus is on filtering/sorting and affecting change regarding priority post-submit. [..]

	Yes, I've been working on a design for filtering. The main
	request I get is to be able to limit job reports to only show
	jobs owned by a certain user or users.

	I figure the easiest way to do that would be to have a 'Filter'
	button on the main page that opens a dialog allowing one to
	specify various search criteria for the different reports, and
	make it clear when the filter is on or off.

	At its simplest, it could simply be a small input field instead
	of a button, eg. next to the Jobid: field:

		Job Filter: fred|jack

	..which would limit the 'jobs' and 'all jobs' reports to only show
	jobs owned by fred or jack.

	At its most flexible it would be a full on dialog, similar to the
	Thunderbird email search dialog, Edit|Find|Search Messages, where
	one can pick various field names, and supply additive/subtractive
	search strings.

	Also, I've gotten a few requests now for multilevel sorting,
	ie. primary and secondary sorting. That will probably involve a
	right click menu of the sort headings. That shouldn't be too hard.

	Finally, I've been working on adding the ability for one to fully
	customize the jobs/cpus/frames reports, so that one can add/remove
	fields that show up in the reports. Similar to how one can add fields
	to the Thunderbird email screen via the popup menu at the right of the
	column headers, and being able to drag fields left+right.

	This would also be available from the command line, eg.
	"rush -lj -fmt 'FieldName[width] FieldName[width]..' "

Regarding priority, we're finding adjusting priority after the fact
a bit cumbersome.  Ideally, we'd like the ability to apply changes
(on priority and/or cpu spec) at the job level, rather than having
to identify and take action at the task id level.

	Since priorities can be at the per-cpu level, such a generalized
	approach would have to assume only one priority for the entire job.
	I could add a "Priority:" field to the jobs report, but whatever you
	type there would have to be applied to the whole job.

	Any other approach would involve presenting the user with a list
	of all the cpus, which you might as well do by hitting the 'cpus'
	button the way you do now. We can discuss this though by phone.

Typically, we really don't care about the task level as we just want to
move the entire job up or down in the priority list.  Ultimately, we want
to build something where we can affect priority at the project/shot/scene/user
levels.  We're not expecting you to handle this but we need a clean way to
identify these jobs with our own tools and then be able to apply blanket changes.

	I think I can at least show the priority values in a user selectable
	field when I finish implementing the 'rush -lj -fmt FieldName[width] Fieldname[width]',
	where one of the fieldnames would be 'Priority', which would show all the priorities
	concatenated, eg:

		+any=4@999,+any=10@1

	At very least with that, you could highlight the job, and enter a new
	priority value, or at very least supply a way so you can program a hotkey
	that runs your own script to prompt the user for a new priority value
	that you can apply in any way you want.

So for example we may want to identify all narnia/dbx100 shots and move them
to the highest priority because we need that shot out asap.

	I see, yes, as it is now, you'd have to highlight all the narnia/dbx100
	and hit 'Set Jobid', then hit 'Cpus' and do a select all, then enter
	a new priority. Which probably isn't so bad, but I can see where you'd
	at least want to see the current priority info in the main jobs report.

	Now that irush has the resizable columns, that makes it possible for me
	to show priority values in a special column of the jobs report, which will
	be accessible once I finish the version with the 'rush -fmt' option to allow
	for customizable fields.

Any number of screening possibilities could be used to identify the job list
we're interested in affecting.  Maybe you have some ideas on how we might best
accomplish this.

	I think the current Hotkey approach will get you there.. I recently
	made a small custom hotkey script for one customer to see priorities
	in a customized jobs report. I'll follow up with a script that does
	what I think you want.

It would also be nice if we could generate 'priority'-centric reports.
Perhaps we want to see all jobs at 'high' priority.  (We've implemented
a low/med/high priority enumeration that the users can select from, so 'high'
has a specific value dependent upon the host group the job is running under).
In effect, this would be more of a priority status report than a per-job report.

	I think a hotkey script would be the best way to implement this,
	so that you see what you want to see, 'high', 'med' and 'low' in your report,
	and a separate script to let one change the priority, given your high/med/low
	values.

	I'll answer the rest of your questions separately, to keep the emails
	shorter.

--
Greg Ercolano, erco@(email surpressed)
Rush Render Queue, http://seriss.com/rush/
Tel: (Tel# suppressed)
Fax: (Tel# suppressed)
Cel: (Tel# suppressed)

[posted to rush.general]


> Typically, we really don't care about the task level as we just want to
> move the entire job up or down in the priority list.  Ultimately, we want
> to build something where we can affect priority at the
project/shot/scene/user
> levels.  We're not expecting you to handle this but we need a clean way to
> identify these jobs with our own tools and then be able to apply blanket
changes.

>	I think I can at least show the priority values in a user selectable
>	field when I finish implementing the 'rush -lj -fmt FieldName[width]
Fieldname[width]',
>	where one of the fieldnames would be 'Priority', which would show
all the priorities
>	concatenated, eg:
>
>		+any=4@999,+any=10@1
>
>	At very least with that, you could highlight the job, and enter a
new
>	priority value, or at very least supply a way so you can program a
hotkey
>	that runs your own script to prompt the user for a new priority
value
>	that you can apply in any way you want.

I think it would be great to see priorities in the jobs report. We too find
it more useful to change an entire jobs priority and if that could be done
from the jobs page all the better. We rarely use individual cpu priorities
and this would make managing many jobs a lot easier for us, we could sort
jobs by user/title and then select multiple jobs and assign a new priority
in one hit. Some of the guys here have custom scripts to do this using jobs
selected from the jobs report and firing off another perl script as you
suggest, but having the priority changeable from the jobs page gets a thumbs
up from me. 

-- 
Greg Ercolano, erco@(email surpressed)
Rush Render Queue, http://seriss.com/rush/
Tel: (Tel# suppressed)
Fax: (Tel# suppressed)
Cel: (Tel# suppressed)