|
Good to hear all the planned features in this reply and https://news.ycombinator.com/item?id=23041522. One small clarification: re: inline comments/reviews, what I had in mind was all reviews aggregated on a single page, not scattered and obsoleted by each patch version, which means comments are basically lost if not immediately addressed. Anyway, it seems to me that once you have all these planned features, the workflow would inch towards the Phabricator workflow, and to a lesser extent the GitHub workflow. The only major differentiator would be that you use emails to send in patches instead of using a branch. The actual code review activity would center around the web interface instead of the mailing list. That would mean (if my interpretations are correct) we disagree to a much smaller extent than I thought, but that would also mean your workflow is actually pretty different from “how git was designed to be used”, which I interpret as the mailing list-centric workflow of lkml (as I understand it; I’m not involved) and other old school projects I have participated in. Re mail clients: > (1) you can use multiple email clients for different reasons, you don't need to give up your current one; It’s possible, but not pleasant. Each client needs to be configured so that mail intended for the other doesn’t clutter it up (not only inbox, but also search, archive, etc.). Usually people already use two or more mail clients to begin with (pc, mobile), so, more configurations. > (2) you don't need a special email client to apply patches from lists.sr.ht, every patchset page has a little CLI command you can copy+run to fetch the patch with curl and feed it to git am. Yeah I’m aware of this, but this just brings back the point that you’re using emails but then not really using emails... |
_I_ like using emails. But the point of tools like that are so that people who don't like using emails can use other tools instead, and seamlessly collaborate with people who prefer to use emails.