From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from einhorn-mail-out.in-berlin.de (einhorn.in-berlin.de [192.109.42.8]) by sourceware.org (Postfix) with ESMTPS id BA28F3858D32 for ; Wed, 22 Jun 2022 19:35:16 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org BA28F3858D32 Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=ubuntu.com Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=ubuntu.com X-Envelope-From: doko@ubuntu.com Received: from authenticated.user (localhost [127.0.0.1]) by einhorn.in-berlin.de with ESMTPSA id 25MJZD3f1470776 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NOT); Wed, 22 Jun 2022 21:35:13 +0200 Message-ID: <69df0c2f-016d-96ed-b4c6-2537453cb3fa@ubuntu.com> Date: Wed, 22 Jun 2022 21:35:13 +0200 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101 Thunderbird/91.9.1 Subject: Re: Getting ready for the 2.39 branch/release Content-Language: en-US To: binutils@sourceware.org, YunQiang Su References: <7e2b1296-8038-84e6-ac04-69890ae71a6d@redhat.com> From: Matthias Klose In-Reply-To: <7e2b1296-8038-84e6-ac04-69890ae71a6d@redhat.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-Spam-Status: No, score=-0.7 required=5.0 tests=BAYES_00, BODY_8BITS, JMQ_SPF_ALL, KAM_DMARC_STATUS, NICE_REPLY_A, RCVD_IN_DNSWL_LOW, RCVD_IN_MSPIKE_H3, RCVD_IN_MSPIKE_WL, RCVD_IN_VALIDITY_RPBL, SPF_HELO_NONE, SPF_PASS, TXREP, T_SCC_BODY_TEXT_LINE autolearn=no autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on server2.sourceware.org X-BeenThere: binutils@sourceware.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Binutils mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Jun 2022 19:35:18 -0000 On 21.06.22 13:09, Nick Clifton via Binutils wrote: > Hi Guys, > >   It is time to think about the next GNU Binutils release. > >   Ideally I would like to make the release at the end of July >   which will be 6 months on from the 2.38 release.  Unfortunately >   I am on vacation for two weeks in the middle of July (11-22) so >   either: > >   1. Someone else volunteers to make the 2.39 release. > >   2. I create the branch early (eg Saturday June 25) but then >      release late (eg Saturday July 30) and the global maintainers >      get to approve patches for the branch. > >      This does not give much time for people to get new features >      into the sources before the branch is cut... > >   3. I create the branch in a couple of week's time (eg Fri Jul 8) >      and then release early in August (eg Sat Aug 6) and again I >      ask the global maintainers for help in approving patches for >      the branch. > >   Thoughts ? Debian and Ubuntu are using the current trunk for the releases in development. There's currently one issue that I'm aware of: https://bugs.debian.org/1013244 just asked the Debian mips porters about it. As I understand, some minor gprofng configuration issues are being worked on. Matthias