[yocto] [PATCH 09/11][auh] upgradehelper.py: Change policy for send emails and fix error passing

[Paul Eggleton]

On Wednesday 10 June 2015 16:28:50 Aníbal Limón wrote:
> Now send emails almost in all cases this give the maintainer
> patches and diff to continue work also if the build isn't
> succesful.
>
> [YOCTO #7489]
> 
> Signed-off-by: Aníbal Limón <anibal.limon at linux.intel.com>
> ---
>  upgradehelper.py | 19 ++++++++++---------
>  1 file changed, 10 insertions(+), 9 deletions(-)
> 
> diff --git a/upgradehelper.py b/upgradehelper.py
> index b1f075d..a4aa0ab 100755
> --- a/upgradehelper.py
> +++ b/upgradehelper.py
> @@ -381,8 +381,11 @@ class Updater(object):
>                  "Attached are the patch, license diff (if change) and
> bitbake log.\n\n" \ "Regards,\nThe Upgrade Helper"
> 
> -            # don't bother maintainer with mail if the recipe is already up
> to date -            if status == "UpgradeNotNeededError":
> +            if status == "Error" or status == "FetchError" or\
> +               status == "UpgradeNotNeededError":
> +                D( "%s: Don't send email to maintainer because the error
> was " \ +                   "%s and the information isn't useful, please
> review it." \ +                    % (self.pn, status))

Obviously this is in the existing code, but I'm not hugely keen on checking 
the error name as a string - I'd much rather we checked it with isinstance 
here. That might require us to have all errors that the maintainer can fix as 
subclasses of a particular class though.

Also, do you have an idea of the types of exception that might now trigger an 
email that don't inherit from our "Error" class here but are actually worth 
telling the maintainer about? I can certainly think about situations where 
bugs in the script here could trigger a large number of emails to maintainers 
which we probably wouldn't want.

Cheers,
Paul

-- 

Paul Eggleton
Intel Open Source Technology Centre