From: "Aníbal Limón" <anibal.limon@linux.intel.com>
To: Paul Eggleton <paul.eggleton@linux.intel.com>
Cc: yocto@yoctoproject.org
Subject: Re: [PATCH 09/11][auh] upgradehelper.py: Change policy for send emails and fix error passing
Date: Thu, 11 Jun 2015 15:56:57 -0500 [thread overview]
Message-ID: <5579F619.4080504@linux.intel.com> (raw)
In-Reply-To: <1740590.zL5b4dpnL6@peggleto-mobl.ger.corp.intel.com>
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@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
>
next prev parent reply other threads:[~2015-06-11 20:55 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-06-10 16:28 [PATCH 00/11][auh]: Add support of new upstream mechanism and improvments Aníbal Limón
2015-06-10 16:28 ` [PATCH 01/11][auh] upgradehelper.py: Fix status_msg in pkg_upgrade_handler Aníbal Limón
2015-06-10 16:28 ` [PATCH 02/11][auh] upgradehelper.py: Make usage of new upstream detection mechanism Aníbal Limón
2015-06-10 16:28 ` [PATCH 03/11][auh] upgradehelper.py: Use settings.from as email for commits Aníbal Limón
2015-06-10 16:28 ` [PATCH 04/11][auh] upgradehelper.py: Improve usage when try to upgrade one recipe Aníbal Limón
2015-06-10 16:28 ` [PATCH 05/11][auh] upgrade_helper.py: Make notice of License change into email Aníbal Limón
2015-06-10 16:28 ` [PATCH 06/11][auh] upgradehelper.py: Add specific information about machines build succeed Aníbal Limón
2015-06-10 16:28 ` [PATCH 07/11][auh] upgradehelper.py: Move recipe work into upgradehelper work dir Aníbal Limón
2015-06-10 16:28 ` [PATCH 08/11][auh] upgradehelper.py: Fix interactive mode when recipe upgrade finish Aníbal Limón
2015-06-10 16:28 ` [PATCH 09/11][auh] upgradehelper.py: Change policy for send emails and fix error passing Aníbal Limón
2015-06-11 20:51 ` Paul Eggleton
2015-06-11 20:56 ` Aníbal Limón [this message]
2015-06-11 21:05 ` Paul Eggleton
2015-06-11 21:18 ` Aníbal Limón
2015-06-10 16:28 ` [PATCH 10/11][auh] upgradehelper.py: Change print to logger info Aníbal Limón
2015-06-10 16:28 ` [PATCH 11/11][auh] README: Edit Maintainece section to add current maintainer Aníbal Limón
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=5579F619.4080504@linux.intel.com \
--to=anibal.limon@linux.intel.com \
--cc=paul.eggleton@linux.intel.com \
--cc=yocto@yoctoproject.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.