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 _______________________________________________ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot