[U-Boot] [GIT PULL] Pull request: u-boot-imx u -boot-imx-20190101

[Stefano Babic]

On 09/01/19 17:21, Tom Rini wrote:
> On Wed, Jan 09, 2019 at 04:48:06PM +0100, Stefano Babic wrote:
>> Hi Tom,
>>
>> On 02/01/19 02:02, Tom Rini wrote:
>>> On Tue, Jan 01, 2019 at 02:51:53PM +0100, Stefano Babic wrote:
>>>
>>>> Hi Tom,
>>>>
>>>> I dropped for the moment the following patches from Denis:
>>>>
>>>>       bootcount: i2c: Add bus switching to the I2C bootcount driver
>>>>       bootcount: Configure length limit for I2C bootcount
>>>>       board: ge: Store bootcount in EEPROM on PPD and Bx50v3
>>>>
>>>> I used the same hack and PowerPC boards are built successfully on
>>>> travis. Please pull from u-boot-imx, thanks !
>>>>
>>>> The following changes since commit d117d8f19b0625f88309e47a8a32c2faa384dddc:
>>>>
>>>>   Merge branch 'master' of git://git.denx.de/u-boot-i2c (2018-12-13
>>>> 09:36:55 -0500)
>>>>
>>>> are available in the Git repository at:
>>>>
>>>>   git://www.denx.de/git/u-boot-imx.git tags/u-boot-imx-20190101
>>>>
>>>> for you to fetch changes up to 57d2beb91d705bccdfee5e9e5fd267f5e363a100:
>>>>
>>>>   pico-imx7d: Increase the CONFIG_ENV_OFFSET size (2019-01-01 14:12:18
>>>> +0100)
>>>>
>>>
>>> tl;dr:
>>> Applied to u-boot/master, thanks!
>>>
>>> Slightly longer.  I'm both not happy about taking something still this
>>> large so close to the end of the release and also at fault for it being
>>> so late.
>>
>> Sorry for that.
>>
>>>  I started my holidays a week early so I didn't bisect the
>>> build failure until it was too late.  That said, it's also a strong
>>> reminder of why everyone is encouraged to put their PR through travis.
>>
>> Up now, a method for maintainer to check a PR was to use buildman. If
>> buildman (at least for the maintained architecture) does not report
>> errors, I sent my PR. I think I missed that a switch to Travis is now
>> requested.
> 
> So, yes, I have made a few requests (And, when travis has worse than
> usual network problems for a prolonged time, told people to forget about
> it if they don't want to fight it) for custodians to use travis.
> Buildman is great, and I do a run of that too on a different box (and I
> kicked my script to check better for bad exit codes) but most people
> don't have the time/patience/resources for a world build as well.

This is correct - I just run ARM, not the whole world. It is also
because I have often a "bitbake" running somewhere, and everything slows
down.

> Travis isn't as quick as I'd like, but is also free to use, which is a
> helpful trade-off.

ok, fine.

> 
>> This also means that after a local test via buildman, each maintainer
>> should wait until travis reports its result for all architecture. I
>> mean, each maintainer triggers the same build and gets the result at
>> least one day later. Should not be better if this is done just once when
>> PR are merged into your tree and if ther eare some issues they are
>> reported back to the corresponding maintainer ?
> 
> I would run both simultaneously (travis will just re-start if you
> force-push a branch again).  At the end of the day, I haven't made any
> requirements for what people need to test before they send me a PR.
> Travis is nice in that it builds the world and runs test.py on (just
> about) all of the targets we an do via QEMU.  It also requires you to
> opt-in to using github and then travis-ci and I will not tell people
> they must sign up for a service they disagree with.
> 
> I also really appreciate it when custodians do a travis run and link it
> in their PR, and I still push it to a WIP branch and get my own travis
> run (and my own buildman world build and my own HW targets pushed
> through test.py).

ok, understood, this will be the way I do since now.

> 
> At the end of the day, for me to push things to master, my local tests
> need to pass (and if/when they don't, I debug or try and help the
> author to debug failures) and travis needs to pass.  There is a time
> cost to testing before sending to me and that may or may not be worse
> than the time cost when something fails.

Thanks for clarification,
Stefano


-- 
=====================================================================
DENX Software Engineering GmbH,      Managing Director: Wolfgang Denk
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: +49-8142-66989-53 Fax: +49-8142-66989-80 Email: sbabic at denx.de
=====================================================================