Dear Graeme,
In message 5005562E.6070903@gmail.com you wrote:
I think U-Boot has reached the point that purely manual patch management is not longer cutting the mustard.
100% agreed. The problem I see is that we haven't found a tool that provides the needed interfaces to deal with the amount of patches we have to handle.
Patchwork has a number os serious problems, as I see it:
- It chokes on a lot (or all?) base64 encoded messages that have special charactes in the comitter's names (and/or the commit message). In my opinion it renders the tool more or less worthless if you cannot rely that it really covers all patches.
- Our main communication is e-mail based, and this has proven to be a very efficient way to do the work we have to do - so we need a tool that integrates with this tooling. When I send an e-mail reply to a submitter requesting changes to his patch, I want to be able to use the same e-mail message to automatically change the patch status in PW. Unfortunately, no such way exists.
- PW identifies patches based on the hash value over the commit body. It appears to search oldest first, and stop on first hit. This causes problems with resubmitted patches. Assume someone submits a patch, an I as for changes in the commit message (better documen- tation, etc.); I mark the patch as changes requested. The submitter sends a new version, with improved commit message. I mark the old patch as "superseded", and the new one as "under review". When I finally want to apply the new patch, I usually do this from my mailer, which results in using the hash to locate the patch. Result: 1) The old patc gets applied instead of the new one. 2) The old patch gets mared as applied, the new one remains in "under review" state.
These are just the most aggravating bugs; I've discussed all of these on the PW mailing list, and with JK. Nothing happened since.
For me PW is more or less dead.
Maybe it's time to seriously look at a gerrit + jenkins based solution?
I am not sure that gerrit will solve any of the problems we have. I may be missing it, but for example I don't see any integration into a mostly e-mail based work flow. From what I have seen so far (which is not much, I admit) it appears we would again add another tool that in the first place requires additional steps which interrupt the work flow. Speaking for myself, this is a killing point.
And Jenkins... well, we have been using this for some time internally to run test builds for U-Boot. I can tell you a thing or two about it, and Marek has his own story to tell about his experiences when he added to the build matrix.
As is, we try hard to get rid of Jenkins, because it does not scale well to the type of builds we want to be able to do. Marek even started setting up his own test build framework...
Best regards,
Wolfgang Denk