Description
The naming mechanism introduced in CRUNCH-262 has a flaw. It adds (m/n) to the end of job name, where m is the current stage number at planning time and n is the total number of stages.
Suppose in the following case, where A takes a long time to run, when B is submitted, C and D have completed. As there are 3 jobs done, we should expect B to be (4/5) rather than (2/5) or (3/5).
A C
B D
\ /
E
In planning time, we don't have a clue which stage will complete earlier. So I think it better to assign it at runtime.
One problem here is that the user may access to Job instance before it submits. So he may observe a sudden change of job name.