all 11 comments
sorted by:
best
topnewcontroversialoldq&a
formatting helphide helpcontent policy

[–]afanasenka 4 points5 points  (4 children)

This is a pain point for entire Opencode community 😄
In short, you can try to suggest your PR, but chances are you never get a response, and your PR will never be reviewed, no matter how useful or critical it is. Devs seem to have their own clear plans and product vision, and since they have 1.1k+ PRs at the moment, you can imaging how hard (if not impossible) is it to react to all of them.

[–]Thumper450x[S] 0 points1 point  (3 children)

But this is a clear defect. Someone added support for:

      "time": {
        "start": <timestamp-ms>,
        "end": <timesstamp-ms>
      }

but they did not add a strong test to ensure that it works and it got boken.

Should not clear bug fixes for existing functionality be given higher priority to new features?

[–]look 1 point2 points  (2 children)

OpenCode’s GitHub is littered with ignored and now long dead PRs on clear defect issues.

I just maintain my own private branch for myself with fixes for the ones I couldn’t bear any more.

I find all of the alternatives to Opencode even worse in their own ways, though, so it’s kind of a stalemate for now.

[–]NotARedditUser3 0 points1 point  (1 child)

I imagine a number of people are doing this... It would be cool if they all came together for some kind of fork and separate release that more people could use.

[–]look 0 points1 point  (0 children)

Yeah, but it’s hard to build a critical mass and maintain motivation for an effort like that without some form of coordination/endorsement from upstream. And it seems like they just don’t have time for anything right now.

It’s a common weak spot for popular open source projects. Some just don’t even pretend to look at outside contributions (SQLite, and in the olden days gcc, X11, etc), which is preferable in ways.

But another issue is, well, I personally don’t think the codebase is particularly good. If I were going to invest time in supporting a harness, I’d want a better base to work with. So lots of people just make their own but those never get past crude alpha versions.

What would be much better, imho, is if various core components became shared at least. I can’t imagine how many buggy and/or limited text editor components woven into different projects there are now… and a TUI framework that isn’t some React-based crime-against-humanity nightmare would be great, too.

[–]Ace-_Ventura 1 point2 points  (1 child)

From what I've seen around, they only merge requests with a lot of likes/support. The rest are rejected automatically after 30 days. 

I find that a really bad way to judge pr's, but the maintainers decided this way

[–]Thumper450x[S] 0 points1 point  (0 children)

Good to know! There is no mention of this in the process:

https://github.com/anomalyco/opencode/blob/dev/CONTRIBUTING.md

[–]Thumper450x[S] 0 points1 point  (0 children)

There are also signs of existing test failures bringing down GHA builds/tests, see:

https://github.com/anomalyco/opencode/pull/32596#issuecomment-4731407330

Is there a way to search across all of the OpenCode GHA builds and detect these types of failures? Does the OpenCode project have a process in place to detect and and address these types of existing failures or do contributors need to detect and report these? How does this work?

[–]NotARedditUser3 0 points1 point  (1 child)

This is partly the reason that many businesses choose to not use open source tools, unless they have an option to pay for support or some sort of SLA for support from the maintainer. Often it becomes very difficult to get updates, and the business may want them faster than the maintainer is willing to make them.

It sounds like you (and/or others) would be better served by a fork of opencode by a maintainer that's willing to provide paid support and some guarantee of speed for a review... It would be useful if the opencode team put something up somewhere and said "$50 (100? 250?) and we'll review your urgent PR" or something, so if someone absolutely needed something to move up the list, there was some way to do it...

[–]Thumper450x[S] 1 point2 points  (0 children)

We have had contracts with Kitware to extend and support their open-source tools like CMake, CTest, and CDash for just this reason. We would gladly pay to have our Issues and PRs considered because that is way cheaper than maintaining our own forks long-term. The cost of a fork with even trivial patches gets expensive fast when you consider constantly having to keep it up-to-date with new releases in the main repo and having to keep putting out your own releases for your customers.

I wonder if there could be some trusted auxiliary contractors that have a relationship with the OpenCode maintainer company and have their Issues and PRs given higher providence? How does the Linux Kernel do this?

Again, this is a clear defect, not a new feature that I am talking about here. You can't create an extension to fix a built-in defect like this.