[PATCH RFC] ui: add support for a tweakdefaults knob

Pierre-Yves David pierre-yves.david at ens-lyon.org
Tue Jun 20 05:48:22 EDT 2017



On 06/20/2017 03:53 AM, Augie Fackler wrote:
>
>> On Jun 19, 2017, at 11:32 AM, Pierre-Yves David <pierre-yves.david at ens-lyon.org> wrote:
>>
>>>>
>>>> I'm not sure what is your concerns here can you elaborate? We have about
>>>> 200 known config option in core. That seems a manageable number of object.
>>>
>>> Sorry, I just felt it's overengineered. I don't have no particular concern
>>> about speed.
>>>
>>>> As centralized config growth feature it will needs one item for each
>>>> config option anyway (alias, default, documentation, etc...).
>>>> Do you have an alternative idea in mind?
>>>
>>> Hmm. If we want these features, perhaps configitem() function would be the
>>> best.
>>
>> I think we want these features. David Demelier (+ at least I) want the alias feature for ConfigConsolidationPlan. Gregory Szorc (and others including me) wants the documentation features. If someone has concerns about these feature we should probably resolves them before pushing further forward.
>>
>> I agree that without the future (more complex) feature, that would be a bit heavy (a simple list of 3 tuples would be fine) :-)
>
> I’ve got some nits about the API as expressed in that series, but I see overall merit if it gives us a centralized way to manage config options (and more importantly documenting them in a consistent way).
>
> I think I’d like to leave actually registering a config knob as optional for a cycle to see if it gets much adoption though - feels like a lot of churn to put people through all at once for what is (for now) unclear benefit, especially when you consider how disruptive 4.3 has already been...

I agree here, I'm not planning to make registration mandatory in 4.3. In 
all cases we'll start with at least one cycle of devel-warning about 
unregistered option and we might want to keep unregistered option 
supported for a long while (with a devel warning).

A key feature to push code toward config registration will be the 
documentation management.

Cheers,

-- 
Pierre-Yves David


More information about the Mercurial-devel mailing list