On Tue, May 30, 2017 at 03:36:09PM -0700, 'Tim Hockin' via Kubernetes developer/contributor discussion wrote:
> The trend of `hack/update-something.sh` scripts is as old as the
> project. It started as simple things that basically always worked and
> ran quickly. Over time we have accumulated over 20 such scripts.
> Some are still pretty fast. Some take literally 10s of minutes to
> run. Some fail for absolutely inscrutable reasons. Even _I_ don't
> know how to satisfy some of them.
>
> And we expect our contributors to put up with this?
>
> I'm proposing a full moratorium on new update scripts, and on new
> behavior in existing scripts.
>
> I'm proposing that we set a goal that every one of those scripts runs
> to completion in 10 seconds or less, and that they have no external
> requirements (GOPATH, etc). If they fail or are aborted, they must
> leave the build functioning and leave no artifacts (as per `git
> status`).
>
> Every such script (and their corresponding verify script) needs a
> documented owning SIG or person, and needs an explicit statement of
> "this script has been sanitized".
>
> I'm proposing that whatever else we do in the 1.8 release cycle, we
> HAVE TO FIX THIS. If we don't, nobody will contribute, and I simply
> would not blame them.
I agree with all of this, but would like to share some experience when I first
contributed to kubernetes, that was very nice and because of scripts in `hack/`.
When I started hacking on kubernetes, it was REALLY useful for me to find a
script there that runs a kubernetes cluster so I could easily play with my
changes in a cluster locally. I used the `hack/local-up-cluster.sh` script for
that, at the time.
Maybe now there is a better way, but for my first experience (now I know it has
tons of other things) that was really good. And I'd really would like to keep an
easy way to do it for new contributors :)
But just that, keep in mind some are really useful (or were, at least :)).
Thanks a lot,
Rodrigo