From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from esa2.mentor.iphmx.com (esa2.mentor.iphmx.com [68.232.141.98]) by sourceware.org (Postfix) with ESMTPS id E564E386001F for ; Mon, 31 Jan 2022 16:19:11 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org E564E386001F Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=codesourcery.com Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=mentor.com IronPort-SDR: ENrKvs18TmayhIJXrTBpC1VegFs96z8OzADZAhaBAekS0CLSB0vSpD06IxQ72YZ8ayeC7278Fh 6xUwZ1fqnbiiDiiFWXkgteXpIUmq/Yp9ScOtoXx8sDEF9JWiod7Ti0T40lKn+NnYRDz4YZVfod ws8vm4vqfVh5lcp3vwlnZ4oInU5SeKGFbac+I8EJKfd1uljGSc7HW+51An8+M8lHf06/6/wM+6 N7zvyrB29q2Ah/w43REOTSRySTe65l9XCf6mqrYyBxYtAA3Xyv+m+GJ5b94WiooM6otX4pIZ1j clwKgt17z0JemvS+C4XGwZzZ X-IronPort-AV: E=Sophos;i="5.88,331,1635235200"; d="scan'208";a="71419892" Received: from orw-gwy-02-in.mentorg.com ([192.94.38.167]) by esa2.mentor.iphmx.com with ESMTP; 31 Jan 2022 08:19:10 -0800 IronPort-SDR: gCVb/X5/ihYF+lIIom/WodUGmqpqewV5bzEdpBgAGB194G97byZqMXGHc42zPVh0TIVgs0papC fEMK8L20lIyMdyXtOOtc73JLfNshAWM/v427WHL1HFwTTseXRIL9YEXkKdHjhSPdHL7flU9jHQ xkgz0FEtDQ8vN/8GKuZsFkjOUYQu0oLRAYWJJKz+YFtRAUoY5cX4g2K5VGoU4cdA1lTbU+Xy52 PAo+d/WimgaVQpywJAo9Lht4hzv3ujAl/8tnXEZZgxcR1wNvtxE4PBc4MTaA10D3ytD3XLb6Jc QTc= Date: Mon, 31 Jan 2022 16:19:04 +0000 From: Joseph Myers X-X-Sender: jsm28@digraph.polyomino.org.uk To: Carlos O'Donell CC: libc-alpha , Andreas Schwab , Paul Eggert , Florian Weimer , DJ Delorie , "Ryan S. Arnold" , Jakub Jelinek , Maxim Kuvyrkov Subject: Re: Rename "master" branch to "main" for glibc 2.35 release. In-Reply-To: <77c04408-2508-350e-2f8e-db070e8d35f6@redhat.com> Message-ID: References: <77c04408-2508-350e-2f8e-db070e8d35f6@redhat.com> User-Agent: Alpine 2.22 (DEB 394 2020-01-19) MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" X-Originating-IP: [137.202.0.90] X-ClientProxiedBy: svr-ies-mbx-13.mgc.mentorg.com (139.181.222.13) To svr-ies-mbx-01.mgc.mentorg.com (139.181.222.1) X-Spam-Status: No, score=-3115.1 required=5.0 tests=BAYES_00, HEADER_FROM_DIFFERENT_DOMAINS, KAM_DMARC_STATUS, SPF_HELO_PASS, SPF_PASS, TXREP, T_SCC_BODY_TEXT_LINE autolearn=no autolearn_force=no version=3.4.4 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on server2.sourceware.org X-BeenThere: libc-alpha@sourceware.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Libc-alpha mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 31 Jan 2022 16:19:13 -0000 On Sat, 29 Jan 2022, Carlos O'Donell via Libc-alpha wrote: > My proposal is to rename the development and release branches at the point > that glibc 2.35 branches: > > * master -> main > > * release/2.35/master -> release/2.35/main > > No alias would be provided for the master branch; we would immediately > start using 'main' as the development branch. I strongly disapprove of the approach of renaming an existing branch without providing an alias. Branches aren't just consumed by active developers, there are many people with their own checkouts, automatically updating mirrors, etc., many of which may be useful to their users without much active maintenance and without anyone following glibc mailing lists; it's gratuitous to break them. Note also that build-many-glibcs.py knows about migrating GCC checkouts from SVN to git, so no manual intervention whatever was needed beyond the use of --replace-sources when running the checkout step (which is used automatically in bot mode). Naturally it should be taught to migrate from master to main if the master alias might ever go away (but I don't think such an alias should go away, certainly not for several years). (This is not making any assertion about whether it should be possible to push to the master alias, just that nothing should be broken for anyone pulling from it.) > I have reviewed the git hooks, and we would need to make changes to the > following files after the transition: > * hooks-bin/email-to-bugzilla-filtered > * hooks-bin/post-receive > > Our hooks implementation (AdaCore's hooks) is neutral on the branch name > used. There are two instances where 'master' is removed for '' to > shorten an email message because it's the "default", but that should not > be a blocker for our transition. Configuration to handle the two branch names the same in all regards should be done before adding a branch using the new naming conventions. -- Joseph S. Myers joseph@codesourcery.com