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

[Marek Vasut]

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.

>  - 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.

> 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.

>>> [1] https://git.denx.de/?p=u-boot/u-boot-usb.git;a=commit;h=97a0c6ff577d57f162abc696c4efc962981229b1
>>> [2] https://patchwork.ozlabs.org/cover/1116097/ ("fastboot: Support
>>> new A/B slot format")
>>>
> 


-- 
Best regards,
Marek Vasut