Comment by monkmartinez

10 years ago

I am not Michael Bayer (but I hope to be more like him someday)... that said, what I think he means or could mean is that issues would be distributed along with the repo. Maybe something like a git log for issues that are attached to and/or part of the repo itself.

Thinking about it, something like this would be sweet. I would immediately have a snap shot of things that might go boom when I run said software. eta: Instead, I have to go dig through github itself, which is slow compared to greping through a git log.

6 comments

monkmartinez

Reply
mintplant  10 years ago

You've described Fossil.

http://fossil-scm.org/index.html/doc/trunk/www/index.wiki

  • zzzeek  10 years ago

    yes, fossil, you need to get me past this:

    http://fossil-scm.org/index.html/dir?ci=acbee54e8ba8a3bd&nam...

    I'm talking about a portable issue tracker format that ideally uses something like git as its transport (but note: this does not mean that the issue database would travel along with the application's source code! That might be nice as an option but not by design). command-line and web-based front ends can then refer to it. Fossil, OTOH, looks like a huge monolithic web application / version control system / issue tracker / kitchen sink written in very hard-coded C.

    Looking through some docs, Fossil is anti-git and it claims its own DVCS is a great improvement over git: http://fossil-scm.org/index.html/doc/trunk/www/quotes.wiki. Because Fossil has every possible feature packed all into one monolithic executable, rather than relying upon existing systems like diff, patch, etc. this means Fossil is "the opposite of bloat": http://fossil-scm.org/index.html/doc/trunk/www/qandc.wiki (in fact that is the opposite of the opposite of bloat....)

zanny  10 years ago

Problem is for that system you need per-user authentication mechanisms to verify the interacting party in a bug report. If you can't do that, people can impersonate project members and you're going to have a bad time. Centralized issue tracking is not winning because of implementation details, its winning because you need some central authority to verify people are real and who they say they are.

You would have to sign off every message in a git log tree with a personally authenticated gpg key that can be found in a public keyserver everyone trusts.

  • zzzeek  10 years ago

    All of those issues would apply to DVCS as well, I can clone any project and commit whatever crap I want to it, I just can't push to the main repo of the project.

    Distributed issue tracking would use a similar pull model, but in reality wouldn't normally need people to be "cloning" it or anything like that; more realistically, a project would have just one place that is the "official" bug tracker just like they do a git repo now. But with "distributed", you can now have read-only mirrors of it elsewhere, you can have alternative GUIs that can push to the "official" repo as long as you have an account on that "official" host (which may as well be github), etc. It's not as important that it's truly "distributed", more that this is a set of issues that as a body of information about a project can and does live in many places, just like the version control does, just like the mailing list does, just like the IRC logs do. Right now issue tracking is like none of these other things.