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

[Tom Rini]

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

> 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).

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.

-- 
Tom
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: not available
URL: <http://lists.denx.de/pipermail/u-boot/attachments/20190109/cc04ab89/attachment.sig>