From: Eric Wong <firstname.lastname@example.org> To: Son Luong Ngoc <email@example.com> Cc: Jonathan Nieder <firstname.lastname@example.org>, email@example.com, Raxel Gutierrez <firstname.lastname@example.org>, email@example.com, firstname.lastname@example.org, Junio C Hamano <email@example.com>, Taylor Blau <firstname.lastname@example.org>, Emily Shaffer <email@example.com> Subject: Re: Pain points in Git's patch flow Date: Mon, 19 Apr 2021 02:57:54 +0000 [thread overview] Message-ID: <20210419025754.GA26065@dcvr> (raw) In-Reply-To: <YHhfsqfTJ9NzRwS1@C02YX140LVDN.corpad.adbkng.com> Son Luong Ngoc <firstname.lastname@example.org> wrote: > 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. Thanks for the feedback, some points below. > 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. Note that subscription is totally optional. Gmail's mail filters probably aren't very good, perhaps SpamAssassin or similar filters can be added locally to improve things for you. Spam filtering is a complex topic and Google's monopolistic power probably doesn't inspire them to do better. > 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. The spam (and phishing) problem would be worse if HTML mail were accepted. Obfuscation/misdirection techniques used by spammers and phishers aren't available in plain-text. It's also more expensive to filter + archive HTML mail due to decoding and size overheads, which makes it more expensive for others to mirror/fork things. > - It's a bit intimidating to ask 'trivial questions' about the patch and > create 'noise' in the ML. I'm sorry you feel that way. I understand the Internet and its persistence (especially with mail archives :x) can have a chilling effect on people. I think the way to balance things is to allow/encourage anonymity or pseudonyms, but some folks here might disagree with me for copyright reasons. OTOH, don't ask, don't tell :) (I am not speaking as a representative of the git project) > 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'. (I'm the maintainer of public-inbox, the archival software you seem to be referring to). I'm not sure how to make "Thread overview" easier to find without cluttering the display near the top. Maybe I'll try aria labels in the Subject: link... > - 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. Perhaps TODO files/comments in the source tree are acceptable; or a regularly-posted mail similar to "What's cooking". Having a centralized website/tracker would give too much power and influence to people/orgs who run the site. It would like either require network access or require learning more software to synchronize. > - 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. I'm planning to support Xapian synonyms for that, but haven't gotten around to making it configurable+reproducible by admins. Everything in public-inbox is designed to be reproducible+forkable. > 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. Fwiw, the GCC Farm project gives ssh accounts for all free software contributors, not just gcc hackers: https://cfarm.tetaneutral.net Perhaps there's other similar services, too. Slow down and enjoy travel :) There's very little in free software urgent enough to require constant attention. Email is well-suited for asynchronous work, and nobody should expect instant replies. The always-on nature of the modern Internet and smartphones increases stress and dangerous situations; so I hope free software hackers aren't contributing to that. > 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. Fwiw, git-send-email works for non-patch mails, too. I don't want a monoculture around mutt or any particular clients, either. (I've never used tmux and don't see why it's necessary, here). Anyways, thanks again for the feedback.
next prev parent reply other threads:[~2021-04-19 2:58 UTC|newest] Thread overview: 46+ messages / expand[flat|nested] mbox.gz Atom feed top 2021-04-14 6:13 Jonathan Nieder 2021-04-14 7:22 ` Bagas Sanjaya 2021-04-14 8:02 ` Junio C Hamano 2021-04-14 21:42 ` Junio C Hamano 2021-04-15 8:49 ` Denton Liu 2021-04-15 6:06 ` Junio C Hamano 2021-04-15 15:45 ` Son Luong Ngoc 2021-04-19 2:57 ` Eric Wong [this message] 2021-04-19 13:35 ` Theodore Ts'o 2021-04-21 10:19 ` Ævar Arnfjörð Bjarmason 2021-04-28 7:21 ` Eric Wong 2021-04-28 7:05 ` Eric Wong 2021-04-15 18:25 ` Atharva Raykar 2021-04-16 19:50 ` Junio C Hamano 2021-04-16 20:25 ` Junio C Hamano 2021-05-02 5:35 ` ZheNing Hu 2021-04-18 8:29 ` Sebastian Schuberth 2021-04-18 20:54 ` Ævar Arnfjörð Bjarmason 2021-04-19 2:58 ` Eric Wong 2021-04-19 5:54 ` Sebastian Schuberth 2021-04-19 6:04 ` Sebastian Schuberth 2021-04-19 8:26 ` Ævar Arnfjörð Bjarmason 2021-04-19 19:23 ` Sebastian Schuberth 2021-04-19 22:34 ` Theodore Ts'o 2021-04-20 6:30 ` Sebastian Schuberth 2021-04-20 16:37 ` Theodore Ts'o 2021-04-30 20:45 ` Felipe Contreras 2021-04-20 10:34 ` Ævar Arnfjörð Bjarmason 2021-04-19 19:36 ` Eric Wong 2021-04-19 19:49 ` Sebastian Schuberth 2021-04-19 22:00 ` Konstantin Ryabitsev 2021-05-08 2:10 ` dwh 2021-04-19 21:49 ` Konstantin Ryabitsev 2021-04-19 23:03 ` Stephen Smith 2021-05-08 2:08 ` dwh 2021-05-08 4:41 ` Bagas Sanjaya 2021-04-30 20:58 ` Felipe Contreras 2021-04-21 4:46 ` Daniel Axtens 2021-04-26 2:04 ` brian m. carlson 2021-04-26 14:24 ` Theodore Ts'o 2021-04-26 14:36 ` Ævar Arnfjörð Bjarmason 2021-04-28 7:59 ` Eric Wong 2021-04-28 22:44 ` brian m. carlson 2021-04-30 20:16 ` Felipe Contreras 2021-04-30 20:35 ` Felipe Contreras 2021-04-30 21:09 ` Felipe Contreras
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style List information: http://vger.kernel.org/majordomo-info.html * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --in-reply-to=20210419025754.GA26065@dcvr \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --subject='Re: Pain points in Git'\''s patch flow' \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: link
Code repositories for project(s) associated with this inbox: https://80x24.org/mirrors/git.git This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).