From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Corwin Brust Newsgroups: gmane.emacs.bugs Subject: bug#62509: 30.0.50; Changes to naming for Windows stapshots - PATCH Date: Wed, 13 Sep 2023 08:06:12 -0500 Message-ID: References: <5c566017-59cd-99c8-b564-8ccedda795c2@gmail.com> 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="34184"; mail-complaints-to="usenet@ciao.gmane.io" Cc: 62509@debbugs.gnu.org, Stefan Kangas To: Jim Porter Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Wed Sep 13 15:07:18 2023 Return-path: Envelope-to: geb-bug-gnu-emacs@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 1qgPaQ-0008iP-AF for geb-bug-gnu-emacs@m.gmane-mx.org; Wed, 13 Sep 2023 15:07:18 +0200 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1qgPa7-0002sV-JQ; Wed, 13 Sep 2023 09:06:59 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1qgPa5-0002qe-KD for bug-gnu-emacs@gnu.org; Wed, 13 Sep 2023 09:06:57 -0400 Original-Received: from debbugs.gnu.org ([2001:470:142:5::43]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1qgPa5-0007jv-BK for bug-gnu-emacs@gnu.org; Wed, 13 Sep 2023 09:06:57 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1qgPaA-0001t5-Gu for bug-gnu-emacs@gnu.org; Wed, 13 Sep 2023 09:07:02 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Corwin Brust Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Wed, 13 Sep 2023 13:07:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 62509 X-GNU-PR-Package: emacs Original-Received: via spool by 62509-submit@debbugs.gnu.org id=B62509.16946103997201 (code B ref 62509); Wed, 13 Sep 2023 13:07:02 +0000 Original-Received: (at 62509) by debbugs.gnu.org; 13 Sep 2023 13:06:39 +0000 Original-Received: from localhost ([127.0.0.1]:32910 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1qgPZn-0001s5-Gt for submit@debbugs.gnu.org; Wed, 13 Sep 2023 09:06:39 -0400 Original-Received: from mail-oi1-f178.google.com ([209.85.167.178]:53573) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1qgPZi-0001rn-4S for 62509@debbugs.gnu.org; Wed, 13 Sep 2023 09:06:38 -0400 Original-Received: by mail-oi1-f178.google.com with SMTP id 5614622812f47-3aca5c85a34so83644b6e.3 for <62509@debbugs.gnu.org>; Wed, 13 Sep 2023 06:06:28 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1694610382; x=1695215182; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=szSy1fpsX8h9P7SQcVGr0LuW+7ke0FlaN7n5D0y/A2o=; b=EC46SQjUdZJWshKDjPV0I67io5D5wTKVp5Ht8aO+zkUoldmi9ihZiQSLsacds45sEo 2t/GbU//B3iH60Qo1UjlaSMIx1JYMvYqJSIWFt5Emd359gEiuSgwJWlUgxI4KE+cQwle m5JTgFBC4QbO+Uf2xlaoOgu/OOeezuGJS7KuZutB2tK36//N16S+KDFW6PpoiW7KZ4VM lHJ+dxLuVZ+Q6gGVafr4IbJd2Ob3Pfa/fpJ+khIKnAuntciB3NN5IeUXXK/WXnvlnKkO W2CYfK4pfzU9DsAMBedq3ojG0bbNNIrtIUr4aEWVZUWtGjRRuZ8TcgZo1Fmg/YbA3klK /Qeg== X-Gm-Message-State: AOJu0YxDE45vR+OyYyjrF95W3IYAjW1hoR/LNSUhcq/TgEFWwEpayOy6 dwB9sj9cnkDqQLW6AMfoih1/Rc7wu0UXqfGAx5g= X-Google-Smtp-Source: AGHT+IHxeVgX3ZfLZCBca1OqqMHorRvcxksifrxeUaF4NpSx5r5YFPskyCPW1VqQlFMX/9VM8jwGD3fRED8EkiA8xgk= X-Received: by 2002:aca:1106:0:b0:3a8:6abe:8380 with SMTP id 6-20020aca1106000000b003a86abe8380mr2719223oir.53.1694610382291; Wed, 13 Sep 2023 06:06:22 -0700 (PDT) In-Reply-To: <5c566017-59cd-99c8-b564-8ccedda795c2@gmail.com> X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list X-BeenThere: bug-gnu-emacs@gnu.org List-Id: "Bug reports for GNU Emacs, the Swiss army knife of text editors" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Original-Sender: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Xref: news.gmane.io gmane.emacs.bugs:270274 Archived-At: On Tue, Sep 12, 2023 at 11:14=E2=80=AFPM Jim Porter = wrote: > > On 9/12/2023 7:33 PM, Corwin Brust wrote: > > From my standpoint, it is challenging to pick the date to use. I do > > most releases for GNU rather manually, and might take a day or two > > doing it. Is there information to be gained from knowing the "build > > start date" (but not time?) that isn't better sourced by git log > > ? > > I think so, yes. For those of us close to the development process, the > Git SHA is the most-useful bit of info for sure, but thinking back to a > couple of years ago before I contributed to Emacs, the date would have > been a lot more useful. That's helpful. I was under the impression we published snapshots for developers and didn't typically direct users to use them at all (except for pre-release snaps and special circumstances such as recently when glibc got several potentially breaking changes. It would let me see at a glance how new the > snapshot is. It would also make it easier to tell users what snapshot to > try, e.g. if you're a package author: "Make sure you use the Emacs > snapshot from at least YYYY-MM-DD in order to prevent such-and-such bug." > > The timestamp of the file itself isn't as useful for this purpose since, > as you say, the process is a bit manual and could be a few days after > the latest commit. > > As for what date exactly to use, I'd say, "Use the CommitDate in either > US Eastern time (the FSF's time zone), or possibly UTC." > I'm still puzzled as to why we should exclude the time component. Wouldn't that be rather more useful than including the date alone for those looking to see what revision is that last included (but doing so without referencing git logs)? As to collecting the date, my approach would be to take the date at the end of the process by extracting the date of REVISION from git log. Any concerns with this approach?