Dear Graeme Russ,
[...]
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.
There are a few things I don't like about gerrit:
- Not based on an email-centric workflow
+1
- Need to 'drill-down' to get to the actual patch
- UI is overly verbose
Add - it's java crap, prone to breakage. - it's overengineered
And ad. jenkins -- with all that plugins infrastructure, it's so vast it can even make coffee and bake a cake damned!
But there are other things I do like:
- Maintains the revision history of each patch
If you follow some rules though :/
- Keeps track of review status
Not so usable tho
- Keeps track of the what branch the patch is against
Yes?
Patchwork is GPL'd and, in my personal opinion, gets fairly close to what we might need. Maybe we could take Patchwork and modify it to suit our needs?
Maybe ... where're the sources?
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...
OK, so we already have a fair number of in-house tools that have been developed to get the job done. We have checkpatch.pl, patman, buildman (in development), and Marek's build framework. Why don't we look at integrating these - A modified Patchwork could:
- Automatically run checkpatch and test if the patch applies
But based on tags in the email header, so it'd know against which tree. This is doable, yes!
- Notify the build framework to trigger a build-test
Which might schedule vast MAKEALL across all arches, effectivelly clogging it very soon.
- Apply patches to repo's when the maintainer sends an 'Accepted-by:' to the mailing list
Such email can be forged!
- Re-run apply and build tests when a maintainer issues a pull request
You mean when maintainer clicks "Submit pull RQ of this branch" ... then it's rebuild it and only after it passes submit the pullrq?
- Re-run the apply and build tests on all 'staged' patches when patches are committed or branches are merged
Um, what do you mean here?
I short, we have three options
- Modify our workflow so we can use existing tools
- Modify existing tools and/or create new tools to match our existing workflow
- A bit of both
And remember, Linus wrote git because no other tool was available that exactly suited his needs
Regards,
Graeme
Best regards, Marek Vasut