7 ms·

We kind of need this yesterday... what's the point of having a decentralized git if the issues are centralized at Github? (which, not to make too fine a point o

by dsign 6y ago

We kind of need this yesterday... what's the point of having a decentralized git if the issues are centralized at Github? (which, not to make too fine a point of it, is owned by Microsoft). Even if you host your own Gitlab, there is always that day when the hard drive of the server fails and the ops have to spend a weekend restoring backups while changing hosting company because who crashes the hard-drive of an expensive VPS anyway... I hope Radicle gets a lot of funding and tons of adoption.

fn1 6y ago
Can't you just serialize all issues into the repository and then write scripts/hooks to sync them in/out of textfiles in the repo?
- dm3 6y ago
  I know of an attempt to implement an approach to track issues and code in a decentralized manner with SIT[0]. Unfortunatlely the project seems to be dead. [0] https://github.com/sit-fyi https://github.com/sit-fyi
- m4rtink 6y ago
  Pagure does something like that: https://pagure.io/pagure https://pagure.io/pagure All the issues, wiki, PR review are stored in Git as well. You still need a Pagure instance (that you can self host if you want) to provide the web ui, but you can easily just clone the repo and put it to a different instance, keeping all your metadata.
- masklinn 6y ago
  This was attempted multiple times in the past. None succeeded, in large parts because at a fundamental level issues are a synchronisation point, making issues part of the repository adds overhead and complexity but doesn't really give you anything, and furthermore it increases complexity for reporters.
- hamaluik 6y ago
  I’ve used git-bug[1] successfully in the past for something similar but more ergonomic. 1: https://github.com/MichaelMure/git-bug https://github.com/MichaelMure/git-bug
Frost1x 6y ago
I always find it comically ironic how the industry basically centralized a version management system (git) that was inherently designed to be decentralized. "Git is so great! Let's add these higher level project management features but let's do it in a centralized model!"
- neurobashing 6y ago
  the industry aggressively seeks centralization. One browser always ends up taking huge amounts of market share. A small number of sites end up being hubs for large amounts of activity. We then spend forever trying to put the toothpaste back in the tube - federated social networks and chat, stuff like this.
- ehejsbbejsk 6y ago
  Physical infrastructure itself needs to be federal. I believe that’s the most economical solution. But it could be virtually decentralized.
- dangoor 6y ago
  I think the centralization comes from convenience. Building a good, decentralized UX is a lot harder than making a centralized one (evidence: almost every attempt at P2P networks.)
- mistercow 6y ago
  I don't think that's any more ironic than it is to point out that LLVM is backend agnostic, yet we always end up hooking it up to backends that lock the end result to a specific architecture. It's not ironic; it's the advantage of the design. In git's case, its decentralized nature ends up being an advantage because it decouples centralization from the VCS itself, which has allowed the centralized aspects of code and project management to evolve independently and be tuned to specific use cases.
bob1029 6y ago
We use Github and we are not that interested in the decentralized aspects of git itself. The low-friction UX and integration of issues/PRs/code makes it lightyears easier to ramp new developers than if I had to sit down and also explain Jira & Jenkins to them. The fact that git is centralized or decentralized crosses our minds precisely zero times per week. In the absolute worst case where Microsoft somehow loses everyones' issue/PR/project data (assuming non-enterprise cloud hosted account), we could still rebuild with whoever has the latest master copy on their local. Presumably, one of our developers must have made the latest commit so this should work out always. We have a process where we include the issue numbers in our commits, so it would be possible to reconstruct a large portion of these with inference across commit history. Personally, I trust Microsoft to safeguard our business data more than I trust our 7 person team w/ a $2000/m AWS budget. Ultimately, I think the objective of making all things around your source control technology look & talk like your source control technology is a huge mistake. Issues and code are completely orthogonal things that intersect in very narrow ways. These intersections are hugely valuable, but we are not interested in aligning the planes of functionality.
- p5a0u9l 6y ago
  this is naïve. the problems being addressed do exist, independent of whether this particular solution will work. that’s great that the status quo is working for you, but it’s silly to then assert that progress cannot be made.
  - bob1029 6y ago
    Well maybe our "naive" approach might be worth investigating. Because we put so little time into ridiculous missions like "distributed issues because git is also distributed", we are able to focus more on the product, customers, and processes. You know, things that actually drive business value and pay out everyones' bonus checks at the end of the year. We have actually considered doing a complete in-house implementation of the things that GitHub handles, because we do already have an in-house management system that integrates with GitHub's API. But, we realized that we would then be in the business of maintaining what is effectively the GitHub product for a market size of 1 customer.

by dsign 6y ago

fn1 6y ago

Can't you just serialize all issues into the repository and then write scripts/hooks to sync them in/out of textfiles in the repo?

dm3 6y ago
I know of an attempt to implement an approach to track issues and code in a decentralized manner with SIT[0]. Unfortunatlely the project seems to be dead. [0] https://github.com/sit-fyi https://github.com/sit-fyi
m4rtink 6y ago
Pagure does something like that: https://pagure.io/pagure https://pagure.io/pagure All the issues, wiki, PR review are stored in Git as well. You still need a Pagure instance (that you can self host if you want) to provide the web ui, but you can easily just clone the repo and put it to a different instance, keeping all your metadata.
masklinn 6y ago
This was attempted multiple times in the past. None succeeded, in large parts because at a fundamental level issues are a synchronisation point, making issues part of the repository adds overhead and complexity but doesn't really give you anything, and furthermore it increases complexity for reporters.
hamaluik 6y ago
I’ve used git-bug[1] successfully in the past for something similar but more ergonomic. 1: https://github.com/MichaelMure/git-bug https://github.com/MichaelMure/git-bug

Frost1x 6y ago

I always find it comically ironic how the industry basically centralized a version management system (git) that was inherently designed to be decentralized. "Git is so great! Let's add these higher level project management features but let's do it in a centralized model!"

neurobashing 6y ago
the industry aggressively seeks centralization. One browser always ends up taking huge amounts of market share. A small number of sites end up being hubs for large amounts of activity. We then spend forever trying to put the toothpaste back in the tube - federated social networks and chat, stuff like this.
ehejsbbejsk 6y ago
Physical infrastructure itself needs to be federal. I believe that’s the most economical solution. But it could be virtually decentralized.
dangoor 6y ago
I think the centralization comes from convenience. Building a good, decentralized UX is a lot harder than making a centralized one (evidence: almost every attempt at P2P networks.)
mistercow 6y ago
I don't think that's any more ironic than it is to point out that LLVM is backend agnostic, yet we always end up hooking it up to backends that lock the end result to a specific architecture. It's not ironic; it's the advantage of the design. In git's case, its decentralized nature ends up being an advantage because it decouples centralization from the VCS itself, which has allowed the centralized aspects of code and project management to evolve independently and be tuned to specific use cases.

bob1029 6y ago

We use Github and we are not that interested in the decentralized aspects of git itself. The low-friction UX and integration of issues/PRs/code makes it lightyears easier to ramp new developers than if I had to sit down and also explain Jira & Jenkins to them. The fact that git is centralized or decentralized crosses our minds precisely zero times per week. In the absolute worst case where Microsoft somehow loses everyones' issue/PR/project data (assuming non-enterprise cloud hosted account), we could still rebuild with whoever has the latest master copy on their local. Presumably, one of our developers must have made the latest commit so this should work out always. We have a process where we include the issue numbers in our commits, so it would be possible to reconstruct a large portion of these with inference across commit history. Personally, I trust Microsoft to safeguard our business data more than I trust our 7 person team w/ a $2000/m AWS budget. Ultimately, I think the objective of making all things around your source control technology look & talk like your source control technology is a huge mistake. Issues and code are completely orthogonal things that intersect in very narrow ways. These intersections are hugely valuable, but we are not interested in aligning the planes of functionality.

p5a0u9l 6y ago
this is naïve. the problems being addressed do exist, independent of whether this particular solution will work. that’s great that the status quo is working for you, but it’s silly to then assert that progress cannot be made.
- bob1029 6y ago
  Well maybe our "naive" approach might be worth investigating. Because we put so little time into ridiculous missions like "distributed issues because git is also distributed", we are able to focus more on the product, customers, and processes. You know, things that actually drive business value and pay out everyones' bonus checks at the end of the year. We have actually considered doing a complete in-house implementation of the things that GitHub handles, because we do already have an in-house management system that integrates with GitHub's API. But, we realized that we would then be in the business of maintaining what is effectively the GitHub product for a market size of 1 customer.