On 7/9/2019 6:05 PM, Junio C Hamano wrote: > Derrick Stolee <stolee@xxxxxxxxx> writes: > >> From this list, do you think any of these settings are likely to >> become defaults? It seems that protocol.version = 2 may be a default >> now that _most_ services have an implementation, and it always falls >> back to protocol v1 without extra cost. >> >> When pack.useSparse was first introduced, I considered making it true >> by default after a while. But you protested, saying you want people >> knocking at the door saying it is useful. What if it lived here? >> >> fetch.negotiationAlgorithm and merge.directoryRenames seem like >> valuable features and maybe just need more time out in the world >> before they could be considered defaults. > > I mostly agree with the categorization you gave above. > > I think it is perfectly fine for a knob, after proving its worth by > existing in the world without being a part of any feature.* set, to > become part of feature.experimental, and then later be ejected > without ever becoming the default in response to reactions by real > world users. This would be easier to arrange if we had at least two > experiment levels. One class would be "we are firmly committed to > make these default in the future and ironing kinks out---please help > by setting feature.experimental on" and is more for early adopter > testing. The other class may be "we try this on users to see if > there are some populations of them with usage patterns we did not > anticipate, and will yank it out if it turns out to be problematic > to some users." The more guinea pig users opt into the latter > "Highly Experimental" category, the more help they can give us to > prevent an ill-thought-out feature that does not universally help to > become a new default. How about "feature.preview" for defaults we expect to change in a later version, while "feature.experimental" is for defaults we are not sure about? -Stolee
