github.com/go-fuzz

[AlekSi]

I was reading through #218 where @josharian mentioned:

That import path will obviously have to change if go-fuzz moves into the standard toolchain. Or if we migrate to github.com/go-fuzz/go-fuzz, or the like.

My first thought was "oh, that would be really cool to have this org on GitHub". Then I realized that I already created that org for my early prototype. It went nowhere, so I'm happy to donate it to @dvyukov (please see invitation). Feel free to use for another prototype, for Fuzzing Evangelism Strike Force community place, or for anything else.

/cc @thepudds

[dvyukov]

Thanks!
That's definitely better than a private repo.
So if we name the repo go-fuzz and have the command sub-dir go-fuzz, that will be github.com/go-fuzz/go-fuzz/go-fuzz. We need to go-fuzz deeper! :)

[dvyukov]

Any suggestions on how to better move the code? Just pull from my repo and push there? Any caveats with this?

[dvyukov]

Also @josharian @thepudds what do you think about moving go-fuzz to the new location? Is it worth it?

[thepudds]

This might be too optimistic, but I guess at least personally I'm hoping the #19109 proposal can get into a state where it is is ready to be re-reviewed by the core Go team during the 1.13 freeze or maybe shortly after the 1.14 tree opens. The transition to modules I think has been mostly maxing out the people who work on cmd/go and the tooling team who have been building things like sum.golang.org, proxy.golang.org, gopls, etc., but I'm at least hoping there might be some breathing room roughly around then such that there is time to review the proposal. (That might be too optimistic both in terms the core Go team having time as well as time for work on the proposal itself, but one can always hope ;-)

Of course, actually implementing the proposal is further away than that, but if that is the rough timeframe for getting a thumbs up / thumbs down on the proposal itself, then migrating to go-fuzz/go-fuzz might be unnecessary churn in the short term (including issue migrations, etc.). Also, dvyukov/go-fuzz has a certain amount of recognition across the world-wide gopher population, whereas go-fuzz/go-fuzz does not.

If the review ends with a decline, or if over the course of the next few months it seems like it might be more like 12-18 months before a re-review of the proposal is going to happen, then in that case it might make sense to settle in more for the long haul and do the migration.

Of course, it is possible to have a different opinion, but that is my quick two cents...

[dvyukov]

Fair enough.

[dgryski]

The proper thing to do from GitHub's perspective is to transfer ownership of the existing repo to the organization. This has the benefit that GitHub will handle redirects when people visit the current repo. It will also handle cloning from the old location (although if/when the repo is moved we'll probably want to add import path comment so people know about the change.)

I'm against moving to a go-fuzz organization unless we know we're not going to be integrated into the main tool just to avoid breaking things twice.

[AlekSi]

Feel free to use for another prototype, for Fuzzing Evangelism Strike Force community place, or for anything else.

Also, feel free to not use it for anything. :) Up to you. Just wanted to let you know that this org is not squatted by an unknown party.

[josharian]

Thanks, @AlekSi! Very, very much appreciated.

I think that we should move if/when two conditions are met:

• It is clear that integration into the core go tool won't happen soon.
• There are breaking changes we want to make. I've taken pains to retain backwards compatibility, but at some point we might want to remove all those shims and adapters.

[dgryski]

@josharian Breaking changes are probably easier before we get integrated into the standard tooling. I wonder if it does make sense to leave dvyukov/go-fuzz stable and push a clone to go-fuzz/go-fuzz (or perhaps dvyukov/go-fuzz2?) with no promises of stability as a playground to start the remodelling.

[josharian]

Interesting idea. Although I think it’d be better to do that with a branch for now.

[tv42]

If you use github repo transfers, it breaks all users of the old import path (that don't have it cached already).

But I'm in favor of "stdlib or bust".

[dvyukov]

Re stdlib integration, if there is an agreement that fuzzing goes in, the first step would be to add testing.F and go tool support for building the binary. We don't need any instrumentation, coverage nor complex logic at all, we just need the public interfaces and feed dumb random garbage. The rest can be added incrementally under the hood later. For corpus we could save just 1 file to denote the location, maybe update it on each run to denote the "churn". Trying to implement all or nothing is never a good idea (that will always be nothing then).

[tv42]

I mean "stdlib or bust" in the sense that if there's a good chance fuzzing becomes part of the standard toolchain, independent development to "make it prettier" (switching repo locations, import paths) seems not useful.