5 ms·

I want the opposite - tickets-as-code as part of the git repo. Something like SIT[1]. Fossil has it, but today's standard DVCS is git. There are 2 trends here:

I want the opposite - tickets-as-code as part of the git repo. Something like SIT[1]. Fossil has it, but today's standard DVCS is git. There are 2 trends here: 1. Everything-as-a-code stored in the git repo in a text format close to the actual source code. If you store documention-as-a-code, diagrams-as-a-code, IaaC, tests-as-a-code, loadtesting-as-a-code, etc. - then why not issues/tickets as a code also? 2. Reduce number of tools/services/mechanisms you use in order to eliminate impedance mismatch, simplify workflows, and remove barriers to collaboration. For example if you standardize on Github, then you can use Guthub Issues, Projects, Packages, Actions, Codespaces, etc. And most developers are already having Github a/c. [1] https://github.com/sit-fyi/sit https://github.com/sit-fyi/sit

thow_away_soon 5y ago
This reminded me of toodles[0], a nice project you can use to visualize TODO comments as issues. I didn't have the chance to try it, but I'm looking forward it for my next project [0] https://github.com/aviaviavi/toodles https://github.com/aviaviavi/toodles
crdrost 5y ago
So we need to be a little careful here. Git has won the version control wars, and Git actually reifies a very hard-nosed and pragmatic sort of postmodernism.¹ Postmodernism gets a bad rap from modernists as being anti-Truth, and you can see this somewhat in how a Subversion diehard might view Git, “okay but what is the real truth of the code?” Git had this from kernel development, the real truth is that there are about a million different Linuxes out there due to combinatorial explosion, this one is kernel 4.15 with patches X, and Y applied, that one is 4.15 with X and Z applied...” It's not a philosophical choice but a practical reality for Linux. And so too, branch names in Git generally have process associated with them, they have to get their meaning by sociopolitical agreement among the developers and their tooling. This conspicuous reference to tooling highlights something really important. Git’s postmodernism is constantly clashing with the modernism of Prod. We expect our websites to have one canonical authoritative Truth, at least until we start really committing to postmodernism making A/B testing etc. the norm. You see this last point particularly in the context of Gitlab and GitHub doing CI/CD tasks.² And indeed now the general wisdom is to do trunk-based development, in other words try to ditch postmodernism at this level, thinking that way is too hard when we've got such a modernist reality in front of us, let us instead bound our postmodernism in modernism-plus-feature-toggles or or so. Anyway, the reason I'm ranting about all of this to you is that the same modernism/postmodernism tension is present for issue tracking. Yes, logically an issue should be closed by a commit that fixes the issue. This means that an issue can be closed in production and still open in some feature branch, say. Makes perfect sense. Especially this plays well with one piece of advice I am always giving people, which is that the size of your repository, monorepo vs mini-repo, should be at the level that it makes sense to time-travel on.³ Except: we might like a very modernist view on our issues. We might want them to have a single known status, some person worked on it and finished it and now it is done. We want this issue to be in a Kanban board, say. Does a new issue get merged into all of the release candidates? Those sorts of questions. So again, trunk based development may be necessary to mitigate the mismatch. [1] Postmodernism means a lot of different things to a lot of people. For a quick perspective to help this comment make sense, I take postmodernism as saying that there are blind-sages-and-the-elephant problems for any sufficiently interesting topic: there are multiple perspectives which each give you a partial truth, and only by seeing something from many perspectives do you get a well-rounded education on it. Furthermore, if people are saying “they're actually is only one correct perspective, one sage is Correct above all others, and it is This One” then that is best interpreted not as a genuine criticism of other ideas but as a power grab of sorts—the problem is sociopolitical and not technical. [2] How do you configure those tasks? “With a file in the repository.” Oh, you mean a CI/CD branch that has one particular name and sets the rules for all branches, per modernist requirement? “No, like in the root of each branch’s folder structure. Like the prod and develop branches will both say “if my branch name is ‘prod’ then deploy me to production,” but this will only trigger for the one branch.” And if I push up a new branch called “hotfix” that says “deploy me to production if my name is ‘prod’ or ‘hotfix’?” Um, er, ah. This is a hard problem that both companies had to invent some sort of external-to-repo tooling for, because they both failed to understand the most basic thing about Git! You want a different take, look to Gerrit. ACLs are in the refs/meta/config branch—ah! [3] That is, if you have microservices and it makes no sense to roll back one microservice 30 days without rolling back another, which will probably be using some new functionality that was added to the first—then you should version both together even if you build/release separately. (Git lets you get subtree hashes for this pretty easily.)
- nighthawk454 5y ago
  Thank you for writing this. It helped me relate a lot of half-thoughts around coordinated releases, and lack of connection between build artifacts and code (see: PyPI…). There is a certain strangeness that we have a very distributed and local notion of code, but _running_ that code (even in local environments) is much harder.
  - pabs3 5y ago
    PyPI really needs reproducible builds and bootstrappable builds. https://reproducible-builds.org/ https://reproducible-builds.org/ https://bootstrappable.org/ https://bootstrappable.org/
    - nighthawk454 5y ago
      Badly. Best I can tell, you can't even get the source for a certain build. Even if the owners bother to put a tag in git, there's no proof that's the code they used or even necessarily how they built it. Everything on PyPI is just random artifacts uploaded by whoever ran a build script on their machine - it's nuts.
chriswarbo 5y ago
I use artemis to track issues/bugs in my personal projects. Each issue is an email thread in maildir format, stored in a '.issues' hidden directory in the repo. Metadata (severity, status, etc.) is kept in headers of the original message. http://chriswarbo.net/blog/2017-06-14-artemis.html http://chriswarbo.net/blog/2017-06-14-artemis.html
b3morales 5y ago
> why not issues/tickets as a code also? This means that to let, e.g., testers add information to a ticket they have to do a code commit? I doubt they want to deal with that, and I don't particularly want to extend commit access to my repo to everyone who might need to interact with an issue.
- cdcarter 5y ago
  Github (and plenty of other solutions) provide "edit in browser" capabilities. One could even imagine a custom web front end that enumerates the tickets, allows search, has a new/edit form that does a commit behind the scenes, etc... Fossil SCM has all of the ticketing/bugs stored in the source control repo. Of course, in this case the repo is a SQLite database.
  - b3morales 5y ago
    I still don't think I want those in the repo history, and (for a public repo) this opens up a security hole, letting arbitrary people write directly to code files. I'm not familiar at all with Fossil; perhaps its design makes this possible in a way that doesn't work so well with Git.
- sedatk 5y ago
  That's an important point. Not everyone who processes the tickets need to access the code, let alone change it.

thow_away_soon 5y ago

This reminded me of toodles[0], a nice project you can use to visualize TODO comments as issues. I didn't have the chance to try it, but I'm looking forward it for my next project [0] https://github.com/aviaviavi/toodles https://github.com/aviaviavi/toodles

crdrost 5y ago

So we need to be a little careful here. Git has won the version control wars, and Git actually reifies a very hard-nosed and pragmatic sort of postmodernism.¹ Postmodernism gets a bad rap from modernists as being anti-Truth, and you can see this somewhat in how a Subversion diehard might view Git, “okay but what is the real truth of the code?” Git had this from kernel development, the real truth is that there are about a million different Linuxes out there due to combinatorial explosion, this one is kernel 4.15 with patches X, and Y applied, that one is 4.15 with X and Z applied...” It's not a philosophical choice but a practical reality for Linux. And so too, branch names in Git generally have process associated with them, they have to get their meaning by sociopolitical agreement among the developers and their tooling. This conspicuous reference to tooling highlights something really important. Git’s postmodernism is constantly clashing with the modernism of Prod. We expect our websites to have one canonical authoritative Truth, at least until we start really committing to postmodernism making A/B testing etc. the norm. You see this last point particularly in the context of Gitlab and GitHub doing CI/CD tasks.² And indeed now the general wisdom is to do trunk-based development, in other words try to ditch postmodernism at this level, thinking that way is too hard when we've got such a modernist reality in front of us, let us instead bound our postmodernism in modernism-plus-feature-toggles or or so. Anyway, the reason I'm ranting about all of this to you is that the same modernism/postmodernism tension is present for issue tracking. Yes, logically an issue should be closed by a commit that fixes the issue. This means that an issue can be closed in production and still open in some feature branch, say. Makes perfect sense. Especially this plays well with one piece of advice I am always giving people, which is that the size of your repository, monorepo vs mini-repo, should be at the level that it makes sense to time-travel on.³ Except: we might like a very modernist view on our issues. We might want them to have a single known status, some person worked on it and finished it and now it is done. We want this issue to be in a Kanban board, say. Does a new issue get merged into all of the release candidates? Those sorts of questions. So again, trunk based development may be necessary to mitigate the mismatch. [1] Postmodernism means a lot of different things to a lot of people. For a quick perspective to help this comment make sense, I take postmodernism as saying that there are blind-sages-and-the-elephant problems for any sufficiently interesting topic: there are multiple perspectives which each give you a partial truth, and only by seeing something from many perspectives do you get a well-rounded education on it. Furthermore, if people are saying “they're actually is only one correct perspective, one sage is Correct above all others, and it is This One” then that is best interpreted not as a genuine criticism of other ideas but as a power grab of sorts—the problem is sociopolitical and not technical. [2] How do you configure those tasks? “With a file in the repository.” Oh, you mean a CI/CD branch that has one particular name and sets the rules for all branches, per modernist requirement? “No, like in the root of each branch’s folder structure. Like the prod and develop branches will both say “if my branch name is ‘prod’ then deploy me to production,” but this will only trigger for the one branch.” And if I push up a new branch called “hotfix” that says “deploy me to production if my name is ‘prod’ or ‘hotfix’?” Um, er, ah. This is a hard problem that both companies had to invent some sort of external-to-repo tooling for, because they both failed to understand the most basic thing about Git! You want a different take, look to Gerrit. ACLs are in the refs/meta/config branch—ah! [3] That is, if you have microservices and it makes no sense to roll back one microservice 30 days without rolling back another, which will probably be using some new functionality that was added to the first—then you should version both together even if you build/release separately. (Git lets you get subtree hashes for this pretty easily.)

nighthawk454 5y ago
Thank you for writing this. It helped me relate a lot of half-thoughts around coordinated releases, and lack of connection between build artifacts and code (see: PyPI…). There is a certain strangeness that we have a very distributed and local notion of code, but _running_ that code (even in local environments) is much harder.
- pabs3 5y ago
  PyPI really needs reproducible builds and bootstrappable builds. https://reproducible-builds.org/ https://reproducible-builds.org/ https://bootstrappable.org/ https://bootstrappable.org/
  - nighthawk454 5y ago
    Badly. Best I can tell, you can't even get the source for a certain build. Even if the owners bother to put a tag in git, there's no proof that's the code they used or even necessarily how they built it. Everything on PyPI is just random artifacts uploaded by whoever ran a build script on their machine - it's nuts.

chriswarbo 5y ago

I use artemis to track issues/bugs in my personal projects. Each issue is an email thread in maildir format, stored in a '.issues' hidden directory in the repo. Metadata (severity, status, etc.) is kept in headers of the original message. http://chriswarbo.net/blog/2017-06-14-artemis.html http://chriswarbo.net/blog/2017-06-14-artemis.html

b3morales 5y ago

> why not issues/tickets as a code also? This means that to let, e.g., testers add information to a ticket they have to do a code commit? I doubt they want to deal with that, and I don't particularly want to extend commit access to my repo to everyone who might need to interact with an issue.

cdcarter 5y ago
Github (and plenty of other solutions) provide "edit in browser" capabilities. One could even imagine a custom web front end that enumerates the tickets, allows search, has a new/edit form that does a commit behind the scenes, etc... Fossil SCM has all of the ticketing/bugs stored in the source control repo. Of course, in this case the repo is a SQLite database.
- b3morales 5y ago
  I still don't think I want those in the repo history, and (for a public repo) this opens up a security hole, letting arbitrary people write directly to code files. I'm not familiar at all with Fossil; perhaps its design makes this possible in a way that doesn't work so well with Git.
sedatk 5y ago
That's an important point. Not everyone who processes the tickets need to access the code, let alone change it.