From owner-svn-src-stable@freebsd.org Thu Mar 29 02:57:45 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 ACEA7F6ADE1; Thu, 29 Mar 2018 02:57:45 +0000 (UTC) (envelope-from gjb@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [96.47.72.132]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "freefall.freebsd.org", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 5BEF874123; Thu, 29 Mar 2018 02:57:45 +0000 (UTC) (envelope-from gjb@FreeBSD.org) Received: from FreeBSD.org (freefall.freebsd.org [IPv6:2610:1c1:1:6074::16:84]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by freefall.freebsd.org (Postfix) with ESMTPS id EDBEC1BCBC; Thu, 29 Mar 2018 02:57:44 +0000 (UTC) (envelope-from gjb@FreeBSD.org) Date: Thu, 29 Mar 2018 02:57:42 +0000 From: Glen Barber To: rgrimes@FreeBSD.org Cc: Eitan Adler , src-committers , svn-src-all@FreeBSD.org, svn-src-stable@FreeBSD.org, svn-src-stable-11@FreeBSD.org, FreeBSD Release Engineering Team Subject: Re: Mismerge at r330897 in stable/11, Audit report Message-ID: <20180329025742.GQ81123@FreeBSD.org> References: <20180329022626.GP81123@FreeBSD.org> <201803290249.w2T2n6Hq060412@pdx.rh.CN85.dnsmgr.net> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="3mUD2hqWbnBptYHy" Content-Disposition: inline In-Reply-To: <201803290249.w2T2n6Hq060412@pdx.rh.CN85.dnsmgr.net> User-Agent: Mutt/1.9.1 (2017-09-22) 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 02:57:45 -0000 --3mUD2hqWbnBptYHy Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable 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?l= imit_changes=3D0&r1=3D330897&r2=3D330896&pathrev=3D330897 > > > >> > > > > >> > Can we try to identify exactly what rXXXXXX that is a merge of? > > > >> > > > > >> >> >> Could you please MFC back the other random related changes t= oo? 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 reve= rting > > > >> >> those fixes. > > > >> >> > > > >> >> That said, I should do that since this commit message is utterl= y 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.) > > >=20 > > > 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. > > >=20 > > >=20 > > > Note that I won't have access my dev box after tomorrow for about a w= eek. > > >=20 > >=20 > > 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). > >=20 > > Any disagreements on this decision should be directed to me specifically > > in this case. >=20 > 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. >=20 > In Eitans absence I am willing to take responsiblity to untangle > the wrong bits and clean up stable/11. >=20 > Ok? >=20 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. > Eitan, > Are you ok with that as well? >=20 Glen --3mUD2hqWbnBptYHy Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAEBCAAdFiEEjRJAPC5sqwhs9k2jAxRYpUeP4pMFAlq8ViYACgkQAxRYpUeP 4pMKvA/+MJv2LFCULUtMLBWkffHxkn0Y/3CiNkObu/6WaAf2gdO4W5QyDn+RlTL8 Sz1mQOZdlym2wdlPjQo1+OpdSO5SwgIx8M2SIMRj1vBb8JrnXUkzNM5zfG4CXiQm 8IqLzpnQ94yzv9NFrM5NIWIq96mlE5A2j/hfHus+BjV7bczEFAEGKAcZ8YN2q0wQ oPINIra32YsHtorJ1UvLe9RSqlAVLJ8SFjhU+em20MTF3cFLk1/vpgFgjLz1rV3X k2bKalkCgiOycnyVStV2yghrxj0WP3/7P+RlMzaFWhUmu6/Apxsm+FOZT7TPxHBE 2/1uXQs8HGuQijbF1/qCiP+LTCfzAeLjfPN4vDaomh7YtXfAFBDSZnA9Nc1Lfv1N b0avZc+j4WDc/gZ8gdkRQcI6uhOYY+cMg4eYEj/tq8qqcriiWjmIrheCuwhbEEX8 cEkSwPQ2tTYA38o0HYAw3ccdssrMRMlo6CXDiOVltMVz2Mjns99Nq1vB6v6i7rGr V6XJTz+lsh8e9GJLqCCtsetBpi1cnCzUV0DJ4dqCAluk2ySrJlRy18lpqTHyDLFd p/MbpUwn/0lfmA5VgnKmUfpop6OXoymyRM0u7OMJA5bI2z0NYMJnWDyK1MEqL7Uq vXJ94ISb11x+ai2702E89EdVwnmKLhx1koK86vbwPU8aJ80z5rI= =bTQ0 -----END PGP SIGNATURE----- --3mUD2hqWbnBptYHy--