[OE-core] About auto-upgrade-helper's enhancement

[Robert Yang]

Hi Paul,

Thanks for the reply.

On 11/30/2017 11:27 AM, Paul Eggleton wrote:
> Hi Robert,
> 
> FYI Anibal has left Intel; the AUH is now being worked on by Alex Kanavin (on
> CC).
> 
> On Thursday, 30 November 2017 3:23:25 PM NZDT Robert Yang wrote:
>> I tried auto-upgrade-helper, it is very helpful when upgrade recipes.
>> I'd like to make some enhancements to make it can be easily used by the
>> maintainer (recipe upgrader) himself:
>> 1) Don't send email when maintainer uses it, for example, when I want to
>>      upgrade "strace", I don't need it send email to anyone.
>> 2) Use git's user.name and user.email in git commit when not send email,
>>      we need let the maintainer take responsible for it.
> 
> It's probably not just about not sending email - manually running the script
> without sending email is also useful when testing the AUH script during
> development so we'd need to switch usage of the git user/email a different
> way, but otherwise yes this seems reasonable. Probably we would just have some
> kind of local-only mode, possibly that's made the default (or can be
> configured to be).

I prefer default to local.

> 
>> 3) Do the commit on the recipes when the upgrade is succeed, currently,
>>      it keeps the commit when failed, but removed it when succeed.
> 
> No problem as long as it doesn't interfere with automated operation on the
> server.
> 
>> 4) Make upgradehelper.py can accept multiple recipes as args.
> 
> Seems reasonable yes.
> 
>> 5) It's a small tool and helpful when upgrade recipes, can we move it into
>>      oe-core/scripts, please ?
> 
> So for manual (or should I say semi-automatic) recipe upgrades, our primary
> tool is "devtool upgrade" - at the moment it is true that there are things
> that the AUH can do that devtool upgrade can't (e.g. auto-detecting the latest
> upstream version, handling LIC_FILES_CHKSUM, etc.), but I believe Alex will be
> working on some of those and then will be moving the AUH to use devtool
> upgrade itself so that we don't have two codebases for the same task. We don't
> plan to deprecate manual usage of the AUH, but if there are use cases that
> devtool upgrade cannot currently handle, then assuming they fit I would like
> to handle them there first and point most users at devtool upgrade rather than
> manually running the AUH, since devtool upgrade is much more suited to
> enabling the work that follows on when an upgrade cannot be completed
> automatically.
> 
> Have you looked at devtool upgrade at all?

I tried "devtool upgrade less --version 529" just now. What I like AUH most is
it can help update md5sum, do the commit, and do build testing on a few qemu
machines, that really helps a lot, which can enhance the quality of patches.
Does "devtool upgrade" has a plan to do that, please ?

// Robert

> 
> Cheers,
> Paul
>