Re: Our cumbersome mailing list workflow
Jonathan Nieder jrnie...@gmail.com writes: I don't think there's any reason that newcomers should need more iterations than regulars to finish a patch. Regulars are actually held to a higher standard, so they are likely to need more iterations. A common mistake for newcomers, that I haven't learned yet how to warn properly against, is to keep re-sending minor iterations on a patch too quickly. Some ways to avoid that: * feel free to respond to review comments with something like how about this? and a copy/pasted block of code that just addresses that one comment. That way, you can clear up ambiguity and avoid the work of applying that change to the entire patch if it ends up seeming like a bad idea. This also avoids having to re-send a larger patch or series multiple times to clear up a small ambiguity from a review. This can go both ways. A trivial improvement can be suggested that way by the reviewer. * be proactive. Look for other examples of the same issue that a reviewer pointed out once so they don't have to find it again elsewhere in the next iteration * feel free to get more review out-of-band, too. If you're still playing with ideas and want someone to take a quick glance before the patches are in reviewable form, you can do that and say so (e.g., with 'RFC/' before 'PATCH' in the subject line). Overall, good suggestions. Thanks. -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Our cumbersome mailing list workflow
On 2014-12-03 03.20, Stefan Beller wrote:
On Sun, Nov 30, 2014 at 6:46 PM, Junio C Hamano gits...@pobox.com wrote:
Michael Haggerty mhag...@alum.mit.edu 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.
Not sure if I understand. Editing text files isn't that hard, we do it all the
time.
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.
How do you inject the inter patch change log ? Is that manually, or is it a
script ?
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.
Thanks for the description (and everybody for the discussion)
In the hope that it may help, I can try to describe my work flow:
- Run a script to send the patch (this is a real example)
#
SRCCOMMIT=119efe90bffee688a3c37d4358667
DSTCOMMIT=$(git log --oneline -n1 | awk '{print $1}')
VERSION=-v 1
PATCHFILE=$( echo $0 | sed -e 's/\.sh$/.patch/')
GIT_TEST_LONG=t
export GIT_TEST_LONG
git am --abort || :
( test -s $PATCHFILE ||
git format-patch $VERSION -s --to=git@vger.kernel.org
--cc=tbo...@web.de --cc=mhag...@alum.mit.edu --stdout $SRCCOMMIT..$DSTCOMMIT
$PATCHFILE )
git checkout $SRCCOMMIT
git am $PATCHFILE
cd t cd .. make
(cd t ./t0001*.sh)
git imap-send $PATCHFILE
#
The script formats a patch file (if that does not exist),
applies the patch on the source commit,
runs make and then the test cases to verify that the patch works.
(For bigger patches more tests or the whole test suite should be run,
for this very isolated work it OK to run a singe test)
Once everything is OK, the patch is stored both on disc and in the Drafts
folder of the email program.
(In your case you can use grep to remove the ChangedId or to check that it had
been removed)
Now it is time to tweak the patch file with an editor:
Add what has been changed since V1
Save the patch file, run the script again to verify that the patch still
applies and works and
put it into the Drafts folder of the mail program.
(That's why I abort the git imap-send in the first round
and press ^C when the password is asked)
Start the favorite email program
(Kmail works, or Thunderbird or
every other program that can send email in plain text)
Have a final look at the patch in the email prgram
(remove the V1 from the header, change PATCH into PATCH/RFC).
Let the spell checker look at it, re-read once more.
If everything is OK, press the send button.
If I send out a V2 version, make a copy of
Re: Our cumbersome mailing list workflow
From: Michael Haggerty mhag...@alum.mit.edu Sent: Tuesday, November 25, 2014 12:28 AM On 11/21/2014 07:00 PM, Junio C Hamano wrote: Michael Haggerty mhag...@alum.mit.edu writes: I don't think that those iterations changed anything substantial that overlaps with my version, but TBH it's such a pain in the ass working with patches in email that I don't think I'll go to the effort of checking for sure unless somebody shows interest in actually using my version. Sorry for being grumpy today :-( [..] 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. 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. I had a thought about the issue of version labeling and of keeping the old patch series hanging about during development that I felt was worth recording. My thought was that while the cover letter and series version number are currently stripped out from the start of the series, they could be added back as a supplemental commit at the end of the series (an --allow-empty commit). This could contain all of the patch subject lines and their post '---' notes as appropriate. Thus the series branch would appear to have an extra commit (compared to the current process) after the original tip's possible merge into say pu. When subsequent series are sent to the list, the new supplemental commit would be a 'merge', with its second parent being the old series, thus the old series is not lost until the branch is deleted, and the existing merge pattern is retained. Clearly if this would need some additional coding as it's not suitable as a manual process, but it could be just as automatic as the current process while providing that little bit of additional visibility. Below, I've tried to set out how the commit graph might look (oldest to the left). Hopefully my MUA won't ruin it. The first patch series branches at A, and is merged at D, with the supplemental commit labeled with v1z. When the new series arrives, and pu is rewound, we have the new series applied from G (which in reality may not be linked directly from A), and merged back at K. However the new v2z supplemental commit is now the po/patches branch head, and is also a merge back to v1z. patch series 1 (cover letter z) - A - B - C - D - E - F - pu \/ v1a-v1b--v1z -po/patches patch series 2 - A - G - H - I - J - K - pu (note re-wound) |\ /(merge D lost) \ v2a-v2b-v2c--v2z-po/patches \ / v1a-v1b--v1z - - -. The key idea here is to use the existing branching model, but then to add the cover letter and other details at the end, rather than the beginning as might have been expected from the email transmit sequence. Philip -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Our cumbersome mailing list workflow
Editing text files isn't that hard, we do it all the time. It is not indeed. But doing it all over again and again is hard and error prone. I did re-read the man page on git format-patch and found the --notes option, which I am going to try to use in my workflow. That way I only need to update the notes instead of redoing them all the time. By redoing it I mean copying the changelog from the last time I sent the patch and adding new entries. My thought was that while the cover letter and series version number are currently stripped out from the start of the series, they could be added back as a supplemental commit at the end of the series (an --allow-empty commit). This could contain all of the patch subject lines and their post '---' notes as appropriate. This sounds interesting. The only changes I can see here are the referenced message ids, so it would be worthwhile to have the last patch sent out first and all other patches 1..n-1 referencing the last empty commit. If additionally the numbering is corrected, the reader of the mailing list would not notice any difference to the status quo, just the sender would have the convenience to be able to track the cover letter as an empty commit on top of a series. -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Our cumbersome mailing list workflow
On Sun, Nov 30, 2014 at 6:46 PM, Junio C Hamano gits...@pobox.com wrote: Michael Haggerty mhag...@alum.mit.edu 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 majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Our cumbersome mailing list workflow
Stefan Beller wrote: How are non-regulars/newcomers, who supposingly need more iterations on a patch, supposed to handle the inter patch change log conveniently? I think this is one of the more important issues. I don't think there's any reason that newcomers should need more iterations than regulars to finish a patch. Regulars are actually held to a higher standard, so they are likely to need more iterations. A common mistake for newcomers, that I haven't learned yet how to warn properly against, is to keep re-sending minor iterations on a patch too quickly. Some ways to avoid that: * feel free to respond to review comments with something like how about this? and a copy/pasted block of code that just addresses that one comment. That way, you can clear up ambiguity and avoid the work of applying that change to the entire patch if it ends up seeming like a bad idea. This also avoids having to re-send a larger patch or series multiple times to clear up a small ambiguity from a review. * be proactive. Look for other examples of the same issue that a reviewer pointed out once so they don't have to find it again elsewhere in the next iteration. Run the testsuite. Build with the flags from https://kernel.googlesource.com/pub/scm/git/git/+/todo/Make#106 in CFLAGS in config.mak. Proofread and try to read as though you knew nothing about the patch to anticipate what reviewers will find. * feel free to get more review out-of-band, too. If you're still playing with ideas and want someone to take a quick glance before the patches are in reviewable form, you can do that and say so (e.g., with 'RFC/' before 'PATCH' in the subject line). Jonathan -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Our cumbersome mailing list workflow
Michael Haggerty mhag...@alum.mit.edu 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? As a reviewer / contributor (not speaking as the top maintainer), I would say that everything in one place, and for that one place mailbox is preferrable. Somebody commented on (this instance of | the central) Gerrit, come look at it is not usable; sending that comment out to those who work in their MUA, and allowing them to respond via their MUA probably adding their response as a new comment to Gerrit) would be usable. 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). 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. 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 majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Our cumbersome mailing list workflow
From: Matthieu Moy matthieu@grenoble-inp.fr Torsten Bögershausen tbo...@web.de writes: 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. I personnally submit all my Git patches from a machine whose /usr/sbin/sendmail knows how to send emails, so for me configuration is super simple. But I can imagine the pain of someone working on various machines with various network configuration and normally using a webmail to send emails. Sharing ~/.gitconfig does not always work because on machine A you only can use one SMTP server, and on machine B only another ... The bit I find awkward for the send-email step is the creation of the to and cc lists. I tend to create the command line in a separate file so that I can re-use it for V2 etc. and even then I end up with all patches going to the full to/cc list. Michael's original discussion email did feel to summarise the isses [1] well. -- Philip [1] System Problems are Wicked problems : http://en.wikipedia.org/wiki/Wicked_problem www.poppendieck.com/wicked.htm -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Our cumbersome mailing list workflow
On 11/27/2014 06:46 PM, Torsten Bögershausen wrote: 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 ? I used to need one setup at work and a different one at home (because of how my email was configured), and sometimes had to switch back and forth as I carried my notebook around. [...] * 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. I know it's *possible*. The question is whether it could be made easier. * 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 ? That would be helpful, but it would put yet *another* requirement on the submitter (to send patch emails *and* push the branch to some accessible repository). We regulars could script this pretty easily, but people who only contribute occasionally or who are trying to get started will be even more overwhelmed. As an alternative, you can save the branches locally, after running git-am once, just keep the branch. [] Yes, but it is even more unnecessary manual bookkeeping. [...] 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. Yes, good idea. 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. One day per patch might be exaggerated, but I agree that long series should be iterated more slowly than short ones. What does it cost to push your branch to a public repo and include that information in the email ? One has to run an additional command and add some information to the cover letter, every time a patch series is submitted. If it's scripted then it's relatively painless. But for a newcomer these will be manual steps that are easy to forget or to do incorrectly, making it more likely that the newcomer's first contribution to Git will end in mild embarrassment rather than success. Michael -- Michael Haggerty mhag...@alum.mit.edu -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Our cumbersome mailing list workflow
On 11/27/2014 11:53 PM, Eric Wong wrote: Torsten Bögershausen tbo...@web.de wrote: On 2014-11-25 01.28, Michael Haggerty wrote: [...] 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 ? Not unreasonable. I hope that won't give folks an excuse to refuse to mail patches, though. Some folks read email offline and can't fetch repos until they're online again. My ideal would be to invert the procedure. Let the patches in a public Git repository somewhere be the primary artifact, and let the review process be focused there. Let email be an alternative interface to the central review site: * Generate patch emails (similar to the current format) when pull requests are submitted. * Generate notification emails when people comment on the patches. * Allow people to respond to the patch and notification emails via email. The central review site should associate those comments with the patches that they apply to, and present them along with other review comments received via other interfaces. 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... IMNSHO, development of non-graphical software should never depend on graphical software. Also, I guess there is no way to comment on Gerrit via email (without registration/logins?). The days of the vt52 are over. I'm an old neckbeard myself and have used *real* vt52s. But these days even my *cellphone* is able to handle the GitHub website [1]. Rejecting modern technology is not intrinsically virtuous; it only makes sense if the old technology is really superior. And it is not enough for it to be superior only for neckbeards; it should be superior when averaged over all of the people whose participation we would like to have in the Git project. And by the way, there are text-only clients for interacting with GitHub [1]. Lately, I've been trying to think of ways to make collaboration less centralized. Moving to more centralized collaboration tools is a step back for decentralized VCS. If an efficient decentralized collaboration system existed, then I'd love to give it a chance. But as far as I know, the existing systems are all embryonic. Don't forget that even our current system is centralized to some extent. There is a single mailing list through which all emails pass. There are a few email archives that we de facto rely on (and it is a brittle dependency--if Gmane were to disappear, we would have an awful lot of broken URLs in our emails that would be impossible to fix). 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? In my opinion, a central system with good Git integration (helps with 1) and both a straightforward web UI (also helps 1) and a good email interface (which gives both 2 and 3) and the ability to export the review history (which avoids lockin, the most important aspect of 4) would be perfect. Is there such a thing? Michael [1] ...probably other websites too. I'm really not trying to flog GitHub here; it's just the one I have the most experience with. In fact, I kindof assume that the Git project would choose a service that is itself based on open-source software. -- Michael Haggerty mhag...@alum.mit.edu -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Our cumbersome mailing list workflow
On 14-11-28 09:31 AM, Michael Haggerty wrote: On 11/27/2014 06:46 PM, Torsten Bögershausen wrote: 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 ? I used to need one setup at work and a different one at home (because of how my email was configured), and sometimes had to switch back and forth as I carried my notebook around. [...] * 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. I know it's *possible*. The question is whether it could be made easier. * 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 ? That would be helpful, but it would put yet *another* requirement on the submitter (to send patch emails *and* push the branch to some accessible repository). We regulars could script this pretty easily, but people who only contribute occasionally or who are trying to get started will be even more overwhelmed. A bot could subscribe to the list and create branches in a public repo. (This idea feels familiar -- didn't somebody attempt this already?) Integrate the bot into the list manager, and every PATCH email sent through the list could have the patch's URL (maybe in the footer, or as an X- header). Could this make a decent GSoC project? M. -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Our cumbersome mailing list workflow
On Fri, Nov 28, 2014 at 04:34:09PM +0100, Michael Haggerty wrote: My ideal would be to invert the procedure. Let the patches in a public Git repository somewhere be the primary artifact, and let the review process be focused there. Let email be an alternative interface to the central review site: * Generate patch emails (similar to the current format) when pull requests are submitted. * Generate notification emails when people comment on the patches. * Allow people to respond to the patch and notification emails via email. The central review site should associate those comments with the patches that they apply to, and present them along with other review comments received via other interfaces. I think these are good goals. Even as a semi-regular contributor, I prefer to push branches around using Git rather than formatting patches and mailing them. Also, I think that being able to comment on a patch or report a bug without a login (via email) is desirable. I'm not a fan of having to have an account on every Bugzilla on the planet. That's why I like debbugs. 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 I think 1 is definitely important. For me personally, 2 isn't very important, as all my email is via IMAP (so I have to be online). I think 3 is important for accessibility reasons. There are a lot of blind or low-sighted people for whom a GUI is infeasible or burdensome. Something else? It might be useful to have a system that has a bug or issue tracker. We often have posts to the mailing list that don't get a response, even though those may represent legitimate bugs (code or documentation). -- brian m. carlson / brian with sandals: Houston, Texas, US +1 832 623 2791 | http://www.crustytoothpaste.net/~bmc | My opinion only OpenPGP: RSA v4 4096b: 88AC E9B2 9196 305B A994 7552 F1BA 225C 0223 B187 signature.asc Description: Digital signature
Re: Our cumbersome mailing list workflow
A bot could subscribe to the list and create branches in a public repo. (This idea feels familiar -- didn't somebody attempt this already?) Thomas Rast maintains git notes that link git commits to their gmane discussion, you can get them with [remote mailnotes] url = git://github.com/trast/git.git fetch = refs/heads/notes/*:refs/notes/* There is gmane branch and a message-id branch, its pretty usefull. -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Our cumbersome mailing list workflow
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,
Re: Our cumbersome mailing list workflow
Torsten Bögershausen tbo...@web.de writes: 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. I personnally submit all my Git patches from a machine whose /usr/sbin/sendmail knows how to send emails, so for me configuration is super simple. But I can imagine the pain of someone working on various machines with various network configuration and normally using a webmail to send emails. Sharing ~/.gitconfig does not always work because on machine A you only can use one SMTP server, and on machine B only another ... -- Matthieu Moy http://www-verimag.imag.fr/~moy/ -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Our cumbersome mailing list workflow
Torsten Bögershausen tbo...@web.de wrote: On 2014-11-25 01.28, Michael Haggerty wrote: * 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? Not that I'm aware of, but Documentation/email-clients.txt in the Linux kernel has some short notes... My muttrc has had the following since my early days as a git user: macro index A :unset pipe_decode\n|git am -3\n:set pipe_decode\n macro pager A :unset pipe_decode\n|git am -3\n:set pipe_decode\n (Hit Shift-A while viewing/selecting a message to apply a patch, it requires you run mutt in your project working directory, though). Perhaps there can be a similar document or reference to it in our Documentation/ 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 ? Not unreasonable. I hope that won't give folks an excuse to refuse to mail patches, though. Some folks read email offline and can't fetch repos until they're online again. 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... IMNSHO, development of non-graphical software should never depend on graphical software. Also, I guess there is no way to comment on Gerrit via email (without registration/logins?). Lately, I've been trying to think of ways to make collaboration less centralized. Moving to more centralized collaboration tools is a step back for decentralized VCS. 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 ? All that sounds good. -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Our cumbersome mailing list workflow (was: Re: [PATCH 0/6] repack_without_refs(): convert to string_list)
On 11/21/2014 07:00 PM, Junio C Hamano wrote: Michael Haggerty mhag...@alum.mit.edu writes: I don't think that those iterations changed anything substantial that overlaps with my version, but TBH it's such a pain in the ass working with patches in email that I don't think I'll go to the effort of checking for sure unless somebody shows interest in actually using my version. Sorry for being grumpy today :-( Is the above meant as a grumpy rant to be ignored, or as a discussion starter to improve the colaboration to allow people to work better together instead of stepping on each other's patches? I think I know the sentiments of the mailing list regulars well enough that it didn't seem worthwhile to open this topic again, so I was just letting off steam without any hope of changing anything. But since you asked... 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. 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. * 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. * 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. * Because of the indeterminate application point, accumulating Signed-off-by lines, changed committer metadata, and maintainer tweaks, the commits that make it to the official tree have different SHA-1s than the commits in the submitter's tree, and both are different than the commits in the tree of any reviewer who got the patches using git am. This makes it hard to be sure that everybody is on the same page. It also makes it awkward for people to exchange ideas for further changes via Git protocols in the form of patches. * Because of the crude serialization of patches through email, it is only possible to submit linear patch series, not merge commits. Hmmm, I think that covers most of the problems of handling patches and review via a mailing list. What are some alternatives? 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
