On Wed, 2016-03-09 at 09:58 +0100, Laszlo Ersek wrote: > I disagree. A v1 can be (and very frequently is) applied from patches, > if it passes review at the first try. When the patches are picked up > from the list, and all patches get R-b's, then it's the maintainer that > adds the tags, so the contributor need not do anything else.
OK. So v1 is not to be applied as-is from patches; it needs the Reviewed-by tags added. Sometimes the submitter rounds them up when submitting v2; sometimes the maintainer adds them. > Whereas, for a purely merge-oriented workflow, even if the first > submission passed review fully, it would be the submitter's > responsibility to append the tags, and send a separate PULL with that > version of the series. Right. So in the optional case where the submitter wants to do that, they can add the Reviewed-by and other tags for themselves before submitting a v2. Or otherwise, the maintainer can add them. Note that is perfectly feasible for the maintainer to add the R-b tags even if he/she pulls the tree from the submitter. How the commits get from A to B is mostly irrelevant — the important thing for preserving history is that the commits are applied to the right base, and the resulting code is identical. (In the general case it's *also* frowned upon to edit commits after they've been made public. It's mostly important when there are lots of derivative trees which occasionally depend on each others' work. If you base your work on the early commits in *my* repository, and then I mess with them, then they're no longer the same commit. But in the EDK2 world I think that's less common, so editing commits is probably OK.) > I was only trying to reconstruct the argument for this claim, from the > kernel docs: > > Note, however, that pulling patches from a developer requires a > higher degree of trust than taking patches from a mailing list. > > It is perfectly possible that my attempt to retrofit a security argument > to this claim failed. But, in that case, can you please explain why the > above claim is valid? Or are you suggesting that this statement of > SubmittingPatches is bogus? I think the trust bit is bogus these days yes. I'll go fix it (qv). It might have had some historical relevance, when the tools were such that applying a series of patches *did* actually mean you had to look at them. But it's so easy to save a mailbox and use 'git am' these days, that crap can slip in *just* as easily as with a 'git pull'. > For several versions of the same patchset, I have a good workflow where > I can incrementally review only the new stuff (the changes), without > fully trusting the submitter. I compare the patch emails as well between > each other, and I can git-diff the end results of the various versions. > > The same seems possible with branches that are to be merged, sure, it's > just that I don't yet have hands-on experience with that. Yeah, it's basically the same. But again, this is why we shouldn't take half-measures. You're getting used to a workflow that *doesn't* represent how we should be using the tools correctly. And that means the pain of the transition to git is multiplied. > Thank you, but thus far noone has complained as vehemently as you about > rebasing as a norm (for now), for the sake of a linear history. I've had > series with 50+ patches, and I don't recall any rebase-incurred problems. Excellent. That means we can fix it, and start keeping *accurate* history in the version control system (which is, after all, what version control systems are for), before our laxity ever caused you a real problem. > I don't want to dismiss this endeavor, but with QEMU and top Linux > maintainers insisting on signed tag pulls, and you saying "nonsense" to > it (or to my attempt anyway to interpret that requirement), I feel much > less confident about a pull-based workflow. Signed pulls are about personal trust. If you have signed emails or a signed pull request from someone you trust sufficiently, you don't *need* to look at the content. There is no difference between email and pull requests, in this respect. Likewise, if you are taking submissions from someone in whom you do not have sufficient trust, then you *do* to need to look at the content. There is no difference between email and pull request in this respect either. -- David Woodhouse Open Source Technology Centre [email protected] Intel Corporation
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ edk2-devel mailing list [email protected] https://lists.01.org/mailman/listinfo/edk2-devel
