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

[Tom Rini]

On Sat, Jun 15, 2019 at 04:43:38PM +0200, Marek Vasut 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.

Yes, as a community we expect people to be clear and, well, plainly
spoken, perhaps is the best way to say it.  A bug fix is a bug fix and a
new feature is a new feature.

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

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

Agreed.  Thanks all!

-- 
Tom
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: not available
URL: <http://lists.denx.de/pipermail/u-boot/attachments/20190617/2db74060/attachment.sig>