Thoughts on "Separation of Concerns"


Separation of Concerns by sgtatham While $this does not strictly aim to be a bug tracker but rather a generic project management tool (which, in essence, is a bug tracker and notes smushed together with some graphs. (it reminds me of how xhs is a bunch of other apps smushed together. maybe that’s our tagline. xhs of pm )) we’ve built a generic document store (with some oddities like layering) of course that can be functionally anything, someone could use this as a postgres backend if they were a bit silly. the important distinguishing features are what come on top that fashion the generic piece of steel into a blade. fix version field yep, agreed. it’s more relevant to store a specific commit as the reference for where something is fixed, rather than a version. it feels like the version is just the easiest thing for people to enter. maybe for us, for connected repositories, we should have a way to point to a specific commit? and then resolve which branches that commit is included on? it could be a plugin of course, a specific Tag type that can use its combination of commit + repo awareness to resolve into useful information when rendered? it shouldn’t be anyone’s task to update that pointer. If you’re looking specifically for facts, you can’t just ask for ‘bugs with Fix Version < 1.3.0’. is an interesting inverse query, had not considered someone would want that in their bug tracker but of course that’s logical. so, that data shouldn’t just be resolved but persisted in such a way it can be calculated against later. the `<` is scary, is there a data structure that supports that, is `vers.split('.')` to get a tuple back a reasonable way to store that, that in turn the sqlglot queries can find it back? need some ability to scan git logs for “fixes #1234” (a urn?) turn that into a tag on that specific resolved note. at a later date, re-scan and apply a “Fix appears in branch X” Two-tier Status and Resolution fields If I want to find out what bugs exist in the code, I have to do a search that picks out tickets with state ‘Open’, and also tickets with state ‘Closed’ and resolution ‘Won’t Fix’. I can’t imagine many PMs consider the second class as bugs, but it is a useful thing to query. if we’re copying every tag to the ‘task’ table when we go to query it it would be as simple as `select title, status, resolution where status == 'open' or (status == 'closed' and resolution == 'won't-fix')` i’m still a bit worried about tags clobbering metadata on the table. maybe that’s a “you’re holding it wrong” issue, or, maybe it can be safe with prefixing tags with `t_` or `tag_` or just `_` in the column name and preventing those strings from being used for real tag names. since tags are of the shape (type, value) i don’t think there’s a good query i can imagine for selecting status=closed & resolution=wontfix in a query like that. maybe needs a union or, join or something. or the tags table needs to be reshaped for querying, as ‘(id, status, resolution, … 50 other tags)’ Fake bugs for other kinds of to-do item I think this section really appealed to me when i originally read this and motivated some of this work. bugs, notes, documents, wiki, everything mixed together in one big happy pile, as it should be. So you have to make a bug record, or a bug-like record, to represent your plan to implement that feature – in effect, representing the feature as a sort of ‘anti-bug’. this will be solved here, just by being able to have a ‘plan’ shaped thing alongside a ‘bug’ shaped thing, and being able to transition between these two. that transformation will be interesting, I guess we will retain all previous metadata, and just default to prioritising metadata that is default for the ‘bug’ profile. how are these profiles managed? right now it’s at the server implementation level which feels off. people will want different defaults. should we then encode the shape of a bug (default tags) in the system somehow? every repo that wants to can ship their own version of the template. template issues customising the template of an ‘app’. We should reduce app surface to be only what actual functionality is needed and see if we can eliminate it nearly entirely (except e.g. `file`) In the prototypical case, you’d create a pair of parallel records in both tables. Someone reports a bug, so you have to make a facts record saying that the bug exists; you intend to fix it, so you make a plans record describing that intention. The system would certainly need to make it easy to do this double operation. I think this is solved more easily with documents. I’m, very anti-mongo, anti-docstores generally but, i think this is a use case that makes sense. and i’ll add that it doesn’t preclude a sql backend, it’s just shitty ugly sql that has fewer columns than it could, or some severe denormalisation.

Separation of Concerns by sgtatham

While $this does not strictly aim to be a bug tracker but rather a generic project management tool (which, in essence, is a bug tracker and notes smushed together with some graphs. (it reminds me of how xhs is a bunch of other apps smushed together. maybe that’s our tagline. xhs of pm ))

we’ve built a generic document store (with some oddities like layering) of course that can be functionally anything, someone could use this as a postgres backend if they were a bit silly. the important distinguishing features are what come on top that fashion the generic piece of steel into a blade.

fix version field

yep, agreed. it’s more relevant to store a specific commit as the reference for where something is fixed, rather than a version. it feels like the version is just the easiest thing for people to enter. maybe for us, for connected repositories, we should have a way to point to a specific commit? and then resolve which branches that commit is included on? it could be a plugin of course, a specific Tag type that can use its combination of commit + repo awareness to resolve into useful information when rendered?

it shouldn’t be anyone’s task to update that pointer.

If you’re looking specifically for facts, you can’t just ask for ‘bugs with Fix Version < 1.3.0’.

is an interesting inverse query, had not considered someone would want that in their bug tracker but of course that’s logical. so, that data shouldn’t just be resolved but persisted in such a way it can be calculated against later. the < is scary, is there a data structure that supports that, is vers.split('.') to get a tuple back a reasonable way to store that, that in turn the sqlglot queries can find it back?

need some ability to scan git logs for “fixes #1234” (a urn?)
turn that into a tag on that specific resolved note.
at a later date, re-scan and apply a “Fix appears in branch X”

Two-tier Status and Resolution fields

If I want to find out what bugs exist in the code, I have to do a search that picks out tickets with state ‘Open’, and also tickets with state ‘Closed’ and resolution ‘Won’t Fix’.

I can’t imagine many PMs consider the second class as bugs, but it is a useful thing to query.

if we’re copying every tag to the ‘task’ table when we go to query it it would be as simple as

select title, status, resolution where status == 'open' or (status == 'closed' and resolution == 'won't-fix')

i’m still a bit worried about tags clobbering metadata on the table. maybe that’s a “you’re holding it wrong” issue, or, maybe it can be safe with prefixing tags with t_ or tag_ or just _ in the column name and preventing those strings from being used for real tag names.

since tags are of the shape (type, value) i don’t think there’s a good query i can imagine for selecting status=closed & resolution=wontfix in a query like that. maybe needs a union or, join or something.

or the tags table needs to be reshaped for querying, as ‘(id, status, resolution, … 50 other tags)’

Fake bugs for other kinds of to-do item

I think this section really appealed to me when i originally read this and motivated some of this work. bugs, notes, documents, wiki, everything mixed together in one big happy pile, as it should be.

So you have to make a bug record, or a bug-like record, to represent your plan to implement that feature – in effect, representing the feature as a sort of ‘anti-bug’.

this will be solved here, just by being able to have a ‘plan’ shaped thing alongside a ‘bug’ shaped thing, and being able to transition between these two.

that transformation will be interesting, I guess we will retain all previous metadata, and just default to prioritising metadata that is default for the ‘bug’ profile.

how are these profiles managed? right now it’s at the server implementation level which feels off. people will want different defaults.

should we then encode the shape of a bug (default tags) in the system somehow? every repo that wants to can ship their own version of the template.

template issues
customising the template of an ‘app’. We should reduce app surface to be only what actual functionality is needed and see if we can eliminate it nearly entirely (except e.g. file)

In the prototypical case, you’d create a pair of parallel records in both tables. Someone reports a bug, so you have to make a facts record saying that the bug exists; you intend to fix it, so you make a plans record describing that intention. The system would certainly need to make it easy to do this double operation.

I think this is solved more easily with documents. I’m, very anti-mongo, anti-docstores generally but, i think this is a use case that makes sense.

and i’ll add that it doesn’t preclude a sql backend, it’s just shitty ugly sql that has fewer columns than it could, or some severe denormalisation.