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.li...@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


--
_______________________________________________
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Reply via email to