From owner-svn-src-stable@freebsd.org Thu Mar 29 03:01:47 2018 Return-Path: Delivered-To: svn-src-stable@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id BCB57F6B3C8; Thu, 29 Mar 2018 03:01:46 +0000 (UTC) (envelope-from freebsd@pdx.rh.CN85.dnsmgr.net) Received: from pdx.rh.CN85.dnsmgr.net (br1.CN84in.dnsmgr.net [69.59.192.140]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 41935747C8; Thu, 29 Mar 2018 03:01:45 +0000 (UTC) (envelope-from freebsd@pdx.rh.CN85.dnsmgr.net) Received: from pdx.rh.CN85.dnsmgr.net (localhost [127.0.0.1]) by pdx.rh.CN85.dnsmgr.net (8.13.3/8.13.3) with ESMTP id w2T31h8R060566; Wed, 28 Mar 2018 20:01:43 -0700 (PDT) (envelope-from freebsd@pdx.rh.CN85.dnsmgr.net) Received: (from freebsd@localhost) by pdx.rh.CN85.dnsmgr.net (8.13.3/8.13.3/Submit) id w2T31fpe060565; Wed, 28 Mar 2018 20:01:41 -0700 (PDT) (envelope-from freebsd) From: "Rodney W. Grimes" Message-Id: <201803290301.w2T31fpe060565@pdx.rh.CN85.dnsmgr.net> Subject: Re: Mismerge at r330897 in stable/11, Audit report In-Reply-To: <20180329025742.GQ81123@FreeBSD.org> To: Glen Barber Date: Wed, 28 Mar 2018 20:01:41 -0700 (PDT) CC: rgrimes@FreeBSD.org, Eitan Adler , src-committers , svn-src-all@FreeBSD.org, svn-src-stable@FreeBSD.org, svn-src-stable-11@FreeBSD.org, FreeBSD Release Engineering Team Reply-To: rgrimes@FreeBSD.org X-Mailer: ELM [version 2.4ME+ PL121h (25)] MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII X-BeenThere: svn-src-stable@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: SVN commit messages for all the -stable branches of the src tree List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Mar 2018 03:01:47 -0000 > On Wed, Mar 28, 2018 at 07:49:06PM -0700, Rodney W. Grimes wrote: > > > On Wed, Mar 28, 2018 at 07:17:20PM -0700, Eitan Adler wrote: > > > > On 28 March 2018 at 19:04, Rodney W. Grimes > > > > wrote: > > > > >> On 28 March 2018 at 18:35, Rodney W. Grimes > > > > >> wrote: > > > > >> >> >> Hi! > > > > >> >> >> > > > > >> >> >> This part of the MFC is wrong: > > > > >> >> >> > > > > >> >> >> https://svnweb.freebsd.org/base/stable/11/sys/sys/random.h?limit_changes=0&r1=330897&r2=330896&pathrev=330897 > > > > >> > > > > > >> > Can we try to identify exactly what rXXXXXX that is a merge of? > > > > >> > > > > > >> >> >> Could you please MFC back the other random related changes too? Some > > > > >> >> >> of them made by cem@. > > > > >> >> >> > > > > >> >> >> On 3/14/18, Eitan Adler wrote: > > > > >> >> >>> Author: eadler > > > > >> >> >>> Date: Wed Mar 14 03:19:51 2018 > > > > >> >> >>> New Revision: 330897 > > > > >> >> >>> URL: https://svnweb.freebsd.org/changeset/base/330897 > > > > >> >> >>> > > > > >> >> >>> Log: > > > > >> >> >>> Partial merge of the SPDX changes > > > > >> >> >>> > > > > >> >> >>> These changes are incomplete but are making it difficult > > > > >> >> >>> to determine what other changes can/should be merged. > > > > >> >> >>> > > > > >> >> >>> No objections from: pfg > > > > >> >> >>> > > > > >> >> > Am I missing something? If this MFC was supposed to be of the SPDX > > > > >> >> > license tagging, why does it have any functional changes? > > > > >> >> > > > > > >> >> > Especially changes to random(4)? > > > > >> >> > > > > >> >> This was my failure. I only spot checked & compile-checked the diff > > > > >> >> since I expected all changes to be comments/SPDX. > > > > >> >> > > > > >> >> However, I must have gotten carried away and included a few too many > > > > >> >> revisions. Unfortunately some people have already merged fixes to my > > > > >> >> failure and thus this can't be reverted as is without also reverting > > > > >> >> those fixes. > > > > >> >> > > > > >> >> That said, I should do that since this commit message is utterly wrong. > > > > >> > > > > > >> > We do not have to revert r330897, with what follows I think > > > > >> > we can easily find the revisions to revert from stable/11. > > > > >> > ... > > > > >> > > > > >> While we don't have to revert it I'd rather do so than have bogus history. > > > > > > > > > > Reverting wont remove that history, thats a one way deal, > > > > > and I think if we revert the bogus merges with the wrong > > > > > history thats as good as its gona get. > > > > > > > > > >> > > > > >> >From a look it seems the following was also merged: > > > > >> r316370, r317095, r324394, and a few others. > > > > >> > > > > >> Is there a reason you don't want me to revert the changes? > > > > > > > > > > Repository churn is my main concern. > > > > > > > > > > It touches 6000+ files some of which have probably > > > > > been touched since. A very carefull pre commit > > > > > audit would need to be done. > > > > > > > > > > Then another commit to 6000+ files to put it back, > > > > > also needing a pre-commit audit. (Pretty easy now > > > > > that I have a filter.) > > > > > > > > I'm actually using the same filter you pasted above to verify that my > > > > changes are only reverting said files. That said, while I'd prefer to > > > > revert, I'll defer to others if they have a differing opinion. > > > > > > > > > > > > Note that I won't have access my dev box after tomorrow for about a week. > > > > > > > > > > IMHO, if you are going to be away for over a week while we're headed > > > directly into the 11.2 release cycle, revert the change. What you > > > committed is not what was intended, clearly, and the commit message does > > > not reflect what had happened (as you noted). > > > > > > Any disagreements on this decision should be directed to me specifically > > > in this case. > > > > Glen, > > I would rather not revert, as I believe that would cause more > > damages as people have already cleaned up some of the mis merge from > > this commit. I am pretty sure a revert would lead to a broken tree. > > > > In Eitans absence I am willing to take responsiblity to untangle > > the wrong bits and clean up stable/11. > > > > Ok? > > > > I disagree with this approach. A mishandled merge which as in this case > contains extraneous changes limit our ability to properly audit the > branch. > > My strong feeling is that if "too many" revisions were merged, we should > not piecemeal break out what should not have been included. We should, > instead, revert the offending commit as an "oops", redo the intended > merge, and then in a separate commit re-apply the bits from the > offending merge in a completely separate commit. > > While this may be perceived as churn against the tree, it keeps tracking > what happened much easier to manage, especially if we were to have to > rely on mergeinfo. And now already reverted, so moot. > > Eitan, > > Are you ok with that as well? Eitan, I think the re merge of SPDX can wait tell you get back, you have the list of revisions already, and I am more than willing to audit your diff pre commit. Thanks, -- Rod Grimes rgrimes@freebsd.org