LWN: Comments on "A new free-software forge: sr.ht"

A new free-software forge: sr.ht

aigarius — Fri, 25 Jan 2019 14:57:53 +0000

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

oldtomas — Thu, 17 Jan 2019 14:07:47 +0000

This is hardly surprising from you, knowing your background.

See, I have a love-hate relationship with Mozilla, and this post from you clearly falls in the "hate" part.

It is jarring to be told "you don't exist" -- especially by those who want to be one's ally.

A new free-software forge: sr.ht

aaronmdjones — Tue, 15 Jan 2019 03:17:49 +0000

It may be because, as in my case, you have a photo UID on the key. This can be many kilobytes; in my case it results in a key more than 600 KiB. You can temporarily delete photo UIDs and export it, and then refresh your key from a keyserver to get your UIDs and their signatures back. After all, encrypting email to you doesn't need photos anyway. For some unknown reason, '--export-options export-minimal' doesn't remove photos.

$ gpg --edit-key ...
(gpg) uid 3
(gpg) deluid
(gpg) save
$ gpg --export ...
$ gpg --refresh-keys ...

A new free-software forge: sr.ht

jkingweb — Fri, 11 Jan 2019 15:47:52 +0000

I had been under the mistaken impression that such string insanity had ended, but apparently only some forms have to date been stamped out; notably 0eAnything is still alive and well, it seems. :(

A new free-software forge: sr.ht

BenHutchings — Fri, 11 Jan 2019 15:44:39 +0000

... Github and Gitlab are solely focused on the Web UI model, ...

Primarily focused on web UI, perhaps, but both have APIs that can be used to script many operations.

A new free-software forge: sr.ht

begriffs — Fri, 11 Jan 2019 04:09:22 +0000

> I think it's the first time I see this "email has more features" angle, it's rather the opposite as in email keeps things simple, flexible and not "bloated" etc. Can you list some of these features?

I think that the email collaboration style of development does offer features that Github-style development lacks:

https://begriffs.com/posts/2018-06-05-mailing-list-vs-git...

But, as mentioned in this thread, Github has some advantages too.

A new free-software forge: sr.ht

neilbrown — Thu, 10 Jan 2019 23:11:48 +0000

> My (personal) main argument in the comparison of email vs web based system would be:

Mine would be "federation". By this, I particularly mean a global name-space for contributors, together with (at least) minimal interaction possibilities between all platforms.

If I want to add "Reported-by:" to a patch that I generate, based on a report that I received on some weird platform (case-in-point: github issues), the name attached to the problem report should be a universal name that I can use in the Reported-by tag.

If I want to include someone in a conversation - I should be able to request that within the platform and they should be able to receive my request, review the history, and make a comment without having to sign-in or anything - just follow a link to read, and then reply to the original message to contribute.

A new free-software forge: sr.ht

ddevault — Thu, 10 Jan 2019 17:57:00 +0000

An important difference is that email is governed by standards and enjoys a lush ecosystem of open source implementations.

A new free-software forge: sr.ht

domenpk — Thu, 10 Jan 2019 14:20:35 +0000

Very liberal type conversion can be responsible for some of those bugs. See https://www.cryptologie.net/article/268/how-to-compare-pa... for example.

A new free-software forge: sr.ht

jani — Thu, 10 Jan 2019 11:16:27 +0000

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.

A new free-software forge: sr.ht

grawity — Thu, 10 Jan 2019 09:39:12 +0000

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

lkundrak — Thu, 10 Jan 2019 07:41:00 +0000

I had this on my mind: http://php.net/manual/en/security.globals.php
Likely not relevant for present-day PHP which I don't know much about

Then there's other such classes; i.e. you probably have somewhat higher chance of messing up handling of files with whitespace characters or begining with an "-" when writing a shell script.

A new free-software forge: sr.ht

marcH — Thu, 10 Jan 2019 05:45:03 +0000

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

marcH — Thu, 10 Jan 2019 05:34:26 +0000

For people who can't get enough of these debates there was also:
https://lwn.net/Articles/768483/ A farewell to email October 16, 2018

A new free-software forge: sr.ht

marcH — Thu, 10 Jan 2019 05:30:52 +0000

> Github and Gitlab are solely focused on the Web UI model,

I'm always surprised how rarely Gerrit is mentioned in these discussions. It's more comparable to email because it doesn't "confuse" code review with bug and release tracking, CI etc. It's far from perfect but open-source, actively developed and has been used in production by some really big projects for years. It's fairly scriptable and sends (too many and very poor) emails.

> and so end up reinventing a lot of functionality that either already exists in a git-send-email world, or works around issues caused by not using email as a collaboration platform.

Wow, I've seen a lot of discussions on this topic but I think it's the first time I see this "email has more features" angle, it's rather the opposite as in email keeps things simple, flexible and not "bloated" etc. Can you list some of these features?

Hopefully you didn't just mean: "email can be scripted hence it can do anything".

A new free-software forge: sr.ht

jkingweb — Thu, 10 Jan 2019 03:54:13 +0000

> Is the certain class of bugs likely to be present? (hello PHP!)

What class of bugs would that be, out of curiosity?

A new free-software forge: sr.ht

roc — Wed, 09 Jan 2019 21:10:46 +0000

Actually there's quite a lot one can do to customize Github and Gitlab. Both of them have APIs that let you write applications that read/write data and customize workflow. On the UI side, browser extensions let you customize look and feel.

A new free-software forge: sr.ht

iabervon — Wed, 09 Jan 2019 20:58:34 +0000

It would be an interesting next step to offer some email-client-inspired web interfaces to archives of the mailing list; having an email-style development method doesn't has to mean that programs have to use SMTP and POP/IMAP. I see this style as being fundamentally that development is represented with a sequence of human-readable messages which tend to be a couple thousand words each, where it is possible to search the database across all threads associated with a single project (i.e., see all new messages to a mailing list), rather than having to look at a number of separate places to see whether each of them has new messages, and you can see a list of results with one line per message when the message is much longer than that in full.

Being able to insert and receive messages by SMTP is useful for a lot of people's existing tooling, but I think the more important aspect of this project style is that model of what an interaction consists of, and I think it would be valuable to offer that to people who don't prefer to use SMTP for development.

A new free-software forge: sr.ht

Beolach — Wed, 09 Jan 2019 18:21:33 +0000

"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

k8to — Wed, 09 Jan 2019 17:20:06 +0000

Well if the attraction is the open source aspect, then these concerns will have an influence even if you plan to use the service for now.

A new free-software forge: sr.ht

claude.bing — Wed, 09 Jan 2019 17:00:25 +0000

Ah, from the self-hosted approach I completely agree. I was referring to the SaaS sr.ht site itself, sorry for the misunderstanding.

A new free-software forge: sr.ht

lkundrak — Wed, 09 Jan 2019 16:28:55 +0000

This matters *a lot* to people who are going to operate servers that run the software.

* Am I able to understand the code?
* Will I be able to rebuild the thing?
* Is the certain class of bugs likely to be present? (hello PHP!)
* Am I able to reasonably and safely install the correct versions of the required dependencies? Will I be able to do so next week? (hello nodejs!)
* Will it run with the next year's version of the interpreter? (hello Python)
* What is the resource consumption? (hello Java)

A new free-software forge: sr.ht

ddevault — Wed, 09 Jan 2019 15:43:03 +0000

Yep! You can see the beginnings of this today, here's an example mailing list where patches are coming in often:

https://lists.sr.ht/~emersion/mrsh-dev

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.

A new free-software forge: sr.ht

ejr — Wed, 09 Jan 2019 15:39:12 +0000

Oh, email centric, I like... Any plans for patchwork or something equivalent? (I see the "Write this doc" under code review.)

A new free-software forge: sr.ht

claude.bing — Wed, 09 Jan 2019 15:37:49 +0000

As long as the service works as advertised, why does it matter what language it is written in?

A new free-software forge: sr.ht

jpsamaroo — Wed, 09 Jan 2019 14:13:34 +0000

While I agree that "Github wannabe" is a bit strong, as a user of Gitlab, I definitely can see it as an more featureful clone of Github. Many of the features of Github are replicated in Gitlab, just with added functionality and a different name.

I think the most important thing to consider is that unlike sr.ht and related software forges/methodologies, Github and Gitlab are solely focused on the Web UI model, and so end up reinventing a lot of functionality that either already exists in a git-send-email world, or works around issues caused by not using email as a collaboration platform.

Comparison of code development service platforms and services?

ber — Wed, 09 Jan 2019 11:46:03 +0000

It is good to see more efforts to improve Free Software products and services build upon them, so thanks for reporting about it.

What I'm missing from the announcement and the article is an attempt at comparing the different options, for instance there is allura.apache.org (and their first link is at least a start of an comparison).

There are also many other products and service providers like Phabricator / Phacility and others already mentioned.

Regards, Bernhard

A new free-software forge: sr.ht

smurf — Wed, 09 Jan 2019 08:38:35 +0000

Yes, email is painful. Just try to get outgoing SMTP to work when you're behind a restrictive ISP. Blame the spam mail viruses …

A new free-software forge: sr.ht

Archimedes — Wed, 09 Jan 2019 08:29:57 +0000

My (personal) main argument in the comparison of email vs web based system would be:
I can choose my email client, I am allowed to configure that client as I wish, I can enhance that client (depending on it) in plenty of ways which help me to work as I would like to, and the great thing is that all what I like on my setup does not influence anybody else.

On Web based systems in all (or maybe most) the user has no real way to change the "websie client" as he would like to use it. Also the workflow, shorcuts, ui, whatever is given by solely the web client. For me that feels like the mainframe times, root == god, user == nothing+epsilon ...

A new free-software forge: sr.ht

Shugyousha — Wed, 09 Jan 2019 07:51:15 +0000

Sounds like a bug. Maybe you can report the issue you had here?: https://todo.sr.ht/%7Esircmpwn/git.sr.ht

A new free-software forge: sr.ht

unixbhaskar — Wed, 09 Jan 2019 03:26:29 +0000

Well, bumped on it. PGP key upload always said it's too big, In spite of using their method to get the minimal key and tried to upload the same ...still the result is same. I do hope someone might look into that.

A new free-software forge: sr.ht

roc — Wed, 09 Jan 2019 02:34:20 +0000

Especially if it's open source so that ornery minority can maintain their own JS-free fork if they really want to.

A new free-software forge: sr.ht

roc — Wed, 09 Jan 2019 02:32:48 +0000

If I was building a Web client I wouldn't bother making it work at all for the negligible number of users who would insist on disabling JS on my site. Any effort spent on that would give a bigger payoff by spending it on something useful for the vast majority of JS-enabled users.

A new free-software forge: sr.ht

vstinner — Wed, 09 Jan 2019 01:28:20 +0000

There is Pagure which is written in Python as well: https://pagure.io/pagure It's used by Fedora for example.

A new free-software forge: sr.ht

mageta — Wed, 09 Jan 2019 00:28:37 +0000

You should at least try to get some form of coherent argument, instead of just calling it names.

A new free-software forge: sr.ht

q3cpma — Wed, 09 Jan 2019 00:06:13 +0000

It may be ahead, but it's quite behind when it comes to basic functionalities without Javascript enabled, sadly.

A new free-software forge: sr.ht

awilfox — Wed, 09 Jan 2019 00:00:37 +0000

> Email is painful to set up and use any more—many are finding alternatives far more attractive.

This is an outright falsehood. Email is not painful to set up, and it is miles easier to use than the webby JavaScript slow-as-hell BS GitHub and, to a lesser extent, modern GitLab are full of.

To hell with the webby BS. I don't think sr.ht is the project that will fix code forges, but it definitely has the right ideas at heart.

A new free-software forge: sr.ht

roc — Tue, 08 Jan 2019 23:14:17 +0000

The announcement has a quote describing Gitlab as a "Github wannabe", which is very unfair. Gitlab is well ahead of Github in some areas, e.g. CI/CD; Github simply doesn't have anything built in for that.

A new free-software forge: sr.ht

ddevault — Tue, 08 Jan 2019 23:00:25 +0000

Thank you for the write-up, Jake! If any LWN subscribers have comments/quesitons/feedback about sr.ht, I'm always a short email away: sir@cmpwn.com

Cheers!

A new free-software forge: sr.ht

brouhaha — Tue, 08 Jan 2019 22:52:23 +0000

I haven't used sr.ht yet, but being written in Python 3 makes it a good deal more attractive to me than the alternatives I'm aware of. I don't know much PHP, Ruby, or Go, and what I do know of PHP turns my stomach. Ruby and Go are probably fine languages, but I don't have time to learn them.