4 ms·

http://sit-it.org/ http://sit-it.org/ > Of course it is debatable how "serious" these attempts ever have been. I doubt things like this will really gain tract

by pknopf 9y ago

http://sit-it.org/ http://sit-it.org/ > Of course it is debatable how "serious" these attempts ever have been. I doubt things like this will really gain traction. I mean, you could always host your own GitLab instance for free if you are worried about GitHub ever going down. The ergonomics are terrible. For me to submit a bug, are you really telling me that I need to fork a repository, commit my issue and then submit a pull-request? Ughh, pass...

db48x 9y ago
Most in-repository bug trackers have (or plan to have) a way to get bug reports committed to the repository automatically, usually via email or a web site.
- pknopf 9y ago
  So now your decentralized solution requires a server running somewhere. Why not just install GitLab or Bugzilla on that server? This reminds me of something someone (forgot who) said, "If it can be built with JavaScript, for better or for worse, it will be." I think the same thing applies blockchain and edge-computing.
  - db48x 9y ago
    For the same reason that you could use cvs or svn, but choose to use git: if the bug database is part of the source-code repository (or is checked into the repository, which is much the same thing), then it goes with you when you're offline. You might be riding a train through the Rockies, but you can still add new bug reports, and mark existing ones fixed, as part of your normal work and then push those commits to the server when the train stops in Denver. You probably still have a server holding a copy of the repository that you can push your commits to simply because it simplifies the logistics. Likewise you would want a server hosting a web view of the bug database, because it simplifies the logistics. Think of the layers of management who you would have to teach git commands to, or the QA department who were still using spreadsheets a few years ago.
    - pknopf 9y ago
      > You might be riding a train through the Rockies, but you can still add new bug reports So, you want to loose-out on the many benefits of having <best-in-class> issue system because of that one time you decide to dev on a moving train? Open up notepad, man. Your next stop is only a few hours away.
      - db48x 9y ago
        In principle there is nothing that you would lose out on. Of course in practice there are several existing bug trackers that have had years or decades of work put into them and therefore have a huge checklist of features. I'll grant you that I've never seen a distributed bug-tracking system with a similarly long checklist. BTW, this is the same argument that people used to use against distributed version control. Why give up this long feature checklist to get a version control system that works on the train? Because even when you are connected to the internet, every time you wait on a server is time you'll never get back. Even if it's only a hundred milliseconds, your life is too short.
        pknopf 9y ago
        > BTW, this is the same argument that people used to use against distributed version control. Maybe people do, but it's Apple's and organges. Modifying files locally is the nature of software development. Switching from SVN to git didn't change the actual developer workflow of "make changes and commit", which is just not how issues are dealt with in reality. Also, what about authentication for the web front-end? Are you going to have a database to manage users? Every use case of a distributed issue tracker just seems to go against the grain. A better approach would be to build a traditional issue tracker (centralized) that has the ability to use git internally as a database engine for issues only (not users, settings, etc). Commit author names/emails are linked to actual user accounts and users could optionally clone the issues repository, use a cli-tool and push it back up to the server. This would be to issue trackers what GitHub/GitLab is to repositories.
        db48x 9y ago

by pknopf 9y ago

db48x 9y ago

Most in-repository bug trackers have (or plan to have) a way to get bug reports committed to the repository automatically, usually via email or a web site.

pknopf 9y ago
So now your decentralized solution requires a server running somewhere. Why not just install GitLab or Bugzilla on that server? This reminds me of something someone (forgot who) said, "If it can be built with JavaScript, for better or for worse, it will be." I think the same thing applies blockchain and edge-computing.
- db48x 9y ago
  For the same reason that you could use cvs or svn, but choose to use git: if the bug database is part of the source-code repository (or is checked into the repository, which is much the same thing), then it goes with you when you're offline. You might be riding a train through the Rockies, but you can still add new bug reports, and mark existing ones fixed, as part of your normal work and then push those commits to the server when the train stops in Denver. You probably still have a server holding a copy of the repository that you can push your commits to simply because it simplifies the logistics. Likewise you would want a server hosting a web view of the bug database, because it simplifies the logistics. Think of the layers of management who you would have to teach git commands to, or the QA department who were still using spreadsheets a few years ago.
  - pknopf 9y ago
    > You might be riding a train through the Rockies, but you can still add new bug reports So, you want to loose-out on the many benefits of having <best-in-class> issue system because of that one time you decide to dev on a moving train? Open up notepad, man. Your next stop is only a few hours away.
    - db48x 9y ago
      In principle there is nothing that you would lose out on. Of course in practice there are several existing bug trackers that have had years or decades of work put into them and therefore have a huge checklist of features. I'll grant you that I've never seen a distributed bug-tracking system with a similarly long checklist. BTW, this is the same argument that people used to use against distributed version control. Why give up this long feature checklist to get a version control system that works on the train? Because even when you are connected to the internet, every time you wait on a server is time you'll never get back. Even if it's only a hundred milliseconds, your life is too short.
      - pknopf 9y ago
        > BTW, this is the same argument that people used to use against distributed version control. Maybe people do, but it's Apple's and organges. Modifying files locally is the nature of software development. Switching from SVN to git didn't change the actual developer workflow of "make changes and commit", which is just not how issues are dealt with in reality. Also, what about authentication for the web front-end? Are you going to have a database to manage users? Every use case of a distributed issue tracker just seems to go against the grain. A better approach would be to build a traditional issue tracker (centralized) that has the ability to use git internally as a database engine for issues only (not users, settings, etc). Commit author names/emails are linked to actual user accounts and users could optionally clone the issues repository, use a cli-tool and push it back up to the server. This would be to issue trackers what GitHub/GitLab is to repositories.
        db48x 9y ago