~eliasnaur/gio#32:
Sourcehut Pain Points

This is a tracker issue for collecting the experience reports of using Sourcehut for contributing to Gio.

Post your specific and clearly explained issues as comments on this issue.

If you can, keep in mind that Sourcehut is still in alpha. The list of planned 1.0 features are listed here:

https://sourcehut.org/alpha-details/

To add a comment by email, use

~eliasnaur/gio/32@todo.sr.ht

Status
REPORTED
Submitter
~eliasnaur
Assigned to
No-one
Submitted
21 days ago
Updated
a day ago
Labels
No labels applied.

~joeblew99 21 days ago

I am excited about gio but detest using sourcehut to collaborate on the project.

I hate the monopoly that GitHub has but I would prefer if the project is one GitHub.

~eliasnaur 21 days ago

On Thu Aug 29, 2019 at 8:59 PM ~joeblew99 wrote:

I am excited about gio but detest using sourcehut to collaborate on the project.

I hate the monopoly that GitHub has but I would prefer if the project is one GitHub.

Can you elaborate on the specific pain points you have with Sourcehut?

If we stay on Sourcehut, can you specify what we could do to make it acceptable for you? For example, the Go project use a bot to convert Github PRs to Gerrit CLs.

~joeblew99 20 days ago

Actually i played with it and it does work.

I feel that using a different git system is not conducive to the gio project getting developer uptake. Why did you decide to use such a different approach?

On Thu, Aug 29, 2019 at 11:36 PM ~eliasnaur outgoing@sr.ht wrote:

On Thu Aug 29, 2019 at 8:59 PM ~joeblew99 wrote:

I am excited about gio but detest using sourcehut to collaborate on the project.

I hate the monopoly that GitHub has but I would prefer if the project is one GitHub.

Can you elaborate on the specific pain points you have with Sourcehut?

If we stay on Sourcehut, can you specify what we could do to make it acceptable for you? For example, the Go project use a bot to convert Github PRs to Gerrit CLs.

View on the web: https://todo.sr.ht/~eliasnaur/gio/32#comment-3538

~joeblew99 referenced this from #32 20 days ago

~dennwc 20 days ago

Here are some specific pain points, details that I think are important and possible solutions.

Disclaimer: It's mostly personal opinion. If you think any of the statements below are offensive, sorry, I haven't meant that. I believe that we should have a consensus on this, and not push toward any specific decision without a good understanding of the trade-offs (including SH itself).

Go community

This is the fact that no one can deny, like it or not: Go community is primarily on the Github. Because of this, it's easy to create issues, easy to contribute.

Go core team tried hard to keep away from Github, but now they allow contributions from it as well. The main tree is also hosted there, as well as countless Go projects.

Centralization is evil in many ways, but it's good for bringing the community together, especially if the service is free and distributed (Git always is).

Having said that, I think using open-source Git service is a very good idea. But there are better alternatives than SH, some also minimize the friction by trying to keep feature parity with Github. More on this later.

Contributions only by email

Sending patches by email is a pretty old way of sending changes to upstream. Most Git services nowadays provide automation for this (e.g. pull requests, merge requests). But let's put aside the it's old argument for a moment. Specifically, setting up Git to send email patches may not be as easy as one may assume.

First, there are still people using Windows to develop desktop/Android apps. Those people may freak out from just hearing open the terminal and change those things. One may argue that those people probably won't contribute to Gio, but I think it's wrong. It's possible to contribute widgets without touching any low-level code.

Second, some people use IDEs which already have many convenient features for pushing changes/PRs as branches and for Git management in general. Those people would have to drop to the terminal every now and then and paste hashes instead of allowing IDE to deal with it. I would argue that user who care about UI may prefer to use IDEs, thus this category of users might grow significant in the long run.

High-level devs aside, let's talk about low-level devs. Dropping to CLI is not a problem, and setting SMTP configs per this guide is trivial. The problem is, the email is a pretty sensitive service, you may not want any apps to access it. If you attempt to follow the guide, for example, Git will store your email password unencrypted on the disk! Yikes!

Yes, there are ways around it, for example, you can enable keyring integration. But to be more specific, I personally never allow any apps to access my primary email. Ever. And I have no plans to maintain a separate email for the sake of SH way of doing things. And I believe there are other people that take this way more seriously, than I do.

Friction of setting those things up may discourage many potential contributors for no good reason.

SourceHut alpha

SH is still an alpha is not a particularly good argument for using it in the first place, to be honest. Things tend to break, even Github has outages. And it's usually more true for new project like SH. But to be honest, most of us don't really care. We like the bleeding edge, so it's not a strong argument.

SH have a few things planned for the release, but it may take a considerable amount of time (year? two?) to develop and stabilize those. I believe that the Gio community should not suffer during this period due to missing core features, especially if there are better alternatives.

So instead of forcing contributions to happen on SH, it may be practical to use some other open-source and feature-complete alternative (e.g. Gitea) until SH hits the 1.0 milestone.

And yes, I mentioned that contributors will be forced to use SH to contribute to Gio. It is possible to send things to Gio without registering, but let's be honest, to effectively follow the project you'll need to register and visit SH from time to time. Which may be annoying since some useful features are missing.

I wouldn't get into details on missing features, because the list is quite long (SH is really simplistic), but you can open any of the pages from https://try.gitea.io/explore/repos and compare the number of buttons to the same page on SH. It may give a rough estimations of what's missing.

Also, during previous discussions it was mentioned that Gitea is a no go because it implies self-hosting and someone will need to pay for it. But if you read SH's plan for the release, you will notice that there is a clear statement: SH will be a payed service. So eventually someone will need to pay for hosting Gio on SH.

So I personally prefer to pick a feature-complete open alternative and self-host it (and yes, pay for it now), instead of picking alpha-quality service as the source of truth for the project (and paying the same cost in the future).

Centralization

There is an awesome article by the founder of SH about how Github changed the meaning of the fork:

https://drewdevault.com/2019/05/24/What-is-a-fork.html

It's a really good one, despite of the misleading name, and I highly recommend to read before arguing against SH. The chances that you are missing the SH's whole point are pretty high (I missed it too at first).

TL;DR: The article states that Github centralized things by introducing forks in a very specific way. I would say that author is highly subjective when mentioning Github, and blames it for a lot of things without giving enough credits for the positive effect. But if you ignore those occasional statements, author makes a very good point. Being enterprise-focused, Github unintentionally promoted a centralized model to the open-source world.

You see, Git shouldn't have a central project repo. Instead, a project is a combination of all branches in all forks. Linux is mostly developed this way today, while still being hosted by Github. But most other developers embraced the centralized way by creating orgs and assigning canonical names to projects. Now there is always a small group of people controlling each project. Some have weird rules which doesn't make sense, but forking is usually not an option, because there still be a canonical project.

Sorry for a long explanation, but I think it's crucial for an understanding what SH is trying to achieve. They are trying to remove this centralization feature and promote a decentralized way. At least on their own platform. And here is the main but for this discussion, I think.

Both the intention and the core idea is awesome, but this specific thread in Gio indicates that it's easy to miss the point and impose a centralized way of managing things on the new platform as well. No offense here, we all are used to think in terms of orgs and ownership (in the centralized way). Which seems to be different from what SH promotes.

To give a specific example, the distributed approach would imply that ~eliasnaur/gio is a fork and is equal to my fork at Github, and your fork on Bitbucket. So the contribute things to SH where Gio is hosted approach doesn't makes sense in the SH's ideology. At least this is my understanding.

To make this work in practice, however, SH will need to implement a good integration with other Git hosting provides like Github, Bitbucket, or any private Git instances, really. But right now it's seems kind of the opposite. Remember the on this new platform argument? Without any integrations (email is not a good one), it's still a centralized/isolated model. But instead of Github, there is a SourceHut: you need to go here to track issues on the project, you need to go here to contribute. I hope this will change eventually, but it's not the case right now.

And going back to emails, why we as Gio community need to find ways to integrate our workflows with SH (e.g. syncing issues/PRs), rather than SH integrating with tools the broad open-source community uses? I'm pretty sure they have plans for it, but again, no offense here, I don't think it's practical to pick a tool that is still this deep in the development.

Summary

Some key takeaways, in my opinion:

  • Go community is mostly on the Github. Picking anything too different creates friction.
  • There is no way to contribute via SourceHut except emails (during alpha?).
  • Setting up Git to send emails might not work for some people. Not necessarily a minority.
  • Contributing issues is important. Creating/tracking those is harder on SourceHut.
  • SourceHut is not yet there in terms of functionality. There are better open-source alternatives.
  • SourceHut will be paid on release. There are better open-source alternatives for the same price.
  • Gitea may be a good alternative. Open-source, feature-complete, less friction to switch for Github.
  • Picking SourceHut from an idealistic perspective should imply a different management model.
  • Different management model will imply allowing Github as a peer. Doing so will shift contributions back to it.
  • Using Github as a peer for SH is hard for now. Requires additional community effort to build integrations.
Possible solutions

Again, personal opinion. Propose other options. From less hardcore to more hardcore:

1) Move the project to Github completely. It would be easier for others, but will defeat the decentralization again.

2) Setup self-hosted Gitea. Almost no friction. Github auth (optional), feature parity, similar UI. But we'll have to pay for hosting it.

3) Bazaar way (SourceHut ideology). Gio's forks on Github and SourceHut are equal. The one with less contributions merges from the one with more. May organically degrade to (1), (2) or (6) depending on the largest fork.

4) SourceHut is the source of truth. Sync with Github issues and PRs. Significant effort. May degrade to (6) since no one will probably have time to build the sync.

5) Gitea with modifications. Similar to (2), but also contribute code to Gitea (it's in Go) to enable anonymous email contributions as in SourceHut. Less effort than (4)? Supports Gophers. May degrade to (2).

6) Stick with SourceHut. Use emails until the release, pay for it afterwards. Probably lose contributors. If development will pause for too long, may degrade to (1) due to a new maintainer.

Personally I would prefer option (5), it's seems to match a Go way in my opinion and preserve a decentralized bit as well.

~dennwc 20 days ago

Sorry for the long post and the formatting. SH doesn't support Markdown to a full extent.

See a formatted version here: https://gist.github.com/dennwc/f3e8f498768b659f9a0d3f89ad6f2369

~eliasnaur 20 days ago

The problem is, the email is a pretty sensitive service, you may not want any apps to access it. If you attempt to follow the guide, for example, Git will store your email password unencrypted on the disk! Yikes!

Good point. I filed a proposal for using a sr.ht account for git send-email.

~dennwc 20 days ago

~eliasnaur Thanks! That would help to some degree.

But still, I have no idea why you don't even want to consider Gitea/Gitlab/whatever as an option, since you haven't commented on most of the points :D

I did a bit more research on it and found a nice feature comparison table: https://docs.gitea.io/en-us/comparison/

Apparently, they plan to support creating issues by email. Same can be done for patches eventually.

Also, turned out they have a free hosted version at https://gitea.com.

~eliasnaur 20 days ago

On Fri Aug 30, 2019 at 12:21 PM ~dennwc wrote:

~eliasnaur Thanks! That would help to some degree.

But still, I have no idea why you don't even want to consider Gitea/Gitlab/whatever as an option, since you haven't commented on most of the points :D

I do consider all options, including Gitea. In fact I'm a big fan of them being in Go! My favorite host would be a Go binary that I could easily self-host on the gioui.org domain and that supported issues and mailing lists.

I just happened to pick one objection that I had something useful to contribute to.

I did a bit more research on it and found a nice feature comparison table:

https://docs.gitea.io/en-us/comparison/

Apparently, they plan to support creating issues by email. Same can be done for patches eventually.

Nice. Perhaps Sourcehut will have a subtle influence on other platforms which will then become a better fit for Gio.

Also, turned out they have a free hosted version at https://gitea.com.

Thanks, but I don't particularly mind paying for hosting; after all, I'm paying for SH and I believe it is a healthier business model in the long run.

~theclapp 17 days ago

Specific pain points:

  • There's no preview or edit on issue/todo comments (like this one). Getting one's formatting right is hit-or-miss.
  • Emailed issue updates look like crap in Gmail. I haven't checked in (say) mutt.
  • I've yet to figure out how to get mutt/Gmail to not send me my own mailing list submissions twice. Yes, that's all on my end, but on the other hand, it's not a problem with GitHub, and I doubt it'd be one with Gitea.
  • Related: I don't see how to get SH to send me a copy of my mailing list submission if I make it directly on the SH website.
  • SourceHut is poorly connected. If you know about Gio, finding the mailing list or issues pages is a matter of scrolling down the appropriate part of the README in the Git repo. Or bookmarking them, obviously. A project isn't really a project, it's a loose collection of informally affiliated webpages. (Compare GitHub/Tea where they're all easily discoverable from the front page, and from most other pages.)
  • I disagree with the basic assertion that plaintext is better. It has its advantages, which https://useplaintext.email/ lays out, but I find most of the arguments presented there uncompelling. I like real rich text, and I especially like being able to embed images right inline. Or in issues. Or in wiki pages. Or just generally anywhere. (So here I've kind of conflated my objection to plaintext email and to SH in general, I guess.) I think it's hilarious that useplaintext.email itself is not, in fact, in plaintext. Which it lampshades at the end ("But if plaintext is so good, why is this page written in HTML?" "This is a reference document, not an email, you twit.") which argument I also find uncompelling. To me its most compelling argument is that plaintext is more accessible, and it completely discounts its own point while trying to make it.
  • Related: Being more-or-less forced to use mutt instead of Gmail is annoying. SH should be able to pull out the text of a multi-part email. (Yes, Gmail has a plain text option, 'tis true. Which it then helpfully remembers for my next email to regular people. Which is also annoying.)
  • I find the conflation of a mailing list and a list of patches pretty irritating. I'd prefer they were more separated.

Obviously I don't find any of these issues insurmountable. They're just ... annoying. I still contribute, etc. But nevertheless they're issues that don't arise when random GitHub users want to contribute to random projects hosted on GitHub.

One argument for accepting patches via email is that random people can submit patches without joining anything (GitHub or Gitea or whatever). So ... honestly, is that a huge demographic?

(And, as an aside, what happens when Teh Spammers (almost) inevitably find the SH mailing lists?)

(Here's where I hope for the best and hit Comment, because there's no preview or edit option.)

~sircmpwn a day ago

Thoughts as the founder of Sourcehut. Responding to ~dennwc first.

First, I dismiss any arguments that suggest Github should be used because Github has momentum or because lots of Go users are on Github. There's nothing I can do about that, and by that logic we would all still be on Sourceforge.

If you attempt to follow the guide, for example, Git will store your email password unencrypted on the disk! Yikes!

This isn't true, following the guide will configure git such that it prompts you for your password when sending the email.

But to be more specific, I personally never allow any apps to access my primary email. Ever.

I don't think this is reasonable. Outgoing SMTP can't read any of your stuff, it can just send emails on your behalf. And git is an open source and trusted project, if you can't trust git to send an email then you can't trust git to do a dozen worse things, like protect your SSH keys.

But to be more specific, I personally never allow any apps to access my primary email. Ever.

I would argue that this is a feature, not a bug. It would be helpful if you enumerated exactly what you're missing. More features does not better software make.

Without any integrations (email is not a good one), it's still a centralized/isolated model.

Email is the integration. Why is it not a good one? This isn't justified. Outside of proprietary forges which have designed models to centralize development (how do you integrate with a walled garden, anyway?), email is how it's done. It's not attributable to any particular forge, precisely because it's decentralized. Hundreds, or even thousands, of venerable projects are using email every day to collaborate and have done so for years. Sourcehut already integrates with these projects, with the distributed development ecosystem, without capturing it our building a new wall.

No offense here, we all are used to think in terms of orgs and ownership (in the centralized way). Which seems to be different from what SH promotes.

Yes. But are you suggesting that this institutionalized idea of centralized orgs and ownership is a good thing? I would argue that's totally wrong. Yes, people will have to be retrained, but they were trained by bad actors into serving their interests, not their own, so I'd say some retraining is called for.

But instead of Github, there is a SourceHut: you need to go here to track issues on the project, you need to go here to contribute.

If you subscribe, you can track the issues in your local mail spool. Same as subscribing to the mailing list. Right now subscribing to tickets doesn't work without an account, but that's a bug and will be addressed during the alpha.

Contributing issues is important. Creating/tracking those is harder on SourceHut.

This was part of the tl;dr and I'm assuming that it follows from the last quote I gave, but it doesn't really. Even setting aside the missing subscribe-without-an-account, it seems we're left with a system which is not appreciably different from Github if you have an account. How is that harder? Just because SH is newer and people don't necessarily have accounts? See my initial dismissal of these arguments.

SourceHut will be paid on release. There are better open-source alternatives for the same price.

Only paid to own resources like projects, being a contributor will always be free. And, for those who can't pay the fee, I'll waive the fee. This is promised upfront in the billing material. The alternative is that you pay in some other way, a way you might not like.

Gitea may be a good alternative. Open-source, feature-complete, less friction to switch for Github.

I presume that the SH model is better. Let's acknowledge as well that changing from the Github workflow may be a source of friction. How, then, do we set a path from the Github model to the SH model? What are the iterative steps? I don't think Gitea makes any movement towards the SH model, it's just a striaght-up Github clone. And remember, Github is confusing to new programmers, too. It doesn't seem that way now only because you're already used to it.

And I don't think Gitea is a compelling alternative, anyway. An easy example to point out would be the lack of CI. That being said, if Gitea has webhooks it could be plugged into SH CI. Totally valid use-case. But the point here is that Gitea without Sourcehut is worse than Sourcehut alone.

3) Bazaar way (SourceHut ideology). Gio's forks on Github and SourceHut are equal. The one with less contributions merges from the one with more. May organically degrade to (1), (2) or (6) depending on the largest fork.

Acknowledging this as valid, but that it might not be exactly what you imagine. Right now I trust ~eliasnaur as the maintainer, and no one else has the level of familiarity or has established enough goodwill to make any serious claims for the title. So long as he chooses to host the code here, then that's the upstream. This may become less clear over time, though, if a GregKH-esque figure appears or if a Linux-like system of lieutenants comes into play. Many subsystem maintainers of Linux choose to host their trees on Github and do accept pull requests (including myself, when working on the RISC-V port!), by the way, but the viability of that system depends on the patches flowing up the chain of command which right now would require ~eliasnaur to be on board with receiving patches or pulling branches through this medium. I don't claim to know what he would or wouldn't be on board with, I'm just clarifying the social structure that's implied in this option.


I know that this is mainly being on the defensive here, but I didn't find much in the way of specific points or actionable feedback in your comments. It seems rather that you disagree with the philosophy as a whole, or at least that you find the momentum of Github overwhelming. Would love to hear more of your specific concerns.

~sircmpwn a day ago

There's no preview or edit on issue/todo comments (like this one). Getting one's formatting right is hit-or-miss.

~sircmpwn/todo.sr.ht#134

Emailed issue updates look like crap in Gmail. I haven't checked in (say) mutt.

This is a bug with Gmail, they don't handle plaintext well. It will probably be improved with the addition of format=flowed support. Open area of research, I intend to work on this.

Related: I don't see how to get SH to send me a copy of my mailing list submission if I make it directly on the SH website.

Hm, I hadn't thought about this. It's a bit complicated. Let me ruminate on it for a bit.

SourceHut is poorly connected.

Scheduled to be addressed before the alpha is considered complete. We need to build this system up from first principles like this, with discrete components which can be freely composed, before this can be solved. Unfortunate side-effect is that navigating Sourcehut today can be kind of confusing.

I disagree with the basic assertion that plaintext is better.

Plaintext is better for email, but not for everything. Note that Sourcehut already supports Markdown for the tickets and wiki. Not sure why you called out either of them as bad applications of plaintext. For email, however, I remain a staunch opponent of rich emails as I laid out on useplaintext.email.

Related: Being more-or-less forced to use mutt instead of Gmail is annoying. SH should be able to pull out the text of a multi-part email. (Yes, Gmail has a plain text option, 'tis true. Which it then helpfully remembers for my next email to regular people. Which is also annoying.)

There are plenty of email clients which support plaintext, not just mutt. The best ones are listed here:

https://useplaintext.email/#recommended-clients

But more still have some degree of support, lined out in detail in the following section.

Forgive me for not being especially bothered by having poor support for the single greatest antagonist on the email scene, a proprietary, centralized email provider, which slurps up your private data and sells it to the highest bidder - literally. The only correct response to this kind of behavior is to steadfastly refuse to accomodate for it until they're forced to mend their behavior. Don't bow to agressors.

I find the conflation of a mailing list and a list of patches pretty irritating. I'd prefer they were more separated.

Many projects have separate discussion and dev mailing lists, which gio might consider.


Anyway, I think it bears reemphasising that I don't place much value in arguments based on the fact that a different way is more popular, and therefore must be better. Github is more popular, therefore the project should be moved there. Email is less popular, therefore it's worse. This stuff is nonsense - the best ideas always have to usurp the status quo, and that comes with friction. There's no way around it, if you want to improve things then you have to endure that friction. With Sourcehut the friction really isn't that great - setting up email only needs to be done once and you get used to it pretty quickly, imo.

~sircmpwn a day ago

(And, as an aside, what happens when Teh Spammers (almost) inevitably find the SH mailing lists?)

Note, they already have, we have spam prevention measures in place. Amusingly, 90% of spam is stopped dead by the fact that their shitty software can't handle ~ or / in email addresses.

~theclapp a day ago

(And, as an aside, what happens when Teh Spammers (almost) inevitably find the SH mailing lists?)

Note, they already have, we have spam prevention measures in place.

Good to know! (And thanks for the rest of your response, I'm still considering it.)

Amusingly, 90% of spam is stopped dead by the fact that their shitty software can't handle ~ or / in email addresses.

😆

Register here or Log in to comment, or comment via email.