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

[Aníbal Limón]

Hi Paul,

Comments below,

Kind regards,
     alimon

On 11/06/15 15:51, Paul Eggleton wrote:
> 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.
Yes i'll change the string testing for isinstance.
>
> 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.
That's good observation i filter all the errors that don't are in the 
class of Error,
also i avoided Error/FetchError/UpgradeNotNeeded because when happens no 
usueful info is
generated.
>
> Cheers,
> Paul
>