Hi there, I'm not a regular contributor but I have started to subscribe to the Git's Mailing List recently. So I thought it might be worth sharing my personal view on this. After writting all the below, I do realize that I have written quite a rant, some of which I think some might consider to be off topic. For that, I do want to appologize before hand. Tue, Apr 13, 2021 at 11:13:26PM -0700, Jonathan Nieder wrote: > Hi, > ... > > Those four are important in my everyday life. Questions: > > 1. What pain points in the patch flow for git.git are important to > you? There are several points I want to highlight: 1. Issue about reading the Mailing List: - Subscribing to Git's Mailing List is not trivial: It takes a lot of time to setup the email subscription. I remember having to google through a few documents to get my subscription working. - And even after having subscribed, I was bombarded with a set of spam emails that was sent to the mailing list address. These spams range anywhere from absurd to disguising themselves as legitimate users trying to contact you about a new shiny tech product. 2. Issue about joining the conversation in the Maling List: - Setting up email client to reply to the Mailing List was definitely not trivial. It's not trivial to send a reply without subscribing to the ML(i.e. using a Header provided from one of the archive). The list does not accept HTML emails, which many clients use as default format. Getting the formatting to work for line wrapping is also a challenge depends on the client that you use. - It's a bit intimidating to ask 'trivial questions' about the patch and create 'noise' in the ML. 3. Isssue with archive: - I don't find the ML archive trivial for new comers. It took me a bit of time to realize: 'Oh if I scroll to bottom and find the "Thread overview" then I can navigate a mailing thread a lot easier'. - The lack of labeling / categorization that I can filter while browsing through the archive make the 'browse' experience to be quite unpleasant. Search is one way to do it, but a new comers would not be knowledgable enough to craft search query to get the archive view just right. Perhaps a way to provide a curate set of categories would be nice. - Lost track of issues / discussion: A quick example would be me searching for Git's zstd support recently with > https://lore.kernel.org/git/?q=zstandard and got next to no relevant result. However if I were to query > 'https://lore.kernel.org/git/?q=zstd' then a very relevant thread from Peff appeared. I think this could be avoided if the search in ML archive do more than just matching exact text. 4. Lack of way to run test suite / CI: It would be nice if we can discuss patches while having CI result as part of the conversation. Right now mostly I see that we have to manually running benchmarks/tests and share the paste the results. But for folks who don't have a dev environment ready at hand (new comers, during travel with only phone access), it would be nice to have a way to run tests without a dev environment. This was mostly solved in the context of works spent on Github's Action Workflow. But if we are discussing about pure patch flow, this is a miss. > 2. What tricks do you use to get by with those existing pain points? For (1): - I had to invested a lot of time into setting up a set of Gmail search filter. Move mails with topics that Im interested in into a special tag while the rest into archive. Regularly check if anything interesting went to archive by accident. For (2): - I had to setup Mutt + Tmux to have a compatible experience sending replies like this one. - All the patches I have submitted were through > https://github.com/gitgitgadget/git/pulls and it was not directly trivial to get permission to send email from a PR. For (3): - Spending time reading git blame / git log / commit message helps identifying the keywords I need to refine my search result in the ML archive. This requires some commitments and is a barrier to entry for new comers. - Using service like Github Search or SourceGraph helped a lot in term of navigating through the commit message / git blame. For (4): - I leverage both Github action and a patch that added Gitlab CI to run the test suite. > 3. Do you think patchwork goes in a direction that is likely to help > with these? > > 4. What other tools would you like to see that could help? With all that said, I don't know if patchwork will solve the problems above. I do understand that the current patch workflow comes with a certain set of advantages, and adopting another tool will most likely be a trade-off. Personally I have been spending more and more time reading through git.git via Sourcegraph Web UI and I would love for the search feature to be able to extend to be able to search in the Mailing List from relevant commit if possible. I have also tried both Github's Codespace and Microsoft's DevContainer to setup an opionated IDE with predefined tasks that help executing the test suite. I think these tools (or their competitors such as GitPod) are quite ideal to quickly onboard new contributors onto a history-rich codebase such as git.git. Perhaps some configure a set of sane default, including editor extensions that would handle email config for first time users. As for code review and issue tracking toolings, I don't think there are a perfect solution. Any solutions: Github PR, Gitlab MR, Gerrit, Phabricator would come with their own set of tradeoffs. I like the prospect of PatchWork gona improve the patch workflow though. Perhaps I will give it a try. > > Thanks, > Jonathan Thanks, Son Luong.
