A new free-software forge: sr.ht

Posted Jan 9, 2019 18:21 UTC (Wed) by Beolach (guest, #77384)
In reply to: A new free-software forge: sr.ht by awilfox
Parent article: A new free-software forge: sr.ht

"De gustibus non est disputandum" - "In matters of taste, there can be no dispute."

I consider web interface vs. email vs. whatever else to be a matter of taste. Different people will prefer different things. My personal taste in this matter aligns more w/ yours (I dislike "webby JavaScript" & prefer email, or at least non-JS plain HTML web), but I readily acknowledge the existence of people with other tastes, and that it could be nice to be able to collaborate w/ them w/out having to sacrifice either of our preferences.

IMO that's the biggest issue for sr.ht - that will be the most difficult to get right, and the most important thing that will make them succeed over their competition if they can get it right - is bridging between web & email & git CLI & whatever else people like to use. Upthread SirCmpwn said:

The plan is to extend this to support a web-based review style similar to Gerrit, but where comments on the web become emails in the typical mailing-list-code-review fashion popular in other projects - and vice versa, participating via email shows up on the web.

If they can get that right, that's a killer feature. But I think it's hard to do right - at least, nothing I know of has succeeded at it yet.

A new free-software forge: sr.ht

Posted Jan 10, 2019 5:45 UTC (Thu) by marcH (subscriber, #57642) [Link]

Databases with wildly different (web *and* non-web) interfaces and representation is a long solved problem. The only issue is parsing email's DATA lack of structure which must be why patchwork's database doesn't even try.

A new free-software forge: sr.ht

Posted Jan 10, 2019 9:39 UTC (Thu) by grawity (subscriber, #80596) [Link] (1 responses)

Additionally, a matter of experience influencing how "easy" something seems to be.

I'd agree that setting up `git send-email` is not very difficult at all – point it at the SMTP server and go. (Once you know that you need to use `git send-email` and not e.g. Thunderbird, that is.) But setting up a suitable mail client for receiving patches is a bit more of a hassle – it seems like you have to either use Mutt or Emacs, basically.

I really hope that OP didn't mean to say that setting up a mail server is easy; I've set up mine twice, and even though I enjoyed the process, I wouldn't call it any easier than e.g. setting up Kerberos or BGP: it seems to work at first, but there are pitfalls everywhere you go, your mail gets dropped for reasons you can't control, and if you don't faithfully follow the correct tutorial word-by-word, it'll take weeks if not months to work the kinks out.

A new free-software forge: sr.ht

Posted Jan 25, 2019 14:57 UTC (Fri) by aigarius (subscriber, #7329) [Link]

Locations also differ. Try setting up git send-email when your ISP simply blocks all incoming and outgoing connections to all known email ports. For security. And the selection of alternative ISPs is limited or even non-existent. Email is a really complex system to set up on your own, so most people just use GMail or something similar, so you are effectively trading a WebUI that is optimized for code review for a WebUI that is not.

A new free-software forge: sr.ht

Posted Jan 10, 2019 11:16 UTC (Thu) by jani (subscriber, #74547) [Link]

Personally I've come to the conclusion that while I very much prefer emailed patches for code review, it's not necessarily the best mode of transmission of the actual code changes. I think it would be an interesting idea to git push the changes to a repo, and have the server side git send-email the patches to the right mailing lists and people. This would reduce the patchwork style guesswork on the mailing list, as the server would have more data available to it.