4 ms·

There was a small surge in popularity in distributed git issue trackers a bit over a decade ago, and all of them had some sort of problem baked in to the design

by Izkata 5mo ago

There was a small surge in popularity in distributed git issue trackers a bit over a decade ago, and all of them had some sort of problem baked in to the design that made them not very good. Two weeks ago I had listed out the problems I could remember offhand: https://news.ycombinator.com/item?id=47956979 https://news.ycombinator.com/item?id=47956979 It sounds like there's intentionally no attempt to handle the last one (that this is by devs for devs), and points 3 and 4 might be addressed somehow since it mentions syncing automatically. Does it store data separate from git to avoid the first two?

jolaflow 5mo ago
Thanks for input. Interesting list. A few notes on that: - Issue state is not tied to commits in the checked out repo. Events live in append-only user-scoped logs and are materialized independently of the checked out branch, so switching branches does not change issue state. This is solved with git worktrees. - Epiq keeps state in a dedicated state branch and does not put issue data into normal code history. The working branch stays clean. - Sync uses normal git push/pull semantics. - Multi-user conflicts are prevented because each user writes only to their own immutable event log file. You never co edit a file. Logs converge state in memory from the combined event stream. There’s no shared mutable issue document being edited. - The non-developer distribution can be addressed with exported state .md files (with the board as ascii). They are currently not generated automatically, but you can generate them at will. [edit - addition: Considerable effort has also been put into making the tool accessible to non-technical people, so there is auto completion, hints, a command palette with descriptions of each command, arrow key navigation and so on. It is my hope that anyone can pick it up rapidly. And a web interface could definitely be crafted for that usecase]
- cxr 5mo ago
  You don't need to put it on the Web to be able to leverage the World Wide Wruntime. Epiq looks to be written in TypeScript and distributed as JS via NPM. You know what excels at executing JS? The browser. If you want to actually address the usability problems—then create a CONTRIBUTING.html—linked from the README, that users are instructed to double-click to open (i.e. launch in the browser on any sanely configured system). From there, they can/should be able to load the project either by pointing to it with a filepicker-based workflow that's the same as VSCode's "Open Folder…" workflow, or by dragging and dropping the source tree into the browser window. If you do it right, then this should immediately present them with a browser-based UI for poring over and interacting with all the Epiq data in the repo—down to the Git commands to execute to integrate changes into the Epiq "database". It's beyond baffling that so many programmers who are nominally JS developers thumb their noses at writing standards-compliant code and instead insist on coding directly against Node's proprietary APIs.
  - locknitpicker 5mo ago
    > It's beyond baffling that so many programmers who are nominally JS developers thumb their noses at writing standards-compliant code and instead insist on coding directly against Node's proprietary APIs. You're talking about node.js projects running on node.js, and you're complaining that it consumes node.js APIs. Strange.
    - cxr 5mo ago
      There is no argument or insight in your comment. It's physically possible to type in code that makes direct use of non-standard APIs that work in NodeJS but not the browser. Pointing out that this is so and that there are people who do it is not the same as engaging with the subject of whether they ought not to—which was the point of the remarks you responded to. Previously: > You're offering a retort to someone who is communicating their position that you ought not do something, where the retort consists of nothing more than explaining that people are doing it. Yes, clearly. But what the person you're responding to is arguing is that you ought not do it.¶ Consider[…]: > Person A: Here's little advice: don't take up smoking. Smoking is bad for you. > Person B: Yet people smoke <https://news.ycombinator.com/item?id=38712699 https://news.ycombinator.com/item?id=38712699>
      - locknitpicker 5mo ago
        [flagged]
        deleted 5mo ago
        [deleted]
        deleted 5mo ago
        [deleted]
        cxr 5mo ago
        I am one of ~3 people primarily responsible for the JS Reference as it appeared/appears on developer.mozilla.org since before NodeJS (or V8) ever existed. I "know what JavaScript is".
tim-projects 5mo ago
I am writing a tool with git tracking. Here's how I tackled these. I store the issues in a work tree inside the git repo called .tasks This work tree is not included as part of the standard repo Then I have two commands, a save and restore. These commands create a remote branch inside the git repo called tasks and updates it with the contents of the .tasks work tree. This remote branch only contains tasks no normal code. Restore takes the contents of the remote branch and downloads it back to the locally created .tasks work tree Save and restore are manual processes, but the tool I wrote triggers a save whenever a merge to main occurs.
deleted 5mo ago
[deleted]
crabbone 5mo ago
Out of things listed there, I see some as positives rather than negatives, but, specifically, wanted to reflect on: > No non-developer UI for project managers to see or comment on issues. Strategically, I'd prefer this over anything that offers non-developer UI. My experience with any tool that offers non-developer UI for developer-related activities was overall infuriatingly negative (think Jenkins, JIRA, Github and the likes etc.) Because these UIs will usually expose the underlying functionality in a bad way that will create pathologically bad practices that will require the developers to accommodate the lowest common denominator. Here's one example: Github or GitLab PR management interface. Before this became "standard practice", PRs used to be deal with from the interface to Git chosen by the developer. It allowed more freedom of editing and communication, but, most importantly, it didn't lock the developers into a few selected choices of reconciling the new changes with the existing code. GitLab, for example, doesn't even offer the only good way to do that: there's no way, using GitLab interface to rebase the suggested changes on the target branch. All the options it offers in UI are wrong. And yet, companies, like the one I work for, make it a corporate policy to work exclusively through this garbage UI because they make their OPs / IT teams design workflows around it. As an aside: if a project manager cannot use Git, they shouldn't be a project manager. There are some job requirements that one must meet in order to hold a job, and using the most popular VCS should be one of them. This is just as true as it is true for developers: if they don't know / can't use Git, they shouldn't be in that role. The manager's ineptitude shouldn't be an excuse to make / adopt cruddy software.
captn3m0 5mo ago
Isn’t splitting code and meta into two repos the same solution here? Like how GitHub tracks your Wiki in a separate repo (which you could repurpose for your issues, even).
- Izkata 5mo ago
  The ones in those first two bullets made issues part of the repo so you'd clone/push/pull updates automatically with the normal git commands. They were trying to reduce friction with usage: Fewer new commands to remember/use, local data so the commands were instant like "git commit" or "git show" are, and automatic syncing but only when the user was already doing it so there wouldn't be unexpected hangs if the remote was inaccessible for some reason. Putting them in the same repo also meant since they came along with every normal git clone, every repo had a copy regardless of if a specific user had the tool or not, so switching between hosts would never be an issue and would automatically be supported without having to update however the two repos were linked. The one that tied issues to specific commits I think even portrayed the different-states-in-different-branches as a feature, that for example you could easily tell at a glance whether a bug had been fixed on the branch you're on or not. This was also the era when people were figuring out complex branching strategies like gitflow, where that would be a reasonable thing to be uncertain of. Like I said the problems were part of the design, not incidental, the tradeoffs just ended up not what people wanted. Also something else I didn't mention before, all of these were command-line, not TUI. I have no idea how that would've changed the result. For example I could imagine automatic background syncing actually being reasonable, sidestepping some of the issues the command-line ones had to work around.

by Izkata 5mo ago

jolaflow 5mo ago

Thanks for input. Interesting list. A few notes on that: - Issue state is not tied to commits in the checked out repo. Events live in append-only user-scoped logs and are materialized independently of the checked out branch, so switching branches does not change issue state. This is solved with git worktrees. - Epiq keeps state in a dedicated state branch and does not put issue data into normal code history. The working branch stays clean. - Sync uses normal git push/pull semantics. - Multi-user conflicts are prevented because each user writes only to their own immutable event log file. You never co edit a file. Logs converge state in memory from the combined event stream. There’s no shared mutable issue document being edited. - The non-developer distribution can be addressed with exported state .md files (with the board as ascii). They are currently not generated automatically, but you can generate them at will. [edit - addition: Considerable effort has also been put into making the tool accessible to non-technical people, so there is auto completion, hints, a command palette with descriptions of each command, arrow key navigation and so on. It is my hope that anyone can pick it up rapidly. And a web interface could definitely be crafted for that usecase]

cxr 5mo ago
You don't need to put it on the Web to be able to leverage the World Wide Wruntime. Epiq looks to be written in TypeScript and distributed as JS via NPM. You know what excels at executing JS? The browser. If you want to actually address the usability problems—then create a CONTRIBUTING.html—linked from the README, that users are instructed to double-click to open (i.e. launch in the browser on any sanely configured system). From there, they can/should be able to load the project either by pointing to it with a filepicker-based workflow that's the same as VSCode's "Open Folder…" workflow, or by dragging and dropping the source tree into the browser window. If you do it right, then this should immediately present them with a browser-based UI for poring over and interacting with all the Epiq data in the repo—down to the Git commands to execute to integrate changes into the Epiq "database". It's beyond baffling that so many programmers who are nominally JS developers thumb their noses at writing standards-compliant code and instead insist on coding directly against Node's proprietary APIs.
- locknitpicker 5mo ago
  > It's beyond baffling that so many programmers who are nominally JS developers thumb their noses at writing standards-compliant code and instead insist on coding directly against Node's proprietary APIs. You're talking about node.js projects running on node.js, and you're complaining that it consumes node.js APIs. Strange.
  - cxr 5mo ago
    There is no argument or insight in your comment. It's physically possible to type in code that makes direct use of non-standard APIs that work in NodeJS but not the browser. Pointing out that this is so and that there are people who do it is not the same as engaging with the subject of whether they ought not to—which was the point of the remarks you responded to. Previously: > You're offering a retort to someone who is communicating their position that you ought not do something, where the retort consists of nothing more than explaining that people are doing it. Yes, clearly. But what the person you're responding to is arguing is that you ought not do it.¶ Consider[…]: > Person A: Here's little advice: don't take up smoking. Smoking is bad for you. > Person B: Yet people smoke <https://news.ycombinator.com/item?id=38712699 https://news.ycombinator.com/item?id=38712699>
    - locknitpicker 5mo ago
      [flagged]
      - deleted 5mo ago
        [deleted]
      - deleted 5mo ago
        [deleted]
      - cxr 5mo ago
        I am one of ~3 people primarily responsible for the JS Reference as it appeared/appears on developer.mozilla.org since before NodeJS (or V8) ever existed. I "know what JavaScript is".

tim-projects 5mo ago

I am writing a tool with git tracking. Here's how I tackled these. I store the issues in a work tree inside the git repo called .tasks This work tree is not included as part of the standard repo Then I have two commands, a save and restore. These commands create a remote branch inside the git repo called tasks and updates it with the contents of the .tasks work tree. This remote branch only contains tasks no normal code. Restore takes the contents of the remote branch and downloads it back to the locally created .tasks work tree Save and restore are manual processes, but the tool I wrote triggers a save whenever a merge to main occurs.

deleted 5mo ago

[deleted]

crabbone 5mo ago

Out of things listed there, I see some as positives rather than negatives, but, specifically, wanted to reflect on: > No non-developer UI for project managers to see or comment on issues. Strategically, I'd prefer this over anything that offers non-developer UI. My experience with any tool that offers non-developer UI for developer-related activities was overall infuriatingly negative (think Jenkins, JIRA, Github and the likes etc.) Because these UIs will usually expose the underlying functionality in a bad way that will create pathologically bad practices that will require the developers to accommodate the lowest common denominator. Here's one example: Github or GitLab PR management interface. Before this became "standard practice", PRs used to be deal with from the interface to Git chosen by the developer. It allowed more freedom of editing and communication, but, most importantly, it didn't lock the developers into a few selected choices of reconciling the new changes with the existing code. GitLab, for example, doesn't even offer the only good way to do that: there's no way, using GitLab interface to rebase the suggested changes on the target branch. All the options it offers in UI are wrong. And yet, companies, like the one I work for, make it a corporate policy to work exclusively through this garbage UI because they make their OPs / IT teams design workflows around it. As an aside: if a project manager cannot use Git, they shouldn't be a project manager. There are some job requirements that one must meet in order to hold a job, and using the most popular VCS should be one of them. This is just as true as it is true for developers: if they don't know / can't use Git, they shouldn't be in that role. The manager's ineptitude shouldn't be an excuse to make / adopt cruddy software.

captn3m0 5mo ago

Isn’t splitting code and meta into two repos the same solution here? Like how GitHub tracks your Wiki in a separate repo (which you could repurpose for your issues, even).

Izkata 5mo ago
The ones in those first two bullets made issues part of the repo so you'd clone/push/pull updates automatically with the normal git commands. They were trying to reduce friction with usage: Fewer new commands to remember/use, local data so the commands were instant like "git commit" or "git show" are, and automatic syncing but only when the user was already doing it so there wouldn't be unexpected hangs if the remote was inaccessible for some reason. Putting them in the same repo also meant since they came along with every normal git clone, every repo had a copy regardless of if a specific user had the tool or not, so switching between hosts would never be an issue and would automatically be supported without having to update however the two repos were linked. The one that tied issues to specific commits I think even portrayed the different-states-in-different-branches as a feature, that for example you could easily tell at a glance whether a bug had been fixed on the branch you're on or not. This was also the era when people were figuring out complex branching strategies like gitflow, where that would be a reasonable thing to be uncertain of. Like I said the problems were part of the design, not incidental, the tradeoffs just ended up not what people wanted. Also something else I didn't mention before, all of these were command-line, not TUI. I have no idea how that would've changed the result. For example I could imagine automatic background syncing actually being reasonable, sidestepping some of the issues the command-line ones had to work around.