[U-Boot] [PATCH 00/93] dm: Move towards completing CONFIG_BLK migration

[Marek Vasut]

On 11/19/2018 11:02 PM, Adam Ford wrote:
> On Mon, Nov 19, 2018 at 3:54 PM Tom Rini <trini at konsulko.com> wrote:
>>
>> On Mon, Nov 19, 2018 at 10:32:01PM +0100, Marek Vasut wrote:
>>> On 11/19/2018 08:45 PM, Adam Ford wrote:
>>>> On Mon, Nov 19, 2018 at 12:36 PM Tom Rini <trini at konsulko.com> wrote:
>>>>>
>>>>> On Mon, Nov 19, 2018 at 10:54 AM Simon Glass <sjg at chromium.org> wrote:
>>>>>>
>>>>>> All boards should now be migrated to use CONFIG_BLK. This series removes
>>>>>> those with build problems using this option.
>>>>>>
>>>>>> If maintainers want to keep these boards in they should send a patch in
>>>>>> the next week or two. Otherwise the board will be removed in the next
>>>>>> release, and will need to be added and re-reviewed later.
>>>>>>
>>>>>> The goal is to have all boards use driver model. But so far, we do allow
>>>>>> CONFIG_DM to not be defined.
>>>>>>
>>>>>> PLEASE NOTE: This is not an easy process. It is possible that your board
>>>>>> does work, or works with only minor changes. Please try to understand that
>>>>>> the removal of a board is not done because people don't like your board.
>>>>>> In fact the board might have been the first one I used when trying out
>>>>>> U-Boot! It's just that we expect maintainers to keep up with the migration
>>>>>> to driver model which has been running now for 4 years. It just isn't
>>>>>> possible for a few people to migrate and test hundreds of boards.
>>>>>>
>>>>>> So, send a patch!
>>>>>
>>>>> OK, so with the intention of "need to light a fire", consider the fire
>>>>> lit!  But, I think v2 of this series needs to:
>>>>> - Address the bug that's been noted of you checking on "DM_BLK" when
>>>>>   it's really just "BLK".
>>>>> - Do a test build with BLK just being unconditional now.  For example,
>>>>>   you're deleting the am335x_evm family but it builds fine with BLK
>>>>>   being enabled now.  I even gave it a run time test via test.py and
>>>>>   we're fine.  So, I think a new run where you see what fails to build
>>>>>   with BLK enabled by default now is in order to come up with a new
>>>>>   delete list.
>>>>>
>>>>
>>>> When we were migrating toward GCC 6, we introduced a warning message
>>>> that was displayed at build indicating older versions of GCC would be
>>>> unsupported, and GCC 6 would become a requirement.  The
>>>> CONFIG_DM_I2C_COMPAT generates a build warning and suggests that it be
>>>> removed.  I would like to propose that in the future, when setting
>>>> deadlines, we insert something into the build mechanism that generates
>>>> a warning to tell people that something is going to happen.
>>>
>>> I agree, that sounds good.
>>>
>>> I am extremely unhappy by how Simon decided, unilaterally, some
>>> arbitrary deadline, told pretty much no one about that deadline and then
>>> put a knife on many peoples' throats by sending out this series which
>>> removes boards that are actively used and maintained, demanding they be
>>> converted right this instant.
>>
>> OK, lets step back for a moment.  Part of the problem is that yes, we
>> (I) never found a good way to make a big scary build warning happen.
>> But, lets look at https://patchwork.ozlabs.org/patch/798309/ for a
>> moment, which is when we set this deadline, and we had a good bit of
>> discussion about related issues to make it happen.
>>
>> I also know that around the v2018.05 release I said, in public, but no I
>> can't find a link right this moment, that we were pushing off a little
>> bit on dropping _everything_ right then as there was basically some
>> fairly important / widely used USB stuff that hadn't been converted yet
>> (which has since been, I think, otherwise am335x_evm & co wouldn't have
>> been happy?).  I know I did since I can see in the archives a number of
>> series where maintainers did a bunch of changes to various platforms /
>> SoCs to turn on BLK right then.
>>
>> So, no, I don't want to drop a bunch of platforms _right_now_.  But we
>> really need to see what doesn't link anymore with BLK forced on, and
>> plan from there.
> 
> I remember the discussion, but it seems rather arbitrary for one
> person to unilaterally start deleting boards. I think a more
> appropriate approach would be to start a dialog instead of deleting
> boards and then giving people a fairly short notice to respond -
> especially this close to the US Thanksgiving holiday, several
> religious holidays and New Years.  Many people have planed time off
> and/or end-of-year deadlines to hit without getting an abrupt suprise.

ACK

-- 
Best regards,
Marek Vasut