I'm replying to Crystal's message as an entry point, but this isn't really *to* Crystal.
Whether to support patches by mail or GitLab/GitHub/whatever is a false argument. There's no point having it in the abstract. If the eventual maintainer(s) of mutt elect to accept patches by mail, then it's supported. There's clear value in the platforms that GL, GH, srht, etc offer, especially with CI/CD pipelines and hosting, and I think it's smart but not exclusive or exclusionary to build on that. But it doesn't dictate whether the maintainers allow emailed patches. You can have both. For myself — I've been as close as anyone to being a maintainer without actually ever maintaining — I like and prefer email as a medium, but I use GitLab for work, and I would argue for supporting both channels. On Wed, Jan 7, 2026 at 4:03 PM Crystal Kolipe via Mutt-dev < [email protected]> wrote: > On Wed, Jan 07, 2026 at 03:40:19PM -0800, Will Yardley wrote: > > I think > > anyone who works in any kind of modern software / technology > > organization _or_ works with open source a lot, is pretty familiar with > > these sorts of tools. > > That's a fairly broad assumption. Literally 98% of the development work I > do > requires at most cvs and doesn't go anywhere near the aforementioned > 'development platforms'. > > > And, the issue tracking portion is useful as well > > - IMO, having "flea" (which now appears to just have people submit via > > GitLab) go back to posting to a mailing list would be pretty difficult > > in terms of tracking and scalability. > > Issue tracking in a mailing-list based development environment is perfectly > plausible and practical. Look at how NetBSD integrates a GNATS database > with > mailing list discussions, for example. > > > And, at a simpler level, if someone wants to be able to propose a simple > > change (correcting a typo, say), this also makes it easy for someone to > > do that. > > It's only really easier than creating a three-line diff if the person > either > doesn't have the source code on their local machine, or if they are not > familiar with diff and patch. > > Worse still, it usually makes it _harder_ for other people to casually > review > the proposed change. Instead of looking at a single screenful of text in > mutt, I've got to fire up a web browser and start clicking around the web > interface of a development platform. > > In reality, I'd probably just ignore the proposed change and hope that > somebody else reviews it. > > At the end of the day, we seem to have observed the mutt development > community > dry up somewhat after the move away from list-based development. So there > seems to be some evidence that it's hurt this project, unless the timing > was > pure co-incidence. >
