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.
