From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Dmitry Gutov Newsgroups: gmane.emacs.devel Subject: Re: Merging release branch Date: Sat, 30 Oct 2021 15:30:30 +0300 Message-ID: <51ab9b37-7c1b-0b71-4875-265ac402a756@yandex.ru> References: <87bl37vg9l.fsf@gnus.org> <87y26bu0ih.fsf@gnus.org> <83pmrnppqy.fsf@gnu.org> <874k8yspb4.fsf@gnus.org> <835ytepvad.fsf@gnu.org> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="28097"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.13.0 Cc: rgm@gnu.org, stefan@marxist.se, monnier@iro.umontreal.ca, emacs-devel@gnu.org To: Eli Zaretskii , Lars Ingebrigtsen Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Sat Oct 30 14:34:27 2021 Return-path: Envelope-to: ged-emacs-devel@m.gmane-mx.org Original-Received: from lists.gnu.org ([209.51.188.17]) by ciao.gmane.io with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1mgnZ5-00079Y-5K for ged-emacs-devel@m.gmane-mx.org; Sat, 30 Oct 2021 14:34:27 +0200 Original-Received: from localhost ([::1]:59226 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1mgnZ3-0000cu-Ah for ged-emacs-devel@m.gmane-mx.org; Sat, 30 Oct 2021 08:34:25 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:40226) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1mgnVS-0007Oe-I5 for emacs-devel@gnu.org; Sat, 30 Oct 2021 08:30:42 -0400 Original-Received: from mail-lj1-x233.google.com ([2a00:1450:4864:20::233]:38800) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1mgnVM-0007Xs-5n; Sat, 30 Oct 2021 08:30:41 -0400 Original-Received: by mail-lj1-x233.google.com with SMTP id n7so21290627ljp.5; Sat, 30 Oct 2021 05:30:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=sender:subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=PTNBwHQFzWxwhmzes8yepnPbTSBv/JYPAKCqo++7uM4=; b=P9/S3/KZd+bHzjKvElGEtsl3iafUHkRvEVqJ7Ni9vZMAPcUaCW41NkSYHFlKLWZobf xiIulr1LAH/gCPN2P4eilxjJ/hs9DcdDaiykzZG2vnx8D8/q/TQR93x0FYsNRyA61pfM 7hRmVJubYvWCMkZdeK+IGyGGjeAFAmBDFVD3mTXQ0I0Qxxk5TQuYToigbLr1xuO5TC5c EgkfiSfNKx4tEsr3dstnsv4iBIXk60acAwiuK23WC1cELwA2OZmZG0cuvxIAMf5xEhgY luMv5ieT5t+T+7CG7mUwaBYkhOZmmxShlRUz2MF1RvglOinljaFBPoVtB6HAfoK0Ppa7 YwTg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:sender:subject:to:cc:references:from:message-id :date:user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=PTNBwHQFzWxwhmzes8yepnPbTSBv/JYPAKCqo++7uM4=; b=pffyHBVSVfBUf9Wh/8NzMYPNjxUXSdtYrrA1LxzGlOHfMYYC2gwk1HOKbupYgxtIhZ sHzJmcjujGh/JyeNzdMyrITkckBJ8InZTCwTnYAIfKYyG+EnWKD/lM7Egpcpo0Yokl8C yYuKLv9dCQomKaT5/rQCIKbUxL/cpBLsq0btOJH7wghtxjQhLeICiaT3u8F+72W5bqM9 1dIWR9UtzVWZBekEP0eTQx+SjpPheYjy/0AEW9VSZlIVjISbLCxlfZgfEe9ga4rkvlnh UiFSQY69LKNKTMq6JFYWSr5nSntUQ7EbeFXlB3VR1SC3nXnkykgPqZL3YQoxNjSvbwG7 Df+A== X-Gm-Message-State: AOAM5334Il3f99se9KtV4elQC/lqqjSG5AqtFNN/WyQtVjEYVpIwzKdC zSVF87gocRdhsJEeW9ubNMRlfMLTsvg= X-Google-Smtp-Source: ABdhPJxm4S5pWsQ63JwD0I0ASWOST/HR7MFAHL920sOLsIQFQ1tdlaSa8azgrYGY93x3wUHiLxavrw== X-Received: by 2002:a2e:80cc:: with SMTP id r12mr18109629ljg.448.1635597031972; Sat, 30 Oct 2021 05:30:31 -0700 (PDT) Original-Received: from [192.168.0.103] ([5.18.248.29]) by smtp.googlemail.com with ESMTPSA id d18sm5347lji.115.2021.10.30.05.30.31 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Sat, 30 Oct 2021 05:30:31 -0700 (PDT) In-Reply-To: <835ytepvad.fsf@gnu.org> Content-Language: en-US Received-SPF: pass client-ip=2a00:1450:4864:20::233; envelope-from=raaahh@gmail.com; helo=mail-lj1-x233.google.com X-Spam_score_int: -38 X-Spam_score: -3.9 X-Spam_bar: --- X-Spam_report: (-3.9 / 5.0 requ) BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.249, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.25, NICE_REPLY_A=-2.426, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001 autolearn=ham autolearn_force=no X-Spam_action: no action X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Original-Sender: "Emacs-devel" Xref: news.gmane.io gmane.emacs.devel:278273 Archived-At: On 30.10.2021 15:11, Eli Zaretskii wrote: >> From: Lars Ingebrigtsen >> Cc: monnier@iro.umontreal.ca, rgm@gnu.org, stefan@marxist.se, >> emacs-devel@gnu.org >> Date: Sat, 30 Oct 2021 13:51:59 +0200 >> >> Eli Zaretskii writes: >> >>> Who'd do the cherry-picking in this scenario? And why do you assume >>> people won't forget doing that, like they forget to merge and/or mark >>> the changes "not to be merged to master"? >> >> The people who commit things to master would also be tasked with >> deciding whether to cherry-pick things for the release branch. > > That assumes they will want to, and will do a good job. People seem to generally want to push changes to the release branch. If only to get them to the users sooner. >>> I fear that what you propose will completely demote the release branch >>> to the status of second-rate citizen, because it then becomes a >>> burden. That'd be a regression. >> >> Speaking for myself, a cherry-picking work flow would be less work, not >> more work in general, because I normally use an Emacs from the master >> branch. > > Then it's good for you, but not for me: when a release is in progress, > I work mainly on the release branch. > > And of course, cherry-picking doesn't remove merge conflicts, they > will still need to be resolved. By the author of the change, that's the point. So I also think it might justify the additional overhead of having to cherry-pick every change. > We've been using the current workflow for years without any major > problems. Changing that now radically doesn't make sense to me. It > will most probably need several procedures to be modified that were > stable for several releases, and I don't see the gains which would > justify that. We have enough real work on our hands. So please let's > not do that. Do we have a volunteer who will take over from Glenn?