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

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


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

> > It was agreed that automatic marking of changes as accepted when changes
> > hit mainline would be a good thing.  There is some info on our wiki
> > available, although it is not clear who uses them:
> >
> > http://www.denx.de/wiki/view/U-Boot/Patches#pwclient and
> > http://www.mail-archive.com/patchwork@lists.ozlabs.org/msg00057.html
> >
> > A tool to automatically mark patches as superceded on newer versions
> > was also suggested to be very valuable.

I regularly use this method to update patch status, but the results
are not really satisfactory, especially due to the shortcomings (read:
bugs) of PW itself.

> Also, if one (and only one) maintainer is Cc'd on a patch, it would be
> nice is it was automatically assigned to them. Same goes for tags in the
> patch subject - there should be a way to automatically assign a fair
> number of patches.

This can probablybe done.  I think initial assignment of new patches
can be done based on X-Patchwork mail headers.  We just need tools
that generate these - i. e. a wrapper around git-send-email?

> > During the discussion it showed that many people believe that patches
> > outside the "regular" merge window are handled in-efficiently ending up
> > as large piles in patchwork.  It was agreed that rather then being a

I disagree.  There is no real difference between patche submitted
during or outside a MW.  They all end up on the large pile :-(

> > "accept / don't accept" division, it should be a "accept into mainline /
> > accept into -next branches" split hopefully keeping the flow of incoming
> > patches more uninterrupted.  For this to work, every custodian would
> > open his own "-next" branch and start merging patches from the mailing
> > list resulting in patchwork becoming cleaner during "bug fix" phases.
> 
> And this is where patchwork fails us - The list of states is extremely
> limiting

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.


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

> > 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?

Best regards,
Viele Grüße,

Wolfgang Denk

-- 
DENX Software Engineering GmbH,     MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
Never underestimate the bandwidth of a station wagon full of tapes.
                                -- Dr. Warren Jackson, Director, UTCS