[U-Boot] [PATCH 02/42] moveconfig: Add an option to commit changes

[Simon Glass]

Hi Masahiro,

On 26 August 2016 at 10:47, Masahiro Yamada <yamada.masahiro at socionext.com>
wrote:
> 2016-08-25 21:04 GMT+09:00 Simon Glass <sjg at chromium.org>:
>> Hi Masshiro,
>>
>> On 24 August 2016 at 19:40, Masahiro Yamada
>> <yamada.masahiro at socionext.com> wrote:
>>> 2016-08-25 1:51 GMT+09:00 Simon Glass <sjg at chromium.org>:
>>>> The moveconfig tool is quite clever and generally produces results that
>>>> are suitable for sending as a patch without further work. The main
required
>>>> step is to add the changes to a commit.
>>>>
>>>> Add an option to do this automatically. This allows moveconfig to be
used
>>>> from a script to convert multiple CONFIG options, once per commit.
>>>>
>>>> Signed-off-by: Simon Glass <sjg at chromium.org>
>>>
>>>
>>>
>>> Isn't it possible to do this in your script?
>>>
>>>
>>> BTW, I assume you want this feature
>>> for convert & git-commit per option.
>>>
>>>
>>> In my opinion, you do not have to split to
>>> per-option patches.
>>>
>>>
>>> You can move multiple options at once.
>>>
>>>
>>> tools/moveconfig SPL_DM SPL_RSA SPL_CRYPTO_SUPPORT ...
>>
>> Yes of course, but as you can see from your other comments, some
>> changes are simple and others result in comments and rework. It seems
>> better to deal with each change individually unless they really are
>> simple.
>>
>> Most of these changes affect a lot of boards. If there is a run-time
>> breakage it helps a lot if a bisect can pinpoint the change exactly.
>>
>>>
>>>
>>> Then, git commit and list all the moved options in the commit log.
>>
>> OK. I think the moveconfig tool should handle committing changes since
>> it can do a better job of creating a sensible commit message.
>
>
> No, I don't like this patch.
>
> Anyway, a good practice for moving options
> is to create a Kconfig entry and move configs in
> the same commit, unlike this series.
>
> So, you need some manual interventions
> to build up patches.

I don't think our current approach of conversion has been very successful.
One of the reasons is that even though we have some great automation, it
doesn't go far enough.

It should be possible to convert options over to Kconfig mostly
automatically. That way more people would be willing to try it, and it
would be less work for them.

I don't think it matters whether the Kconfig change is in a separate commit
so long as it is in the same series. I agree it seems like a good practice,
but I don't think it is very important.

Regards,
Simon