On Sun, Nov 30, 2014 at 6:46 PM, Junio C Hamano <gitster@xxxxxxxxx> wrote: > Michael Haggerty <mhagger@xxxxxxxxxxxx> writes: > >> It seems like a few desirable features are being talked about here, and >> summarizing the discussion as "centralized" vs "decentralized" is too >> simplistic. What is really important? >> >> 1. Convenient and efficient, including for newcomers >> 2. Usable while offline >> 3. Usable in pure-text mode >> 4. Decentralized >> >> Something else? > So when I started overtaking the ref log series by Ronnie, Ronnies main concern was missing reviewers time. So my idea was to make it as accessible as possible, so the reviewing party can use their time best. However here are a few points, I want to mention: * Having send emails as well as uploaded it to Gerrit, I either needed a ChangeId (Gerrit strictly requires them to track inter-patch diffs), and the mailing list here strictly avoids them, so I was told. Ok, that's my problem as I wasn't following the actual procedure of the Git development model (mailing list only). * That's why I stopped uploads to Gerrit, so I do not need to care about the ChangeIds any more. I am not sure if that improved the quality of my patches though. * I seem to not have found the right workflow with the mailing list yet, as I personally find copying around the inter-patch changelog very inconvenient. Most of the regulars here just need fewer iterations, so I can understand, that you find it less annoying. Hopefully I'll also get used to the nit-picky things and will require less review iterations in the future. How are non-regulars/newcomers, who supposingly need more iterations on a patch, supposed to handle the inter patch change log conveniently? I tried to keep the inter patch changelog be part of the commit message and then just before sending the email, I'd move it the non-permanent section of the email. * Editing patches as text files is hard/annoying. I have setup git send-email, and that works awesome, as I'd only need one command to send off a series. Having a step in between makes it more error-prone. So I do git format-patch and then inject the inter patch change log, check to remove ChangeId and then use git send-email. And at that final manual step I realized I am far from being perfect, so sometimes patches arrive on the mailing list, which are sub quality in the sense, that there are leftovers, i.e. a ChangeId * A possible feature, which just comes to my mind: Would it make sense for format-patch to not just show the diff stats, but also include, on which branch it applies? In git.git this is usually the origin/master branch, but dealing with patch series, building on top of each other that may be a good feature to have. > > When I had to view a large-ish series by Ronnie on Gerrit, it was > fairly painful. The interaction on an individual patch might be > more convenient and efficient using a system like Gerrit than via > e-mailed patch with reply messages, but as a vehicle to review a > large series and see how the whole thing fits together, I did not > find pages that made it usable (I am avoiding to say "I found it > unusable", as that impression may be purely from that I couldn't > find a more suitable pages that showed the same information in more > usable form, i.e. user inexperience). So you're liking the email workflow more. How do you do the final formatting of an email, such as including the inter patch diff? > > Speaking of the "whole picture", I am hesitant to see us pushed into > the "here is a central system (or here are federated systems) to > handle only the patch reviews" direction; our changes result after > discussing unrelated features, wishes, or bugs that happen outside > of any specific patches with enough frequency, and that is why I > prefer "everything in one place" aspect of the development based on > the mailing list. That is not to say that the "one place" has > forever to be the mailing list, though. But the tooling around an > e-mail based workflow (e.g. marking threads as "worth revisiting" > for later inspection, saving chosen messages into a mailbox and > running "git am" on it) is already something I am used to. Whatever > system we might end up migrating to, the convenience it offers has > to beat the convenience of existing workflow to be worth switching > to, at least to me as a reviewer/contributor. I do like the way as well to just mark emails unread when I need to work on them later. > > As the maintainer, I am not worried too much. As long as the > mechanism can (1) reach "here is a series that is accepted by > reviewers whose opinions are trusted" efficiently, and (2) allow > me to queue the result without mistakes, I can go along with > anything reasonable. > -- 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