A higher bandwidth discussion area separate from issues and PRs

[acmcarther]

I've enabled "discussions" to provide an area for slightly tangent discussions outside of a single PR or issue.

I'm not sure exactly what this should look like, but I wanted a place separate from individual PRs for meta discussion.

[acmcarther]

State of the crate (from me, primary maintainer) in the very worst stream of consciousness form. Bottom line, this is basically a response to #306 (comment) which I typed out, then deleted, several times because it was too long and too off-topic-y.

TL;DR: I suck as a maintainer, the other maintainers can't be expected to pick up the slack, probably, but you all are still building amazing stuff anyway. Also, we probably should start imposing more process somehow. Also I probably need to start implementing features so I can do code reviews effectively...

---

response to #306 (comment)

@UebelAndre has asked earlier about having other maintainers become more involved, but I've pushed back (or not really acted) on that. The primary reason is that those other maintainers were added basically as a hack to allow important features (and, typically features of low complexity) to get reviewed and submitted during the epoch of my absenteeism. Those folks were either Googlers working on odds and ends internally or in 20% time, so I assumed they could be trusted not to nuke the repository, or were external contributors from the ancient times. I think generally they're either not going to be comfortable reviewing huge stuff because they're not current users of the repo anyway (more on that in a second), or because their usage was incidental, and they weren't really signing up to be serious maintainers of big stuff.

So the status of me. I am the king of this repo and all the directories I survey largely because I wrote the 1st (and 2nd implementation of this. I don't use cargo-raze or rules_rust or any of the fun stuff here in my day job and as of late I haven't been doing much work with Rust outside of work either. This is the real explanation for (1) why this repo doesn't get what I would call "institutional" support (that is, because it's not used within the institution), and (2) why it doesn't get ad-hoc support (that is, because I haven't been using it either). There has been some interesting stuff within the organization that resulted in things like cargo-gnaw, a BUILD generator equivalent to this but for gn though.

Anyway, as consequence of that status quo, I actually don't have a strong grasp of the implementation at this point, and code reviews are somewhat arduous for me. This is getting a bit better over time. It's still the main reason why reviews are slow though. I've continued to review PRs but with some of the more complex recent changes this has become a bit more difficult for me to maintain without me becoming an active contributor again so that I have a strong working familiarity with the code.

On a side note, I'm quite heartened (but internally conflicted -- given my aforementioned absenteeism) to see that some other folks are extending this in new and awesome ways, both through contributions to the repo, and also through seriously amazing stuff built on top of it.

---

direction setting

I think we've probably gotten to a state in the rules_rust, cargo-raze, bazel-rust ecosystem where we need proper direction setting to make sure that we're working toward the best possible user experience for folks using Bazel and Rust (especially without breaking their workflows). I don't know what exactly that should look like, but I think it should probably at least consist of (1) unifying of this repo with rules_rust, (2) some sort of design process for new features and (3) a more "official" release and announcement process. We could also probably learn from the rule sets that get "instututional support" to see what their processes are. Aspirationally, I think I'd also like the UX of this crate in particular to converge more closely with Bazel Gazelle, but I haven't invested much time in thinking about how that should work.

[UebelAndre]

One thing I'd like to call out here. I currently have many changes made on top of other changes I'd like to open pull requests for this project. The primary reason for this is I tend to like the changes I make and want to use them. While I wait for a review of a PR I opened, I still want to be able to take advantage of the work I did. I do this and continue going about my day to day to then find some other functionality I want to change. This is where I opt to build more changes on top of the changes I've already made and as more time passes, more changes are made. I wouldn't say I'm making an effort to rapidly crank out change after change. But if a PR is slow enough, then changes will get backed up. Any suggestions on how I can improve my workflow such that I can continue to use what I wrote and not complicate future PRs?

[acmcarther]

At a high level: Propose designs or file issues before you make changes so that I can review them and we can discuss them before too much stuff goes in.

At a lower level: Make the value proposition and tradeoffs more clear in the PRs. In #319, your PR description is "i added this feature". It assumes that the benefit is obvious, when (as we've discussed here), it's not.

[UebelAndre]

I have had no activity on any design/RFC issues I've opened in the past. I've had to ping people multiple times to get any sort of response. I'd love to have more discussions but it just doesn't happen.

[UebelAndre]

In the entire google org. Is there really no one who is willing to do some development on the Rust ecosystem for Bazel? Making contributions to both cargo_raze and rules_rust has felt pretty punishing and makes that me sad since I really like Bazel and Rust and would love to use the two together. Having another person who works on the tool would solve for a lot of directional confusion and the impact of changes like like #319 would be obvious for anyone who had the context of a regular/recent contributor on the repo. Until that PR, I thought I was in alignment with you (@acmcarther) but there and discussions the around the rules_rust repository name show that's not the case which to me is pretty demoralizing after all this time since.

[dae]

Your changes are appreciated Andre - the introduction of platform-specific dependency support is what allowed me to jump on the Bazel train, and I've found the new workspace code useful as well.

Google are not a charity, so I don't think we can expect them to invest into features that don't directly benefit the organization. Individual Googlers may contribute their time due to interest and/or a sense of responsibility, but they no doubt have plenty of other responsibilities as well, limiting the amount of time they can put in here.

[UebelAndre]

Thanks Damien 😄 Really feels good to hear that.

I'm not trying to suggest that Google is or should be a charity. I'm very grateful for the time maintainers have given to review my changes. What I meant by:

In the entire google org. Is there really no one who is willing to do some development on the Rust ecosystem for Bazel

was that I find it surprising that there isn't more interest in this. Everything I do here is done on my free time and if I were a Googler I'd be very interested in how I can make working on improving Rust in Bazel (which I directly equate to working on this project) part of my day to day.