|
||||||||
|
This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators. For more information on JIRA, see: http://www.atlassian.com/software/jira |
||||||||
You received this message because you are subscribed to the Google Groups "Jenkins Issues" group.
To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-issues+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.
> which seems to have the implied requirement that the estimated time uses successful builds (or rather builds with somewhat homogeneous durations), otherwise this feature wouldn't make a lot of sense.
I don't see this. Of course it also would make sense, if the 'usual' outcome of a build is a failure.
> Are there situations the new estimates are actually more helpful to users?
One situation I sometimes see myself is, when I try to set up a new job which is failing several times until I 1st manage to get it successful. In that case an estimation how long the build will take is of some use.
Also build often tend to fail for several times in a row until they are fixed. In that case it's IMO also useful to know who long the build will take.
> Estimates that are deliberately far off any actual build durations OTOH I have no need for.
They are not deliberately far off. Quite in contrary they try to produce the best estimate given the available data,
As said, if you want to provide an algorithm which would create more accurate estimations - what is inherently difficult as the usage patterns vary so much - I'll would be fine to include it.