Hi Wolfgang, On 23/09/11 17:25, Wolfgang Denk wrote: > Dear Graeme Russ, > > In message > <calbutcl9cee9pzrvyuzqf0wp1wh5xabhv-tm8ywlkeru1r+...@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 <v...@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 _______________________________________________ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
