> Now error messages are standardized across whole deployment process.
"Failed tasks: Task[fuel_pkgs/1], Task[fuel_pkgs/3], ..." is an utter nonsense.
It gives no slightest idea about what exactly is wrong and how to fix and/or work around it.
> We have a documentation to create local package mirrors exactly for such cases.
And how on Earth a user can guess that "Task[fuel_pkgs/x]" stands for "your Internet link is too slow, consider creating a local mirror".
>> Please remove the hard-coded timeout
> And what's next? Which deployment time is okay?
That depends. A tool (Fuel) must not impose a policy, it might provide a mechanism to abort deployment if package download/installation takes "too long" (and that "too long" must be configurable)
> Now error messages are standardized across whole deployment process.
"Failed tasks: Task[fuel_pkgs/1], Task[fuel_pkgs/3], ..." is an utter nonsense.
It gives no slightest idea about what exactly is wrong and how to fix and/or work around it.
> We have a documentation to create local package mirrors exactly for such cases.
And how on Earth a user can guess that "Task[fuel_pkgs/x]" stands for "your Internet link is too slow, consider creating a local mirror".
>> Please remove the hard-coded timeout
> And what's next? Which deployment time is okay?
That depends. A tool (Fuel) must not impose a policy, it might provide a mechanism to abort deployment if package download/ installation takes "too long" (and that "too long" must be configurable)