Entities were abstracted - and made available as extension points in commit https://github.com/git-bug/git-bug/commit/d0db3b121bb9b0b8ec007c3a12cec015dc7c77d7. Label, LabelColor and Status were moved to the common package, but if git-bug can provide a generic DB with CRDT-controlled consistency, wouldn't it also be nice if new entities could also use the existing Comment handling facilities?
If this sounds reasonable, I'll take a look at how much effort it will entail.
Move `Comment` to `common` package to Move `Comment` to `common` package
sudoforge commented
this sounds reasonable to me. LMK if you end up in a rabbit hole and want a second set of eyes on it.
Sounds like a plan ... I'm a bit busy ATM but have a project that would need to duplicate comments and @MichaelMure did such a nice job with the Lamport clocks and resolving order. I see a bit of generics needed but can try to keep them "under the covers".
I'm not too sure that would be valuable. Label and Status are concepts that are meaningful and valuable across entities (for example, status makes sense for a bug and a PR, from the point of view of a kanban board).
Note that none of (status,label) define how they are managed in an entity, they only define the general concept and interface.
Comments on the other hand (in their current form), don't seem especially generic to me. My advice would be to start without having a common implementation, and then only see if there is really value in abstracting it.
If a bug title is a blog title and a bug description is the blog content, then the comments as they are seem like they'd work. What makes you think that they're specific to bugs?
My point is: if you remove how it's stored in an entity, you'll more or less end up with a typed string. Is that a valuable abstraction ? What is your goal with this? On the other hand, if what you care about is how it's stored and interpreted ... I fear that you will end up with way more complexity than needed for little gain. The important part is already abstracted in the dag package.
Both PRs and Boards would theoretically benefit from comments - is there an example in your branch?
Board could have comments (like the draft thing on github), but that might not be a standalone comment in the entity. Same story for PRs, the shape and how it's handled could very well be different than for a bug.
An interface could make sense if there is common UI handling, but we should for that need to show up first.