From mboxrd@z Thu Jan 1 00:00:00 1970 From: Sam Protsenko Date: Tue, 18 Jun 2019 14:42:20 +0300 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: List-Id: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: u-boot@lists.denx.de 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. Thanks! > >>> [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