From mboxrd@z Thu Jan 1 00:00:00 1970 From: Tom Rini Date: Mon, 17 Jun 2019 11:31:59 -0400 Subject: [U-Boot] [PULL] u-boot-usb/master In-Reply-To: <85d5c80d-72e1-a7e1-b9e1-4fae02b9c8a1@denx.de> References: <336fad3a-3157-35f7-d291-b49419833ea4@denx.de> <20190615142440.GA30299@x230> <85d5c80d-72e1-a7e1-b9e1-4fae02b9c8a1@denx.de> Message-ID: <20190617153159.GU9388@bill-the-cat> List-Id: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: u-boot@lists.denx.de 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 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: