{"thread":{"id":"55492","subject":"Pain points in Git's patch flow","startedAt":"2021-04-14T06:13:34Z","lastAt":"2021-05-08T04:41:09Z","messageCount":46,"participants":["Jonathan Nieder","Bagas Sanjaya","Junio C Hamano","Denton Liu","Son Luong Ngoc","Atharva Raykar","Sebastian Schuberth","Ævar Arnfjörð Bjarmason","Eric Wong","Theodore Ts'o","Konstantin Ryabitsev","Stephen Smith","Daniel Axtens","brian m. carlson","Felipe Contreras","ZheNing Hu","dwh@linuxprogrammer.org"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"421950","messageId":"YHaIBvl6Mf7ztJB3@google.com","threadId":"55492","inReplyTo":null,"subject":"Pain points in Git's patch flow","fromName":"Jonathan Nieder","fromEmail":"jrnieder@gmail.com","sentAt":"2021-04-14T06:13:26Z","receivedAt":"2021-04-14T06:13:34Z","isPatch":false,"sender":{"key":"jrnieder@gmail.com","avatar":"https://avatars.githubusercontent.com/u/281595?v=4"},"body":"Hi,\n\nI'd like to introduce Raxel (cc-ed), who is starting an internship\nthis June with the Git team at Google.\n\nHe'll be working on a bit of an experimental project: we want to take\nPatchwork[1], which in principle can be a helpful addition to a\nmailing list centric workflow[2], and improve it to be something that\npeople in the Git open source project get day-to-day benefit from.\nRaxel's previous successes in making changes to tools to support a\nbetter user experience make me excited for the potential for this\nwork.\n\nAnyway, yesterday[3] Junio, Taylor, and Emily were discussing how to\nencourage more reviews:\n\n this week, i'd be thinking about ways to get topics, that\n are not reviewed sufficiently, reviewed. I can act as the\n last-resort fallback reviewer, but that's not sufficient.\n gitster: I share your concern.\n gitster: yep, agree, on both counts\n\nThat reminded me that it would be useful preparation to collect\ndescriptions of pain points we are having with our existing patch\nflow. For example:\n\n- As a reviewer, I want to be able to easily find a series that needs\n review. Using patchwork, I can see some recent patch series; or\n using a hierarchical threaded mail reader, I can find a neglected\n thread or one that seems to be likely to have an interesting\n discussion going on. But without reading in detail, there is no\n easy way to see whether the series has reached a review, whether\n someone else intends to review it, and what the author believes its\n status to be.\n\n- Relatedly, as a patch author or reviewer, I want to be able to\n easily tell whether a topic has been sufficiently reviewed. Today,\n the signals for this are implicit: I have to judge consensus, or to\n check the Git repository for whether the patch has been merged, or\n to check the maintainer's latest \"What's cooking in git.git\"\n message.\n\n- As a potential reviewer or interested user, I want to be able to\n follow all relevant discussion for a patch series, while also\n having the ability to stop following it if the discussion goes on\n too long and starts overwhelming my email inbox. Today, I can join\n the discussion and then (1) it is hit-or-miss whether the patch\n author ccs me on later iterations of the patch and (2) there is no\n easy way without aggressive email filtering to stop watching it if\n I am cc-ed.\n\n- After having diagnosed an issue to be due to a patch, I want to be\n able to easily find all relevant review discussion. Today I can\n use the mailing list archive[4] or patchwork to find review\n discussion on the latest version of the series that patch was in,\n but tracing back to previous iterations of that same series can be\n non-trivial. Moreover, if I'm interested in a particular puzzling\n line of code, finding which iteration introduced it can take a long\n time.\n\nThose four are important in my everyday life. Questions:\n\n 1. What pain points in the patch flow for git.git are important to\n you?\n\n 2. What tricks do you use to get by with those existing pain points?\n\n 3. Do you think patchwork goes in a direction that is likely to help\n with these?\n\n 4. What other tools would you like to see that could help?\n\nThanks,\nJonathan\n\n[1] http://jk.ozlabs.org/projects/patchwork/; you can see an instance\nfor Git at https://patchwork.kernel.org/project/git/list/\n[2] https://kernel-recipes.org/en/2016/talks/patches-carved-into-stone-tablets/,\nhttps://www.kernel.org/pub/software/scm/git/docs/gitworkflows.html#_patch_workflow\n[3] https://colabti.org/irclogger/irclogger_log/git-devel?date=2021-04-12#l40\n[4] https://lore.kernel.org/git/\n"},{"id":"421953","messageId":"b562e614-add7-575f-3013-1dbc667bc5bf@gmail.com","threadId":"55492","inReplyTo":"YHaIBvl6Mf7ztJB3@google.com","subject":"Re: Pain points in Git's patch flow","fromName":"Bagas Sanjaya","fromEmail":"bagasdotme@gmail.com","sentAt":"2021-04-14T07:22:51Z","receivedAt":"2021-04-14T07:23:00Z","isPatch":false,"sender":{"key":"bagasdotme@gmail.com","avatar":"https://avatars.githubusercontent.com/u/40219486?v=4"},"body":"\nOn 14/04/21 13.13, Jonathan Nieder wrote:\n> Those four are important in my everyday life. Questions:\n> \n> 1. What pain points in the patch flow for git.git are important to\n> you?\n\nThere is no lists of \"beginner-friendly\" issues that can be worked on by\nnew contributors. They had to search this ML archive for bug report\nissues and determine themselves which are beginner-friendly.\n\n> 2. What tricks do you use to get by with those existing pain points?\n> \n> 3. Do you think patchwork goes in a direction that is likely to help\n> with these?\n\nNo, unrelated to beginner-friendly issues above.\n\n> 4. What other tools would you like to see that could help?\n\nSome sort of bug tracker systems like Bugzilla (used by Linux kernel\nand many other projects) and Debbugs [1] (which is mail-centric and used by\nDebian for its BTS).\n\n[1]: https://bugs.debian.org/debbugs-source/\n\n-- \nAn old man doll... just what I always wanted! - Clara\n"},{"id":"421957","messageId":"xmqq7dl5z425.fsf@gitster.g","threadId":"55492","inReplyTo":"b562e614-add7-575f-3013-1dbc667bc5bf@gmail.com","subject":"Re: Pain points in Git's patch flow","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2021-04-14T08:02:58Z","receivedAt":"2021-04-14T08:03:53Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Bagas Sanjaya writes:\n\n> There is no lists of \"beginner-friendly\" issues that can be worked on by\n> new contributors. They had to search this ML archive for bug report\n> issues and determine themselves which are beginner-friendly.\n\nYeah, looking for \"#leftoverbits\" or \"low-hanging\" on the list\narchive is often cited as a way, and it does seem easy enough to\ndo. You go to https://lore.kernel.org/git/, type \"leftoverbits\"\nor \"low-hanging\" in the text input and press SEARCH.\n\nBut that is only half of the story.\n\nAnybody can throw random ideas and label them \"#leftoverbits\" or\n\"low-hanging fruit\", but some of these ideas might turn out to be\nill-conceived or outright nonsense. Limiting search to the\nutterances by those with known good taste does help, but as a\nnewbie, you do not know who these people with good taste are.\n\nIt might help to have a curated list of starter tasks, but I suspect\nthat they tend to get depleted rather quickly---by definition the\nones on the list are easy to do and there is nothing to stop an\neager newbie from eating all of them in one sitting X-(.\n\nSo, I dunno. We seem to suffer from the same lack of good starter\ntasks before each GSoC begins.\n"},{"id":"421988","messageId":"xmqqzgy0wnk2.fsf@gitster.g","threadId":"55492","inReplyTo":"xmqq7dl5z425.fsf@gitster.g","subject":"Re: Pain points in Git's patch flow","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2021-04-14T21:42:21Z","receivedAt":"2021-04-14T21:42:28Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Junio C Hamano writes:\n\n> So, I dunno. We seem to suffer from the same lack of good starter\n> tasks before each GSoC begins.\n\nAnd long after sending the response, I realize that this has very\nlittle to do with \"Git's patch flow\" issue that you wanted to\ndiscuss. Helping newbies wet their toes may be a topic worth\ndiscussing, but that is not the focus of this thread.\n\nLet me send a response to describe my pain points separately.\nSorry for the noise.\n"},{"id":"422002","messageId":"xmqqv98orsj5.fsf@gitster.g","threadId":"55492","inReplyTo":"YHaIBvl6Mf7ztJB3@google.com","subject":"Re: Pain points in Git's patch flow","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2021-04-15T06:06:06Z","receivedAt":"2021-04-15T06:06:11Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Jonathan Nieder writes:\n\n> That reminded me that it would be useful preparation to collect\n> descriptions of pain points we are having with our existing patch\n> flow.\n\nAs the maintainer, I want to ensure that what I queue on 'seen' is\nkept reasonably up to date. Not picking up the latest every time a\ntopic is rerolled is OK, but before declaring the topic will hit\n'next' in a few days, it must be (1) the latest and (2) the greatest\n(meaning: what reviewers are happy with).\n\nThis requires a few features from any tracking system. It must be\nable to:\n\n - tell which round of patches are in 'seen'.\n\n - tell which e-mail messages are the newer round than what is\n queued, and which ones are the latest round.\n\n - tell which patch have been commented on, and been updated in\n response.\n\n - tell which patch have been positively accepted with an Ack or a\n Reviewed-by, and if a patch in a newer round is identical to an\n already accepted one (in which case, reviewers would not bother\n to send \"this step still looks good to me\").\n\nThe system I use for the first two points is to rely on the list\narchive and the mapping from each individual commit made out of a\npatch on the list (implemented as git notes, that records a blob\nwith the Message-Id for each commit [*1*]). So\n\n $ git log --notes=amlog --no-merges --oneline master..$topic\n\nwould give a list of commits with the original Message-ID, and I can\nsee which piece of e-mail each commit came from.\n\nThe third and fourth are maintained mostly manual, with me keeping\nnotes in the draft of \"What's cooking\" report (which I send out from\ntime to time). Having to notice, pick up and squeeze in Acked-by's\nand Reviewed-by's is quite painful and cumbersome, especially for a\nlong series, and the buggy \"git rebase -x\" does not help, either\n[*2*].\n\nIf we run a patchwork instance for our project, the first two could\nbe largely automated. Automation built around Patchwork should be\nable to, or at least should be able to help me to:\n\n - notice when a new round of an existing topic is posted.\n\n - fetch the \"amlog\" notes, together with a copy of daily 'seen', to\n see if a topic that is queued has an update, and notify me and\n others when the topic queued is stale [*3*].\n\n - tie a step in the latest round with a corresponding step in the\n previous round, and show Ack's and Reviewed-By's that are still\n valid [*4*].\n\n\n[Footnotes]\n\n*1* \"git fetch https://github.com/gitster/git +refs/notes/amlog:refs/notes/amlog\"\n should give you a copy of this database. Then, for example you\n can ask where a commit came from:\n\n $ git show -s --notes=amlog format=\"%N%s\" 61a7660516\n Message-Id: \n reftable: document an alternate cleanup method on Windows\n\n Note that this is not a one-to-one mapping. I may initially\n apply patches to an inappropriate base and push the integration\n result out that has it in 'seen', but I may realize that the\n series needs to be queued on a different commit and rebase the\n topic the next day. Both commits before and after such a\n rebasing have come from the single piece of e-mail, so you can\n say \"this commit came from this message\", but it is impossible\n to expect a single answer to \"which commit is the result of this\n message\"---there will be multiple.\n\n Strictly speaking, when two rounds of the same topic had patches\n that were unchanged between the iterations in their earliest\n parts, two pieces of e-mail may convey the same patch, so in the\n ideal world, it might be more useful to record \"this commit came\n from this and that messges, both of which record an identical\n patch\". I currently do not do so, though.\n\n*2* It would be ideal if \"rebase -i -x 'add-trailer -r peff@'\" can\n be used to stop at each commit, run the 'add-trailer -r peff@'\n script that amends HEAD to add \"Reviewed-by: peff@\", and\n continue, while honoring the \"notes.rewriteref\" configuration\n variable (in my repository, set to \"refs/notes/amlog\"). That\n way, I can queue with \"git am\", at which time \"amlog\" gets\n populated to map each commit to the original message, find\n Reviewed-by: and do the above rebase, while carrying the message\n IDs to resulting commits. Alas, \"rebase -i -x\" is buggy and\n loses the notes during this process (doing s/pick/reword/ and\n manually squeezing Reviewed-by: into the log message is a poor\n but workable workaround).\n cf. https://lore.kernel.org/git/xmqq8s6tcuxc.fsf@gitster.g/\n\n*3* It is perfectly normal if a topic is left stale, if the newer\n iteration breaks integration. So the stale notification going\n directly to a contributor from an automated system would not\n help very much, but it needs to come with the reason why it is\n kept out of 'seen', which must be supplied by human, not by an\n automation.\n\n If an automation around Patchwork can send, instead of \"hey,\n here is an updated series available\" notification, a mbox\n readily usable by \"git am -s3c\" to me, with Acked-by's and\n Reviewed-by's already incorporated, that might be ideal (these\n trailers may have to be filtered/curated to avoid spams,\n though).\n \n\n*4* Judging a step in the latest round and the corresponding step in\n the previous round has not substantially changed may not be\n easily automatable, and carrying Ack's and Reviewed-by's forward\n would require human curator of the \"patchwork\" database.\n"},{"id":"422007","messageId":"YHf+Laph42liGPzw@generichostname","threadId":"55492","inReplyTo":"b562e614-add7-575f-3013-1dbc667bc5bf@gmail.com","subject":"Re: Pain points in Git's patch flow","fromName":"Denton Liu","fromEmail":"liu.denton@gmail.com","sentAt":"2021-04-15T08:49:49Z","receivedAt":"2021-04-15T08:49:53Z","isPatch":false,"sender":{"key":"liu.denton@gmail.com","avatar":"https://avatars.githubusercontent.com/u/9620836?v=4"},"body":"Hi Bagas,\n\nOn Wed, Apr 14, 2021 at 02:22:51PM +0700, Bagas Sanjaya wrote:\n> \n> On 14/04/21 13.13, Jonathan Nieder wrote:\n> > Those four are important in my everyday life. Questions:\n> > \n> > 1. What pain points in the patch flow for git.git are important to\n> > you?\n> \n> There is no lists of \"beginner-friendly\" issues that can be worked on by\n> new contributors. They had to search this ML archive for bug report\n> issues and determine themselves which are beginner-friendly.\n\nAn unofficial and semi-curated list of issues exists at [0]. I've seen\nmany people new to git development pick up some beginner-friendly issues\nfrom there.\n\n-Denton\n\n[0]: https://github.com/gitgitgadget/git/issues\n"},{"id":"422037","messageId":"YHhfsqfTJ9NzRwS1@C02YX140LVDN.corpad.adbkng.com","threadId":"55492","inReplyTo":"YHaIBvl6Mf7ztJB3@google.com","subject":"Re: Pain points in Git's patch flow","fromName":"Son Luong Ngoc","fromEmail":"sluongng@gmail.com","sentAt":"2021-04-15T15:45:54Z","receivedAt":"2021-04-15T15:46:01Z","isPatch":false,"sender":{"key":"sluongng@gmail.com","avatar":"https://avatars.githubusercontent.com/u/26684313?v=4"},"body":"Hi there,\n\nI'm not a regular contributor but I have started to subscribe to the\nGit's Mailing List recently. So I thought it might be worth sharing my\npersonal view on this.\n\nAfter writting all the below, I do realize that I have written quite a\nrant, some of which I think some might consider to be off topic. For\nthat, I do want to appologize before hand.\n\n Tue, Apr 13, 2021 at 11:13:26PM -0700, Jonathan Nieder wrote:\n> Hi,\n> \n...\n> \n> Those four are important in my everyday life. Questions:\n> \n> 1. What pain points in the patch flow for git.git are important to\n> you?\n\nThere are several points I want to highlight:\n\n1. Issue about reading the Mailing List:\n\n- Subscribing to Git's Mailing List is not trivial:\n It takes a lot of time to setup the email subscription. I remember\n having to google through a few documents to get my subscription\n working.\n\n- And even after having subscribed, I was bombarded with a set\n of spam emails that was sent to the mailing list address. These spams\n range anywhere from absurd to disguising themselves as legitimate\n users trying to contact you about a new shiny tech product.\n\n2. Issue about joining the conversation in the Maling List:\n\n- Setting up email client to reply to the Mailing List was definitely\n not trivial. It's not trivial to send a reply without subscribing to\n the ML(i.e. using a Header provided from one of the archive).\n The list does not accept HTML emails, which many clients\n use as default format. Getting the formatting to work for line\n wrapping is also a challenge depends on the client that you use.\n\n- It's a bit intimidating to ask 'trivial questions' about the patch and\n create 'noise' in the ML.\n\n3. Isssue with archive:\n\n- I don't find the ML archive trivial for new comers. It took me a bit\n of time to realize: 'Oh if I scroll to bottom and find the \"Thread \n overview\" then I can navigate a mailing thread a lot easier'.\n\n- The lack of labeling / categorization that I can filter while browsing\n through the archive make the 'browse' experience to be quite\n unpleasant. Search is one way to do it, but a new comers would not be\n knowledgable enough to craft search query to get the archive view just\n right. Perhaps a way to provide a curate set of categories would be\n nice.\n\n- Lost track of issues / discussion:\n A quick example would be me searching for Git's zstd support\n recently with \n\n > https://lore.kernel.org/git/?q=zstandard \n\n and got next to no relevant result. However if I were to query\n\n > 'https://lore.kernel.org/git/?q=zstd'\n\n then a very relevant thread from Peff appeared. I think this could be\n avoided if the search in ML archive do more than just matching exact\n text.\n\n4. Lack of way to run test suite / CI:\n\n It would be nice if we can discuss patches while having CI result as\n part of the conversation. Right now mostly I see that we have to\n manually running benchmarks/tests and share the paste the results.\n\n But for folks who don't have a dev environment ready at hand (new\n comers, during travel with only phone access), it would be nice to\n have a way to run tests without a dev environment.\n\n This was mostly solved in the context of works spent on Github's\n Action Workflow. But if we are discussing about pure patch flow, this\n is a miss.\n\n> 2. What tricks do you use to get by with those existing pain points?\n\nFor (1):\n- I had to invested a lot of time into setting up a set of Gmail search\n filter. Move mails with topics that Im interested in into a special\n tag while the rest into archive. Regularly check if anything\n interesting went to archive by accident.\n\nFor (2):\n- I had to setup Mutt + Tmux to have a compatible experience sending\n replies like this one.\n\n- All the patches I have submitted were through\n > https://github.com/gitgitgadget/git/pulls\n and it was not directly trivial to get permission to send email from a\n PR.\n\nFor (3):\n- Spending time reading git blame / git log / commit message helps\n identifying the keywords I need to refine my search result in the ML\n archive. This requires some commitments and is a barrier to entry for\n new comers.\n\n- Using service like Github Search or SourceGraph helped a lot in term\n of navigating through the commit message / git blame.\n\nFor (4):\n- I leverage both Github action and a patch that added Gitlab CI to run\n the test suite.\n\n> 3. Do you think patchwork goes in a direction that is likely to help\n> with these?\n>\n> 4. What other tools would you like to see that could help?\n\nWith all that said, I don't know if patchwork will solve the problems\nabove. I do understand that the current patch workflow comes with a\ncertain set of advantages, and adopting another tool will most likely be\na trade-off.\n\nPersonally I have been spending more and more time reading through\ngit.git via Sourcegraph Web UI and I would love for the search feature\nto be able to extend to be able to search in the Mailing List from\nrelevant commit if possible. I have also tried both Github's Codespace\nand Microsoft's DevContainer to setup an opionated IDE with predefined\ntasks that help executing the test suite. I think these tools (or\ntheir competitors such as GitPod) are quite ideal to quickly onboard\nnew contributors onto a history-rich codebase such as git.git.\n\nPerhaps some configure a set of sane default, including editor extensions\nthat would handle email config for first time users.\n\nAs for code review and issue tracking toolings, I don't think there are\na perfect solution. Any solutions: Github PR, Gitlab MR, Gerrit,\nPhabricator would come with their own set of tradeoffs. I like the\nprospect of PatchWork gona improve the patch workflow though. Perhaps I\nwill give it a try.\n\n> \n> Thanks,\n> Jonathan\n\nThanks,\nSon Luong.\n"},{"id":"422045","messageId":"3DB12C56-3FDF-49D1-B9CC-3ACB21367F3B@gmail.com","threadId":"55492","inReplyTo":"YHaIBvl6Mf7ztJB3@google.com","subject":"Re: Pain points in Git's patch flow","fromName":"Atharva Raykar","fromEmail":"raykar.ath@gmail.com","sentAt":"2021-04-15T18:25:12Z","receivedAt":"2021-04-15T18:25:21Z","isPatch":false,"sender":{"key":"raykar.ath@gmail.com","avatar":"https://avatars.githubusercontent.com/u/24277692?v=4"},"body":"On 14-Apr-2021, at 11:43, Jonathan Nieder wrote:\n> \n> Hi,\n> \n> I'd like to introduce Raxel (cc-ed), who is starting an internship\n> this June with the Git team at Google.\n> \n> He'll be working on a bit of an experimental project: we want to take\n> Patchwork[1], which in principle can be a helpful addition to a\n> mailing list centric workflow[2], and improve it to be something that\n> people in the Git open source project get day-to-day benefit from.\n> Raxel's previous successes in making changes to tools to support a\n> better user experience make me excited for the potential for this\n> work.\n> \n> Anyway, yesterday[3] Junio, Taylor, and Emily were discussing how to\n> encourage more reviews:\n> \n> this week, i'd be thinking about ways to get topics, that\n> are not reviewed sufficiently, reviewed. I can act as the\n> last-resort fallback reviewer, but that's not sufficient.\n> gitster: I share your concern.\n> gitster: yep, agree, on both counts\n> \n> That reminded me that it would be useful preparation to collect\n> descriptions of pain points we are having with our existing patch\n> flow. For example:\n> \n> - As a reviewer, I want to be able to easily find a series that needs\n> review. Using patchwork, I can see some recent patch series; or\n> using a hierarchical threaded mail reader, I can find a neglected\n> thread or one that seems to be likely to have an interesting\n> discussion going on. But without reading in detail, there is no\n> easy way to see whether the series has reached a review, whether\n> someone else intends to review it, and what the author believes its\n> status to be.\n> \n> - Relatedly, as a patch author or reviewer, I want to be able to\n> easily tell whether a topic has been sufficiently reviewed. Today,\n> the signals for this are implicit: I have to judge consensus, or to\n> check the Git repository for whether the patch has been merged, or\n> to check the maintainer's latest \"What's cooking in git.git\"\n> message.\n> \n> - As a potential reviewer or interested user, I want to be able to\n> follow all relevant discussion for a patch series, while also\n> having the ability to stop following it if the discussion goes on\n> too long and starts overwhelming my email inbox. Today, I can join\n> the discussion and then (1) it is hit-or-miss whether the patch\n> author ccs me on later iterations of the patch and (2) there is no\n> easy way without aggressive email filtering to stop watching it if\n> I am cc-ed.\n> \n> - After having diagnosed an issue to be due to a patch, I want to be\n> able to easily find all relevant review discussion. Today I can\n> use the mailing list archive[4] or patchwork to find review\n> discussion on the latest version of the series that patch was in,\n> but tracing back to previous iterations of that same series can be\n> non-trivial. Moreover, if I'm interested in a particular puzzling\n> line of code, finding which iteration introduced it can take a long\n> time.\n\nThis is a great initiative!\n\nWhile I do not have anything new to add in terms of pain\npoints, I just wanted to let you know that this is definitely\nsomething that would have eased the process of bringing in a\nnew contributor like me.\n\n> Those four are important in my everyday life. Questions:\n> \n> 1. What pain points in the patch flow for git.git are important to\n> you?\n\nAs a new contributor (and also someone new to the patch flow) I\nwould have especially liked the second and fourth point addressed.\nWhen I was preparing my GSoC proposal, I wanted to gather the\nstatus of a previous contributor's work and even though searching\nthe mailing list helped, it was hard to immediately know what were\nthe status of the patches, and which changes got introduced in\nwhich version of the patch series.\n\nAlso with my first patch series that I sent to the mailing list,\nI initially felt unsure about what the status of my patch was\nafter a few people discussed over it. The 'implicit signals' is\nsomething that was not immediately obvious to me, and only after\nreading other interactions in the mailing list did I start getting\na hold of how I should interpret the responses, and what my next\naction should be.\n\n> 2. What tricks do you use to get by with those existing pain points?\n\nIn order to learn about a previous patch series and what was added,\nI used git blame on the relevant part of the codebase, and tried to\nsearch the commit message in the mailing list archive. From there on\nit was just opening a ton of tabs in order to see how the patches\ndeveloped over time.\n\nThe limitation with this trick is it will work only if the patch\nactually landed in the codebase. A part of building my proposal\nrequired me to read a patch that did not get merged, and I had to\njust aggressively search the mailing list and hope I managed to catch\neverything I wanted.\n\n> 3. Do you think patchwork goes in a direction that is likely to help\n> with these?\n\nI have noticed that a patchwork instance for this mailing list\nalready exists[1] so I decided to try it out. It definitely\naddresses the problem of explicitly identifying the status of a\npatch. I also liked that I could search for the previous\ncontributor that I spoke of and sort his contributions by date.\nIf I knew this existed, I would have saved a lot of time.\n\nBut as you also mentioned, it does not yet help me locate an\nolder version of a particular patch, and let me observe how it\ndeveloped over time. So that would definitely be a welcome\naddition.\n\nAs Bagas mentioned in the thread, it seems to lend itself well\nto identify beginner-friendly tasks. I did not personally have\ntoo much difficulty with those thanks to the GitHub issue tracker\nand the Git documentation, but if new contributors are anyway\ngoing to refer to patchwork to study previous patches and learn\nfrom it, it might be helpful to keep beginner issues accessible\nthere as well. Even a generic labelling system to help categorise\nissues will do (a downside being that the labels will have to be\nmaintained and managed too).\n\nSome small nits:\n- The searching capability was not super obvious to me. My\n eyes naturally scan for a search box or search icon, it\n took me a few minutes of fiddling to realise that\n 'show patches with' is a link that opens all the search\n filters.\n- It would be nice (though probably out of scope) to allow\n me to do a code search in the patches.\n\n> 4. What other tools would you like to see that could help?\n\n(...I don't really have an opinion on this)\n\n> Thanks,\n> Jonathan\n> \n> [1] http://jk.ozlabs.org/projects/patchwork/; you can see an instance\n> for Git at https://patchwork.kernel.org/project/git/list/\n> [2] https://kernel-recipes.org/en/2016/talks/patches-carved-into-stone-tablets/,\n> https://www.kernel.org/pub/software/scm/git/docs/gitworkflows.html#_patch_workflow\n> [3] https://colabti.org/irclogger/irclogger_log/git-devel?date=2021-04-12#l40\n> [4] https://lore.kernel.org/git/\n\n[1] https://patchwork.kernel.org/project/git/list/\n\n"},{"id":"422119","messageId":"xmqqfszqko0k.fsf@gitster.g","threadId":"55492","inReplyTo":"YHaIBvl6Mf7ztJB3@google.com","subject":"Re: Pain points in Git's patch flow","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2021-04-16T19:50:03Z","receivedAt":"2021-04-16T19:50:11Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Jonathan Nieder writes:\n\n> 3. Do you think patchwork goes in a direction that is likely to help\n> with these?\n\nSo here is a real-life example.\n\nLet's say somebody is looking at a \"gentle ping\" [*1*]\n\nznh> The patch seems to have fallen into the crack.\nzhn> Jeff and Junio, willing to help?\n\nHow would we figure out what happened to the patch today without\nvisiting patchwork would be:\n\n 1. Visit the message at lore.kernel.org/git/ [*1*]\n\n 2. Notice that it is a response to a message, and click the link to\n be taken to [*2*]\n\n 3. Notice that nobody commented on the patch.\n\n 4. Type \"f:zhening ref-filter\" to the search box and search, with\n suspicion that this was an updated version of something.\n\n 5. Click one of them in the result [*3*]\n\n 6. This time, we can tell that this seemed to have had two earlier\n iterations, and after reading the discussion through, the last\n one changed the course in a major way. Not just a new helper\n introduced in the earlier rounds has gone away, but an existing\n helper got removed.\n\n 7. All comments in the discussion for the earlier two rounds can be\n read as supporting the new direction the latest round takes.\n\n 8. The fact remains that even if the direction has been endorsed\n (see 7. above) nobody took a look at the implementation for the\n latest round.\n\n 9. Make the final verdict.\n\nI use my newsreader to do pretty much the equivalent of the above\nwithout hitting https://lore.kernel.org/git/ but the above is\nwritten to use the web interface, in order to make it reproducible\nmore easily by anybody on the list.\n\nNow, how can patchwork improve the above reviewer experience, out\nof the box and possibly with new helpe rools around it?\n\nI can see #3 would immediately become obvious, and I hope #4-#5\nwould become unnecessary.\n\nAnything else?\n\nAt steps #6 and #7, there is human judgment involved that may not be\nautomatable, but would there be some mechanism to make it easy to\nhelp these steps if the user visits patchwork (instead of staying\nin my newsreader or web interface to the lore archive)?\n\nI am of course not expecting to automate step #9 ;-) It would be\nnice though.\n\nThanks.\n\n\n[References]\n\n*1* https://lore.kernel.org/git/CAOLTT8Tis5Yjg8UR0c-i0BnqiFQvLXvDgxUQJ-WcP6jjQPu9cQ@mail.gmail.com/\n\n*2* https://lore.kernel.org/git/pull.928.git.1617975348494.gitgitgadget@gmail.com/\n\n*3* https://lore.kernel.org/git/pull.927.v2.git.1617809209164.gitgitgadget@gmail.com/\n"},{"id":"422120","messageId":"xmqqblaekmd9.fsf@gitster.g","threadId":"55492","inReplyTo":"xmqqfszqko0k.fsf@gitster.g","subject":"Re: Pain points in Git's patch flow","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2021-04-16T20:25:38Z","receivedAt":"2021-04-16T20:25:41Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Junio C Hamano writes:\n\n> So here is a real-life example.\n>\n> Let's say somebody is looking at a \"gentle ping\" [*1*]\n>\n> znh> The patch seems to have fallen into the crack.\n> zhn> Jeff and Junio, willing to help?\n>\n> How would we figure out what happened to the patch today without\n> visiting patchwork would be:\n> ...\n> Now, how can patchwork improve the above reviewer experience, out\n> of the box and possibly with new helpe rools around it?\n\nAlso, it would be ideal if it is made easy for willing reviewers\nwith excess bandwidth to preemptively find and review patches that\nneed reviewing. I think your original write-up upthread covered\nthis use case sufficiently.\n\nThanks.\n\n"},{"id":"422204","messageId":"22a0a383-0ae1-c7d1-75f7-7dfdfe5fb504@gmail.com","threadId":"55492","inReplyTo":"YHaIBvl6Mf7ztJB3@google.com","subject":"Re: Pain points in Git's patch flow","fromName":"Sebastian Schuberth","fromEmail":"sschuberth@gmail.com","sentAt":"2021-04-18T08:29:02Z","receivedAt":"2021-04-18T08:29:16Z","isPatch":false,"sender":{"key":"sschuberth@gmail.com","avatar":"https://avatars.githubusercontent.com/u/349154?v=4"},"body":"On 2021-04-14 08:13, Jonathan Nieder wrote:\n\n> Those four are important in my everyday life. Questions:\n\nThanks for bringing up these questions in a dedicated format. I'll take \nthis as an opportunity to share my thoughts on this topic, which have \naccompanied me for quite a while.\n\n> 1. What pain points in the patch flow for git.git are important to\n> you?\n\nWell, it's email-based. As a result it's error prone to things like \nformatting / quoting issues, putting the right people it CC, etc.\n\nI have always wondered why Git core development does not start to make \nuse of the Git ecosystem that we have by now, esp. in the form of review \ntools / platforms like GitHub (via pull-requests), GitLab (via \nmerge-requests), or Gerrit (via patches). From these, Gerrit would IMO \nbe the best fit for Git, due to its capability to cope well with \nrebase-workflows. Those tools avoid things like formatting / quoting \nissues completely, and shift the responsibility of assigning reviewers \nfrom the contributor to the tool, where people can subscribe to code \nchanges or code ownership can be defined and automatically taken into \naccount.\n\nSure, I get that that the contribution workflow to Git core has \nhistorically grown, but what concerns me is that the efforts to \"bridge\" \nthe contribution workflow to the \"modern world\" seem to go into the \nwrong direction: Tools like submitgit [1], gitgitgadget [2] and now \npatchwork [3] were created / are considered for use to allow the legacy \nemail path workflow to remain, but also allow more \"GUI minded\" people \nto contribute. While this has worked quite well for some time, and esp. \ngitgitgadget [2] seems to haven gotten popular, I wonder whether it's \nnow the time to \"swap the default\", and make a patch / contribution tool \nwith a GUI the standard, and bridge the legacy workflow by using / \ncreating tooling that makes it convenient to use those modern tools from \nthe CLI, instead of the opposite.\n\n> 2. What tricks do you use to get by with those existing pain points?\n\nNone. I simply have stopped contributing to Git core, to be frank.\n\n> 3. Do you think patchwork goes in a direction that is likely to help\n> with these?\n\nNo. To me, this is yet another effort that tries to come up with a \nwork-around instead of fixing the root cause: It tries to lift the \nlimitations of an email-based contribution workflow instead of getting \nrid of the email-based contribution workflow altogether.\n\n> 4. What other tools would you like to see that could help?\n\nCurrently, only Gerrit [4] comes to my mind, as a complete substitute \nfor the email-based contribution workflow.\n\n[1] https://github.com/rtyley/submitgit\n[2] https://github.com/gitgitgadget/gitgitgadget\n[3] http://jk.ozlabs.org/projects/patchwork\n[4] https://www.gerritcodereview.com\n\n-- \nSebastian Schuberth\n\n"},{"id":"422219","messageId":"87fszn48lh.fsf@evledraar.gmail.com","threadId":"55492","inReplyTo":"22a0a383-0ae1-c7d1-75f7-7dfdfe5fb504@gmail.com","subject":"Re: Pain points in Git's patch flow","fromName":"Ævar Arnfjörð Bjarmason","fromEmail":"avarab@gmail.com","sentAt":"2021-04-18T20:54:18Z","receivedAt":"2021-04-18T20:54:23Z","isPatch":false,"sender":{"key":"avarab@gmail.com","avatar":"https://avatars.githubusercontent.com/u/45301?v=4"},"body":"\nOn Sun, Apr 18 2021, Sebastian Schuberth wrote:\n\n> On 2021-04-14 08:13, Jonathan Nieder wrote:\n>\n>> Those four are important in my everyday life. Questions:\n>\n> Thanks for bringing up these questions in a dedicated format. I'll\n> take this as an opportunity to share my thoughts on this topic, which\n> have accompanied me for quite a while.\n\nAnd thank you for participating in the discussion. I think it's\nespecially valuable to get a viewpoint like yours, i.e. someone who (per\nthis E-Mail below) gave up in frustration with the current development\nflow.\n\nThe below isn't meant as a retort, but to hopefully clarify things a\nbit.\n\n>> 1. What pain points in the patch flow for git.git are important to\n>> you?\n>\n> Well, it's email-based. As a result it's error prone to things like\n> formatting / quoting issues, putting the right people it CC, etc.\n>\n> I have always wondered why Git core development does not start to make\n> use of the Git ecosystem that we have by now, esp. in the form of\n> review tools / platforms like GitHub (via pull-requests), GitLab (via \n> merge-requests), or Gerrit (via patches). From these, Gerrit would IMO\n> be the best fit for Git, due to its capability to cope well with \n> rebase-workflows. Those tools avoid things like formatting / quoting\n> issues completely, and shift the responsibility of assigning reviewers \n> from the contributor to the tool, where people can subscribe to code\n> changes or code ownership can be defined and automatically taken into \n> account.\n\nI think it's important not to conflate tooling issues with social\nissues. It's not that we e.g. couldn't whip up a quick script to\nround-robin randomly assign reviewers on the basis of topics Junio has\npicked up, which is basically the function of some of these \"open a MR\nend get on the review train\" tools.\n\nRather it's that it's a volunteer project and people work on what\nthey're interested in.\n\nSo maybe having assigned reviewers would help move things along. But I\nwonder if it wouldn't also lead down the rut of PRs/MRs languishing for\nmonths, because the reviewers just want to spend their time in some\nother way.\n\nI.e. the design of many of these tools in this regard assumes you have a\nworkforce, not the cat-herding problem of volunteers working on whatever\nstrikes their fancy.\n\n> Sure, I get that that the contribution workflow to Git core has\n> historically grown, but what concerns me is that the efforts to\n> \"bridge\" the contribution workflow to the \"modern world\" seem to go\n> into the wrong direction: Tools like submitgit [1], gitgitgadget [2]\n> and now patchwork [3] were created / are considered for use to allow\n> the legacy email path workflow to remain, but also allow more \"GUI\n> minded\" people to contribute. While this has worked quite well for\n> some time, and esp. gitgitgadget [2] seems to haven gotten popular, I\n> wonder whether it's now the time to \"swap the default\", and make a\n> patch / contribution tool with a GUI the standard, and bridge the\n> legacy workflow by using / creating tooling that makes it convenient\n> to use those modern tools from the CLI, instead of the opposite.\n\nI think characterizing E-Mail as a \"legacy\" workflow isn't accurate. All\nof these proposed alternatives involve moving away from something that's\na distributed system today (E-Mail infrastructure, local clients), to\nwhat's essentially some website run by a centralized entity, in some\ncases proprietary.\n\nEven in cases where the tool itself isn't proprietary (e.g. GitLab\ninstead of GitHub) using GitHub/GitLab/Gerrit/Atlassian Bitbucket\netc. means having some centralized infrastructure somewhere holding a\nbunch of data only the operator of that infrastructure can realistically\naccess.\n\nSo really basic things that are comparatively trivial with E-Mail\n(e.g. \"I think the search sucks, try another client\") run up against a\nbrick wall with those tools.\n\nAnd to e.g. as one good example to use (as is the common convention on\nthis list) git-range-diff to display a diff to the \"last rebased\nrevision\" would mean some long feature cycle in those tools, if they're\neven interested in implementing such a thing at all.\n\nBecause we're E-Mail based that's just something some people started\nusing (well, it was called \"tbdiff\" then), some others picked it up etc.\n\nWhich is not to say that one can't argue that on balance using those\ntools isn't better overall, I'm just responding to the characterization\nof E-Mail based development as \"legacy\", or something those tools\nsupersede. I think it's better to think of them as orthagonal ways to\nreach similar aims.\n"},{"id":"422228","messageId":"20210419025754.GA26065@dcvr","threadId":"55492","inReplyTo":"YHhfsqfTJ9NzRwS1@C02YX140LVDN.corpad.adbkng.com","subject":"Re: Pain points in Git's patch flow","fromName":"Eric Wong","fromEmail":"e@80x24.org","sentAt":"2021-04-19T02:57:54Z","receivedAt":"2021-04-19T02:57:57Z","isPatch":false,"sender":{"key":"e@80x24.org","avatar":null},"body":"Son Luong Ngoc wrote:\n> Hi there,\n> \n> I'm not a regular contributor but I have started to subscribe to the\n> Git's Mailing List recently. So I thought it might be worth sharing my\n> personal view on this.\n> \n> After writting all the below, I do realize that I have written quite a\n> rant, some of which I think some might consider to be off topic. For\n> that, I do want to appologize before hand.\n\nThanks for the feedback, some points below.\n\n> Tue, Apr 13, 2021 at 11:13:26PM -0700, Jonathan Nieder wrote:\n> > Hi,\n> > \n> ...\n> > \n> > Those four are important in my everyday life. Questions:\n> > \n> > 1. What pain points in the patch flow for git.git are important to\n> > you?\n> \n> There are several points I want to highlight:\n> \n> 1. Issue about reading the Mailing List:\n> \n> - Subscribing to Git's Mailing List is not trivial:\n> It takes a lot of time to setup the email subscription. I remember\n> having to google through a few documents to get my subscription\n> working.\n> \n> - And even after having subscribed, I was bombarded with a set\n> of spam emails that was sent to the mailing list address. These spams\n> range anywhere from absurd to disguising themselves as legitimate\n> users trying to contact you about a new shiny tech product.\n\nNote that subscription is totally optional.\n\nGmail's mail filters probably aren't very good, perhaps\nSpamAssassin or similar filters can be added locally to improve\nthings for you.\n\nSpam filtering is a complex topic and Google's monopolistic\npower probably doesn't inspire them to do better.\n\n> 2. Issue about joining the conversation in the Maling List:\n> \n> - Setting up email client to reply to the Mailing List was definitely\n> not trivial. It's not trivial to send a reply without subscribing to\n> the ML(i.e. using a Header provided from one of the archive).\n> The list does not accept HTML emails, which many clients\n> use as default format. Getting the formatting to work for line\n> wrapping is also a challenge depends on the client that you use.\n\nThe spam (and phishing) problem would be worse if HTML mail were\naccepted. Obfuscation/misdirection techniques used by spammers\nand phishers aren't available in plain-text.\n\nIt's also more expensive to filter + archive HTML mail due to\ndecoding and size overheads, which makes it more expensive for\nothers to mirror/fork things.\n\n> - It's a bit intimidating to ask 'trivial questions' about the patch and\n> create 'noise' in the ML.\n\nI'm sorry you feel that way. I understand the Internet and its\npersistence (especially with mail archives :x) can have a\nchilling effect on people. I think the way to balance things is\nto allow/encourage anonymity or pseudonyms, but some folks here\nmight disagree with me for copyright reasons. OTOH, don't ask,\ndon't tell :)\n\n(I am not speaking as a representative of the git project)\n\n> 3. Isssue with archive:\n> \n> - I don't find the ML archive trivial for new comers. It took me a bit\n> of time to realize: 'Oh if I scroll to bottom and find the \"Thread \n> overview\" then I can navigate a mailing thread a lot easier'.\n\n(I'm the maintainer of public-inbox, the archival software you\nseem to be referring to).\n\nI'm not sure how to make \"Thread overview\" easier to find\nwithout cluttering the display near the top. Maybe I'll try\naria labels in the Subject: link...\n\n> - The lack of labeling / categorization that I can filter while browsing\n> through the archive make the 'browse' experience to be quite\n> unpleasant. Search is one way to do it, but a new comers would not be\n> knowledgable enough to craft search query to get the archive view just\n> right. Perhaps a way to provide a curate set of categories would be\n> nice.\n\nPerhaps TODO files/comments in the source tree are acceptable;\nor a regularly-posted mail similar to \"What's cooking\".\n\nHaving a centralized website/tracker would give too much power\nand influence to people/orgs who run the site. It would like\neither require network access or require learning more software\nto synchronize.\n\n> - Lost track of issues / discussion:\n> A quick example would be me searching for Git's zstd support\n> recently with \n> \n> > https://lore.kernel.org/git/?q=zstandard \n> \n> and got next to no relevant result. However if I were to query\n> \n> > 'https://lore.kernel.org/git/?q=zstd'\n> \n> then a very relevant thread from Peff appeared. I think this could be\n> avoided if the search in ML archive do more than just matching exact\n> text.\n\nI'm planning to support Xapian synonyms for that, but haven't\ngotten around to making it configurable+reproducible by admins.\nEverything in public-inbox is designed to be reproducible+forkable.\n\n> 4. Lack of way to run test suite / CI:\n> \n> It would be nice if we can discuss patches while having CI result as\n> part of the conversation. Right now mostly I see that we have to\n> manually running benchmarks/tests and share the paste the results.\n> \n> But for folks who don't have a dev environment ready at hand (new\n> comers, during travel with only phone access), it would be nice to\n> have a way to run tests without a dev environment.\n\nFwiw, the GCC Farm project gives ssh accounts for all free\nsoftware contributors, not just gcc hackers: https://cfarm.tetaneutral.net\nPerhaps there's other similar services, too.\n\nSlow down and enjoy travel :) There's very little in free\nsoftware urgent enough to require constant attention. Email is\nwell-suited for asynchronous work, and nobody should expect\ninstant replies. The always-on nature of the modern Internet\nand smartphones increases stress and dangerous situations; so I\nhope free software hackers aren't contributing to that.\n\n> This was mostly solved in the context of works spent on Github's\n> Action Workflow. But if we are discussing about pure patch flow, this\n> is a miss.\n> \n> > 2. What tricks do you use to get by with those existing pain points?\n> \n> For (1):\n> - I had to invested a lot of time into setting up a set of Gmail search\n> filter. Move mails with topics that Im interested in into a special\n> tag while the rest into archive. Regularly check if anything\n> interesting went to archive by accident.\n> \n> For (2):\n> - I had to setup Mutt + Tmux to have a compatible experience sending\n> replies like this one.\n\nFwiw, git-send-email works for non-patch mails, too. I don't\nwant a monoculture around mutt or any particular clients, either.\n(I've never used tmux and don't see why it's necessary, here).\n\nAnyways, thanks again for the feedback.\n"},{"id":"422229","messageId":"20210419025842.GA15976@dcvr","threadId":"55492","inReplyTo":"87fszn48lh.fsf@evledraar.gmail.com","subject":"Re: Pain points in Git's patch flow","fromName":"Eric Wong","fromEmail":"e@80x24.org","sentAt":"2021-04-19T02:58:42Z","receivedAt":"2021-04-19T02:58:45Z","isPatch":false,"sender":{"key":"e@80x24.org","avatar":null},"body":"Ævar Arnfjörð Bjarmason wrote:\n> On Sun, Apr 18 2021, Sebastian Schuberth wrote:\n> \n> > On 2021-04-14 08:13, Jonathan Nieder wrote:\n> >\n> >> Those four are important in my everyday life. Questions:\n> >\n> > Thanks for bringing up these questions in a dedicated format. I'll\n> > take this as an opportunity to share my thoughts on this topic, which\n> > have accompanied me for quite a while.\n> \n> And thank you for participating in the discussion. I think it's\n> especially valuable to get a viewpoint like yours, i.e. someone who (per\n> this E-Mail below) gave up in frustration with the current development\n> flow.\n\nAgreed\n\n> The below isn't meant as a retort, but to hopefully clarify things a\n> bit.\n\nSome further clarifications on my part below.\n\n\n\n> > Sure, I get that that the contribution workflow to Git core has\n> > historically grown, but what concerns me is that the efforts to\n> > \"bridge\" the contribution workflow to the \"modern world\" seem to go\n> > into the wrong direction: Tools like submitgit [1], gitgitgadget [2]\n> > and now patchwork [3] were created / are considered for use to allow\n> > the legacy email path workflow to remain, but also allow more \"GUI\n> > minded\" people to contribute. While this has worked quite well for\n> > some time, and esp. gitgitgadget [2] seems to haven gotten popular, I\n> > wonder whether it's now the time to \"swap the default\", and make a\n> > patch / contribution tool with a GUI the standard, and bridge the\n> > legacy workflow by using / creating tooling that makes it convenient\n> > to use those modern tools from the CLI, instead of the opposite.\n> \n> I think characterizing E-Mail as a \"legacy\" workflow isn't accurate. All\n> of these proposed alternatives involve moving away from something that's\n> a distributed system today (E-Mail infrastructure, local clients), to\n> what's essentially some website run by a centralized entity, in some\n> cases proprietary.\n> \n> Even in cases where the tool itself isn't proprietary (e.g. GitLab\n> instead of GitHub) using GitHub/GitLab/Gerrit/Atlassian Bitbucket\n> etc. means having some centralized infrastructure somewhere holding a\n> bunch of data only the operator of that infrastructure can realistically\n> access.\n\nThanks all for bringing this up. I should add the mail archives\nat lore.kernel.org are backed by public-inbox, thus all mail and\ncode are completely reproducible by anyone. It even targets\nold, slow, legacy hardware and tries to minimize bandwidth to\nbenefit the economically-disadvantaged.\n\nForking is the checks-and-balances system of free software to\nprevent any central entity from becoming too powerful (remember:\npower corrupts). DVCS (e.g. git) makes forking easier,\npublic-inbox uses git to make text communications history\nreproducible (and therefore, forkable). My end goal is\ncompletely forkable communities without any central arbiters.\n\nEmail has problems, of course. Big players are constantly\nintroducing more complexity to squeeze out smaller players.\nAnd most mail servers require DNS through ICANN, an organization\nthat tried to extort .org users and hence likely to attempt\nfurther abuses of power in the future. Again, power corrupts.\n\n> So really basic things that are comparatively trivial with E-Mail\n> (e.g. \"I think the search sucks, try another client\") run up against a\n> brick wall with those tools.\n\nI'm working on some local tooling based on public-inbox ;)\n(of course, totally optional)\n\nAnd public-inbox will support JMAP in coming months, so it'll\nbe a standardized API and hopefully compatible with a wider\nvariety of clients and frontends. This should help users who\nprefer other other layouts.\n\n\nAnyways, I do what I can to keep hardware and bandwidth\nrequirements low for folks who:\na) can't afford to keep up with Moore's law\nb) won't accept mystery firmware blobs in modern HW\nI got into free software because HW was constantly obsoleted by\nproprietary software; and I'm sad so much \"modern\" free software\nhas followed that path...\n\nThe modern web is largely unusable with HW I first tried git\nwith in 2005. Despite being technically free software, the size\nof \"modern\" browsers makes it impractical for people on slow\nHW/connections to actually exercise software freedom. IMHO, any\nHW that worked well in 2005 when git started ought to work well\nfor git and anything associated with it today.\n"},{"id":"422231","messageId":"CAHGBnuOVmzzhgW6GanHBXNb22UW3P1m3i6PJnOUEhYPO76hH4g@mail.gmail.com","threadId":"55492","inReplyTo":"87fszn48lh.fsf@evledraar.gmail.com","subject":"Re: Pain points in Git's patch flow","fromName":"Sebastian Schuberth","fromEmail":"sschuberth@gmail.com","sentAt":"2021-04-19T05:54:37Z","receivedAt":"2021-04-19T05:54:53Z","isPatch":false,"sender":{"key":"sschuberth@gmail.com","avatar":"https://avatars.githubusercontent.com/u/349154?v=4"},"body":"On Sun, Apr 18, 2021 at 10:54 PM Ævar Arnfjörð Bjarmason\n wrote:\n\n> And thank you for participating in the discussion. I think it's\n> especially valuable to get a viewpoint like yours, i.e. someone who (per\n> this E-Mail below) gave up in frustration with the current development\n> flow.\n\nTo be fair, Git's contribution flow isn't the only reason why I chose\nto stop contributing. Another reason is the very lengthy and tedious\ndiscussions that too often spark from rather small changes.\n\nAlso, I wouldn't say I \"gave up in frustration\". It was a mostly\nunemotional decision on which of the many OSS projects I contribute to\nmy rare spare time is spent best.\n\n> I think it's important not to conflate tooling issues with social\n> issues. It's not that we e.g. couldn't whip up a quick script to\n\nI'm not sure I agree completely here, because some tools make it\neasier to overcome social issues than others.\n\n> Rather it's that it's a volunteer project and people work on what\n> they're interested in.\n\nExactly. That's why I believe tooling should allow people to subscribe\nto changes in code areas they're interested in, rather than a\ncontributor having to know which subsystem maintainer to put in CC\n(e.g. for gitk changes). At least at the time when I contributed it\nwas sometimes hard to move things forward if you didn't reach out to\nthe right people.\n\n> So maybe having assigned reviewers would help move things along. But I\n> wonder if it wouldn't also lead down the rut of PRs/MRs languishing for\n> months, because the reviewers just want to spend their time in some\n> other way.\n\nHaving default assignees for reviews / code owners / however you want\nto call it does not mean that only these people should review, or that\nsomething cannot be merged without their review. It just makes it more\nclear who's opinion would be the best to get, and who should execute a\n\"word of command\" if things do not move forward.\n\n> I.e. the design of many of these tools in this regard assumes you have a\n> workforce, not the cat-herding problem of volunteers working on whatever\n> strikes their fancy.\n\nE.g. GitHub makes the distinction between \"reviewers\" for a PR and\n\"assignees\" for a PR, and the former can be configured from a\nCODEOWNERS file. In projects I contribute to on GitHub, \"reviewers\"\nare used as an optional list of named reviewers, i.e. these people are\nexplicitly invited for a review. There's no obligation to review,\nthough. On the other hand, if there are additional \"assignees\", these\npeople are explicitly asked for a review. Assignees can also be\nassigned only at a later stage of the review, to \"settle\" a\ndiscussion.\n\nThe cat-herd of volunteers would neither be \"reviewers\" nor\n\"assignees\", but they would just browse the list or open PRs can jump\nit where they want to.\n\n> I think characterizing E-Mail as a \"legacy\" workflow isn't accurate. All\n\nI admit it was a deliberately provocative choice of words, well\nknowing it's not reflecting the current state, to underline how I'm\nfeeling about the workflow. E-mail is great. Also plain text e-mail is\ngreat (I've configured all my client to only send plain text), but\nplease, not for sending around code patches.\n\nIf you send around code patches by mail instead of directly working on\nGit repos plus some UI, that feels to me like serializing a data class\ninstance to JSON, printing the JSON string to paper, taking that sheet\nof paper to another PC with a scanner, using OCR to scan it into a\nJSON string, and then deserialize it again to a new data class\ninstance, when you could have just a REST API to push the data from on\nPC to the other.\n\n> of these proposed alternatives involve moving away from something that's\n> a distributed system today (E-Mail infrastructure, local clients), to\n> what's essentially some website run by a centralized entity, in some\n> cases proprietary.\n\nThat's a good point, I admit I haven't thought of that. Probably\nbecause I also don't care much. So *does* it really matter? What\nexactly concerns you about a \"centralized entity\"? Is it the technical\naspect of a single point of failure, or the political / social aspect\nof being dependent on someone you do not want to get influenced by? I\nguess it's a bit of both.\n\nWhile these concerns could probably be addressed somewhat e.g. by\nmultiple independently operated Gerrit servers that are kept in sync,\nI was curious and quickly search for more fitting \"truly\ndecentralized\" solutions, and came across radicle [1]. Just FYI.\n\n> So really basic things that are comparatively trivial with E-Mail\n> (e.g. \"I think the search sucks, try another client\") run up against a\n> brick wall with those tools.\n\nNot necessarily. As many of these tools have (REST) APIs, also\ndifferent API clients exist that you could try.\n\n> And to e.g. as one good example to use (as is the common convention on\n> this list) git-range-diff to display a diff to the \"last rebased\n> revision\" would mean some long feature cycle in those tools, if they're\n> even interested in implementing such a thing at all.\n\nAFAIK Gerrit can already do that.\n\n-- \nSebastian Schuberth\n"},{"id":"422232","messageId":"CAHGBnuOtJ-oHGe+jb5L-qPQQ6v-fQ-1xHC0BPrR4eDeym3coCw@mail.gmail.com","threadId":"55492","inReplyTo":"CAHGBnuOVmzzhgW6GanHBXNb22UW3P1m3i6PJnOUEhYPO76hH4g@mail.gmail.com","subject":"Re: Pain points in Git's patch flow","fromName":"Sebastian Schuberth","fromEmail":"sschuberth@gmail.com","sentAt":"2021-04-19T06:04:07Z","receivedAt":"2021-04-19T06:04:22Z","isPatch":false,"sender":{"key":"sschuberth@gmail.com","avatar":"https://avatars.githubusercontent.com/u/349154?v=4"},"body":"On Mon, Apr 19, 2021 at 7:54 AM Sebastian Schuberth\n wrote:\n\n> While these concerns could probably be addressed somewhat e.g. by\n> multiple independently operated Gerrit servers that are kept in sync,\n> I was curious and quickly search for more fitting \"truly\n> decentralized\" solutions, and came across radicle [1]. Just FYI.\n\nForgot to add the link:\n\n[1] https://radicle.xyz/\n\n-- \nSebastian Schuberth\n"},{"id":"422234","messageId":"87czuq4r4l.fsf@evledraar.gmail.com","threadId":"55492","inReplyTo":"CAHGBnuOVmzzhgW6GanHBXNb22UW3P1m3i6PJnOUEhYPO76hH4g@mail.gmail.com","subject":"Re: Pain points in Git's patch flow","fromName":"Ævar Arnfjörð Bjarmason","fromEmail":"avarab@gmail.com","sentAt":"2021-04-19T08:26:18Z","receivedAt":"2021-04-19T08:26:22Z","isPatch":false,"sender":{"key":"avarab@gmail.com","avatar":"https://avatars.githubusercontent.com/u/45301?v=4"},"body":"\nOn Mon, Apr 19 2021, Sebastian Schuberth wrote:\n\n> On Sun, Apr 18, 2021 at 10:54 PM Ævar Arnfjörð Bjarmason\n> wrote:\n>\n>> And thank you for participating in the discussion. I think it's\n>> especially valuable to get a viewpoint like yours, i.e. someone who (per\n>> this E-Mail below) gave up in frustration with the current development\n>> flow.\n>\n> To be fair, Git's contribution flow isn't the only reason why I chose\n> to stop contributing. Another reason is the very lengthy and tedious\n> discussions that too often spark from rather small changes.\n>\n> Also, I wouldn't say I \"gave up in frustration\". It was a mostly\n> unemotional decision on which of the many OSS projects I contribute to\n> my rare spare time is spent best.\n>\n>> I think it's important not to conflate tooling issues with social\n>> issues. It's not that we e.g. couldn't whip up a quick script to\n>\n> I'm not sure I agree completely here, because some tools make it\n> easier to overcome social issues than others.\n\nIndeed, to clarify I'm not dismissing that. E.g. is an easier UX or\nother \"prodding\" going to result in better collaboration? Maybe. I'm\njust pointing out that it may not mostly/entirely be a tooling issue.\n\n>> Rather it's that it's a volunteer project and people work on what\n>> they're interested in.\n>\n> Exactly. That's why I believe tooling should allow people to subscribe\n> to changes in code areas they're interested in, rather than a\n> contributor having to know which subsystem maintainer to put in CC\n> (e.g. for gitk changes). At least at the time when I contributed it\n> was sometimes hard to move things forward if you didn't reach out to\n> the right people.\n>\n>> So maybe having assigned reviewers would help move things along. But I\n>> wonder if it wouldn't also lead down the rut of PRs/MRs languishing for\n>> months, because the reviewers just want to spend their time in some\n>> other way.\n>\n> Having default assignees for reviews / code owners / however you want\n> to call it does not mean that only these people should review, or that\n> something cannot be merged without their review. It just makes it more\n> clear who's opinion would be the best to get, and who should execute a\n> \"word of command\" if things do not move forward.\n>\n>> I.e. the design of many of these tools in this regard assumes you have a\n>> workforce, not the cat-herding problem of volunteers working on whatever\n>> strikes their fancy.\n>\n> E.g. GitHub makes the distinction between \"reviewers\" for a PR and\n> \"assignees\" for a PR, and the former can be configured from a\n> CODEOWNERS file[...]\n\nCODEOWNERS and default assignment etc. is something that tends to\nover-assign things, which is fine for a workforce you're paying, but\nit's important to realize that the practice in the git project is to put\nthe onus on the submitter of the change to manually find who they should\nCC.\n\nBecause it's not a problem you can really solve automatically without\nthe a trade-off of feeding potentially uninterested parties a bunch of\npatches they're not interested in, which could be another thing that\nmakes them give up contributing.\n\nSo for example I've got a lot of code in git I consider that I \"own\" in\nthe sense that I'm responsible for creating it, have been involved in\npast design discussions about it etc.\n\nBut very little of that cleanly maps to a file as the CODEOWNERS\nworkflow expects. E.g. there's parts of grep.c that I'd definitely like\nto be CC'd on, but others not. Even a \"git blame\" of the specific lines\nyou're touching isn't always what you want.\n\nHaving used CODEOWNERS in a corporate setting I think it's most useful\nfor e.g. when you have a monorepo with different subdirectories that do\n(at least mostly) map o different teams or peope, think drivers/usb/* or\narch/s390/*.\n\n>> I think characterizing E-Mail as a \"legacy\" workflow isn't accurate. All\n>\n> I admit it was a deliberately provocative choice of words, well\n> knowing it's not reflecting the current state, to underline how I'm\n> feeling about the workflow. E-mail is great. Also plain text e-mail is\n> great (I've configured all my client to only send plain text), but\n> please, not for sending around code patches.\n>\n> If you send around code patches by mail instead of directly working on\n> Git repos plus some UI, that feels to me like serializing a data class\n> instance to JSON, printing the JSON string to paper, taking that sheet\n> of paper to another PC with a scanner, using OCR to scan it into a\n> JSON string, and then deserialize it again to a new data class\n> instance, when you could have just a REST API to push the data from on\n> PC to the other.\n\nThat's not inherent with the E-Mail workflow, e.g. Linus on the LKML\nalso pulls from remotes.\n\nIt does ensure that e.g. if someone submits patches and then deletes\ntheir GitHub account the patches are still on the ML.\n\n>> of these proposed alternatives involve moving away from something that's\n>> a distributed system today (E-Mail infrastructure, local clients), to\n>> what's essentially some website run by a centralized entity, in some\n>> cases proprietary.\n>\n> That's a good point, I admit I haven't thought of that. Probably\n> because I also don't care much. So *does* it really matter? What\n> exactly concerns you about a \"centralized entity\"? Is it the technical\n> aspect of a single point of failure, or the political / social aspect\n> of being dependent on someone you do not want to get influenced by? I\n> guess it's a bit of both.\n\nTo begin with if we'd have used the bugtracker solution from the\nbeginning we'd probably be talking about moving away from Bugzilla\nnow. I.e. using those things means your data becomes entangled with the\ntheir opinionated data models.\n\n> While these concerns could probably be addressed somewhat e.g. by\n> multiple independently operated Gerrit servers that are kept in sync,\n> I was curious and quickly search for more fitting \"truly\n> decentralized\" solutions, and came across radicle [1]. Just FYI.\n\nThat's interesting, but I haven't looked into that tool. Browsing their\ndocumentation earlier many of the links were 404s.\n\n>> So really basic things that are comparatively trivial with E-Mail\n>> (e.g. \"I think the search sucks, try another client\") run up against a\n>> brick wall with those tools.\n>\n> Not necessarily. As many of these tools have (REST) APIs, also\n> different API clients exist that you could try.\n\nAPI use that usually (always?) requires an account/EULA with some entity\nholding the data, and as a practical concern getting all the data is\nusually some huge number of API requests.\n\n>> And to e.g. as one good example to use (as is the common convention on\n>> this list) git-range-diff to display a diff to the \"last rebased\n>> revision\" would mean some long feature cycle in those tools, if they're\n>> even interested in implementing such a thing at all.\n>\n> AFAIK Gerrit can already do that.\n\nSure, FWIW the point was that you needed Gerrit to implement that, and\nto suggest what if they weren't interested. Would you need to maintain a\nforked Gerrit?\n\nNot to say that's a dealbreaker, just trying to bridge the understanding\nof why some people prefer the E-Mail workflow.\n\nAnyway, as before don't take any of the above as arguing, FWIW I\nwouldn't mind using one of these websites overall if it helped\ndevelopment velocity in the project.\n\nUltimately those things are up to Junio though, which these discussions\nalways come down to.\n\nI just wanted to help bridge the gap between the distributed E-Mail v.s\ncentralized website flow.\n\n"},{"id":"422314","messageId":"YH2HLtZY/KjrYrng@mit.edu","threadId":"55492","inReplyTo":"20210419025754.GA26065@dcvr","subject":"Re: Pain points in Git's patch flow","fromName":"Theodore Ts'o","fromEmail":"tytso@mit.edu","sentAt":"2021-04-19T13:35:42Z","receivedAt":"2021-04-19T13:37:02Z","isPatch":false,"sender":{"key":"tytso@mit.edu","avatar":"https://avatars.githubusercontent.com/u/51416?v=4"},"body":"On Mon, Apr 19, 2021 at 02:57:54AM +0000, Eric Wong wrote:\n> > But for folks who don't have a dev environment ready at hand (new\n> > comers, during travel with only phone access), it would be nice to\n> > have a way to run tests without a dev environment.\n> \n> Fwiw, the GCC Farm project gives ssh accounts for all free\n> software contributors, not just gcc hackers: https://cfarm.tetaneutral.net\n> Perhaps there's other similar services, too.\n> \n> Slow down and enjoy travel :) There's very little in free\n> software urgent enough to require constant attention. Email is\n> well-suited for asynchronous work, and nobody should expect\n> instant replies. The always-on nature of the modern Internet\n> and smartphones increases stress and dangerous situations; so I\n> hope free software hackers aren't contributing to that.\n\nFWIW, I find the disconnected, e-mail based workflow using a\ncommand-line interface to be *ideal* for working while travelling on\nan airplane. I'm mostly disconnected from the internet, because the\nairplane wifi is so slow that you *really* don't want to use a\nweb-based interface, but I can use offlineimap to sync my e-mail onto\nmy laptop, and using the command-line interface and the lack of\ndistractions is great since you really can't surf the web on the\ngogoonline's pathetically slow 'net access.\n\nThis also means I have an excuse to work on open source projects which\nare using e-mail and off-line git, as opposed to $WORK which mandates\nthe use of gerrit. :-)\n\n(All of the above applies pre-pandemic, of course. I've been working\nfrom home and not travelling for the past year+, sigh.)\n\n \t \t \t \t \t - Ted\n\nP.S. Also, while working on the road, I find that web-based\ninterfaces are much more tolerable when I'm at my desk with a 40\"\nscreen. When I'm using a 13\" laptop screen, I much prefer CLI\ninterfaces. YMMV, of course.\n"},{"id":"422324","messageId":"CAHGBnuMedez4SE-4-JwCcR8k=_FRtjgBdBSEJqshQnVceCvGug@mail.gmail.com","threadId":"55492","inReplyTo":"87czuq4r4l.fsf@evledraar.gmail.com","subject":"Re: Pain points in Git's patch flow","fromName":"Sebastian Schuberth","fromEmail":"sschuberth@gmail.com","sentAt":"2021-04-19T19:23:14Z","receivedAt":"2021-04-19T19:23:43Z","isPatch":false,"sender":{"key":"sschuberth@gmail.com","avatar":"https://avatars.githubusercontent.com/u/349154?v=4"},"body":"On Mon, Apr 19, 2021 at 10:26 AM Ævar Arnfjörð Bjarmason\n wrote:\n\n> > If you send around code patches by mail instead of directly working on\n> > Git repos plus some UI, that feels to me like serializing a data class\n> > instance to JSON, printing the JSON string to paper, taking that sheet\n> > of paper to another PC with a scanner, using OCR to scan it into a\n> > JSON string, and then deserialize it again to a new data class\n> > instance, when you could have just a REST API to push the data from on\n> > PC to the other.\n>\n> That's not inherent with the E-Mail workflow, e.g. Linus on the LKML\n> also pulls from remotes.\n\nYeah, I was vaguely aware of this. To me, the question is why \"also\"?\nWhy not *only* pull from remotes? What's the feature gap email patches\ntry to close?\n\n> It does ensure that e.g. if someone submits patches and then deletes\n> their GitHub account the patches are still on the ML.\n\nAh, so it's basically just about a backup? That could also be solved\ndifferently by forking / syncing Git repos.\n\n> To begin with if we'd have used the bugtracker solution from the\n> beginning we'd probably be talking about moving away from Bugzilla\n> now. I.e. using those things means your data becomes entangled with the\n> their opinionated data models.\n\nIndeed, it's an art to choose the right tool at the time, and to\nensure you're not running into some \"vendor-lock-in\" if data export is\nmade too hard. And aligning on someone's \"opinionated data model\" is\nnot necessarily a bad thing, as standardization can also help\ninteroperability and to smoothen workflows.\n\n> > Not necessarily. As many of these tools have (REST) APIs, also\n> > different API clients exist that you could try.\n>\n> API use that usually (always?) requires an account/EULA with some entity\n> holding the data, and as a practical concern getting all the data is\n> usually some huge number of API requests.\n\nI'm not sure how relevant that concern really is, but in any cause it\nwould be irrelevant for a self-hosted solution.\n\n> >> And to e.g. as one good example to use (as is the common convention on\n> >> this list) git-range-diff to display a diff to the \"last rebased\n> >> revision\" would mean some long feature cycle in those tools, if they're\n> >> even interested in implementing such a thing at all.\n> >\n> > AFAIK Gerrit can already do that.\n>\n> Sure, FWIW the point was that you needed Gerrit to implement that, and\n> to suggest what if they weren't interested. Would you need to maintain a\n> forked Gerrit?\n\nSorry, I can't follow that. Why would you need to maintain a fork of\nGerrit if Gerrit already has the feature you're looking for? Is it a\nhypothetical question about what to do if Gerrit would not have the\nfeature yet?\n\n> Anyway, as before don't take any of the above as arguing, FWIW I\n> wouldn't mind using one of these websites overall if it helped\n> development velocity in the project.\n\nI appreciate that open mindset of yours here.\n\n> I just wanted to help bridge the gap between the distributed E-Mail v.s\n> centralized website flow.\n\nMaybe, instead of jumping into something like an email vs Gerrit\ndiscussion, what would help is to get back one step and gather the\nabstract requirements. Then, with a fresh and unbiased mind, look at\nall the tools and infrastructure out there that are able to fulfill\nthe needs, and then make a choice.\n\n-- \nSebastian Schuberth\n"},{"id":"422327","messageId":"20210419193600.GA19186@dcvr","threadId":"55492","inReplyTo":"CAHGBnuOVmzzhgW6GanHBXNb22UW3P1m3i6PJnOUEhYPO76hH4g@mail.gmail.com","subject":"Re: Pain points in Git's patch flow","fromName":"Eric Wong","fromEmail":"e@80x24.org","sentAt":"2021-04-19T19:36:00Z","receivedAt":"2021-04-19T19:36:01Z","isPatch":false,"sender":{"key":"e@80x24.org","avatar":null},"body":"Sebastian Schuberth wrote:\n> On Sun, Apr 18, 2021 at 10:54 PM Ævar Arnfjörð Bjarmason\n> wrote:\n> \n> > And thank you for participating in the discussion. I think it's\n> > especially valuable to get a viewpoint like yours, i.e. someone who (per\n> > this E-Mail below) gave up in frustration with the current development\n> > flow.\n> \n> To be fair, Git's contribution flow isn't the only reason why I chose\n> to stop contributing. Another reason is the very lengthy and tedious\n> discussions that too often spark from rather small changes.\n> \n> Also, I wouldn't say I \"gave up in frustration\". It was a mostly\n> unemotional decision on which of the many OSS projects I contribute to\n> my rare spare time is spent best.\n\nI guess some things aren't for everybody. When I started\ngit-svn, I never expected git to be the right tool for others.\nI figured most folks could just continue using SVN since they\nseem to like centralized things or at least have some sort of\n\"authority\" to look to.\n\nI'm largely uninvolved with git nowadays since I'm reasonably\nsatisfied with how it works; that and I prefer scripting\nlanguages rather than ahead-of-time languages.\n\n> > Rather it's that it's a volunteer project and people work on what\n> > they're interested in.\n> \n> Exactly. That's why I believe tooling should allow people to subscribe\n> to changes in code areas they're interested in, rather than a\n> contributor having to know which subsystem maintainer to put in CC\n> (e.g. for gitk changes). At least at the time when I contributed it\n> was sometimes hard to move things forward if you didn't reach out to\n> the right people.\n\nFwiw, any public-inbox endpoint with Xapian search enabled lets\nyou request an Atom feed via \"x=A\" query parameter.\n\nTo watch a particular filename, the \"dfn:\" prefix may be used.\nThe prefixes supported for a particular instance are documented in\n, and you\ncan watch multiple files by combining with \"OR\".\n\nhttps://public-inbox.org/git/?q=dfn:cache.h+OR+dfn:git-send-email.perl&x=A\n\nYou can also POST to get a gzipped mboxrd file:\n\ncurl -d '' \\\n 'https://public-inbox.org/git/?q=dfn:cache.h+OR+dfn:git-send-email.perl&x=m'\n\n> > of these proposed alternatives involve moving away from something that's\n> > a distributed system today (E-Mail infrastructure, local clients), to\n> > what's essentially some website run by a centralized entity, in some\n> > cases proprietary.\n> \n> That's a good point, I admit I haven't thought of that. Probably\n> because I also don't care much. So *does* it really matter? What\n> exactly concerns you about a \"centralized entity\"? Is it the technical\n> aspect of a single point of failure, or the political / social aspect\n> of being dependent on someone you do not want to get influenced by? I\n> guess it's a bit of both.\n\nYes, both for me. The political/social aspect is the main\nreason I'm involved with DVCS (and a large part of why I'm\ninvolved with free software in general).\n\n> While these concerns could probably be addressed somewhat e.g. by\n> multiple independently operated Gerrit servers that are kept in sync,\n> I was curious and quickly search for more fitting \"truly\n> decentralized\" solutions, and came across radicle [1]. Just FYI.\n\nI don't think any sort of radicle \"flag day\" or tool mandate is\ngoing to fly. I seem to recall at least one prominent Linux\nkernel hacker doesn't even use git; though I'm not sure if\nthat's still the case.\n\nDespite being a DVCS user even pre-git, I'm actually\npessimistic about decentralization protocols that either:\n\n1) rely on planet-destroying proof-of-work schemes\n\n2) will need to reinvent the spam filtering techniques\n of email once they hit critical mass\n\nEmail is already well-established with a good amount of small\nplayers, and plain-text is relatively inexpensive. So it seems\nbest to build off the only halfway-decentralized thing we have\nin wide use, rather than trying to start from scratch.\n"},{"id":"422328","messageId":"CAHGBnuOv5PvCcKqed-sTOs2uxyuhRS7RDF4XvzPu9oHpyroasQ@mail.gmail.com","threadId":"55492","inReplyTo":"20210419193600.GA19186@dcvr","subject":"Re: Pain points in Git's patch flow","fromName":"Sebastian Schuberth","fromEmail":"sschuberth@gmail.com","sentAt":"2021-04-19T19:49:46Z","receivedAt":"2021-04-19T19:50:04Z","isPatch":false,"sender":{"key":"sschuberth@gmail.com","avatar":"https://avatars.githubusercontent.com/u/349154?v=4"},"body":"On Mon, Apr 19, 2021 at 9:36 PM Eric Wong wrote:\n\n> > Also, I wouldn't say I \"gave up in frustration\". It was a mostly\n> > unemotional decision on which of the many OSS projects I contribute to\n> > my rare spare time is spent best.\n>\n> I guess some things aren't for everybody. When I started\n> git-svn, I never expected git to be the right tool for others.\n> I figured most folks could just continue using SVN since they\n> seem to like centralized things or at least have some sort of\n> \"authority\" to look to.\n>\n> I'm largely uninvolved with git nowadays since I'm reasonably\n> satisfied with how it works; that and I prefer scripting\n> languages rather than ahead-of-time languages.\n\nTrue, since quite a while I'm also at a point where I'm satisfied with\nhow Git (for Windows) works, so I also ceased to see the need to\ncontribute. That's indeed another reason I forgot to mention.\n\n> To watch a particular filename, the \"dfn:\" prefix may be used.\n> The prefixes supported for a particular instance are documented in\n> , and you\n> can watch multiple files by combining with \"OR\".\n\nThanks for pointing out these interesting features, I wasn't aware of them.\n\n> I don't think any sort of radicle \"flag day\" or tool mandate is\n> going to fly. I seem to recall at least one prominent Linux\n> kernel hacker doesn't even use git; though I'm not sure if\n> that's still the case.\n\nLike you said in the beginning, I guess some things aren't for everybody.\n\n> Email is already well-established with a good amount of small\n> players, and plain-text is relatively inexpensive. So it seems\n> best to build off the only halfway-decentralized thing we have\n> in wide use, rather than trying to start from scratch.\n\nWhile I can understand that conservative approach for a community\naround a tool as important as Git, I still fear that only ever\nsticking to technology that is already in wide use will hinder to look\nover the rim of the tea cup.\n\n-- \nSebastian Schuberth\n"},{"id":"422343","messageId":"20210419214921.afurkxy7oru6bny6@nitro.local","threadId":"55492","inReplyTo":"CAHGBnuOVmzzhgW6GanHBXNb22UW3P1m3i6PJnOUEhYPO76hH4g@mail.gmail.com","subject":"Re: Pain points in Git's patch flow","fromName":"Konstantin Ryabitsev","fromEmail":"konstantin@linuxfoundation.org","sentAt":"2021-04-19T21:49:21Z","receivedAt":"2021-04-19T21:49:27Z","isPatch":false,"sender":{"key":"konstantin@linuxfoundation.org","avatar":"https://gravatar.com/avatar/7cb8827c6de56e1bd2dea16508c6708aa43feed3bf3813bcdacecdf96ceadd79?d=mp&s=160"},"body":"On Mon, Apr 19, 2021 at 07:54:37AM +0200, Sebastian Schuberth wrote:\n> > of these proposed alternatives involve moving away from something that's\n> > a distributed system today (E-Mail infrastructure, local clients), to\n> > what's essentially some website run by a centralized entity, in some\n> > cases proprietary.\n> \n> That's a good point, I admit I haven't thought of that. Probably\n> because I also don't care much. So *does* it really matter? What\n> exactly concerns you about a \"centralized entity\"? Is it the technical\n> aspect of a single point of failure, or the political / social aspect\n> of being dependent on someone you do not want to get influenced by? I\n> guess it's a bit of both.\n\nIt's all of the above, and really should not be discounted. Let's take what\nRussian government is doing lately as an example. In its effort to control\nsocial dissent, Russian censorship organization RosKomNadzor (RKN) has taken\nsteps to deliberately break internet operation -- in a very ham-fisted way.\nJust a month ago they tried to \"slow down\" Twitter by blocking DNS queries for\nany domains containing the substring \"t.co\" -- which, hey, broke\ngihubusercontent.com among many other sites. There's every reason to believe\nthat this won't be the only time they do something idiotic like that, so as a\nresult it is increasingly difficult for Russian contributors to justify\nparticipating in projects that are hosted on GitHub -- one day they may not be\nable to reach it reliably (or at all).\n\n(If you think the answer to that would be \"just use a VPN\", it's one of those\nrecommendations that are easy to make for someone not worried about their ISP\nreporting \"sketchy encrypted traffic\" to \"the authorities.\")\n\nPatches sent via email remain immune to this. Even if vger falls over, it's\nmerely a list service -- there are alternative ways of transmitting RFC2822\nmessages that don't involve a central host (such as via a NNTP gateway,\npublishing a public-inbox \"feed\", etc). Email remains one of the few protocols\nthat are designed ground-up to be decentralized and I'm afraid that we are\nagain finding ourselves in a world where this is increasingly relevant.\n\n> While these concerns could probably be addressed somewhat e.g. by\n> multiple independently operated Gerrit servers that are kept in sync,\n> I was curious and quickly search for more fitting \"truly\n> decentralized\" solutions, and came across radicle [1]. Just FYI.\n\nI know Radicle folks -- I was on their technical board. A lot of what they\nhave implemented is very similar to my initial thoughts expressed in\nhttps://people.kernel.org/monsieuricon/patches-carved-into-developer-sigchains\n\nI have high hopes for the project, but it's not ready to take on the world\nuntil they implement code collaboration aspects (issue tracking, change\nrequests, etc). It's going to be tough and I really hope they succeed.\n\n-K\n"},{"id":"422346","messageId":"20210419220013.mguw4l5644r2c7gj@nitro.local","threadId":"55492","inReplyTo":"CAHGBnuOv5PvCcKqed-sTOs2uxyuhRS7RDF4XvzPu9oHpyroasQ@mail.gmail.com","subject":"Re: Pain points in Git's patch flow","fromName":"Konstantin Ryabitsev","fromEmail":"konstantin@linuxfoundation.org","sentAt":"2021-04-19T22:00:13Z","receivedAt":"2021-04-19T22:00:22Z","isPatch":false,"sender":{"key":"konstantin@linuxfoundation.org","avatar":"https://gravatar.com/avatar/7cb8827c6de56e1bd2dea16508c6708aa43feed3bf3813bcdacecdf96ceadd79?d=mp&s=160"},"body":"On Mon, Apr 19, 2021 at 09:49:46PM +0200, Sebastian Schuberth wrote:\n> > To watch a particular filename, the \"dfn:\" prefix may be used.\n> > The prefixes supported for a particular instance are documented in\n> > , and you\n> > can watch multiple files by combining with \"OR\".\n> \n> Thanks for pointing out these interesting features, I wasn't aware of them.\n\nEric is being modest. There are very cool things brewing in public-inbox, like\nability to create saved searches and follow threads you're interested in.\nE.g. you should be able to define something like \"whenever someone mentions my\nfavourite file, function name, or term, copy the entire thread into my inbox\nand continuously update it with new messages.\"\n\nI'm hoping that this will help turn the concept of mailing lists on their head\n-- instead of subscribing to a list, folks will instead subscribe to closely\nrelevant saved searches across any number of remote and local sources.\n\n> > Email is already well-established with a good amount of small\n> > players, and plain-text is relatively inexpensive. So it seems\n> > best to build off the only halfway-decentralized thing we have\n> > in wide use, rather than trying to start from scratch.\n> \n> While I can understand that conservative approach for a community\n> around a tool as important as Git, I still fear that only ever\n> sticking to technology that is already in wide use will hinder to look\n> over the rim of the tea cup.\n\nI view email as merely one way of exchanging RFC2822-formatted messages. \nThere are others and RFC2822 is robust enough to serve as a good standard\nbase that allows both free-form and structured content, including mixed.\n\n-K\n"},{"id":"422347","messageId":"YH4FaQRB/vWOI9aI@mit.edu","threadId":"55492","inReplyTo":"CAHGBnuMedez4SE-4-JwCcR8k=_FRtjgBdBSEJqshQnVceCvGug@mail.gmail.com","subject":"Re: Pain points in Git's patch flow","fromName":"Theodore Ts'o","fromEmail":"tytso@mit.edu","sentAt":"2021-04-19T22:34:17Z","receivedAt":"2021-04-19T22:34:30Z","isPatch":false,"sender":{"key":"tytso@mit.edu","avatar":"https://avatars.githubusercontent.com/u/51416?v=4"},"body":"On Mon, Apr 19, 2021 at 09:23:14PM +0200, Sebastian Schuberth wrote:\n> > That's not inherent with the E-Mail workflow, e.g. Linus on the LKML\n> > also pulls from remotes.\n> \n> Yeah, I was vaguely aware of this. To me, the question is why \"also\"?\n> Why not *only* pull from remotes? What's the feature gap email patches\n> try to close?\n\nLinus mostly pulls from git trees. The e-mail workflow tends to be\nused by maintainers, who are reviewing submissions from their\ncontributors. People submitting changes relating to ext4 know to send\nit to the linux-ext4 mailing list; people who are submitting changes\nto the xfs file system send it to linux-xfs, etc.\n\n> > It does ensure that e.g. if someone submits patches and then deletes\n> > their GitHub account the patches are still on the ML.\n> \n> Ah, so it's basically just about a backup? That could also be solved\n> differently by forking / syncing Git repos.\n\nThe primary reason why the kernel uses mailing lists is because code\nreviews are fundamentally *discussions*, and people are used to using\ninboxes. Sure, you can have a gerrit server send e-mail notifications\nabout code reviews, but then you have to reply by going to the gerrit\nserver (and gerrit really doesn't work well on slow network link such\nas those found on airplanes and cruise ships). I'd say that most\nmaintainers simply find e-mail reviews to simply be more *convenient*\nthan using gerrit. And over time, we've used other tools to track\nmetadata over the status of a patch, such as patchwork, which are\noptional.\n\n> > I just wanted to help bridge the gap between the distributed E-Mail v.s\n> > centralized website flow.\n> \n> Maybe, instead of jumping into something like an email vs Gerrit\n> discussion, what would help is to get back one step and gather the\n> abstract requirements. Then, with a fresh and unbiased mind, look at\n> all the tools and infrastructure out there that are able to fulfill\n> the needs, and then make a choice.\n\nI'll note that the kernel folks have done this, starting with a 2019\nKernel Summit talk at the Linux Plumbers Conference in Lisbon. A\ndescription of the follow-up discussions from that talk can be found\nhere:\n\n\thttps://lwn.net/Articles/803619/\n\nThere was a collection of requirements on a thread on the newly\ncreated workflows@vger.kernel.org mailing list. This has led to a\nnumber of proposals to make improvements to git, public-inbox,\npatchwork, the kernel.org infrastructures, etc., some of which were\nfunded by the Linux Foundation last year.\n\nKonstantin Ryabitsev has been driving a large amount of that work, and\none of the things that has come out of that is b4. (Yes, that's a\nStar Trek reference... https://memory-alpha.fandom.com/wiki/B-4)\n\n https://people.kernel.org/monsieuricon/introducing-b4-and-patch-attestation\n\nObviously, this isn't intended to be a solution for everyone, and I'm\nsure there are many projects that are happy forcing developers to use,\nsay, Gerrit, which might be a better solution for them.\n\nHowever, there are a number of core kernel developers who are\nsuper-allergic to solutions which force users to use web interfaces.\nSo solutions that have a combination of CLI's as well as web interface\nis probably going to be the right approach. Things like pwclient and\nb4 are exciting starting points for improved kernel workflows.\n\nOf course, we've gone a bit farther afield from the original question\nwhich is what should git's development workflows should be. Given\nthat git is using some of the kernel.org infrastructures, certainly\nsome of the kernel workflow tools are options for the git development\ncommunity to consider.\n\nOne of the advantages of the kernel workflows model is that we don't\nforce users to use github or gitlab or gerrit, without having to make\na global decision for the entire community. For example, if some\ndevelopers want to start using b4 to download patch series for git,\nthey could start doing that today.\n\nCheers,\n\n\t\t\t\t\t\t- Ted\n"},{"id":"422353","messageId":"3913391.baLtWKaSvh@thunderbird","threadId":"55492","inReplyTo":"20210419214921.afurkxy7oru6bny6@nitro.local","subject":"Re: Pain points in Git's patch flow","fromName":"Stephen Smith","fromEmail":"ischis2@cox.net","sentAt":"2021-04-19T23:03:47Z","receivedAt":"2021-04-19T23:11:02Z","isPatch":false,"sender":{"key":"ishchis2@gmail.com","avatar":null},"body":"On Monday, April 19, 2021 2:49:21 PM MST Konstantin Ryabitsev wrote:\n> On Mon, Apr 19, 2021 at 07:54:37AM +0200, Sebastian Schuberth wrote:\n> > That's a good point, I admit I haven't thought of that. Probably\n> > because I also don't care much. So *does* it really matter? What\n> > exactly concerns you about a \"centralized entity\"? Is it the technical\n> > aspect of a single point of failure, or the political / social aspect\n> > of being dependent on someone you do not want to get influenced by? I\n> > guess it's a bit of both.\n> \n> It's all of the above, and really should not be discounted. Let's take what\n> Russian government is doing lately as an example. In its effort to control\n> social dissent, Russian censorship organization RosKomNadzor (RKN) has taken\n> steps to deliberately break internet operation -- in a very ham-fisted way.\n\nIt can be other things too. \n\nFor instance a corporation that for a variety of reasons has an urgent need to \nrestrict internet traffic. Email will usually get through, but web site traffic \nmay not.\n\nWhile Github is unlikely to get taken offline, other sites that hold data may \nnot be so lucky. Think bankrupcy or other issues. \n\nEmail traffic allows for routing around such issues.\n\n\n\n\n\n"},{"id":"422370","messageId":"CAHGBnuNrXrHUz9f8nWEdB0PoO0FeLsNpNOGgdiYmsmAD5LjTmg@mail.gmail.com","threadId":"55492","inReplyTo":"YH4FaQRB/vWOI9aI@mit.edu","subject":"Re: Pain points in Git's patch flow","fromName":"Sebastian Schuberth","fromEmail":"sschuberth@gmail.com","sentAt":"2021-04-20T06:30:57Z","receivedAt":"2021-04-20T06:31:18Z","isPatch":false,"sender":{"key":"sschuberth@gmail.com","avatar":"https://avatars.githubusercontent.com/u/349154?v=4"},"body":"On Tue, Apr 20, 2021 at 12:34 AM Theodore Ts'o wrote:\n\n> The primary reason why the kernel uses mailing lists is because code\n> reviews are fundamentally *discussions*, and people are used to using\n> inboxes. Sure, you can have a gerrit server send e-mail notifications\n\n[...]\n\n> maintainers simply find e-mail reviews to simply be more *convenient*\n> than using gerrit. And over time, we've used other tools to track\n\nThat still sounds to me as if people are stuck to what they know.\nMaintainers are \"used to using inboxes'', and that's *why* they find\ne-mail reviews to be convenient.\n\nOf course, there's basically nothing wrong with sticking to a flow\nthat works. But I understood the start of this discussion as a sign\nthat you guys acknowledge that something does *not* work. At least not\nwhen it comes to attracting new contributors.\n\n> I'll note that the kernel folks have done this, starting with a 2019\n> Kernel Summit talk at the Linux Plumbers Conference in Lisbon. A\n> description of the follow-up discussions from that talk can be found\n> here:\n\nI'm reading a lot about \"maintainers\" and \"kernel developers\" here.\nBut what I believe is important to accept is that Git is not only\nabout kernel development anymore. While I'm well aware of Git's\nhistory, there are by far more people using Git than there are kernel\ndevelopers, and also by lines of code (or whatever \"stupid\" metric you\nwant to choose) the kernel is not the biggest project maintained in\nGit. Maybe not even the most important one, but that's highly\nsubjective anyway. So asked in a heretic way, why should the opinion\nof a kernel developer count more than the opinion of, say, an Eclipse\nFoundation developer when it comes to Git workflow questions?\n\nTo me, that means if you want to make contributions to Git more\nattractive to the Git community beyond the kernel, you need to stop\nmaking incremental improvements to existing tools and start thinking\nout of the box by looking at the tools that are most popular in that\n\"other side\" of the community.\n\nAnd, please don't take anything I've written as a try to talk you into\nanything. But as the lead of a team who's day job it is to contribute\nto various Open Source projects, I believe to have a good feeling\nabout what the pain points of developers are to start contributing.\nI'm just trying to foster some appreciation for the thinking of the\n\"other side\".\n\n-- \nSebastian Schuberth\n"},{"id":"422379","messageId":"87a6pt4534.fsf@evledraar.gmail.com","threadId":"55492","inReplyTo":"CAHGBnuMedez4SE-4-JwCcR8k=_FRtjgBdBSEJqshQnVceCvGug@mail.gmail.com","subject":"Re: Pain points in Git's patch flow","fromName":"Ævar Arnfjörð Bjarmason","fromEmail":"avarab@gmail.com","sentAt":"2021-04-20T10:34:39Z","receivedAt":"2021-04-20T10:34:46Z","isPatch":false,"sender":{"key":"avarab@gmail.com","avatar":"https://avatars.githubusercontent.com/u/45301?v=4"},"body":"\nOn Mon, Apr 19 2021, Sebastian Schuberth wrote:\n\n> On Mon, Apr 19, 2021 at 10:26 AM Ævar Arnfjörð Bjarmason\n> wrote:\n>\n>> > If you send around code patches by mail instead of directly working on\n>> > Git repos plus some UI, that feels to me like serializing a data class\n>> > instance to JSON, printing the JSON string to paper, taking that sheet\n>> > of paper to another PC with a scanner, using OCR to scan it into a\n>> > JSON string, and then deserialize it again to a new data class\n>> > instance, when you could have just a REST API to push the data from on\n>> > PC to the other.\n>>\n>> That's not inherent with the E-Mail workflow, e.g. Linus on the LKML\n>> also pulls from remotes.\n>\n> Yeah, I was vaguely aware of this. To me, the question is why \"also\"?\n> Why not *only* pull from remotes? What's the feature gap email patches\n> try to close?\n>\n>> It does ensure that e.g. if someone submits patches and then deletes\n>> their GitHub account the patches are still on the ML.\n>\n> Ah, so it's basically just about a backup? That could also be solved\n> differently by forking / syncing Git repos.\n\nI just mentioned that as an example, FWIW I think Linus mainly uses that\nmethod for pulling \"for-linus\" tags from lieutenants, but that those\n\"forks\" in turn are developed over E-Mail (e.g. on the linux-usb list).\n\nSo they're supporting a flow the Git ML doesn't, of e.g. needing\nhundreds of patches from a subsystem maintainer to bring that subsystem\nup-to-date for a release.\n\nAside from that:\n\n 1. Once you have patches sent to the list for review / commenting you\n might as well use them to apply the changes, why also require a\n repository to pull from?\n\n I may just not be understanding what you're suggesting here.\n\n 2. One thing you may have missed is that patches != sending someone a\n repo URL to \"pull\" / run \"log\" etc. on because:\n\n 2.1: You can provide different context (-U -W) and diff algorithm\n for patches, and submitters sometimes do on this list to make\n the job of reviewers easier. I.e. sometimes I'll want to\n manually extend the context to some relevant code related to\n what's being changed.\n\n 2.2: There's also the convention of a free-form (e.g. extra\n commentary, a reply to another E-Mail, whatever) after the\n \"---\" in the patch.\n\n>> To begin with if we'd have used the bugtracker solution from the\n>> beginning we'd probably be talking about moving away from Bugzilla\n>> now. I.e. using those things means your data becomes entangled with the\n>> their opinionated data models.\n>\n> Indeed, it's an art to choose the right tool at the time, and to\n> ensure you're not running into some \"vendor-lock-in\" if data export is\n> made too hard. And aligning on someone's \"opinionated data model\" is\n> not necessarily a bad thing, as standardization can also help\n> interoperability and to smoothen workflows.\n>\n>> > Not necessarily. As many of these tools have (REST) APIs, also\n>> > different API clients exist that you could try.\n>>\n>> API use that usually (always?) requires an account/EULA with some entity\n>> holding the data, and as a practical concern getting all the data is\n>> usually some huge number of API requests.\n>\n> I'm not sure how relevant that concern really is, but in any cause it\n> would be irrelevant for a self-hosted solution.\n\nYes and no, getting kicked off the service due to e.g. being from Iran\nwould probably be a non-issue (as was the case with GitHub until\nrecently).\n\nI've still done various searching/for-looping over the ML archive in a\nway that would if translated to API requests against some remote service\nprobably be considered a DoS, so being distributed helps there.\n\n>> >> And to e.g. as one good example to use (as is the common convention on\n>> >> this list) git-range-diff to display a diff to the \"last rebased\n>> >> revision\" would mean some long feature cycle in those tools, if they're\n>> >> even interested in implementing such a thing at all.\n>> >\n>> > AFAIK Gerrit can already do that.\n>>\n>> Sure, FWIW the point was that you needed Gerrit to implement that, and\n>> to suggest what if they weren't interested. Would you need to maintain a\n>> forked Gerrit?\n>\n> Sorry, I can't follow that. Why would you need to maintain a fork of\n> Gerrit if Gerrit already has the feature you're looking for? Is it a\n> hypothetical question about what to do if Gerrit would not have the\n> feature yet?\n\nMy example of range-diff upthread in\n<87fszn48lh.fsf@evledraar.gmail.com> which started this discussion\nwasn't to make a point about range-diff per-se, but just mention it\noffhand as a \"feature\" that in an E-Mail based flow is simply a matter\nof someone including a thing like that in their cover letter and sending\na patch.\n\nSo for that example the specifics of range-diff being a part of Gerrit\nnow don't matter that much, the point is that the next thing lik\nrange-diff first has to be made part of such a service, it can't easily\nemerge \"bottom-up\".\n\nOf course there's disadvantages to that too, I'm just pointing out that\nthe free-form of text also has advantages that shouldn't be overlooked.\n\n>> Anyway, as before don't take any of the above as arguing, FWIW I\n>> wouldn't mind using one of these websites overall if it helped\n>> development velocity in the project.\n>\n> I appreciate that open mindset of yours here.\n>\n>> I just wanted to help bridge the gap between the distributed E-Mail v.s\n>> centralized website flow.\n>\n> Maybe, instead of jumping into something like an email vs Gerrit\n> discussion, what would help is to get back one step and gather the\n> abstract requirements. Then, with a fresh and unbiased mind, look at\n> all the tools and infrastructure out there that are able to fulfill\n> the needs, and then make a choice.\n\nThe abstract requirement comes down to one thing: Whatever Junio\ndecides.\n\nFor a bit of context on the current discussion:\n\nThere have been versions of this discussion in-person in various \"git\nmerge\" developer meets over the years, Junio doesn't attend most of\nthose (I believe the last one was the one in April 2016 in NYC, but I\nmissed a couple since then, so don't take my word for it).\n\nSo those discussions re-hashing of the various pain points that have\nbeen brought up over the years (and again in this thread), but have had\nto tip-toe around the fact that most things can't make radical forward\nprogress (as is being proposed by some here) unless Junio is on board\nwith them, without the benefit of being able to get feedback from him in\nreal-time.\n\nSo the things that have come out of them are things like submitGit\n(later GitGitGadget), which are very useful, but still something\nimplemented inside the narrow confines of fitting into the confines of\nthe existing E-Mail/ML-based workflow.\n\nMy reading of [1] and [2] (including some \"between the lines\", so I may\nbe wrong) is that Junio's very much interested in using his current\nworkflow as the primary \"source of truth\", and that any (issue) tracking\nsystem will need to be shimmied on top of that.\n\nWhich I think means that any such \"system on top\" is going to have to be\nbespoke and inevitably drift from the real \"source of truth\" which is\nthe mailing list, What's Cooking E-Mails etc.\n\nAs opposed to say, imagining some \"light\" in-between state where we\ndon't use a bugtracker, or have any discussion on some centralized\nwebsite, but would (or rather, Junio would) commit to creating one-line\ntracking issues for what's now the topics in \"next\" and \"seen\"\nbranches. I.e. just the smaller step of answering \"what's the status of\nmy topic\" via a some bug tracker, nevermind using it for anything else.\n\nWhich at least for some contributors like myself means that I'm\nuninterested in using any such system myself, not because I would mind\nusing it in theory, but as long as it's not the \"source of truth\" I\ndon't see the point. I'd still need to scour the ML for anything it may\nhave missed.\n\n1. https://lore.kernel.org/git/xmqqv98orsj5.fsf@gitster.g/\n2. https://lore.kernel.org/git/xmqqfszqko0k.fsf@gitster.g/\n"},{"id":"422451","messageId":"YH8DMB7C0WCn6Rff@mit.edu","threadId":"55492","inReplyTo":"CAHGBnuNrXrHUz9f8nWEdB0PoO0FeLsNpNOGgdiYmsmAD5LjTmg@mail.gmail.com","subject":"Re: Pain points in Git's patch flow","fromName":"Theodore Ts'o","fromEmail":"tytso@mit.edu","sentAt":"2021-04-20T16:37:04Z","receivedAt":"2021-04-20T16:37:17Z","isPatch":false,"sender":{"key":"tytso@mit.edu","avatar":"https://avatars.githubusercontent.com/u/51416?v=4"},"body":"On Tue, Apr 20, 2021 at 08:30:57AM +0200, Sebastian Schuberth wrote:\n> \n> I'm reading a lot about \"maintainers\" and \"kernel developers\" here.\n> But what I believe is important to accept is that Git is not only\n> about kernel development anymore. While I'm well aware of Git's\n> history, there are by far more people using Git than there are kernel\n> developers, and also by lines of code (or whatever \"stupid\" metric you\n> want to choose) the kernel is not the biggest project maintained in\n> Git. Maybe not even the most important one, but that's highly\n> subjective anyway. So asked in a heretic way, why should the opinion\n> of a kernel developer count more than the opinion of, say, an Eclipse\n> Foundation developer when it comes to Git workflow questions?\n\nI think it should be up to each development community to decide what\nworkflows makes sense for that community.\n\nThe kernel community has been taking requirements for what works well\nfor *that* community, and we've found companies who are willing to\nfund improvements in the tools that we use (which include git,\npublic-inbox, patchwork, etc.) so that it can meet our needs.\n\nOur approach is that we don't want to *force* everyone to switch to\nsome web interface. Instead, instead of either-or, we're looking for\nsome kind both/and, so we don't have to insult people who are\n*extremely* productive with an e-mail workflow by calling them\ndinosaurs, and force them to use a web interface which would make them\nmuch less productive, on the hope that maybe we would get some more\nnew contributors. (And at least for the kernel, we're blessed by the\nfact that there is no shortage of new contributors; so our goals are\nto make *everyone* more productive, and not have an attitude of \"you\nshall use gerrit/github and everyone else can go suck wind\".)\n\nGit is going to have to decide what development workflows will work\nwell for its development community. Historically, since git was\noriginally authored by Linus Torvalds, it's not surprising that there\nis a bias towards an e-mail workflow. Indeed, git commands like \"git\nsend-email\" and \"git apply-mbox\" are there from the very beginning\nbecause it was *designed* to work well with the kernel workflow.\n\n> To me, that means if you want to make contributions to Git more\n> attractive to the Git community beyond the kernel, you need to stop\n> making incremental improvements to existing tools and start thinking\n> out of the box by looking at the tools that are most popular in that\n> \"other side\" of the community.\n\nI'm not sure that's what was meant by the question of pain points in\nGit's patch flow. Your perspective is certainly a valid one, and it's\ncertainly easier to choose sides and make an opinioned decision which\ndisenfranches \"one side\" of the community in favor of the \"other side\"\nof the community.\n\nIt's not the approach that was adopted by the folks who are working on\nimproving the Kernel development workflows. The git development\ncommunity will need what approach makes sense for it.\n\nCheers,\n\n\t\t\t\t\t\t- Ted\n"},{"id":"422525","messageId":"87tuo0z1li.fsf@dja-thinkpad.axtens.net","threadId":"55492","inReplyTo":"YHaIBvl6Mf7ztJB3@google.com","subject":"Re: Pain points in Git's patch flow","fromName":"Daniel Axtens","fromEmail":"dja@axtens.net","sentAt":"2021-04-21T04:46:33Z","receivedAt":"2021-04-21T04:46:40Z","isPatch":false,"sender":{"key":"dja@axtens.net","avatar":null},"body":"Hi all,\n\n> I'd like to introduce Raxel (cc-ed), who is starting an internship\n> this June with the Git team at Google.\n>\n> He'll be working on a bit of an experimental project: we want to take\n> Patchwork[1], which in principle can be a helpful addition to a\n> mailing list centric workflow[2], and improve it to be something that\n> people in the Git open source project get day-to-day benefit from.\n> Raxel's previous successes in making changes to tools to support a\n> better user experience make me excited for the potential for this\n> work.\n\nGreetings Raxel! Myself and Stephen F are patchwork maintainers so we'll\nbe reviewing and merging any proposals you have for patchwork. We try to\nbe a welcoming place. We're also both extremely busy so (unfortunately)\nyou will probably need to ping me if I forget to respond.\n\n> Anyway, yesterday[3] Junio, Taylor, and Emily were discussing how to\n> encourage more reviews:\n>\n> this week, i'd be thinking about ways to get topics, that\n> are not reviewed sufficiently, reviewed. I can act as the\n> last-resort fallback reviewer, but that's not sufficient.\n> gitster: I share your concern.\n> gitster: yep, agree, on both counts\n>\n> That reminded me that it would be useful preparation to collect\n> descriptions of pain points we are having with our existing patch\n> flow. For example:\n>\n> - As a reviewer, I want to be able to easily find a series that needs\n> review. Using patchwork, I can see some recent patch series; or\n> using a hierarchical threaded mail reader, I can find a neglected\n> thread or one that seems to be likely to have an interesting\n> discussion going on. But without reading in detail, there is no\n> easy way to see whether the series has reached a review, whether\n> someone else intends to review it, and what the author believes its\n> status to be.\n\nPatchwork does have the A/R/T/F\n(Acked-by:/Reviewed-by:/Tested-by:/Fixes:) column, but this doesn't have\na good way to capture something that falls short of a full\nreview. There's also the patch states (e.g. Changes Requested), but that\nrequires either the author or a maintainer to change the status via the\nweb interface or with an API client.\n\n> - Relatedly, as a patch author or reviewer, I want to be able to\n> easily tell whether a topic has been sufficiently reviewed. Today,\n> the signals for this are implicit: I have to judge consensus, or to\n> check the Git repository for whether the patch has been merged, or\n> to check the maintainer's latest \"What's cooking in git.git\"\n> message.\n>\n> - As a potential reviewer or interested user, I want to be able to\n> follow all relevant discussion for a patch series, while also\n> having the ability to stop following it if the discussion goes on\n> too long and starts overwhelming my email inbox. Today, I can join\n> the discussion and then (1) it is hit-or-miss whether the patch\n> author ccs me on later iterations of the patch and (2) there is no\n> easy way without aggressive email filtering to stop watching it if\n> I am cc-ed.\n>\n> - After having diagnosed an issue to be due to a patch, I want to be\n> able to easily find all relevant review discussion. Today I can\n> use the mailing list archive[4] or patchwork to find review\n> discussion on the latest version of the series that patch was in,\n> but tracing back to previous iterations of that same series can be\n> non-trivial. Moreover, if I'm interested in a particular puzzling\n> line of code, finding which iteration introduced it can take a long\n> time.\n>\n\nYeah, cross-series linking is something we've been interested in for a\nlong time. We have a little bit of the infrastructure already but\nthere's a long way to go.\n\nOne of the real challenges for us has been figuring out how to reliably\nlink iterations. It's one thing if iterations are sent in-reply-to the\nearly version, but at least for the kernel that's not The Way Things Are\nDone. There's lot of common things people do (split series, rename\nseries, add/drop patches) that makes reliable linking very\nchallenging. And traditionally Patchwork has tried to Do It Right rather\nthan go for a probabilistic approach. (We get a lot of email complaints\nif we get things wrong.)\n\n(Having said that, I'd certainly be open to considering any attempts to\nautomatically link series, even if only probabilistic, so long as they\nerr by missing things rather than err by linking things that are\nunrelated.)\n\nOne thing that's come up as another possible option is free-form tags. I\nthink there's some old series on the list from Veronika that attempts\nthis. That'd allow Someone to 'tag' a patch or a series on\npatchwork. For Veronika's use case this was for complex CI - things like\n\"ready-for-real-hw-tests\" that shouldn't happen until someone has cast\nan eye over the patches.\n\nOne big challenge for patchwork development (which catches us out\nregularly) is the odd interaction between patchwork-the-project and\npatchwork-the-deployments. There are 2 large deployments:\npatchwork.ozlabs.org and patchwork.kernel.org, and they all have\nmultiple-GB databases. This means that performance and db load matters,\nbut is really hard to test locally. A good example is writing efficient\nmigrations - historically we have struggled with this.\n\nAnyway, good luck with the dozens of messages and strong opinions!\n\nKind regards,\nDaniel\n\n> Those four are important in my everyday life. Questions:\n>\n> 1. What pain points in the patch flow for git.git are important to\n> you?\n>\n> 2. What tricks do you use to get by with those existing pain points?\n>\n> 3. Do you think patchwork goes in a direction that is likely to help\n> with these?\n>\n> 4. What other tools would you like to see that could help?\n>\n> Thanks,\n> Jonathan\n>\n> [1] http://jk.ozlabs.org/projects/patchwork/; you can see an instance\n> for Git at https://patchwork.kernel.org/project/git/list/\n> [2] https://kernel-recipes.org/en/2016/talks/patches-carved-into-stone-tablets/,\n> https://www.kernel.org/pub/software/scm/git/docs/gitworkflows.html#_patch_workflow\n> [3] https://colabti.org/irclogger/irclogger_log/git-devel?date=2021-04-12#l40\n> [4] https://lore.kernel.org/git/\n> _______________________________________________\n> Patchwork mailing list\n> Patchwork@lists.ozlabs.org\n> https://lists.ozlabs.org/listinfo/patchwork\n"},{"id":"422569","messageId":"87o8e82b4p.fsf@evledraar.gmail.com","threadId":"55492","inReplyTo":"20210419025754.GA26065@dcvr","subject":"Re: Pain points in Git's patch flow","fromName":"Ævar Arnfjörð Bjarmason","fromEmail":"avarab@gmail.com","sentAt":"2021-04-21T10:19:18Z","receivedAt":"2021-04-21T10:19:27Z","isPatch":false,"sender":{"key":"avarab@gmail.com","avatar":"https://avatars.githubusercontent.com/u/45301?v=4"},"body":"\nOn Mon, Apr 19 2021, Eric Wong wrote:\n\n> Son Luong Ngoc wrote:\n>> [...]\n>> 3. Isssue with archive:\n>> \n>> - I don't find the ML archive trivial for new comers. It took me a bit\n>> of time to realize: 'Oh if I scroll to bottom and find the \"Thread \n>> overview\" then I can navigate a mailing thread a lot easier'.\n>\n> (I'm the maintainer of public-inbox, the archival software you\n> seem to be referring to).\n>\n> I'm not sure how to make \"Thread overview\" easier to find\n> without cluttering the display near the top. Maybe I'll try\n> aria labels in the Subject: link...\n\nI'd say the bare-bones style of it is probably jarring to most users\ntoday. I had to check if the site even had any CSS at all.\n\nI.e. I think a more intuitive UI to users today would probably be some\ncollapsible side-bar on the left of the screen, which would have a\nthreaded view. The \"Archives are clonable\" would probably belong in some\n\"help\" tab in such a UI.\n"},{"id":"422911","messageId":"YIYfsMsz0Uz48GaI@camp.crustytoothpaste.net","threadId":"55492","inReplyTo":"YHaIBvl6Mf7ztJB3@google.com","subject":"Re: Pain points in Git's patch flow","fromName":"brian m. carlson","fromEmail":"sandals@crustytoothpaste.net","sentAt":"2021-04-26T02:04:32Z","receivedAt":"2021-04-26T02:04:41Z","isPatch":false,"sender":{"key":"sandals@crustytoothpaste.net","avatar":"https://avatars.githubusercontent.com/u/497054?v=4"},"body":"On 2021-04-14 at 06:13:26, Jonathan Nieder wrote:\n> Those four are important in my everyday life. Questions:\n> \n> 1. What pain points in the patch flow for git.git are important to\n> you?\n\nI realize I'm a bit late here, but I've been thinking about this some\nand wanted to chime in.\n\nI have trouble finding all the spots where people have given me review\nfeedback. I have patch mails and responses to those mails go to a\nparticular folder, but I still often find that I'm not quite sure if\nI've gotten every piece of feedback in a review. Sometimes,\nembarrassingly, I don't, and then I have to send another reroll.\nRegardless, this makes rerolling a series much slower as I have to comb\nmy mail multiple times.\n\nI find I'm often unsure what to put in the cover letter for a v2 or\nsubsequent series. Clearly people don't want the same thing as v1, but\nI rarely have useful information other than a summary of changes.\n\nI have tooling to automatically generate the proper range for\nrange-diffs in cover letters, but that tooling requires some sort of\nmanual timestamp, which means I need to go search for my previous series\nto find the date and generate the range diff, or if I'm in a rush, I\njust have to omit it. This can take some time, having to guess what I\nnamed the cover letter the last time and search for it in a mailbox with\na 6-digit quantity of mails[0].\n\nIn general, I have trouble keeping track of the patch mails I've sent.\nI do definitely need to refer to them later, but I don't generally keep\nthem around on my system since they tend to duplicate my repository, so\nI end up needing to find them in my mailbox, which as mentioned, is\nslow and error prone.\n\nI find that the git-contacts script is often not helpful to find\nreviewers. When I send out a series, it often suggests Peff and Junio.\nWhile both of them are very capable, they are also not capable of\nreviewing every series, and in many cases I know full well that one or\nthe other is not going to be able to give me a good review (for lack of\nfamiliarity with the SHA-256 work, due to having many other things to\nreview and to do in life, or for other reasons). It also,\nunfortunately, suggests me as a reviewer for many things, which while\nflattering, reflects the fact that I've touched a lot of code and not\nthat I have a deep understanding of most of the codebase, which I do\nnot. For areas where I do have relevant insight, such as the signature\ncode, I'm often not chosen.\n\nI realize a lot of these are not intrinsic to our workflow and can be\nsolved with tooling, but because I haven't built that tooling, they're\npain points that I experience in our workflow.\n\n> 2. What tricks do you use to get by with those existing pain points?\n\nI've built some tooling around this, including mail filtering, aliases,\nand scripting, but it doesn't seem like enough. I know others have\nbuilt really great tooling for themselves, but by the time I notice\nthese pain points, it's usually the evening and I don't have time\nto build tooling and get things sent out as well. I also don't\nespecially enjoy building tooling here.\n\nThe friction here makes me less likely to send out patches and much\nslower to reroll patches than I'd otherwise be. And I feel like that\nmeans that I practically can only ever send out a series when I have\nmore time on the weekend, and as a result, I worry that my patches hold\nup others in the tree much more often than I'd like. It also makes\ncontributing to Git less fun, which is important since overwhelmingly my\npatches are sent on my own time.\n\n> 3. Do you think patchwork goes in a direction that is likely to help\n> with these?\n\nI don't think I know enough about it to say. If it can more clearly\ntrack review feedback and help keep track of patch emails, I think it\nwould be a major improvement, for me at least.\n\n> 4. What other tools would you like to see that could help?\n\nI think we definitely need a bug tracker. We extremely frequently lose\nbugs and feature requests on the list and people aren't very likely to\nsearch the list. If we could use the same one as someone else, such as\nthe kernel, that would be ideal, because it means people are more likely\nto already have an account and therefore the friction to report a bug is\nlower. Alternatively, we could use something like debbugs which is\ncontrollable entirely by email and therefore requires no accounts (but\ndoes require someone to occasionally prune reported spam).\n\nI know full well why we don't use a forge-based model and I'm not\nrecommending that, but I do want to point out that forges solve all of\nmy pain points, and I do have a much quicker turnaround time on patches\nwhen I'm using a forge. So ideally we'd have some standard or\nrecommended tooling, whether built by us or by others (e.g., an open\nsource project for patch workflows), that addresses these pain points so\nthat everyone doesn't have to build their own and turnaround time can be\nimproved.\n\nI have seen replies downthread that some developers really are reticent\nto use more common tooling, like web interfaces. While I do want to\nkeep our project as accessible as possible to as many people as\npossible, I worry that by catering to folks who don't want to adopt this\ntooling, we are drastically reducing the number of possible contributors\nof all sorts (code authors, documentation writers, bug reporters) by\nnot doing so and worsening our own experience in many ways. I do think\nwe should adopt modern tooling (e.g., web interfaces) provided that it\nis usable for people with accessibility needs, even if that makes some\npeople unhappy.\n\n[0] I don't, as a general rule, delete emails to this list or otherwise.\n-- \nbrian m. carlson (he/him or they/them)\nHouston, Texas, US\n"},{"id":"422926","messageId":"YIbNE0Fw2VaZt9ry@mit.edu","threadId":"55492","inReplyTo":"YIYfsMsz0Uz48GaI@camp.crustytoothpaste.net","subject":"Re: Pain points in Git's patch flow","fromName":"Theodore Ts'o","fromEmail":"tytso@mit.edu","sentAt":"2021-04-26T14:24:19Z","receivedAt":"2021-04-26T14:24:47Z","isPatch":false,"sender":{"key":"tytso@mit.edu","avatar":"https://avatars.githubusercontent.com/u/51416?v=4"},"body":"On Mon, Apr 26, 2021 at 02:04:32AM +0000, brian m. carlson wrote:\n> In general, I have trouble keeping track of the patch mails I've sent.\n> I do definitely need to refer to them later, but I don't generally keep\n> them around on my system since they tend to duplicate my repository, so\n> I end up needing to find them in my mailbox, which as mentioned, is\n> slow and error prone.\n\nA quick and easy feature request to this (which I have had as well)\nwould be implementing a sendmail.fcc config, which if set, would\nappend any mail messages sent by git send-email to the Unix\nmbox file specified by sendmail.fcc.\n\nOnce you have the message id of any patch mail that you've sent...\n\n> I have trouble finding all the spots where people have given me review\n> feedback. I have patch mails and responses to those mails go to a\n> particular folder, but I still often find that I'm not quite sure if\n> I've gotten every piece of feedback in a review. Sometimes,\n> embarrassingly, I don't, and then I have to send another reroll.\n> Regardless, this makes rerolling a series much slower as I have to comb\n> my mail multiple times.\n\nThis becomes pretty easy to solve using existing tooling. For people\nwho like web interfaces:\n\n https://lore.kernel.org/r/\n\n(This works today because git@vger.kernel.org is archived by the\nlore.kernel.org public-inbox archive.)\n\nOr for those who like CLI's and/or text-based mail readers such as\nmutt or pine:\n\n b4 mbox -o /tmp \n\nThis will dump the full mail thread (given any any message-id in that\nmail thread) to /tmp/.mbx in Unix mbox format, again\nrelying on lore.kernel.org. I've found this to be especially handy if\nI've been cc'ed part-way through a mail thread, or if I was only cc'ed\non a single patch and I want to see the full patch series for context.\n\nCheers,\n\n\t\t\t\t\t\t- Ted\n"},{"id":"422930","messageId":"87fszd3xo0.fsf@evledraar.gmail.com","threadId":"55492","inReplyTo":"YIYfsMsz0Uz48GaI@camp.crustytoothpaste.net","subject":"Re: Pain points in Git's patch flow","fromName":"Ævar Arnfjörð Bjarmason","fromEmail":"avarab@gmail.com","sentAt":"2021-04-26T14:36:19Z","receivedAt":"2021-04-26T14:53:09Z","isPatch":false,"sender":{"key":"avarab@gmail.com","avatar":"https://avatars.githubusercontent.com/u/45301?v=4"},"body":"\nOn Mon, Apr 26 2021, brian m. carlson wrote:\n\n> [[PGP Signed Part:Undecided]]\n> On 2021-04-14 at 06:13:26, Jonathan Nieder wrote:\n>> [...]\n>> 4. What other tools would you like to see that could help?\n>\n> I think we definitely need a bug tracker. We extremely frequently lose\n> bugs and feature requests on the list and people aren't very likely to\n> search the list. If we could use the same one as someone else, such as\n> the kernel, that would be ideal, because it means people are more likely\n> to already have an account and therefore the friction to report a bug is\n> lower. Alternatively, we could use something like debbugs which is\n> controllable entirely by email and therefore requires no accounts (but\n> does require someone to occasionally prune reported spam).\n>\n> I know full well why we don't use a forge-based model and I'm not\n> recommending that, but I do want to point out that forges solve all of\n> my pain points, and I do have a much quicker turnaround time on patches\n> when I'm using a forge. So ideally we'd have some standard or\n> recommended tooling, whether built by us or by others (e.g., an open\n> source project for patch workflows), that addresses these pain points so\n> that everyone doesn't have to build their own and turnaround time can be\n> improved.\n>\n> I have seen replies downthread that some developers really are reticent\n> to use more common tooling, like web interfaces. While I do want to\n> keep our project as accessible as possible to as many people as\n> possible, I worry that by catering to folks who don't want to adopt this\n> tooling, we are drastically reducing the number of possible contributors\n> of all sorts (code authors, documentation writers, bug reporters) by\n> not doing so and worsening our own experience in many ways. I do think\n> we should adopt modern tooling (e.g., web interfaces) provided that it\n> is usable for people with accessibility needs, even if that makes some\n> people unhappy.\n\nI'm not disagreeing, just replying to point out that I think for your\nsuggestion & others having as much of a split as possible between \"what\"\nand \"how\" would, I think, be useful in moving things along.\n\nA web interface is a \"how\", but it's also implicitly a \"what\" in the way\nthat most people think about it in this context.\n\nI.e. it's not like we couldn't have a bug tracker now using the ML,\nyou'd send a patch, Junio would pick up the report and we'd drop it into\nbug/some-description.md (with some handwaiving for formatting, merge\nconflicts etc.). We'd remember bug reports, feature requests\netc. forever, and patches could atomically change/close/remove those as\nthey fix/change/implement them.\n\nThe point I'm getting at is that the \"what\" we're also implicitly\ndiscussing is the developer community shouldering the burden of keeping\nsuch a tracker and the information within it up-to-date.\n\nA web-based interface that worked like our mailing list does now would\nbe one that, say, deleted your bug 30 days of inactivity (or otherwise\nmade it as \"archived\" as something in the ML lore).\n\nI couldn't find a reference to it now, but as I recall (and maybe I\nwrote some) there's been some prominent defenses of this model of\ndevelopment in the past.\n\nI.e. it puts the onus on reporters to make sure their issue is being\naddressed, if nobody cares to pick it up it probably wasn't that\nimportant, and we shouldn't so lightly assume the fixed cost of adding\nthat one-off report to an ever-growing list of reports we'd need to\ncontinually look at / curate / keep up to date etc.\n\nBut none of that's an argument I'm looking to get into right now, or\nreally have much of a firm stance on. I just wanted to point out that\nit's a clear case where a \"what\" is being conflated with a \"how\".\n\nI.e. we're implicitly not only talking about how something gets done,\nbut a big change in what gets done.\n\nI had a similar comment upthread (or in a side-thread) about how much of\nthe suggestions of making use of the various reviewer/approver\nPR/MR/whatever tools in the wild seem to simply assume a move away from\nthe long-time model where there's effectively only one approver/merge\nmaster/committer (i.e. Junio). That's an entirely defensible argument,\nbut another case of making a \"how\" and \"what\" argument at the same time.\n\nMaybe the people proposing both a \"how\" and a \"what\" will have an easier\ntime if those are untangled, and we change one thing at a time.\n"},{"id":"423178","messageId":"20210428070519.GA13114@dcvr","threadId":"55492","inReplyTo":"20210419025754.GA26065@dcvr","subject":"Re: Pain points in Git's patch flow","fromName":"Eric Wong","fromEmail":"e@80x24.org","sentAt":"2021-04-28T07:05:19Z","receivedAt":"2021-04-28T07:05:21Z","isPatch":false,"sender":{"key":"e@80x24.org","avatar":null},"body":"Eric Wong wrote:\n> Son Luong Ngoc wrote:\n> > 3. Isssue with archive:\n> > \n> > - I don't find the ML archive trivial for new comers. It took me a bit\n> > of time to realize: 'Oh if I scroll to bottom and find the \"Thread \n> > overview\" then I can navigate a mailing thread a lot easier'.\n> \n> (I'm the maintainer of public-inbox, the archival software you\n> seem to be referring to).\n> \n> I'm not sure how to make \"Thread overview\" easier to find\n> without cluttering the display near the top. Maybe I'll try\n> aria labels in the Subject: link...\n\nI think I made [thread overview] easier-to-find without adding\nmore clutter:\n\n\thttps://public-inbox.org/meta/20210428065522.12795-1-e@80x24.org/\n\nNot sure about title attribute or aria labels (my version of w3m\ndoesn't support that, yet). Anyways, an an example of it\ndeployed:\n\n\thttps://public-inbox.org/git/20210419025754.GA26065@dcvr/\n"},{"id":"423180","messageId":"20210428072138.GB13114@dcvr","threadId":"55492","inReplyTo":"87o8e82b4p.fsf@evledraar.gmail.com","subject":"Re: Pain points in Git's patch flow","fromName":"Eric Wong","fromEmail":"e@80x24.org","sentAt":"2021-04-28T07:21:38Z","receivedAt":"2021-04-28T07:21:39Z","isPatch":false,"sender":{"key":"e@80x24.org","avatar":null},"body":"Ævar Arnfjörð Bjarmason wrote:\n> On Mon, Apr 19 2021, Eric Wong wrote:\n> > Son Luong Ngoc wrote:\n> >> [...]\n> >> 3. Isssue with archive:\n> >> \n> >> - I don't find the ML archive trivial for new comers. It took me a bit\n> >> of time to realize: 'Oh if I scroll to bottom and find the \"Thread \n> >> overview\" then I can navigate a mailing thread a lot easier'.\n> >\n> > (I'm the maintainer of public-inbox, the archival software you\n> > seem to be referring to).\n> >\n> > I'm not sure how to make \"Thread overview\" easier to find\n> > without cluttering the display near the top. Maybe I'll try\n> > aria labels in the Subject: link...\n> \n> I'd say the bare-bones style of it is probably jarring to most users\n> today. I had to check if the site even had any CSS at all.\n> \n> I.e. I think a more intuitive UI to users today would probably be some\n> collapsible side-bar on the left of the screen, which would have a\n> threaded view. The \"Archives are clonable\" would probably belong in some\n> \"help\" tab in such a UI.\n\nThe plan is to support read-only JMAP, so it's a stable API that\nusers can build their own displays on top of (of course, NNTP\nand IMAP support already exists).\n\nI can't make drastic UI changes such as a sidebar without\nbreaking things for users who like the current UI. I only know\nabout GNOME3 and Digg because they made drastic UI changes that\nangered their existing userbase.\n\nThe current UI is designed to for a terminal with w3m|lynx since\nit's the lowest common denominator. Graphics drivers/stacks\nseem to be most frequently broken thing on GNU/Linux systems, so\nit's important users can find patches/configs/help easily with a\ntext-only browser in order to get graphics working.\n"},{"id":"423184","messageId":"20210428075927.GC13114@dcvr","threadId":"55492","inReplyTo":"YIYfsMsz0Uz48GaI@camp.crustytoothpaste.net","subject":"Re: Pain points in Git's patch flow","fromName":"Eric Wong","fromEmail":"e@80x24.org","sentAt":"2021-04-28T07:59:27Z","receivedAt":"2021-04-28T07:59:30Z","isPatch":false,"sender":{"key":"e@80x24.org","avatar":null},"body":"\"brian m. carlson\" wrote:\n> I have tooling to automatically generate the proper range for\n> range-diffs in cover letters, but that tooling requires some sort of\n> manual timestamp, which means I need to go search for my previous series\n> to find the date and generate the range diff, or if I'm in a rush, I\n> just have to omit it. This can take some time, having to guess what I\n> named the cover letter the last time and search for it in a mailbox with\n> a 6-digit quantity of mails[0].\n> \n> In general, I have trouble keeping track of the patch mails I've sent.\n> I do definitely need to refer to them later, but I don't generally keep\n> them around on my system since they tend to duplicate my repository, so\n> I end up needing to find them in my mailbox, which as mentioned, is\n> slow and error prone.\n\nAlong the lines of what Ted said about Fcc, I've always Bcc-ed\nmyself on every message I send to verify deliverability and\ncheck/train my spam filter.\n\nWhat search tool do you use? mairix can handle the 6-digit\nquantity of the git list fairly well. The following finds all\nthreads with \"sandals\" in From/To/Cc:\n\n\tmairix -t a:sandals d:YYYYMMDD-YYYYMMDD\n\nand dumps it to whatever Maildir/mbox/IMAP \"mfolder\" you've\nconfigured. (prefixes in public-inbox such as \"a:\", \"d:\" and\n\"s:\" are stolen from mairix; though mairix ranges use \"-\" and\npublic-inbox uses \"..\" due to Xapian).\n\n\nI've also heard good things about notmuch, but I archive old\nmail to gzipped mboxrd right now[1], and that only supports\nMaildir... I learned to use Xapian by reading code in notmuch.\n\n\n\n[1] Fwiw, I'm also working on an AGPL Perl5 storage+search CLI\n that scales to 7/8-digit mail collections. It's not ready\n for prime-time, yet, but getting there... (Assuming it\n doesn't set my SSD on fire, first :x)\n"},{"id":"423218","messageId":"YInlZStiucEn4Km9@camp.crustytoothpaste.net","threadId":"55492","inReplyTo":"20210428075927.GC13114@dcvr","subject":"Re: Pain points in Git's patch flow","fromName":"brian m. carlson","fromEmail":"sandals@crustytoothpaste.net","sentAt":"2021-04-28T22:44:53Z","receivedAt":"2021-04-28T22:45:32Z","isPatch":false,"sender":{"key":"sandals@crustytoothpaste.net","avatar":"https://avatars.githubusercontent.com/u/497054?v=4"},"body":"On 2021-04-28 at 07:59:27, Eric Wong wrote:\n> \"brian m. carlson\" wrote:\n> > I have tooling to automatically generate the proper range for\n> > range-diffs in cover letters, but that tooling requires some sort of\n> > manual timestamp, which means I need to go search for my previous series\n> > to find the date and generate the range diff, or if I'm in a rush, I\n> > just have to omit it. This can take some time, having to guess what I\n> > named the cover letter the last time and search for it in a mailbox with\n> > a 6-digit quantity of mails[0].\n> > \n> > In general, I have trouble keeping track of the patch mails I've sent.\n> > I do definitely need to refer to them later, but I don't generally keep\n> > them around on my system since they tend to duplicate my repository, so\n> > I end up needing to find them in my mailbox, which as mentioned, is\n> > slow and error prone.\n> \n> Along the lines of what Ted said about Fcc, I've always Bcc-ed\n> myself on every message I send to verify deliverability and\n> check/train my spam filter.\n> \n> What search tool do you use? mairix can handle the 6-digit\n> quantity of the git list fairly well. The following finds all\n> threads with \"sandals\" in From/To/Cc:\n> \n> \tmairix -t a:sandals d:YYYYMMDD-YYYYMMDD\n\nI simply use mutt to read my mailbox and search. Nothing fancy. I\nshould point out that it's not local; it's on a Dovecot IMAP server\nlocated on a VPS in New York City.\n-- \nbrian m. carlson (he/him or they/them)\nHouston, Texas, US\n"},{"id":"423371","messageId":"608c65b36c122_2cb2087f@natae.notmuch","threadId":"55492","inReplyTo":"20210428075927.GC13114@dcvr","subject":"Re: Pain points in Git's patch flow","fromName":"Felipe Contreras","fromEmail":"felipe.contreras@gmail.com","sentAt":"2021-04-30T20:16:51Z","receivedAt":"2021-04-30T20:16:57Z","isPatch":false,"sender":{"key":"felipe.contreras@gmail.com","avatar":"https://avatars.githubusercontent.com/u/8358?v=4"},"body":"Eric Wong wrote:\n> I've also heard good things about notmuch, but I archive old\n> mail to gzipped mboxrd right now[1], and that only supports\n> Maildir... I learned to use Xapian by reading code in notmuch.\n\nFor what it's worth I've been using notmuch for several years now and\nit's much superior to anything I've seen. I can find all kinds of emails\ninstantly and using my prefered text-editor (vim).\n\nBut yeah, the only problem is getting the mail in the right format in my\nmachine in the first place. But once I have it, it's blazingly fast to\ndeal with email.\n\n-- \nFelipe Contreras\n"},{"id":"423372","messageId":"608c6a2cca7dc_2cb2088@natae.notmuch","threadId":"55492","inReplyTo":"YIYfsMsz0Uz48GaI@camp.crustytoothpaste.net","subject":"Re: Pain points in Git's patch flow","fromName":"Felipe Contreras","fromEmail":"felipe.contreras@gmail.com","sentAt":"2021-04-30T20:35:56Z","receivedAt":"2021-04-30T20:36:03Z","isPatch":false,"sender":{"key":"felipe.contreras@gmail.com","avatar":"https://avatars.githubusercontent.com/u/8358?v=4"},"body":"brian m. carlson wrote:\n> I find I'm often unsure what to put in the cover letter for a v2 or\n> subsequent series. Clearly people don't want the same thing as v1, but\n> I rarely have useful information other than a summary of changes.\n> \n> I have tooling to automatically generate the proper range for\n> range-diffs in cover letters, but that tooling requires some sort of\n> manual timestamp, which means I need to go search for my previous series\n> to find the date and generate the range diff, or if I'm in a rush, I\n> just have to omit it. This can take some time, having to guess what I\n> named the cover letter the last time and search for it in a mailbox with\n> a 6-digit quantity of mails[0].\n\nI wrote a tool to deal precisely with that: git-send-series[1]. All the\nmetadata in the patch series is stored in a text file (version, subject, cc,\ncover letter, etc.).\n\nSo when you want to send the next version of your series you just do\n`git send-series` and it deals with all that tedious stuff\nautomatically. You just need to update the cover letter.\n\nIt also keeps track of the previous versions of your series in order to\nautomatically generate the range-diff.\n\n> In general, I have trouble keeping track of the patch mails I've sent.\n> I do definitely need to refer to them later, but I don't generally keep\n> them around on my system since they tend to duplicate my repository, so\n> I end up needing to find them in my mailbox, which as mentioned, is\n> slow and error prone.\n\nI have my mailbox stored in my machine syncronized with isync[2], and\nindexed with notmuch[3]. I can view all mails I've ever sent instantly\nwith a simple search:\n\n nmm tag:git tag:sent subject:PATCH\n\n> I find that the git-contacts script is often not helpful to find\n> reviewers.\n\ngit-contacts is a subpar rewrite of my original script: git-related[4].\n\nUsing git-contacts on your last merged patch I get this:\n\n Cornelius Weig \n Jeff King \n Junio C Hamano \n Johannes Schindelin \n\nHowever, with git-related I get this:\n\n Junio C Hamano (signer: 62%, author: 37%)\n Johannes Schindelin (author: 37%)\n Jeff King (reviewer: 12%, author: 12%)\n Cornelius Weig (author: 12%)\n\nWhich is much more useful.\n\nHowever, you actually have options to catch more changes:\n\n % git related --min-percent=5 --since=10-years-ago 75555676ad -1\n Junio C Hamano (signer: 80%, author: 20%)\n Jeff King (reviewer: 10%, author: 30%)\n Johannes Schindelin (author: 30%)\n Patrick Steinhardt (author: 10%)\n Cornelius Weig (author: 10%)\n\nThis may not solve your paticular complaint, but it's clearly superior.\n\nCheers.\n\n[1] https://github.com/felipec/git-send-series\n[2] https://isync.sourceforge.io/\n[3] https://notmuchmail.org/\n[4] https://github.com/felipec/git-related\n\n-- \nFelipe Contreras\n"},{"id":"423373","messageId":"608c6c64746b2_2cb208ee@natae.notmuch","threadId":"55492","inReplyTo":"CAHGBnuNrXrHUz9f8nWEdB0PoO0FeLsNpNOGgdiYmsmAD5LjTmg@mail.gmail.com","subject":"Re: Pain points in Git's patch flow","fromName":"Felipe Contreras","fromEmail":"felipe.contreras@gmail.com","sentAt":"2021-04-30T20:45:24Z","receivedAt":"2021-04-30T20:45:30Z","isPatch":false,"sender":{"key":"felipe.contreras@gmail.com","avatar":"https://avatars.githubusercontent.com/u/8358?v=4"},"body":"Sebastian Schuberth wrote:\n> On Tue, Apr 20, 2021 at 12:34 AM Theodore Ts'o wrote:\n> \n> > The primary reason why the kernel uses mailing lists is because code\n> > reviews are fundamentally *discussions*, and people are used to using\n> > inboxes. Sure, you can have a gerrit server send e-mail notifications\n> \n> [...]\n> \n> > maintainers simply find e-mail reviews to simply be more *convenient*\n> > than using gerrit. And over time, we've used other tools to track\n> \n> That still sounds to me as if people are stuck to what they know.\n> Maintainers are \"used to using inboxes'', and that's *why* they find\n> e-mail reviews to be convenient.\n\nI'm not stuck with what I know.\n\nThe reason why I use the email workflow is not because \"I'm stuck\" with\nit, it's because I've tried every approach out there, and they are *all*\ninferior.\n\nYou tell me of an approach and I will tell you all the ways in which\nit's inferior to email.\n\nIf some people want to use Gerrit, and/or Patchwork on top of email,\nthat's fine. You can use inferior approaches if you want, just don't\nforce the rest of us to stop using the superior approach.\n\nCheers.\n\n-- \nFelipe Contreras\n"},{"id":"423375","messageId":"608c6f662db37_2cb20829@natae.notmuch","threadId":"55492","inReplyTo":"CAHGBnuOVmzzhgW6GanHBXNb22UW3P1m3i6PJnOUEhYPO76hH4g@mail.gmail.com","subject":"Re: Pain points in Git's patch flow","fromName":"Felipe Contreras","fromEmail":"felipe.contreras@gmail.com","sentAt":"2021-04-30T20:58:14Z","receivedAt":"2021-04-30T20:58:28Z","isPatch":false,"sender":{"key":"felipe.contreras@gmail.com","avatar":"https://avatars.githubusercontent.com/u/8358?v=4"},"body":"Sebastian Schuberth wrote:\n> On Sun, Apr 18, 2021 at 10:54 PM Ævar Arnfjörð Bjarmason\n> wrote:\n> \n> > And thank you for participating in the discussion. I think it's\n> > especially valuable to get a viewpoint like yours, i.e. someone who (per\n> > this E-Mail below) gave up in frustration with the current development\n> > flow.\n> \n> To be fair, Git's contribution flow isn't the only reason why I chose\n> to stop contributing. Another reason is the very lengthy and tedious\n> discussions that too often spark from rather small changes.\n\nI completely agree with this assessment.\n\nIn the spectrum from all code is allowed (0) to only perfect code is allowed\n(100) I'd say the git project is around 95. It's good in the sense that\nuser expectation rarely breaks, but on the other hand not much progress\nhappens.\n\nPersonally I would turn the dial of perfectedness down to 90, or even\n80.\n\nIt's because of this focus on perfection that discussions get tedious,\nand thus perfect becomes the enemy of good.\n\nBut since the current maintership is never going to change that focus, I\nthink a fork of git is necessary.\n\nCheers.\n\n-- \nFelipe Contreras"},{"id":"423376","messageId":"608c722135d6f_2cb20846@natae.notmuch","threadId":"55492","inReplyTo":"YHaIBvl6Mf7ztJB3@google.com","subject":"RE: Pain points in Git's patch flow","fromName":"Felipe Contreras","fromEmail":"felipe.contreras@gmail.com","sentAt":"2021-04-30T21:09:53Z","receivedAt":"2021-04-30T21:09:57Z","isPatch":false,"sender":{"key":"felipe.contreras@gmail.com","avatar":"https://avatars.githubusercontent.com/u/8358?v=4"},"body":"Jonathan Nieder wrote:\n> He'll be working on a bit of an experimental project: we want to take\n> Patchwork[1], which in principle can be a helpful addition to a\n> mailing list centric workflow[2], and improve it to be something that\n> people in the Git open source project get day-to-day benefit from.\n> Raxel's previous successes in making changes to tools to support a\n> better user experience make me excited for the potential for this\n> work.\n\nRaxel, I would consider looking at nmbug[1]. It is a tool developed by\nthe notmuch team in order to deal with patches both in command line and\nweb interfaces.\n\nAs you can see from the discussion that ensured from the original mail,\nthe git community does care about the command line interface a great\ndeal.\n\n> Those four are important in my everyday life. Questions:\n> \n> 1. What pain points in the patch flow for git.git are important to\n> you?\n\nMy only real pain point is that sometimes a patch series is sent as a\nsubthread of another patch series, which makes it difficult for me to\nmentally separate the two.\n\n> 2. What tricks do you use to get by with those existing pain points?\n\nThere is nothing I can do. This is a culture thing that hopefully will\nchange.\n\n> 3. Do you think patchwork goes in a direction that is likely to help\n> with these?\n\nNo.\n\n> 4. What other tools would you like to see that could help?\n\nnmbug[1], but again, it depends on how it's actually used.\n\nCheers.\n\n[1] https://notmuchmail.org/nmbug/\n\n-- \nFelipe Contreras\n"},{"id":"423433","messageId":"CAOLTT8Sr8hMe7jOaBNb10szbw219HP+FB439jgZu-xua7K9Xug@mail.gmail.com","threadId":"55492","inReplyTo":"xmqqfszqko0k.fsf@gitster.g","subject":"Re: Pain points in Git's patch flow","fromName":"ZheNing Hu","fromEmail":"adlternative@gmail.com","sentAt":"2021-05-02T05:35:56Z","receivedAt":"2021-05-02T05:36:11Z","isPatch":false,"sender":{"key":"adlternative@gmail.com","avatar":"https://avatars.githubusercontent.com/u/58138461?v=4"},"body":"Haaaa, everyone, I am this example :)\nSorry I haven't checked these mails cc to me for a long time.\n\nJunio C Hamano 于2021年4月17日周六 上午3:50写道：\n>\n> Jonathan Nieder writes:\n>\n> > 3. Do you think patchwork goes in a direction that is likely to help\n> > with these?\n>\n> So here is a real-life example.\n>\n> Let's say somebody is looking at a \"gentle ping\" [*1*]\n>\n> znh> The patch seems to have fallen into the crack.\n> zhn> Jeff and Junio, willing to help?\n>\n> How would we figure out what happened to the patch today without\n> visiting patchwork would be:\n>\n> 1. Visit the message at lore.kernel.org/git/ [*1*]\n>\n> 2. Notice that it is a response to a message, and click the link to\n> be taken to [*2*]\n>\n> 3. Notice that nobody commented on the patch.\n>\n> 4. Type \"f:zhening ref-filter\" to the search box and search, with\n> suspicion that this was an updated version of something.\n>\n> 5. Click one of them in the result [*3*]\n>\n> 6. This time, we can tell that this seemed to have had two earlier\n> iterations, and after reading the discussion through, the last\n> one changed the course in a major way. Not just a new helper\n> introduced in the earlier rounds has gone away, but an existing\n> helper got removed.\n>\n> 7. All comments in the discussion for the earlier two rounds can be\n> read as supporting the new direction the latest round takes.\n>\n> 8. The fact remains that even if the direction has been endorsed\n> (see 7. above) nobody took a look at the implementation for the\n> latest round.\n>\n> 9. Make the final verdict.\n>\n> I use my newsreader to do pretty much the equivalent of the above\n> without hitting https://lore.kernel.org/git/ but the above is\n> written to use the web interface, in order to make it reproducible\n> more easily by anybody on the list.\n>\n> Now, how can patchwork improve the above reviewer experience, out\n> of the box and possibly with new helpe rools around it?\n>\n> I can see #3 would immediately become obvious, and I hope #4-#5\n> would become unnecessary.\n>\n\nHere are my thoughts:\n\nFor the reviewers like Junio, after missing a new patch iteration, need to\nreview the past history to find the correct patch and related comments\nfrom other reviewers. Just like I once read a github blog saying that\n\"patch\" is also a special object in git. I would like to have a \"new\" tool\n which can link multiple related patches and comments.\n\n1. Coder need Reviewers' help.\n2. This new tool will obtained multiple different patches contents automatically\nor coder provided those pathes versions links.\n3. This tool will analyze the differences between multiple patches\nversions, get all\nthe reviewers comments and coder comments related to the \"patch stream\",\norganize it into \"patch graph\".\n4. The tool will notify the reviewer(by email or something else) and\nshow the links\nand patch graph or patch range-diff. It can visualize the entire patch process,\n It’s best that comments from different people can be displayed on one page.\n\nIn order to be more accurate, I made a picture [*1*].\n\nUsing this new tool, reviewers can choose to see or not see the range-diff\nand diff in multiple different patch versions, Instead of the range-diff\nautomatically sent by GGG. When my second patch processing was greatly\nchanged from the previous one, I have to rebuild a new branch and create a new\nPR, this is my pain point.\n\nThanks!\n--\nZheNing Hu\n\n> Anything else?\n>\n> At steps #6 and #7, there is human judgment involved that may not be\n> automatable, but would there be some mechanism to make it easy to\n> help these steps if the user visits patchwork (instead of staying\n> in my newsreader or web interface to the lore archive)?\n>\n> I am of course not expecting to automate step #9 ;-) It would be\n> nice though.\n>\n> Thanks.\n>\n>\n> [References]\n>\n> *1* https://lore.kernel.org/git/CAOLTT8Tis5Yjg8UR0c-i0BnqiFQvLXvDgxUQJ-WcP6jjQPu9cQ@mail.gmail.com/\n>\n> *2* https://lore.kernel.org/git/pull.928.git.1617975348494.gitgitgadget@gmail.com/\n>\n> *3* https://lore.kernel.org/git/pull.927.v2.git.1617809209164.gitgitgadget@gmail.com/\n\n*1* https://github.com/adlternative/git/blob/pic/git-patch-pain-point-solve-idea.png\n"},{"id":"423905","messageId":"20210508020855.GF3986@localhost","threadId":"55492","inReplyTo":"20210419214921.afurkxy7oru6bny6@nitro.local","subject":"Re: Pain points in Git's patch flow","fromName":"","fromEmail":"dwh@linuxprogrammer.org","sentAt":"2021-05-08T02:08:55Z","receivedAt":"2021-05-08T02:09:00Z","isPatch":false,"sender":{"key":"dwh@linuxprogrammer.org","avatar":null},"body":"On 19.04.2021 17:49, Konstantin Ryabitsev wrote:\n>On Mon, Apr 19, 2021 at 07:54:37AM +0200, Sebastian Schuberth wrote:\n>> > of these proposed alternatives involve moving away from something that's\n>> > a distributed system today (E-Mail infrastructure, local clients), to\n>> > what's essentially some website run by a centralized entity, in some\n>> > cases proprietary.\n>>\n>> That's a good point, I admit I haven't thought of that. Probably\n>> because I also don't care much. So *does* it really matter? What\n>> exactly concerns you about a \"centralized entity\"? Is it the technical\n>> aspect of a single point of failure, or the political / social aspect\n>> of being dependent on someone you do not want to get influenced by? I\n>> guess it's a bit of both.\n>\n>Patches sent via email remain immune to this. Even if vger falls over, it's\n>merely a list service -- there are alternative ways of transmitting RFC2822\n>messages that don't involve a central host (such as via a NNTP gateway,\n>publishing a public-inbox \"feed\", etc). Email remains one of the few protocols\n>that are designed ground-up to be decentralized and I'm afraid that we are\n>again finding ourselves in a world where this is increasingly relevant.\n\nI agree with Konstantin on this one. To this day, email is still the\nmost decentralized and \"user sovereign\" system on the internet. The\nstandardization of protocols and file formats is not perfect but it is\n\"complete\" in the sense that it meets all of the requirements for\ndecentralized software development.\n\nThink about it like this. Right now, I could use an IMAP client to\ndownload all of my emails from GMail, store them in mbox files, then\nuse the IMAP client to upload the email to Fastmail or SDF.org or some\nother email provider. Or better yet, I can install local tools for\nworking with my email. The fact that email providers/tools are largely\ninterchangeable and replacable--despite Google/Yahoo/Microsoft's best\nefforts--gives maximum power to users.\n\nLike I said, I totally agree with Konstantin and I think the vision he\ndescribed in his post on developer sigchains is what I've always wanted\nas an open source developer. It is common to hear the argument that\ncentralized systems are more convient and easier to use and the more\ndecentralized a sysetem, the harder it gets to use. I suspect that is\nonly a half-truth because I don't think we've achieved full\ndecentralization which is what Konstantin touches on in his post too.\nFull decentralization will bring automatic maintainence of p2p\nconnections and synchronization. Things will \"just work\".\n\nI know I'm veering off topic a bit here but decentralization has been\nthe focus of all of my learning, research and work for more than a\ndecade now. Email is critical for maintaining decentralized development\ncapabilities.\n\nCheers!\nDave\n"},{"id":"423906","messageId":"20210508021011.GG3986@localhost","threadId":"55492","inReplyTo":"20210419220013.mguw4l5644r2c7gj@nitro.local","subject":"Re: Pain points in Git's patch flow","fromName":"","fromEmail":"dwh@linuxprogrammer.org","sentAt":"2021-05-08T02:10:11Z","receivedAt":"2021-05-08T02:10:16Z","isPatch":false,"sender":{"key":"dwh@linuxprogrammer.org","avatar":null},"body":"On 19.04.2021 18:00, Konstantin Ryabitsev wrote:\n>I view email as merely one way of exchanging RFC2822-formatted messages.\n>There are others and RFC2822 is robust enough to serve as a good standard\n>base that allows both free-form and structured content, including mixed.\n\n+1 on RFC2822 as universal message format. It is simple, easy to\nunderstand, trivial to manipulate in any programming language and widely\nsupported. Standard file formats, along with standard protocols, both\nwithout \"proprietary extensinos\" is the key to maintaining\ndecentralization and avoiding siloing of data and users.\n\nCheers!\nDave\n"},{"id":"423913","messageId":"6f42d6e2-087a-4c95-1aa1-31ee871c06b4@gmail.com","threadId":"55492","inReplyTo":"20210508020855.GF3986@localhost","subject":"Re: Pain points in Git's patch flow","fromName":"Bagas Sanjaya","fromEmail":"bagasdotme@gmail.com","sentAt":"2021-05-08T04:41:02Z","receivedAt":"2021-05-08T04:41:09Z","isPatch":false,"sender":{"key":"bagasdotme@gmail.com","avatar":"https://avatars.githubusercontent.com/u/40219486?v=4"},"body":"On 08/05/21 09.08, dwh@linuxprogrammer.org wrote:\n\n> Think about it like this. Right now, I could use an IMAP client to\n> download all of my emails from GMail, store them in mbox files, then\n> use the IMAP client to upload the email to Fastmail or SDF.org or some\n> other email provider. Or better yet, I can install local tools for\n> working with my email. The fact that email providers/tools are largely\n> interchangeable and replacable--despite Google/Yahoo/Microsoft's best\n> efforts--gives maximum power to users.\n\nWell, I use Thunderbird because it supports Gmail accounts out of the box.\nBut I wish I could use Mutt or similar, alas Gmail requires that I need\nto enable 2FA and s///\nin order to access Gmail via Mutt. I currently steer clear from 2FA, because\nonce upon a time in 2018 I screwed up (locked-out) from my older account,\nwhich IMO mission-critical., for I couldn't pass all possible verification\nmethods for that. So I created new account one in about Día de Kartini\n(Kartini's day).\n\nAnd yes, Google/Yahoo/MS have webmail interface for their mail services\n(Gmail/YahooMail/Outlook), but for purposes for sending to vger.kernel.org,\nthese above are rubbish because they genereated HTML emails, and vger hate\nHTML emails.\n\n-- \nAn old man doll... just what I always wanted! - Clara\n"}]}