On 2014-11-25 01.28, Michael Haggerty wrote: [] > Let me list the aspects of our mailing list workflow that I find > cumbersome as a contributor and reviewer: > > * Submitting patches to the mailing list is an ordeal of configuring > format-patch and send-email and getting everything just right, using > instructions that depend on the local environment. Typically everything fits into ~/.gitconfig, which can be carried around on a USB-Stick. Is there any details which I miss, or howtows we can improve ? > We saw that hardly > any GSoC applicants were able to get it right on their first attempt. > Submitting a patch series should be as simple as "git push". > > * Once patches are submitted, there is no assurance that you (Junio) > will apply them to your tree at the same point that the submitter > developed and tested them. > > * The branch name that you choose for a patch series is not easily > derivable from the patches as they appeared in the mailing list. Trying > to figure out whether/where the patches exist in your tree is a largely > manual task. The reverse mapping, from in-tree commit to the email where > it was proposed, is even more difficult to infer. > > * Your tree has no indication of which version of a patch series (v1, > v2, etc) is currently applied. > > The previous three points combine to make it awkward to get patches into > my local repository to review or test. There are two alternatives, both > cumbersome and imprecise: > > * I do "git fetch gitster", then try to figure out whether the branch > I'm interested in is present, what its name is, and whether the version > in your tree is the latest version, then "git checkout xy/foobar". There are 12 branches from mh/, so it should be possible to find the name, und run git log gitster/xy/fix_this_bug or so. Even more important, this branch is the "single point of truth", because this branch may be merged eventually, and nothing else. > > * Or I save the emails to a temporary directory (awkward because, Oh > Horror, I use Thunderbird and not mutt as email client), hope that I've > guessed the right place to apply them, run "git am", and later try to > remember to clean up the temporary directory. Is there a "mutt howto" somewhere? > > * Once I've done that, the "supplemental" comments from the emails (the > cover letter and the text under the "---") are nowhere available in the > Git repository. So if I want to see the changes in context plus the > supplemental comments, I have to jump back and forth between email > client and Git repo. Plus I have to jump around the rest of the email > thread to see what comments other reviewers have already made about the > series. > > * Following patch series across iterations is also awkward. To compare > two versions, I have to first get both patch series into my repo, which > involves digging through the ML history to find older versions, followed > by the "git am" steps. Often submitters are nice enough to put links to > previous versions of their patch series in their cover letters, but the > links are to a web-based email archive, from which it is even more > awkward to grab and apply patches. So in practice I then go back to my > email client and search my local archive for my copy of the same email > that was referenced in the archive, and apply the patch from there. > Finding comments about old versions of a patch series is nearly as much > work. In short: We can ask every contributor, if the patch send to the mailing list is available on a public Git-repo, and what the branch name is, like _V2.. Does this makes sense ? As an alternative, you can save the branches locally, after running git-am once, just keep the branch. [] > > I did enjoy the variety of reviewing some patch series using Gerrit. It > is nice that it tracks the evolution of a patch from version to version, > and that the comments made on all versions of a patch are summarized in > a single place. This makes it easier to avoid commenting on issues that > other reviewers have already noted and easier to check that your own > comments have been addressed by later versions of the patch. On the > other hand, Gerrit seems strongly focused on individual patches rather > than on patch series (which might not match our workflow so well), the > UI is overwhelming (though I think one could get quite productive with > it if one used it every day), and the notification emails come in blizzards. > > Michael > > [1] Disclaimer: I work for GitHub. > I like Gerrit as well. But it is less efficient to use, a WEB browser is slower (often), and you need to use the mouse... However, if you put your patches on Gerrit, and add the link in your cover-letter, it may be worth a trial. But there is another thing: Once a patch is send out, I would ask the sender to wait and collect comments at least 24 hours before sending a V2. We all living in different time zones, so please let the world spin once. My feeling is that a patch > 5 commits should have a waiting time > 5 days, otherwise I start reviewing V1, then V2 comes, then V3 before I am finished with V1. That is not ideal. What does it cost to push your branch to a public repo and include that information in the email ? And how feasable/nice/useful is it to ask contributers for a wait time between re-rolling ? -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html