[U-Boot] Application of patch submitted during the previous Merge Window

[Wolfgang Denk]

Dear Graeme Russ,

In message <CALButCL9Cee9pZRvyUZqF0wp1Wh5XabhV-Tm8ywLKErU1r+vOw at mail.gmail.com> you wrote:
> 
> With the next release pending and the next Merge Window about to open, I
> thought I might take the opportunity to ask a question that's been on my
> mind...What is the 'procedure' (for want of a better word) you use for
> patches applied during the merge window?
> 
> Now I know maintainers typically keep a 'next' branch which they can
> quickly rebase and issue a pull request for, but you don't seem to keep
> such a branch for the 'generic' patches (well, there is one, but it is now
> nine months old)

In theory I create a new next branch when we have -rc1, but frequently
(like during this release) I then find that we're already very late in
the schedule, so we can as well wait another week or two and then
start with the next release.

> Just wondering how we should be tracking said patches - Do you want us to
> ping you when the Merge Window opens, or do you have them nicely piled up
> in Patchwork ready to apply?

Also in theory, most of the patches should go through the respective
custodians, so only a minimal remainder should be on my stack.


Also, many of the patches are RFC's, that go through several
iterations, and it is not always clear (to me) when they reach a state
when they should be applied.


I have to admit that I am disappointed about patchwork.  Only very few
of the custodians actually use it.  Normally they should "grab"
(assign to themself) patches that fall into their responsibility.
Normally everybody should marks patches where they request changes oin
the ML as "Changes Requested".  They should set patches to "accepted"
or "Waiting upstream" or ... when they deal with them.  They should
also occasionally go through the list and mark superseded patches etc.
as such.

Very few ever do.  Occasionally I try to raise some awareness when I
send another round of 20 or so mails "please change the status in
patchwork when you request changes", but this does not help much.

In the result, a huge patch list is piling up, and dealing with this
becomes more and more frustrating.


> Personnaly, I like the idea of the next branch more than Patchwork, just
> to be consistent with the maintainers

What Patchwork really does well is to automatically take care of
Acked-By: or Tested-By: comments.


I'm not really satisfied with the current process myself either.  Any
suggestions for improvement would be welcome.

Also any volunteers to help out.  There are many areas where help
could be needed.

- We need a new network custodian.

- We could need some "trivial patch monkeys" that pick up trivial
  patches (like cosmetic changes cleaning up coding style things etc.,
  documentation changes etc.) so I just can pull that stuff.

- We could need more testers.  We have a growing number of cases where
  patches get checked in that later turn out to cause problems.  Our
  test coverage is far from satisfactory.

- I would appreciate if custdians make more active use of patchwork,
  so the pile of patches there was shrinking instead of ever growing.

etc. etc.

Best regards,

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
I paid too much for it, but its worth it.