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

[Graeme Russ]

Hi Wolfgang,

On 23/09/11 17:25, Wolfgang Denk wrote:
> 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.

Ah, OK - I figured it must be related to the increased load you seem to be
under lately

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

Well my two console patches are ready for the next merge window - I notice
you have not claimed them, so I'll ping you when it opens

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

Well I have a few niggles with Patchwork:
 - It failed to see one patch in one of my multi-patch series
 - Even though I kept the 'in-reply-to' chain intact, it still has the
   individual versions of my console patches (it should just update the
   existing patch)
 - I cannot even find phylib: remove a couple of redundant code lines
   (submitted 06/09/11 by Vladimir Zapolskiy <vz at mleia.com>)

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

Well my theory on that would be that if the take-up of a process is not
naturally organic, then forcing the issue probably won't work either

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

Maybe so, but keeping in-reply-to: intact (which any decent mailer will do
with the reply button) make it easy for a maintainer to scan through and
pick them up as well - YMMV. And if it's creating a huge backlog, maybe the
ends don't justify the means

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

I think you have made far more ground on enforcing good in-reply-to:
adherence and patch revision commenting than getting everyone on board with
Patchwork. Even for large patch sets I'm happy to make sure I get the
in-reply-to: correct

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

Maybe the load can be spread here - maintainers can put these in designated
branches in their repositories. I know this will cause the odd conflict,
but we (the maintainers) could also periodically sync between each other.
Another alternative is to create a new repo that all the custodians have
access to...

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

Noted - A few architectural fixups (driver framework anyone) will help a
long way here as well

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

As mentioned above - I do wonder...

> etc. etc.

et. al.

Regards,

Graeme