Remove skip-validate option

[joonho3020]

The default installation option should not ask "y/n".
I think most people would want to run build-setup.sh and walk away 🥲

Related PRs / Issues:

Type of change:

• Bug fix
• New feature
• Other enhancement

Impact:

• RTL change
• Software change (RISC-V software)
• Build system change
• Other

Contributor Checklist:

• Did you set main as the base branch?
• Is this PR's title suitable for inclusion in the changelog and have you added a changelog:<topic> label?
• Did you state the type-of-change/impact?
• Did you delete any extraneous prints/debugging code?
• Did you mark the PR with a changelog: label?
• (If applicable) Did you update the conda .conda-lock.yml file if you updated the conda requirements file?
• (If applicable) Did you add documentation for the feature?
• (If applicable) Did you add a test demonstrating the PR?

• (If applicable) Did you mark the PR as Please Backport?

[jerryz123]

I personally agree with this change

[jerryz123]

It's probably a good idea to leave the flags as no-ops so people's existing flows and documentation won't all immediately break.

[joonho3020]

It's probably a good idea to leave the flags as no-ops so people's existing flows and documentation won't all immediately break.

Hmmm.... but then we need to cleanup the "no-op" flags later...

[jerryz123]

It's probably a good idea to leave the flags as no-ops so people's existing flows and documentation won't all immediately break.

Hmmm.... but then we need to cleanup the "no-op" flags later...

Yeah, at some point. But IMO this is an instance where we should prioritize minimizing user pain.

[joonho3020]

There are times when radical changes just have to take place.......

[jerryz123]

There are times when radical changes just have to take place.......

Removing the flag and all relevant documentation is fine.

Leaving behind the parsing as a no-op is a minimal QoL feature that has no impact otherwise.

[joonho3020]

Hmm.. I think it is even more confusing to users if there is a "flag that does nothing".

[joonho3020]

😢

[jerryz123]

Remove it from the documentation and help text. Users should not be able to discover it and be confused.

It would only affect existing users following old docs, or with their own scripts.

[SeahK]

Oh, this change seems good. I sometimes forget to do Y and waste an hour.

[T-K-233]

Nice change. I will update the tutorials when we do a version release with this change.

[jerryz123]

I'd like to wait for @abejgonzalez and @sagark before merge.

[jerryz123]

Wait for @abejgonzalez and @sagark

[joonho3020]

Release has to happen...

[jerryz123]

I know, but as others have asked for this feature in the past, it would be rude to unilaterally remove it without their feedback.

[abejgonzalez]

This is going to get rejected by @sagark most likely. This flag being there exists strictly for new users who accidentally don't check out a release to have some sort of prompt telling them "Hey this isn't a release, this may not work". I'm personally indifferent about this now.

[jerryz123]

If @sagark concedes then we can merge this, after my backwards-compatibility concerns are addressed. I think we certainly have some consensus that this is the right move.

FWIW, this isn't the Wild West of rocket-chip and RTL changes between releases anymore... at this point, most changes are strictly QoL improvements or new-features. The latest commit on main is much more likely to be usable than the latest release, and we will continue to only provide support for the latest main.

Thus, I don't see the benefit of pushing users into using tagged releases.

[sagark]

FWIW, this isn't the Wild West of rocket-chip and RTL changes between releases anymore... at this point, most changes are strictly QoL improvements or new-features. The latest commit on main is much more likely to be usable than the latest release, and we will continue to only provide support for the latest main.

Thus, I don't see the benefit of pushing users into using tagged releases.

I'll approve, let's give it a try.

Since this is so early in the setup process, I also think it's fine to just delete the flag completely (no deprecation warning), as long as we've scrubbed references to it throughout the docs/code. It'll just error immediately for anyone using the flag and then they can fix it.

[jerryz123]

Thanks for bringing this up @joey0320