From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: =?utf-8?Q?K=C3=A9vin_Le_Gouguec?= Newsgroups: gmane.emacs.devel Subject: Re: When will emacs 27.1 be officially released? Date: Wed, 01 Jul 2020 00:09:30 +0200 Message-ID: <87a70kw6hx.fsf@gmail.com> References: <28BB39D5-074F-4450-A747-C2BFB37AA482@gnu.org> <87pn9g6fuo.fsf@gmail.com> <83bll0ze1x.fsf@gnu.org> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="16378"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/28.0.50 (gnu/linux) Cc: liwei.ma@gmail.com, emacs-devel@gnu.org To: Eli Zaretskii Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Wed Jul 01 00:10:12 2020 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 1jqOSB-00049T-ND for ged-emacs-devel@m.gmane-mx.org; Wed, 01 Jul 2020 00:10:11 +0200 Original-Received: from localhost ([::1]:59968 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1jqOSA-0004Sn-PH for ged-emacs-devel@m.gmane-mx.org; Tue, 30 Jun 2020 18:10:10 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:58524) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1jqORd-00041A-T9 for emacs-devel@gnu.org; Tue, 30 Jun 2020 18:09:37 -0400 Original-Received: from mail-wm1-x334.google.com ([2a00:1450:4864:20::334]:50411) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1jqORc-0000kr-2Y; Tue, 30 Jun 2020 18:09:37 -0400 Original-Received: by mail-wm1-x334.google.com with SMTP id l17so20268581wmj.0; Tue, 30 Jun 2020 15:09:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:to:cc:subject:references:date:in-reply-to:message-id :user-agent:mime-version:content-transfer-encoding; bh=gpoEI+EIHXFAnK7kMKBhKnRbxShgA/ehEmcYsqyb/x8=; b=P/BXwZ1q312o0FBAEeuyq0bgihR9Kj3TBbb9NZvuGXt5xu90yLNIqy7ymTCycuvciX vv5267HTu5vzAaIhGG0c8PWBl/5cR9EaJ6g1SlJxO1+q49ijksDIio+aGtNmrS5XCbwo FsNj6ZEpqN1lgAWtNWyHLC05hty3A7JpJfjtvG/BrXbdUT2Ddicw4s2shng60W6kBlOK FdNltyxMIyNVchW8bpZCkl+krdu1ULwGDeWKXMdpA7CBFls4wUQmgVdQIMnpgQV0nwWE jcLvjvd5l9NEujPza7A4AZSuGTeTPb3mboOqLbDdSP8YtM8DvzK+pI4o+de3heTSh4ew Gf9A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:cc:subject:references:date:in-reply-to :message-id:user-agent:mime-version:content-transfer-encoding; bh=gpoEI+EIHXFAnK7kMKBhKnRbxShgA/ehEmcYsqyb/x8=; b=W3Ov5q332vh6ebGciKHahjcQuO4qIQXgRceiMxeSL6Px2T33L0kw26DlubQmt9BNMN lzk7/1zeV5u8QjBJgelJQRQPTu+VpSpK7as31eFm1IBCLJZHPCv60fRabeIeBTlVeP5j kNxNzGaWJieJ6EXrTAZOyPOqMccS3oOm7KdHKAnXGkBO9ilgujX82TafjIx8qAcZ/meK a+7JsBPQ8Z4YF8YVq2LkZU9Sj/ZjHpnu1Q5UqKtpBnSRSU8yeI2z9XyPz0h8eyIzxKCQ hm2v9DNfMMeW3gVi4XKqQ2jEe4yJRYPoqS8t2sgCDiktW15amTumbqlhHxF2Tq9xTT5g NOtw== X-Gm-Message-State: AOAM533MIapJesuNCta2Z0Hd4aIxGci6g75pjPLe1XrBgNIBK1xGSxKx vviPQUUeLB+oDHzHNCtcpjc= X-Google-Smtp-Source: ABdhPJxGUPlFsKgibsI2H3GJdpBq1XFZen4i33FWvrWRbW2L96C75mGqwmXl7r5Qr0NTO6WrGTY13A== X-Received: by 2002:a1c:7c19:: with SMTP id x25mr13618136wmc.176.1593554972279; Tue, 30 Jun 2020 15:09:32 -0700 (PDT) Original-Received: from my-little-tumbleweed (200.143.13.109.rev.sfr.net. [109.13.143.200]) by smtp.gmail.com with ESMTPSA id l14sm4929019wrn.18.2020.06.30.15.09.31 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 30 Jun 2020 15:09:31 -0700 (PDT) In-Reply-To: <83bll0ze1x.fsf@gnu.org> (Eli Zaretskii's message of "Tue, 30 Jun 2020 19:58:02 +0300") Received-SPF: pass client-ip=2a00:1450:4864:20::334; envelope-from=kevin.legouguec@gmail.com; helo=mail-wm1-x334.google.com X-detected-operating-system: by eggs.gnu.org: No matching host in p0f cache. That's all we know. X-Spam_score_int: -20 X-Spam_score: -2.1 X-Spam_bar: -- X-Spam_report: (-2.1 / 5.0 requ) BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001 autolearn=_AUTOLEARN 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:252600 Archived-At: Thank you for this thoughtful answer. Eli Zaretskii writes: >> - Does bug#39200 come anywhere close to an exhaustive list of issues to >> address before the 27 branch is considered stable? > > I tend to treat these "blocking" bug reports as advisory only. E.g., > the bugs you see there now (a) don't sound too serious to me, and > (b) don't seem to cause anyone to go out of their way fixing them. > > So if you think this is what prevents us from releasing Emacs 27.1, > it's not. OK. I'm sure each maintainer has their own ways of prioritizing bugs and keeping track of those he considers serious; from the POV of curious users who watch the development process, knowing what's holding the release is not obvious. Point (b) taken, though. >> (Also can debbugs.el display the "blocked-by" list in a human-readable >> format?) > > What's wrong with the current display? Nothing, actually, I hadn't taken the time to check what bindings were available; now I see that "b" (debbugs-gnu-show-blocked-by-reports) does exactly what I was looking for (bar hiding resolved issues, but I'm sure there's a knob somewhere for that). > Even the most mundane aspect of an Emacs release, such as > update of the documentation and NEWS, takes orders of magnitude more > time for us than it takes for an elpa package. Would you agree to > release Emacs with incorrect/inaccurate/outdated manuals? Mmm, I guess in the specific case of documentation, a very naive answer would be "let's gate pushes to master until commits/branches include the documentation for the changes they bring". That would make the master branch "always release-ready", as far as documentation is concerned. No idea how to enforce that of course (more on that below). > See, that's another factor that people tend to forget or ignore: it > takes a long time for Emacs problems to be discovered and reported. A > new Emacs release can take years to reach end users. We are routinely > receiving bug reports about changes made two or more releases ago. If > you are looking for a single most important reason why it takes so > long to put out another pretest, it is this one: experience shows that > it takes weeks if not months for enough people to try a pretest and > report the problems they see. Once a problem is reported, it is > usually fixed very quickly, but how do you know the important problems > were all discovered, except by waiting? It sounds like a vicious cycle; the more we wait for feedback on pretests, the more disruptive things happen on master, and the more unstability the next release cycle will face=E2=80=A6 I admit I don't see an easy way out of this situation. I suspect some users (the kind who use Debian Sid, Ubuntu PPAs, or any rolling release distro) would flock to "nightly" tarballs and would not get overly fussed about incomplete documentation, but that's just a guess. > Especially since an > emergency bugfix release is also not something we can do quickly > enough, as one or two occurrences in the past have shown. I dimly remember that 25.3 sparked some debate regarding the difficulty of putting out "targeted bugfix" releases as quickly as we'd like. I don't remember the conclusions; is there anything specific to Emacs that prevents us from getting better? > So once again, the practical issue here is what to do differently to > make the releases more frequent, without losing too much of stability > and other good qualities. I mean practical measures, not general > considerations with which everyone will agree. "One bug =E2=87=92 one test" is a pretty concrete measure. Although there = are a lot of areas in Emacs where writing automated tests is as daunting as fixing the bug, if not more=E2=80=A6 > E.g., let's start with > a small step: how do we make the effort of preparing the manuals and > NEWS for a release less time-consuming? Off the top of my head, I don't have a better answer than "restrict pushes to master to fully documented commits/branches". I don't expect this to make editing manuals and NEWS less time-consuming, but it *should* help ensure that "things landing on master" does not lead to "slow buildup of undocumented stuff/obsolete documentation to catch up with on the release branch". Of course, (1) I have no idea how this could possibly be enforced. (2) Assuming it could be enforced, I'm not sure how well-received the idea would be: "drive-by" contributors comply when they are told that their changes need manual/NEWS updates, but AFAICT the master branch is also used for developers with push access to iterate and get some feedback on features they are working on; I'm not sure they would get as much visibility if they kept to feature branches=E2=80=A6