State of the project / forking the project

[ctron]

First of all: I would prefer to keep things in this project. I don't want a fork. I think trunk is awesome and @thedodd did an amazing job!

On the other side, I desperately need a fix for the issue of the "endless build loop", and others too :

• Reproducible Trunk inf loop. Try it yourself #461
• bevy_asset_loader + trunk: Changes in assets folder trigger ~10 reloads NiklasEi/bevy_asset_loader#110
• trunk serve can get caught in a build loop when compiling web workers #422
• …

I created a PR for this a long time ago (#516), which didn't receive any attention until recently. I followed up on this an created a second implementation as suggested: #569. Those PRs work for me and seem to work for others. But installing from a PR/branch isn't the best experience.

Not getting any attention on such an important issue, I can just assume that the project isn't actively maintained anymore. And I absolutely understand that priorities change. That's live, that's normal.

A possible solution for me is to keep the fork (that I already have because of the bug fix: https://github.com/ctron/trunk) and just publish it on crates.io.

As I did notice that there are other PRs which seem to have the same issue, I would suggest to join efforts. Maybe ping me, maybe create an issue in the forked repo, so that I know. And I can try to add some of those changes as well.

Should such a fork already exist, sorry for not finding it. Let me know!

I will leave this lingering for a few more days, and follow up when I start working on it.

---

The fork is available at: https://github.com/ctron/trunk/releases

[thedodd]

@ctron I can appreciate where you are coming from. Folks often times have a great deal of urgency when it comes to fixes that they need for their projects and such. YOU SHOULD do whatever it is that you need to do in order to get to a stable point. Host a build yourself. Whatever. Its fine. This is open source.

"Actively maintained" is an entirely subjective and arbitrary phrase. The last release was literally 2 weeks ago. Trunk is maintained, but obviously the maintainers (myself and a few others) do not have as much time to address your specific issues as much as you would like. That is a more accurate and precise statement.

Why not just become a fellow maintainer? If you feel like you have time to contribute, and you think you have an aligned vision, then that is by far the best approach.

I will hopefully have time to review and merge your PR. My questions right now:

• Is this a general solution?
• Do we fully understand what is causing the problem for the webworkers and a few of the other stated problems?
  • If a pipeline is causing an additional build to be triggered, it is because a pipeline is writing something to a watched file/folder when it should not be. Have you figured that out? That seems to be the actual fix.

Also ... you can just disable the watcher temporarily, or ignore the problematic file/folder. We will fix these issues, but please remember the nature of this project.

[v-kat]

I had created ctron#1 I'm mostly at the point where hopefully the offline nix fix will also get merged in soon or I will drop down a level and gut my trunk use. I hope you manage to contribute to the project!

[ctron]

Why not just become a fellow maintainer? If you feel like you have time to contribute, and you think you have an aligned vision, then that is by far the best approach.

I think that is what I am trying to do. Not getting any feedback for over three months, despite other's having the same problem, doesn't help. And getting a simple response as, "sorry I don't have time at the moment" would definitely help to understand the situation.

I will hopefully have time to review and merge your PR. My questions right now:

* Is this a general solution?

Yes.

* Do we fully understand what is causing the problem for the webworkers and a few of the other stated problems?
  
  * If a pipeline is causing an additional build to be triggered, it is because a pipeline is writing something to a watched file/folder when it should not be. Have you figured that out? That seems to be the actual fix.

For the webworkers no. But for the other issues: yes. Any event happening during a build will queue up. Having operations like npm i or git operations like changing branches causes loads of change events queuing up.

Also ... you can just disable the watcher temporarily, or ignore the problematic file/folder. We will fix these issues, but please remember the nature of this project.

I do need the watchers. That's the whole idea of trunk serve.

I am not sure if "We will fix these issues" is the right approach to get new contributors. If there is something wrong with the PR, let me know. I already re-wrote the PR once. If there is something wrong with it, I can change it.

[thedodd]

I am not sure if "We will fix these issues" is the right approach to get new contributors.

@ctron sorry about the misunderstanding. I was using the word "we" in attempts to be inclusive (of you). I think the nature of this discussion painted an exclusionary context, but that was not my intention. Thanks for all of the work you've done on this.

[ctron]

As I am a daily user of trunk, I am happy to help beyond my own PRs if that's something which helps the project. Just let me know.

[thedodd]

@ctron if you are on the Trunk discord, maybe we could discuss a few ideas there. I couldn't find an obvious handle for you. Ping me there if you are interested in helping out :)