Peter, On Wed, Oct 12, 2011 at 01:21:44PM +0200, Peter Stuge wrote: > Jason wrote: > > Is there any intent to integrate gerrit back into the ML? > > Sending email is easy. Receiving and parsing email is not as easy.
Agreed, I've been thinking through the obstacles, from a submitter pov, and I've come up with a few things that I think would help. I'm willing to write the patches if it's generally agreed they would be useful. 1.) Threading versions of a patch series together. So, when the maintainer has a chance to look at the thread, he/she can just go to the end of the thread to get the latest version. This would require a hook script in 'git format-patch' to add In-Reply-To: and to do patch versioning (read and detect from output directory?). Possibly, --versioning? Basically, I'm replacing gerrit's "Change-Id" with smtp's already useful "Message-Id" and "In-Reply-To". 2.) Mod 'git format-patch' hook script to run checkpatch.pl with a repo appropriate config, inject the output into the patch. Between '---' and the diff. U-boot is already working on making checkpatch.pl more generic and configurable. 3.) While I'm breaking 'git format-patch' why not try to integrate a changelog file? eg. extract the changelog from the previous version for each patch, and throw in a '*** ADD NEW CHANGES HERE ***'. How to handle collapsed patches? 4.) Build a reject filter into the mailinglist server. If it sees 'PATCH' '[vV][0-9]' in the Subject and no In-Reply-To:, it will reject it with a pointer to 'How to submit patches' instructions. Additionally, it could also refuse patches without a 'git-send-email' Message-Id:, and patches without the output of checkpatch.pl in them. This could also be a 'Hold for moderator approval', depending on config options. Or, it could be implemented in the maintainers .procmailrc... > > See [1] for an existing gripe. > > I'm the Peter refered to there. I also like to do patch review in the > mailer rather than in the browser, but it is difficult to integrate > that with Gerrit. Instead of asking about intent, please participate > in actually doing this integration. I'm more than happy to, however, I have no maintainer experience. I need some insight before I invest time in creating patches. ... > You have probably already found out that Gerrit has an SSH interface > besides the web interface. The SSH interface is of course much better > suited for integration, but so far I don't think it's possible to > create inline comments through it, which is the main glitch for me > between what I can do in my mailer and what I could do with Gerrit > via SSH. On the other hand the data is better structured in Gerrit > which is worth much more for everyone who consumes my review. Oops, missed the ssh interface. Thanks for pointing that out. > Jason wrote: > > If I am out for several days, my openocd imap folder has everything that > > happened. I browse the subjects, read the threads of interest, and move > > on. In the gerrit lurkflow, there's quite a bit more clicking (how long > > ago was it I last checked the pending patch list?) to get the same > > information. I also have to remember to visit the site. > > Again: Look at what the tool does and how it works! It is not a web > site. It is a code review tool which receives git commits. > > I'm not at all against Gerrit sending lots of email to the list, the > only bug is that review happening on the list will miss out on the > point with Gerrit. But of course ideas about how to connect the > glitch are very welcome. See my ideas, above. Admittedly, I'm trying to make existing tools do more, not add new ones. I've no problem with gerrit itself, I just tend to be a minimalist when it comes to new tools in existing workflows. > > A new user has to work significantly harder to maintain a prolonged > > interest in the project with gerrit (imnsho). > > See other email about Gerrit sending email. Point taken. > > On a personal note, I've found it much easier to contribute to u-boot > > and the kernel vice cyanogenmod. The main reason for this is the lack > > of a mailinglist for CM (they use gerrit). > > It is IMO not possible to replace a mailing list with a code review > tool. They serve different purposes and complement each other. I agree, github, cyanogenmod and others seem to miss that... > > Maybe I'm odd and a one-off, but I thought it was worth mentioning > > Please give yourself more freedom in shaping how the project works. > If you like patches to still come to the mailing list then you just > have to say so, don't apologize. :) And FWIW I don't think anyone is > against it. Thanks, I have no problem contributing to a project, I just haven't contributed here and didn't want to come off like a feature-requester. > > I'd hate to see that stream of patches and comments dissappear. :-( > > I'd really like a way to do inline comments via SSH. Can you think of > any ideas for how we could do this? Gerrit needs to know which line > in which file. As seen above, my ideas are tending towards improving the existing workflow, which may not be what you want... > The quickest thing I can come up with would be to add a prefix on > each patch line sent in email, like 1:14 meaning file 1 this patch > touches, line 14 of either the patch or the file. It would cost a few > characters per line, but it would have the data needed for an inline > comment. Combine with a PGP signature (or send via SSH) and I think > it could work. Of course someone has to develop this software too. This seems rather rube-goldberg-ish [1] ;-) Assuming my ideas above were implemented successfully (non-default options, etc), is there anything in the maintainer workflow it doesn't cover? thx, Jason. [1] http://en.wikipedia.org/wiki/Rube_Goldberg_machine _______________________________________________ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
