5 ms·

Last time I checked, sr.ht was mostly an email based workflow, and many teams wanted an issue tracking system that is web based

ddevault 4y ago
SourceHut offers an email-based workflow with a web application built on top of it. You can file tickets via email, but you can also file tickets on the web: https://todo.sr.ht/~sircmpwn/hare https://todo.sr.ht/~sircmpwn/hare The same goes for patches. You can submit changes directly via email, but you can also use our web interface. We're also working on web-based tools for code review built on top of our mailing lists, which will provide a complete experience similar to GitHub's pull requests, but built on top of the decentralized, standardized protocol that git was designed for.
- hunterb123 4y ago
  Hello, kinda offtopic, but are there plans for ForgeFed / ActivityPub support? That really seems the best way to dethrone GitHub, as it's moat is mainly carved via a social network. The git repo is already decentralized, ForgeFed is a great way to integrate and decentralize the social part. In the future gitea, srht, and many other implementations could interact with each other's users.
  - ddevault 4y ago
    No, not at this time. I don't think that ActivityPub is the correct way to address this issue -- some people treat it like a golden hammer. SourceHut is already federated: via email. Email is a standardized, federated protocol with thousands of implementations and a global fault-tolerant system already working in production for decades, and it's the approach git was designed to use. I think this is a better solution. You can already use SourceHut's tooling to contribute to projects like Linux, which don't use any forge software at all, thanks to this standardization.
    - hunterb123 4y ago
      That's unfortunate. It's pretty difficult to run your own email server plus deal with the blacklisting. I see your points, but I also see a possibility to support both email and ActivityPub mediums. A lot of people want a dedicated interface, hence you having to make a web portal. I don't see why the web portal couldn't support ForgeFed in addition to email. Being able to bridge standalone gitea instances users with repos on your service would be a good step forward for federation.
      - ddevault 4y ago
        ForgeFed is just a protocol, just like email. The interfaces can be essentially identical. It's pretty difficult to host a fediverse server, too. I want to make SourceHut easier to self-host post-beta, including dealing with email bits, but I also don't think the dream of federation involves everyone running their own servers. One of the advantages of the federation model is that it strikes a balance between total centralization and total de-centralization in that it allows a talented sysadmin to provide services for a large number of users. There are more ways to federate than ActivityPub.
        hunterb123 4y ago
        Exactly my point. You could support both ActivityPub and email as protocols. I believe even commits could contain either address as it's a similar format. As far as hosting difficulty goes, once Gitea supports ForgeFed, you'd be able to spin up your own instance as easy as running one program, and no worries about blacklisting. I agree not everyone needs their own server, which is where shines sr.ht over Gitea, but a community developing a product sometimes wishes to run their own servers for their users. Sure they could run an email server, and users could use that, but it seems roundabout and outdated. I agree there's more than one way to federate, but the goal is bridging everyone together. Those two aren't mutually exclusive if you support both protocols.
        ddevault 4y ago
        Sorry, but I think we have to agree to disagree.
  - mariusor 4y ago
    I see Drew already weight in on this, but there were a number of debates between ActivityPub proponents (of which I am one, though not in the source forge space) and him regarding this, where he was very explicit that he's not interested. Over time I ended up coming more to his side, and I agree that SourceHut doesn't need any extra social interaction that ActivityPub might bring. That being said, the devs of Gitea are in the process of adding AP support, and it has been mentioned on HN already: https://news.ycombinator.com/item?id=31934758 https://news.ycombinator.com/item?id=31934758
    - hunterb123 4y ago
      I'm aware, part of my assertion was to bridge Gitea and Sourcehut projects together via AP, I go into detail in my other replies. I understand and support his decision, but I will be going with Gitea because I'd prefer AP networking over email. To each their own for sure, but my main suggestion was to support both so the communities aren't fragmented, that would be a bigger threat to Github's network effect. Oh well.
- BeetleB 4y ago
  Thanks Drew. I may have been mistaken, or perhaps you added those features after I tried them. I'll take another look.
yowmamasita 4y ago
Email is still the most robust communication medium. But I have also observed that it has also prevented emoji-only replies which is great.
- SnowHill9902 4y ago
  Standard but not robust. In fact it can silently fail.
  - ddevault 4y ago
    Email is very robust and does not fail silently -- unless you ignore the "undelivered returned to sender" emails you get. Mail servers are very fault tolerant, with essentially all implementations supporting an exponential backoff on failure. What's more, even if SourceHut is down, everyone in the Cc will still receive your emails, because they're routed around lists.sr.ht anyway. In the event of a lists.sr.ht outage, you might not even notice that we're down.
    - kelnos 4y ago
      Unfortunately some of the larger mail providers will "accept" mail they don't like, but then blackhole it. Yes, you can say "well, your intended recipients shouldn't use mail providers that do that", but in reality that's not our choice.
    - midenginedcoupe 4y ago
      That's unfortunately just not true. It does, and has, failed silently. I've had Google silently swallow emails before, both sending and receiving. It's not fun.
      - kcartlidge 4y ago
        You may be right generally, but for your specific example that's not email being rubbish it's Google being rubbish. Why not switch to a professional provider?
spoils19 4y ago
Then those teams are wrong considering email is more robust, efficient and overall a better tool for the job.
akudha 4y ago
That is why I said "wherever possible". If your team is going to quit their jobs (I doubt it) because they will only deal with a web based issue tracking, then sure, go for GitHub. The point I am trying to make here is - by default people spend their money with mega corps, because of brand awareness, convenience etc. Instead, it would be nice if the default is indie/small businesses. In other words instead of "the mega corps aren't working for me, let me look for smaller/indie options instead", it would be nice if we all did "smaller indie options don't fit my requirements, let me go with Microsoft/Apple/etc instead". Maybe this is too idealistic?
- billythemaniam 4y ago
  There is usually a reason those mega corporations became mega corporations. GitHub, in particular, is the easiest way to collaborate for most developers and they were the first one to get most things right. Absolutely vote with your wallet. If you want to support smaller companies, then do that. But realistically GitHub will be the default option until something comes along that is better. And whatever replaces Github has to be significantly better to justify the switching cost for majority of developers.
  - presentation 4y ago
    At such point it will probably become a large corporation that people will consider ethically challenged.
- BeetleB 4y ago
  > If your team is going to quit their jobs (I doubt it) because they will only deal with a web based issue tracking, then sure, go for GitHub. No but they will quit because an ideology most members of most teams was used to justify a decision that affected their work.
- nirui 4y ago
  Maybe also too optimistic as well. Let me start by telling you a story about me trying to buy clothes for the first time: Back then, I have no idea of branding and the symbolism behind, I don't even have the idea of quality. After many hours of browsing and comparing, I picked what I liked based on showcase pictures and user reviews, completely brand-blindly. A week later when they arrived, I quickly discovered that few of them are false advertisments, some of them are in the wrong size and one got damaged during shipping. And for the rest items that were "just right", half of them ripped/deformed after half-year of use. So, as a normal person would do, I created a table which consist of factors such as durability, price and styles etc to help me increase my "success rate". And after few years of iteration, that table ended up points me to just few brands that happens to be well-known and big. I eventually settled on those brands with membership cards etc, and now whenever I need new clothes, I open their store page. What I learned from my experience is that discovery itself generates cost, and the cost is nonrefundable. It is reasonable for an user to settle on a trusted brand. It's not brand loyalty, it's just rational decision making. For most users, choose GitHub is rational, because it's the most trusted platform out there, and it provides good services (including the infrastructures and socials). You already knew what to expect before you even sign on, that's the level of trust GitHub delivers. It's really hard to ask users to discover and move to the alternatives once their needs are well-fulfilled by the current one, even when the alternative provides the same level of service. What makes it even harder is that services such as BitBucket, GitLab, SourceHut, Gitea etc can't provide the same level of service that GitHub offers for free. At this circumstances, the megacorp such as GitHub will always win even when the user is pro-indies by default. But we are not completely dead in the water here. GitHub succeed because they created something new at the time, something better than what SourceForge offered. I assume if someone wants to beat GitHub, they need to do the same. Don't just create alternatives, create something new that also does old things better.

ddevault 4y ago

SourceHut offers an email-based workflow with a web application built on top of it. You can file tickets via email, but you can also file tickets on the web: https://todo.sr.ht/~sircmpwn/hare https://todo.sr.ht/~sircmpwn/hare The same goes for patches. You can submit changes directly via email, but you can also use our web interface. We're also working on web-based tools for code review built on top of our mailing lists, which will provide a complete experience similar to GitHub's pull requests, but built on top of the decentralized, standardized protocol that git was designed for.

hunterb123 4y ago
Hello, kinda offtopic, but are there plans for ForgeFed / ActivityPub support? That really seems the best way to dethrone GitHub, as it's moat is mainly carved via a social network. The git repo is already decentralized, ForgeFed is a great way to integrate and decentralize the social part. In the future gitea, srht, and many other implementations could interact with each other's users.
- ddevault 4y ago
  No, not at this time. I don't think that ActivityPub is the correct way to address this issue -- some people treat it like a golden hammer. SourceHut is already federated: via email. Email is a standardized, federated protocol with thousands of implementations and a global fault-tolerant system already working in production for decades, and it's the approach git was designed to use. I think this is a better solution. You can already use SourceHut's tooling to contribute to projects like Linux, which don't use any forge software at all, thanks to this standardization.
  - hunterb123 4y ago
    That's unfortunate. It's pretty difficult to run your own email server plus deal with the blacklisting. I see your points, but I also see a possibility to support both email and ActivityPub mediums. A lot of people want a dedicated interface, hence you having to make a web portal. I don't see why the web portal couldn't support ForgeFed in addition to email. Being able to bridge standalone gitea instances users with repos on your service would be a good step forward for federation.
    - ddevault 4y ago
      ForgeFed is just a protocol, just like email. The interfaces can be essentially identical. It's pretty difficult to host a fediverse server, too. I want to make SourceHut easier to self-host post-beta, including dealing with email bits, but I also don't think the dream of federation involves everyone running their own servers. One of the advantages of the federation model is that it strikes a balance between total centralization and total de-centralization in that it allows a talented sysadmin to provide services for a large number of users. There are more ways to federate than ActivityPub.
      - hunterb123 4y ago
        Exactly my point. You could support both ActivityPub and email as protocols. I believe even commits could contain either address as it's a similar format. As far as hosting difficulty goes, once Gitea supports ForgeFed, you'd be able to spin up your own instance as easy as running one program, and no worries about blacklisting. I agree not everyone needs their own server, which is where shines sr.ht over Gitea, but a community developing a product sometimes wishes to run their own servers for their users. Sure they could run an email server, and users could use that, but it seems roundabout and outdated. I agree there's more than one way to federate, but the goal is bridging everyone together. Those two aren't mutually exclusive if you support both protocols.
        ddevault 4y ago
        Sorry, but I think we have to agree to disagree.
- mariusor 4y ago
  I see Drew already weight in on this, but there were a number of debates between ActivityPub proponents (of which I am one, though not in the source forge space) and him regarding this, where he was very explicit that he's not interested. Over time I ended up coming more to his side, and I agree that SourceHut doesn't need any extra social interaction that ActivityPub might bring. That being said, the devs of Gitea are in the process of adding AP support, and it has been mentioned on HN already: https://news.ycombinator.com/item?id=31934758 https://news.ycombinator.com/item?id=31934758
  - hunterb123 4y ago
    I'm aware, part of my assertion was to bridge Gitea and Sourcehut projects together via AP, I go into detail in my other replies. I understand and support his decision, but I will be going with Gitea because I'd prefer AP networking over email. To each their own for sure, but my main suggestion was to support both so the communities aren't fragmented, that would be a bigger threat to Github's network effect. Oh well.
BeetleB 4y ago
Thanks Drew. I may have been mistaken, or perhaps you added those features after I tried them. I'll take another look.

yowmamasita 4y ago

Email is still the most robust communication medium. But I have also observed that it has also prevented emoji-only replies which is great.

SnowHill9902 4y ago
Standard but not robust. In fact it can silently fail.
- ddevault 4y ago
  Email is very robust and does not fail silently -- unless you ignore the "undelivered returned to sender" emails you get. Mail servers are very fault tolerant, with essentially all implementations supporting an exponential backoff on failure. What's more, even if SourceHut is down, everyone in the Cc will still receive your emails, because they're routed around lists.sr.ht anyway. In the event of a lists.sr.ht outage, you might not even notice that we're down.
  - kelnos 4y ago
    Unfortunately some of the larger mail providers will "accept" mail they don't like, but then blackhole it. Yes, you can say "well, your intended recipients shouldn't use mail providers that do that", but in reality that's not our choice.
  - midenginedcoupe 4y ago
    That's unfortunately just not true. It does, and has, failed silently. I've had Google silently swallow emails before, both sending and receiving. It's not fun.
    - kcartlidge 4y ago
      You may be right generally, but for your specific example that's not email being rubbish it's Google being rubbish. Why not switch to a professional provider?

spoils19 4y ago

Then those teams are wrong considering email is more robust, efficient and overall a better tool for the job.

akudha 4y ago

That is why I said "wherever possible". If your team is going to quit their jobs (I doubt it) because they will only deal with a web based issue tracking, then sure, go for GitHub. The point I am trying to make here is - by default people spend their money with mega corps, because of brand awareness, convenience etc. Instead, it would be nice if the default is indie/small businesses. In other words instead of "the mega corps aren't working for me, let me look for smaller/indie options instead", it would be nice if we all did "smaller indie options don't fit my requirements, let me go with Microsoft/Apple/etc instead". Maybe this is too idealistic?

billythemaniam 4y ago
There is usually a reason those mega corporations became mega corporations. GitHub, in particular, is the easiest way to collaborate for most developers and they were the first one to get most things right. Absolutely vote with your wallet. If you want to support smaller companies, then do that. But realistically GitHub will be the default option until something comes along that is better. And whatever replaces Github has to be significantly better to justify the switching cost for majority of developers.
- presentation 4y ago
  At such point it will probably become a large corporation that people will consider ethically challenged.
BeetleB 4y ago
> If your team is going to quit their jobs (I doubt it) because they will only deal with a web based issue tracking, then sure, go for GitHub. No but they will quit because an ideology most members of most teams was used to justify a decision that affected their work.
nirui 4y ago
Maybe also too optimistic as well. Let me start by telling you a story about me trying to buy clothes for the first time: Back then, I have no idea of branding and the symbolism behind, I don't even have the idea of quality. After many hours of browsing and comparing, I picked what I liked based on showcase pictures and user reviews, completely brand-blindly. A week later when they arrived, I quickly discovered that few of them are false advertisments, some of them are in the wrong size and one got damaged during shipping. And for the rest items that were "just right", half of them ripped/deformed after half-year of use. So, as a normal person would do, I created a table which consist of factors such as durability, price and styles etc to help me increase my "success rate". And after few years of iteration, that table ended up points me to just few brands that happens to be well-known and big. I eventually settled on those brands with membership cards etc, and now whenever I need new clothes, I open their store page. What I learned from my experience is that discovery itself generates cost, and the cost is nonrefundable. It is reasonable for an user to settle on a trusted brand. It's not brand loyalty, it's just rational decision making. For most users, choose GitHub is rational, because it's the most trusted platform out there, and it provides good services (including the infrastructures and socials). You already knew what to expect before you even sign on, that's the level of trust GitHub delivers. It's really hard to ask users to discover and move to the alternatives once their needs are well-fulfilled by the current one, even when the alternative provides the same level of service. What makes it even harder is that services such as BitBucket, GitLab, SourceHut, Gitea etc can't provide the same level of service that GitHub offers for free. At this circumstances, the megacorp such as GitHub will always win even when the user is pro-indies by default. But we are not completely dead in the water here. GitHub succeed because they created something new at the time, something better than what SourceForge offered. I assume if someone wants to beat GitHub, they need to do the same. Don't just create alternatives, create something new that also does old things better.