4 ms·

Now - if we can get Issues doing the same thing by building on top of something like YABT or some other text-based approach to issue tracking, that'll be awesom

Now - if we can get Issues doing the same thing by building on top of something like YABT or some other text-based approach to issue tracking, that'll be awesome.

simonw 16y ago
Definitely. Not having offline access to issues is the only reason I don't use GitHub as my sole issue tracker.
mojombo 16y ago
Where's the Readme? It's hard to tell if the YABT approach has any merit without any documentation.
- tswicegood 16y ago
  I'll try to address that over the weekend. YABT was my original foray into Python, so it's pretty week right now and never really developed into much more than a proof of concept.
avar 16y ago
Yeah, or Emacs's org-mode format. That'd work very well as a machine readable text-based bug and tasklist format.
technoweenie 16y ago
That would rock. Scott hacked on http://github.com/schacon/ticgit http://github.com/schacon/ticgit for a while. I'm not totally sure what happened to that. We're all in favor of a git-backed issue tracker. Though, I think it offers some challenges in filtering, labeling, etc from a git repo.
- tswicegood 16y ago
  YABT popped up shortly after ticgit -- same type of thing. Scratched and itch to try something, then let it fall off. I'm going to revisit it and see where it stands though. I'd love to get it to where it serves as the backend for GitHub Issues. One of the reasons I wrote it instead of extending ticgit was that I wanted something entirely independent of any VCS. All stuff I need to get in a readme, though. :-)
  - technoweenie 16y ago
    I worked on ticgit a little too. It's such a neat idea, but I'm not sure how it would work in practice. I think git repos would be best for syncing, but not the main data store on GitHub. I'm curious about using CouchDB, actually. It has similar versioning and replication features to git.
    - fortes 16y ago
      Have you looked at ditz? http://ditz.rubyforge.org/ http://ditz.rubyforge.org/
      - technoweenie 16y ago
        Yup, I tried using it and ticgit for a little while. Didn't really care for either of them.
      - tswicegood 16y ago
        Yup - I tried a half dozen while thinking about starting YABT. None of them seemed to fit the bill just right.
    - tswicegood 16y ago
      If the storage API inside the project is good enough (something YABT's isn't yet), swapping out where it gets the data is a minor issue. You could use Git for the main storage, then have a web frontend that reads from Couch/Mongo/Redis/NewHotnessNotYetDiscovered and lazy loads from disk. A post-receive hook or two for expiring data in that cache and you're set.
lars512 16y ago
+1 for distributed issue tracking. I'm a BitBucket user, where the wiki has been Mercurial-backed for some time now, but I'd like both sites to go distributed on their issue tracking. Then you'd get complete portability on any project. I looked at Fossil for this reason (distibuted src/wiki/issues), but wasn't convinced that it was a real Mercurial or Git replacement for source control, so I gave up for now. Maybe something like Bugs Everywhere will do the trick.

Now - if we can get Issues doing the same thing by building on top of something like YABT or some other text-based approach to issue tracking, that'll be awesome.

simonw 16y ago

Definitely. Not having offline access to issues is the only reason I don't use GitHub as my sole issue tracker.

mojombo 16y ago

Where's the Readme? It's hard to tell if the YABT approach has any merit without any documentation.

tswicegood 16y ago
I'll try to address that over the weekend. YABT was my original foray into Python, so it's pretty week right now and never really developed into much more than a proof of concept.

avar 16y ago

Yeah, or Emacs's org-mode format. That'd work very well as a machine readable text-based bug and tasklist format.

technoweenie 16y ago

That would rock. Scott hacked on http://github.com/schacon/ticgit http://github.com/schacon/ticgit for a while. I'm not totally sure what happened to that. We're all in favor of a git-backed issue tracker. Though, I think it offers some challenges in filtering, labeling, etc from a git repo.

tswicegood 16y ago
YABT popped up shortly after ticgit -- same type of thing. Scratched and itch to try something, then let it fall off. I'm going to revisit it and see where it stands though. I'd love to get it to where it serves as the backend for GitHub Issues. One of the reasons I wrote it instead of extending ticgit was that I wanted something entirely independent of any VCS. All stuff I need to get in a readme, though. :-)
- technoweenie 16y ago
  I worked on ticgit a little too. It's such a neat idea, but I'm not sure how it would work in practice. I think git repos would be best for syncing, but not the main data store on GitHub. I'm curious about using CouchDB, actually. It has similar versioning and replication features to git.
  - fortes 16y ago
    Have you looked at ditz? http://ditz.rubyforge.org/ http://ditz.rubyforge.org/
    - technoweenie 16y ago
      Yup, I tried using it and ticgit for a little while. Didn't really care for either of them.
    - tswicegood 16y ago
      Yup - I tried a half dozen while thinking about starting YABT. None of them seemed to fit the bill just right.
  - tswicegood 16y ago
    If the storage API inside the project is good enough (something YABT's isn't yet), swapping out where it gets the data is a minor issue. You could use Git for the main storage, then have a web frontend that reads from Couch/Mongo/Redis/NewHotnessNotYetDiscovered and lazy loads from disk. A post-receive hook or two for expiring data in that cache and you're set.

lars512 16y ago

+1 for distributed issue tracking. I'm a BitBucket user, where the wiki has been Mercurial-backed for some time now, but I'd like both sites to go distributed on their issue tracking. Then you'd get complete portability on any project. I looked at Fossil for this reason (distibuted src/wiki/issues), but wasn't convinced that it was a real Mercurial or Git replacement for source control, so I gave up for now. Maybe something like Bugs Everywhere will do the trick.