Stop closing valid issues and pull requests

[ranile]

The trunk project does not appear to have the man power to keep with the 3-month staleness period, introduced by #594. This causes valid issues and pull requests to be wrongly closed.

Here are some examples of issues/PRs that I don't believe should be closed

• Set an environment variable with the JS file that needs to be loaded for workers #604
• Add linux musl target, add aarch64 for all major platforms #553
• Add TLS support to WS proxy. #492
• Support relative public URLs #470
• Added https support for trunk serve. #458
• Support building and serving examples #457
• and others

Those are just the ones I've been following. The fact that issues are being dismissed without any input from maintainers hurts the project and will push people away. I'm losing confidence in the future of Trunk if this keeps up

[ranile]

@thedodd I would like to have your input here

[ctron]

That's part of #623 … and I agree with that.

[thedodd]

Agreed. It was a temporary measure to help clear out a lot of old cruft. 300+ issues just sitting there is already too much. I think we should just tune the staleness bot to be a little less aggressive.

Ultimately, the goal is that it will help maintainers to focus on current issues for which there is not only demand, but also willingness to resolve the issue.

[ranile]

@thedodd can you transfer the repository to a trunk organization? Trunk is quite well-used, so having it in an organization is important.

@ctron made an organization and having this repo there would be helpful

[ctron]

In order to make some progress I created that dedicated organization for trunk development: https://github.com/trunk-dev … I already invited @thedodd as an admin there too.

I started out with my fork, but I am ok with transferring that back and using the original trunk repository. I would also prefer to use the existing crate, nix and homebrew to move forward.

However, I also think it is important to make some progress. And the PR to merge the fork back into trunk is pending because I can't push changes to the repository (due to fact that there are merge commits in there).

So, in order to be able to make more progress, be faster in responding, and being a bit more open, I believe a dedicated repository (and more members) makes sense.

[thedodd]

Hey folks, yea I already have https://github.com/trunk-rs org in place from quite some time ago. Matches the website name as well. I'll send invites out and start the process of moving things over. I'll send out invites and such.

@ctron yea, Trunk has the linear history requirement in place since the beginning. So no merge commits. Squashing things down is typically the way to go.

TBH, given how large the set of changes is, I'm wondering if it is indeed a good idea to squash and merge. It will be a bit more of a distinct location in history.

Thoughts? You should be able to just click the Squash and merge option right now to merge that branch.

[ctron]

@ctron yea, Trunk has the linear history requirement in place since the beginning. So no merge commits. Squashing things down is typically the way to go.

There are ~160 commits from various people. Just squashing their commits seems totally wrong to me.

[ctron]

With the merge of trunk-ng into trunk, the CI config for automatically closing issues and PRs should be removed again. If that still is a problem, please ping me (or the issue) and I will re-investigate. And thanks for bringing this up!

[allan2]

Forks getting merged upstream. You love to see it! This is a big win for the Rust/WASM ecosystem.