From owner-dev-commits-src-main@freebsd.org Thu Dec 31 06:03:10 2020 Return-Path: Delivered-To: dev-commits-src-main@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 4B2574DDE25; Thu, 31 Dec 2020 06:03:10 +0000 (UTC) (envelope-from freebsd@gndrsh.dnsmgr.net) Received: from gndrsh.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 4D5yHx5xlWz3pjJ; Thu, 31 Dec 2020 06:03:09 +0000 (UTC) (envelope-from freebsd@gndrsh.dnsmgr.net) Received: from gndrsh.dnsmgr.net (localhost [127.0.0.1]) by gndrsh.dnsmgr.net (8.13.3/8.13.3) with ESMTP id 0BV62xEp085089; Wed, 30 Dec 2020 22:02:59 -0800 (PST) (envelope-from freebsd@gndrsh.dnsmgr.net) Received: (from freebsd@localhost) by gndrsh.dnsmgr.net (8.13.3/8.13.3/Submit) id 0BV62xUk085088; Wed, 30 Dec 2020 22:02:59 -0800 (PST) (envelope-from freebsd) From: "Rodney W. Grimes" Message-Id: <202012310602.0BV62xUk085088@gndrsh.dnsmgr.net> Subject: Re: git: 70e64ba44941 - main - release.sh: Update GITROOT URL In-Reply-To: To: Warner Losh Date: Wed, 30 Dec 2020 22:02:59 -0800 (PST) CC: "Rodney W. Grimes" , Glen Barber , src-committers , dev-commits-src-all@freebsd.org, dev-commits-src-main@freebsd.org 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-Rspamd-Queue-Id: 4D5yHx5xlWz3pjJ X-Spamd-Bar: ---- Authentication-Results: mx1.freebsd.org; none X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[] X-BeenThere: dev-commits-src-main@freebsd.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: "Commit messages for the main branch of the src repository." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 31 Dec 2020 06:03:10 -0000 > On Wed, Dec 30, 2020 at 2:31 PM Rodney W. Grimes > wrote: > > > > On Wed, Dec 30, 2020 at 5:13 AM Rodney W. Grimes < > > freebsd@gndrsh.dnsmgr.net> > > > wrote: > > > > > > > > On Tue, Dec 29, 2020 at 04:18:07PM -0800, Rodney W. Grimes wrote: > > > > > > > The branch main has been updated by gjb: > > > > > > > > > > > > > > URL: > > > > > > https://cgit.FreeBSD.org/src/commit/?id=70e64ba4494190e64ab8faa04d744182d420c275 > > > > > > > > > > > > > > commit 70e64ba4494190e64ab8faa04d744182d420c275 > > > > > > > Author: Glen Barber > > > > > > > AuthorDate: 2020-12-29 14:34:05 +0000 > > > > > > > Commit: Glen Barber > > > > > > > CommitDate: 2020-12-29 14:40:28 +0000 > > > > > > > > > > > > > > release.sh: Update GITROOT URL > > > > > > > > > > > > > > Hard-code the GITROOT for the ports tree to use cgit-beta > > > > > > > until the ports repository is converted. > > > > > > > > > > > > > > While here, remove $FreeBSD$ RCS IDs. > > > > > > > > > > > > So how do I know what version of some file I am looking at > > > > > > once it has been dis-associated from a git clone? > > > > > > > > > > > > > > > > You can't. Git does not expand the tags. > > > > > > > > And no new mechanism in place to replace it? So, we have > > > > no versioning of files in the final product any more? > > > > > > > > > > No. We will not. > > > > That I take a very hard line against, that is IMHO a very big mistake. > > > > Your opinion has been noted. > > > > > > Sad, very very sad :-(. This may cause some down streams, > > > > other than me, some very serious heart ache. > > > > > > > > > > Git provides tools to reduce that heart ache. You can get the same info, > > > but using different means using git's tools should you need to. > > > > See other mail to Ryan, those tools well not help with the issues > > of locally modified files and being able to figure out what base > > they started with. > > > > You describe a source code management nightmare that $FreeBSD$ might be > able to solve a subset of cases, but other methods will solve them better. This is not a source code management nightmare, it is a traceability of production items, this "feature" has been in BSD since /bin/what was written to extract SCCS id's out of binary files. That got broken cause we stoped putting them in, but the strings of $FreeBSD$ have always been in the binaries. This gives traceability. > > > > > > > > > Is there some new mechanism that can give me the cadence of > > > > > > say, /etc/pkg/FreeBSD.conf once its FreBSD ID is riped out? > > > > > > > > > > > > Also if $FreeBSD$ needs to be removed, can we please just do > > > > > > it in one massive tree wide commit rather than have this > > > > > > random piece wise needless noise in 1000's of commits? > > > > > > > > > > > > > > > > Please, no. There is no benefit to prune these in one fell swoop as > > > > > opposed to, for example, bumping Copyright dates. > > > > > > > > Well have to disagree on that. > > > > > > > > a) If it is removed in one fell swoop it can also probably > > > > be undone in one fell swoop too. > > > > > > > > > > It won't ever be undone, so this is irrelevant. > > > > I would be careful with any claim of never. > > > > I am. It's an extremely poor fit to git, has extreme resistance in git > upstream and the available git support is too limited to be useful. Big > effort, low reward item in a volunteer project generally means it won't > happen when there's other workarounds that are simpler and easier. So basically anything that git doesnt fit is now gone.. *sigh* > > > > b) It concentrates the change in 1 commit that does NOT > > > > ever need to be MFC'ed. > > > > > > > > > > That causes merge conflicts for everybody for years. The cost here is too > > > high. > > > > Again, please, enlighten me how a 1 line +- delta in a file is going to > > cause any merge conflict outside of +-3 lines from that line? These > > strings are VERY well located and in areas that should be very rarely > > touched. Very different than things like large white space clean up. > > > > Let's do some math. We have about 10k commits on a stable branch, give or > take. My experience with MFCing suggests that 5% of these will have a merge > conflict that needs to be resolved. Each one of these conflicts takes 5 > minutes to resolve because it breaks up the flow of the commits, etc. So > ~500 commits for ~5 minutes is ~40 hours. We've just wasted an entire week > of developer time for doing it all at once, vs almost 0 for doing it > incrementally. Your math is not math if you claim that this delta would cause 5% conflicts. MOST MFC conflicts occur because of missing interveing commits. You still have not explained how a 1 line delta removing a line is likely to cause any conflict at all, and I continue to assert it is very unlikely to as this 1 line is almost always in other lines that are very very rarely if ever changed. > > > > c) It'll quickly get us to the damage that is done by > > > > the loss of this information from the released binary > > > > product so repairs may begin. > > > > > > > > > > We can begin repairs w/o doing this. 99% of these never end up in > > binaries > > > anyway. > > > > Oh, now thats false... simple test: > > find /bin | xargs grep -l \$FreeBSD: | wc > > find /bin | wc > > > > 44/45 files on my 12.1 system. > > > > As far as I recall it is more like 99% of our files HAVE these strings in > > them. > > > > On my system, the numbers are quite different: > % find /*bin /usr/*bin -type f | xargs grep -la '$FreeBSD:' | wc > 4 4 64 > 3:14pm rebo:[245]> find /*bin /usr/*bin -type f | wc > 1032 1032 16791 > > And all 4 binaries are from 2016 and appear to be 'stale' leftovers. My guess would be your system is NOT from a production release of FreeBSD, probably compiled with a STRIP_FBSDID defined. I checked /bin on 11.2, 12.0 and 12.1 same results, all but 2 files. > > > > d) It'll shorten 1000's of commit messages by the lines: > > > > While here, remove $FreeBSD$ RCS IDs. > > > > > > > > > > Who cares? I mean, this is not an issue at all. > > > > > > Like I've said: there's a real cost to doing this, and the benefits from > > > doing this are quite small. As someone that's had to deal for years with > > > partial merges of sweeping commits, please listen when I say that they > > > always cause unintended pain due to their size. > > > > You can repeat yourself, but please give relavent factual cause on how > > this causes a merge conflict. > > > I have given numbers. We'd be wasting a week's time of all our developers, > give or take. I do not accept your WAG 5% as a realistic number. > > In most cases it would be a single line delete in an area of the > > file that is rarely touched. This is NOT like white space cleanup, > > macro renames, or other global scope changes. It is no worse than > > the SPDX tagging that was done, and if that had not been caught up > > in some work flow errors, would of been fine. > > > > There's value in the SPDX stuff, which we also did piecemeal, and which > also caused me grief when I MFC'd stuff because it was done in large > batches, and merged incrementally. Just because you see no value in FreeBSD, does not make it have no value. I would argue it has more value that SPDX. At least it is used programatically to create traceability in the production releases. > Warner -- Rod Grimes rgrimes@freebsd.org