From owner-dev-commits-src-main@freebsd.org Thu Dec 31 07:22:52 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 086BE4DED34 for ; Thu, 31 Dec 2020 07:22:52 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: from mail-qv1-xf2b.google.com (mail-qv1-xf2b.google.com [IPv6:2607:f8b0:4864:20::f2b]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1O1" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4D603v6Z1Qz3tLB for ; Thu, 31 Dec 2020 07:22:51 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: by mail-qv1-xf2b.google.com with SMTP id p12so8692697qvj.13 for ; Wed, 30 Dec 2020 23:22:51 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bsdimp-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=bfaEz5vbnfZx768YdvqduP42dqxVjC9nF3/0Rvvf0aQ=; b=nD7kTTsA4Srn0WLvfYOHoNq7bzwlEi9Nqu+J8eXBzAgeNpMZAqCEWbKDjG3zKeeph5 Dkb8uyeN4sTgp11G6VwBElWYDB64ihrXsgsLr7sVEguefXeLgCVcIzbIH67Dgb/iGzMx hJx3qpKgeJ5rq51410PkSEwNC0QdyfY4NmQXi84t2AbzzR6yh8hAIW1rVO6r9P+3GiOl aU1A4jPUuTo4GNLfG/h1Jnzx6eTIzTi0aiJCobb37UL+xK+tXMe4O3pqK32h1/6THk9O C+g6XMht/iArYXYnth30QNWIa79VnLzmg1aqwY0nbEW0JddlVWKLPTvGjb3m6Yb4HBl+ DGAQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=bfaEz5vbnfZx768YdvqduP42dqxVjC9nF3/0Rvvf0aQ=; b=C1D+B4FwQt9rz1HIi1cwdRxvXopVACYHUCb8dB79EIF0xxbUG8X7JcrNFcNDJkykSO K7LpDejpt76Pzq1l+bUkEN3HNUWUmtWPEAHiQljlJ7eOJJfnlhYcGPygg66wUpKWz/7D aOXwd6ztyVcUtTNLKfepDA6PnscGdw4KM3CXQ99A178JkWlNAAgd+T/hKSfh/NCW5cYg M7kjNlNaOvVaUeGScJdv9ynnw/GWiqvG4AAscw7rM+j2CLEuwymkHajT3dDuPOj9uGg4 XsLsi9k9LhtgrjuDtCuF5vcJclSYWXR5KLmB8w+cd4mmaVSjEvrNrx87JI7OgyuZu/to B+1g== X-Gm-Message-State: AOAM533OvzXxxgij0lzchFT/K47rADBNDtXvD8ydnRCtMGBzEMy9cN8S skLWM4FQFKK5jUqMBgynbJCyfvm7N1a6nHFPPcxLzw== X-Google-Smtp-Source: ABdhPJwSAkPgeuUbCHMPJj6nX1KHvBevC2Hr1Ep7q4ZfzSHnGpboj6sfM7fch6rCxmc/2Ce/mhpwbaBh0gB5/vi3hd0= X-Received: by 2002:ad4:5b82:: with SMTP id 2mr60263181qvp.28.1609399370852; Wed, 30 Dec 2020 23:22:50 -0800 (PST) MIME-Version: 1.0 References: <202012310602.0BV62xUk085088@gndrsh.dnsmgr.net> In-Reply-To: <202012310602.0BV62xUk085088@gndrsh.dnsmgr.net> From: Warner Losh Date: Thu, 31 Dec 2020 00:22:39 -0700 Message-ID: Subject: Re: git: 70e64ba44941 - main - release.sh: Update GITROOT URL To: "Rodney W. Grimes" Cc: Glen Barber , src-committers , dev-commits-src-all@freebsd.org, dev-commits-src-main@freebsd.org X-Rspamd-Queue-Id: 4D603v6Z1Qz3tLB X-Spamd-Bar: ---- Authentication-Results: mx1.freebsd.org; none X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[] Content-Type: text/plain; charset="UTF-8" X-Content-Filtered-By: Mailman/MimeDel 2.1.34 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 07:22:52 -0000 On Wed, Dec 30, 2020, 11:03 PM Rodney W. Grimes wrote: > > On Wed, Dec 30, 2020 at 2:31 PM Rodney W. Grimes < > freebsd@gndrsh.dnsmgr.net> > > 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. > Except we don't do that anymore. Nobody dies that any more. They use build IDs instead. They use proper CM. They have traceability through other means. > > > > > > > > > > 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* > Yes. It is gone. The industry has moved on and no longer thinks this is a good idea. > > > > 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. > Lots of changes happen near the start of the file, near where the $FreeBSD$ lives. This is especially true for shorter files. > > > > > 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. > It is the default in current to omit these. I checked a current system. > > > > > 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. > The fact you are demanding work from me makes you acceptance irrelevant. If it causes any extra work, it's too high a price. My WAG was to try to put some numbers around it based on doing hundreds of MFCs. > > > 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. > Git likes smaller changes. One huge commit would become un-revertable without a lot of effort fairly quickly. Small changes could be reverted more easily. The only snag is the one email per commit rather than per push... I'm kinda snarky about this because you are demanding we do this in a way I know will cause problems because when we've done big sweeping commits in the past they have caused problems, even ones that people at the time thought would be no trouble. Done all at once, there will be additional work for me and other frequent MFCers. It's not my burden to disprove everything you throw up. The project has a way of creating problems for itself by doing this in some philosophically right way that ignores history and experiences the project has had. I'm just asking that we not do it please. Warner > Warner > -- > Rod Grimes > rgrimes@freebsd.org >