Hi! > This is good for external (non-core and non-extension) collaborators, particularly allowing write access to those who wouldn't want or need write access to engine code.
Yes, in theory. In practice I don't see too many of those flocking to it, unfortunately. As for process, I think we have enough people (starting with myself) that would gladly guide through any pull req to this particular part if asked, and I don't see anybody ever needing to go through RFCs etc. to contribute there. So the process is probably "make the pull, ping the list" :) > I lean toward the "keep it separate" option, since the process barriers > are much smaller. Couldn't we update Travis to clone the repo, run the > build/configure steps, then invoke the fuzzer as part of the make test > phase? Or, how about the other way: setup Travis on the fuzzing repo to > clone php/php-src:master, integrate it, and run? That's an interesting idea. I still like the integrated repo better, since it's easier for the person making changes to ensure everything builds properly instead of being alerted by Travis and go back digging for a third-party repo they may not even be aware of. But this could be an option too. And btw that reminds me that if it'd be integrated, we also need Travis build to support it. Separate thanks for this reminder! -- Stas Malyshev smalys...@gmail.com -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
