I mean, that literally does not logically follow. Yes, some bug reports are 20 years old. My point is precisely that this one hasn't become a 20-year-old bug and the way the parent comment read made it sound like it's a glaring, long-lasting issue when it's not.
"A broken workflow is a broken workflow" is just a tautology. I guess you're implying "any kind of broken workflow is bad" but yeah, I don't agree with that especially with regards to free tools. The project literally has weekly commits, devs are open and engaged and... patches are welcome
> "A broken workflow is a broken workflow" is just a tautology. I guess you're implying "any kind of broken workflow is bad" but yeah, I don't agree with that especially with regards to free tools. The project literally has weekly commits, devs are open and engaged and... patches are welcome
I just wanted to respond to this a bit more. My moving away from a project is my choice. Just because it has active devs and regular commits doesn’t mean that I’m in any way obligated to continue to use it, or contribute to it. It doesn’t fit my workflow, and the issues are longstanding and glaring. Might they be fixed in the future? Sure. Am I interested in sending patches in or tracking that effort? Actually it really doesn’t even matter, a broken workflow is a broken workflow, even when the tool is free. It doesn’t work for me as is and I will find something else if I want.
This seems to be some sort of defensive response as if I was attacking the project. On the contrary, and like I said before, I generally like it, but the issues I have, which are to be both glaring and longstanding, means that it doesn’t fit my workflow and I’m considering moving. Not all tools need to suit everyone’s workflows, and “patches are welcome” is very beside the point.
I mean, it is a glaring issue for me, but often it causes the most frustration in another task, so I didn’t personally report it much sooner, but it has been broken for a while.
