From mboxrd@z Thu Jan 1 00:00:00 1970 From: Marek Vasut Date: Tue, 18 Jun 2019 14:05:13 +0200 Subject: [U-Boot] [PULL] u-boot-usb/master In-Reply-To: References: <336fad3a-3157-35f7-d291-b49419833ea4@denx.de> <20190615142440.GA30299@x230> <85d5c80d-72e1-a7e1-b9e1-4fae02b9c8a1@denx.de> Message-ID: List-Id: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: u-boot@lists.denx.de On 6/18/19 1:42 PM, Sam Protsenko wrote: > Hi Marek, > > On Sat, Jun 15, 2019 at 6:16 PM 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. >> > > 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