3 ms·
> 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-clas
by 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 agoIn 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.