[U-Boot] Notes from the U-Boot BOF Meeting in Geneva 2012/07/12

[Marek Vasut]

Dear Wolfgang Denk,

> Dear Graeme Russ,
> 
> In message <CALButCJAu4r8wdTpYC7XPfhq_uJFbhQpGUeiNnEx-
jHJjK1nUg at mail.gmail.com> you wrote:
> > > Currently the lack of any reaction whatsoever was identified to be a
> > > very discouraging sign for contributors. One thing we could do is to
> > > declare a "soft" time-limit (two weeks) that patches need to be looked
> > > at.  After this time-limit, one could declare "backup-custodians" to
> > > push patches to or merge patches into some "-staging" branch.  (What to
> > > do with that branch then?) For this to work, custodians would need to
> > > announce "off-times" which currently is not general consensus.
> 
> Declaring a time limit would not help much.  The fact that patches
> receive no response is not a result of disinterest, but usually of
> lack of time.  In this situation the chances that someone monitors the
> list for time-outs is small, and even if he spots these, there is
> still no no resource available for processing the patch.
> 
> The idea of "backup-custodians" is not new either.  I have requested
> repeatedly that the existing custodians (who have write permission to
> patchwork and to the u-boot-staging tree) help me with processing the
> load of "generic" patches that end up on my table.  The amount of
> patches going this way is minimal.  In the last 3 months, only Stefan
> Roese used this tree, and only for a single pull request.
> 
> 
> But this is where help would really be efficient: more people are
> needed to pick up, review, and especially test the load of generic
> patches.  Things like new file system support are independent of
> specific hardware (which is why this stuff ends up on my table), so
> everyone can help here.  On the other hand, this stuff is usually
> qurte test-intensive, so I really need more help with that.

Ain't this the stuff that can be automated?

> > I like this idea in principle. In order to work, I think there needs to
> > be two or three 'top-tier' custodians who will arbitrarily assign
> > 'stale' patches to another custodian. And maybe one top-top-tier
> > custodian (Hi Wolfgang ;)) in case the patch goes very stale.
> 
> Assinging work does not help if there are no resources to process the
> assignments.  We already have assignments: usually on me.  But I
> cannot handle all this load.

+1 on this one. I'm choking even on the small amount of patches I have, I've 
already asked SR how he manages to process so many of them.

[...]
> 
> I think we can define new states if needed.  But this does not fix any
> of the issues that make PW such a PITA to use.

And more thing that'd be cool would be if patchwork (or any other tool) could 
push the Acked patches directly into the respective git tree. Maybe even issue a 
pullRQ when appropriate (but that'd have to be requested by the custodian).

> > > Discussing such automatic merges, the need for continous integration
> > > became apparant.  As mid- to longterm goals we would like to see
> > > automatic builds shifting the requirement to "do MAKEALL" from
> > > individual posters to (cheap) machine time.  One obstacle on this way
> > > is the complexity of automatic builds for different architectures,
> > > i.e. which toolchain to use and how to use them correctly.
> > 
> > 'Bring out your nightly builds!'

I can adjust my automatic testing system to also store the compiled results. 
Effectively giving us nightly builds. But then, there're many other tools needed 
to generate all those weirdo flashable images (u-boot.imx, u-boot.sb etc).

The other problem is how to find the boards that actually need rebuild on per-
patch basis. And for generic patches, we'll need to do MAKEALL across all 
architectures anyway, which takes a bit of time.

> > I very much like the idea of continuous integration - The number of time
> > that a build is breaking only to be picked up weeks after the offending
> > commit is getting a bit annoying.
> 
> I'm not so sure what makes sense here.  I have often dreamed of
> automatic testing (checkpatch + MAKEALL) of all submitted patches.
> But looking at the current situation, we not only have big problems
> because many patches have non-standard requirements (they apply only
> against a specific tree, and require N previous patches to be applied
> first), but we would probably aut-reject 95+ % of all submissions.  I
> don't know if thi would be encouraging for submitters...

Gerrit can do that, but running MAKEALL on each pushed set would still need a 
vast amount of computing power.

> > > Simon Glass mentioned that he is working on "buildman" which he will
> > > present on the mailing list in due time.
> 
> Maybe Simon and Marek could put their heads together?

buildman? Are there any news on that?

> Best regards,
> Viele Grüße,
> 
> Wolfgang Denk

Best regards,
Marek Vasut