Hacker News Reader

> 1. Integrate code that is more experimental into the development trunk

> 2. Let people discover what is wrong with it

> 3. Fix and iterate it

This kind of experimentation can be done on a separate branch. There's no need to involve whoever maintains the "main" development branch until the code is reasonably OK for release.

In some cases, it can be acceptable to merge code that's clearly marked as experimental into the main trunk if it's a totally separate feature that can be ensured to not affect normal use of the project. You can see this, e.g. with "nightly" Rust features, which are opt-in and clearly separate from the "stable" language. But this is not very feasible in something like a terminal emulator, for obvious reasons.

Yeah, that's the party line for sure, but the end effectiveness of waiting until "it's okay for release" is low. You will never reach that point. Most experimental branches basically see no use outside of who is developing them.

So a lot of time you are only really getting them to the point they pass existing tests, and maybe whatever additional testing the person writing the code is doing. As a result it's really rare that code got enough testing on that branch that it was "ready for release" when it was integrated. Show me software done this way, and i'll show you software released with lots of bugs and point releases :)

One of these development processes admits that's true and integrates it at some earlier point and accepts it will take more work despite that.

I'm also not sure what "no need to involve whoever maintains the main branch" means. Software development is a team sport. If you don't want it to be, don't accept contributions (no judgement, i'm serious).

Acknowledging my bias towards correctness first (or a harness for explicitly experimenting), I think your step 3 ("3. Fix and iterate it") is rarely ever done and that absence puts people off. In the corporate environments I work in, the PR sets the standard for what is acceptable and there's vanishingly little motivation to fix anything that isn't blowing up a high profile client. Basically mini tragedy of the commons.

I wouldn't be surprised if an aspect of this is "I don't trust you'll iterate and fix this, and I don't want to, so please make sure this is correct". I would expect a contributor with a long/trust-filled relationship to the maintainer to have much more leeway for not-exactly-perfect contributions.

My bias is from watching a lot of smart people experiment well.

I think you are not wrong in the limit, but it's a bit more complex than that:

1. You need to set expectations up front of what it means to contribute.

2. You need to be willing to spend time to help ensure people know how to iterate it, etc. Check in with them, etc. We often expect people to just figure out what you want or be completely self-sufficient. Especially with folks who have never interacted with your project, how could they possibly know how to do it well? We often motivate (positively or negatively).

But we often suck at training people at things they aren't used to. Training goes a long way. etc

Again, this will never work 100% of the time. You will find people who in fact, will just want to get it in and run away. I'm just trying to get that percent to say 5-10%, rather than 80% :)

I agree with the aspect you see - people are not always willing to trust. This often turns into "you are all helping me with my software" rather than "we are all working together to produce software". In practice - the process i gave is also one of the only good ways i know to build long term trust and contributor relationships. You trust them to work on their code once added, and to care. They trust you to help them. That is how you start to build good team relationships. They will be good at things you are not, you will be good at things they are not.

I'm not sure how you ever build a trust or community relationship if you say "i don't want to trust you to do anything, please drop it on me in a perfect state so i don't have to trust you"

To bring it back to the article, this really seems like one of those "get it in and run away" cases. Or to be a bit more accurate, run away before getting it in...

The author made a number of comments on the PR about how they expected it was almost done while there were still outstanding concerns from maintainers. The author stopped responding to comments when their employer's priorities changed. Someone else volunteered to finish the author's incomplete work, then the author closed the PR, complaining about being tired of seeing it in their PR list.

The maintainers spent a fair amount of effort explaining many (basic Rust) things like the extremely unsound API design of dereferencing a user-supplied raw pointer. They were trying to help.

This just doesn't seem like an individual the maintainers have any reason to trust.

A terminal emulator has security implications.

So? Lots of things do. Good programming practice would be to carefully segregate the security parts of it from the non, and keep that part small and carefully thought out.

Quoting woodruffw:

> The `nix` crate is a cornerstone of the Rust development ecosystem: if you do anything that requires POSIX or various nix-specific APIs beyond those wrapped by the standard library, then `nix` most likely provides a high-level and safe wrapper for them. Perfectionism is a virtue in this context, one that keeps large parts of the Rust ecosystem from accidentally consuming buggy code.

I think "refuse to integrate code until every conceivable thing is thought out and dealt with" is the right* approach when contributing unsafe code to Rust projects, especially to a foundational crate. Rust is designed around the separation of safe code (which allows non-expert programmers to write code with the speed of C and the safety of Java), and safe APIs around unsafe code (exposing a interface around dangerous primitives, constrained so non-expert programmers can't misuse the API to achieve undefined behavior, use-after-free, dereferencing wild pointers, reading uninitialized memory, etc.).

To ensure that safe Rust is actually safe (can't achieve segfaults), third-party libraries which expose safe APIs around unsafe code (like nix) should be proven/provable to never use-after-free, write to wild pointers, expose uninitialized data, etc. This is a high bar to clear, and takes dedicated learning to develop the necessary expertise. But not doing so would expose users of the library to possible segfaults when users "hold the API wrong", which is the failure mode of C++ that Rust exists to avoid. Sadly, the compiler and standard library itself has some unsoundness bugs (described as the "worst kind of bug") which allow convoluted code constructions to result in segfaults despite not containing `unsafe` blocks . These are tracked at https://github.com/rust-lang/rust/issues?q=label%3AI-unsound.)

On the topic of application-level code quality (rather than foundational libraries), I believe that for native applications, code which can't be proven to be memory-safe (either because the program's author doesn't know C++ and the libraries well enough, or because they accept poorly written code from outside contributors) is a significant factor towards the instability of C++ apps I've used. I'm not sure how to best develop this knowledge; perhaps newbies creating/maintaining codebases could be mentored by more experienced developers (who hopefully have prior experience with the app or problem domain)? Perhaps managed/GC'd languages make it easier to write approximately-correct code, since they don't require global architectural knowledge and flawless reasoning to avoid segfaults. However it still takes global architectural knowledge and flawless reasoning to avoid race conditions.

Even though I value code quality over velocity, and despite how incorrect memory-management and threading inevitably results in broken programs, I hate to admit that that gatekeeping code quality and user-facing experience (perhaps architectural design?) could result in more stress, less progress and contributors, and a worse end result.