[U-Boot] [PULL] u-boot-usb/master

[Marek Vasut]

On 6/18/19 1:42 PM, Sam Protsenko wrote:
> Hi Marek,
> 
> On Sat, Jun 15, 2019 at 6:16 PM Marek Vasut <marex at denx.de> wrote:
>>
>> On 6/15/19 4:24 PM, Eugeniu Rosca wrote:
>>> Hi Marek,
>>>
>>> On Sat, Jun 15, 2019 at 02:35:12PM +0200, Marek Vasut wrote:
>>>> On 6/15/19 11:46 AM, Eugeniu Rosca wrote:
>>>>> Hello Marek, Lukasz cc: Sam
>>>>>
>>>>> On Sat, Jun 15, 2019 at 5:23 AM Marek Vasut <marex at denx.de> wrote:
>>>>> [..]
>>>>>> Sam Protsenko (3):
>>>>>>       fastboot: Fix slot names reported by getvar
>>>>>
>>>>> Commit [1] from this PR got replaced by series [2].
>>>>
>>>> Replaced where ? [1] seems like a fix to me, [2] seems like feature
>>>> addition ,
>>>
>>> Your instincts are correct (i.e. features must be rejected at this late
>>> stage) and they deserve credits. However and what seems extremely
>>> interesting is:
>>>  - it is very easy to masquerade a fix as a feature (and viceversa),
>>>    just by slightly adjusting the title [1-2] and it's very easy to
>>>    play with your perception this way
>>
>> Likely because free software development is built on trust. If there are
>> malicious actors who decide to not play nice, and even try to manipulate
>> others by elaborately crafting commit messages or otherwise, this might
>> work out to worm patches in. But at the end of the day, this helps no
>> one, so please refrain from such underhanded practices.
>>
> 
> I believe it's for maintainer to decide, which patches are ok to go to
> -rc, and which are not. We can always discuss that here in mailing
> list, if something is not clear.
> 
>>>  - it seems like there isn't a process (and this is a OSS-wide issue) of
>>>    marking a patch as fix/feature (the latter would help the maintainer
>>>    enormously)
>>
>> Maybe you can start a separate thread and help figure out such a
>> process? Complaining about unrelated stuff under random patches/PRs
>> won't make that happen, it will only happen if someone takes the
>> initiative. Scratching your own itch and all that.
>>
>>>  - it also appears that sometimes there is a fine line in our minds
>>>    between what's a fix and what's a feature
>>>
>>> So, in a nutshell, series [2] is the v2 of commit [1].
>>> IMHO there is no feature added.
>>> The two commits from series [2] are:
>>>  - https://patchwork.ozlabs.org/patch/1116099/
>>>  - https://patchwork.ozlabs.org/patch/1116101/
>>
>> Seems this was not clearly marked as so.
>> I would suggest Sam sends a V3 on top of this PR and be done with it.
>>
> 
> Agreed. From my point of view, both V2 and V3 are simultaneously
> harmless *and* not required in this release. Just because there are no
> users for A/B slotted partitions in upstream U-Boot right now.
> 
> The only important fix to be included in release, is this patch-series:
> 
>     [PATCH v3 0/3] fastboot: Fix getvar "has-slot" and cleanup
> 
> which actually fixes fastboot on non-slotted partitions (like on
> BeagleBoard X15), where right now we are unable to flash images.
> 
>>> What's interesting is that, depending on which version of fastboot
>>> utility users use/assume, they might see a "regression" introduced
>>> by [1-2]. Both [1-2] do changes to align U-Boot with latest fastboot
>>> utility from AOSP. What [2] is doing _in addition_ to [1] is:
>>>  - remove some dead code in U-Boot which will never be exercised
>>>    assuming users run the latest fastboot
>>>  - place a bold warning in commit description that users are assumed to
>>>    be using the latest fastboot utility
>>
>> If this can be fixed better, patches welcome.
>>
>>>> so merging [1] this late in the release cycle seems like the
>>>> right thing to do.
>>>
>>> My assumption is that Sam would like to see [1] being dropped in favor
>>> of [2], as commented in https://patchwork.ozlabs.org/patch/1114850/#2194140
>>
>> I will leave that up to Sam and Lukasz to figure this out.
>> However, I would prefer a V3 on top of this PR, that's easiest IMO.
>>
> 
> Let's make it so. I can send V3 later. Discussed patch ("fastboot: Fix
> slot names reported by getvar") is not crucial anyway, I guess.

Please do, the USB PR is now in.

-- 
Best regards,
Marek Vasut