unofficial mirror of bug-gnu-emacs@gnu.org 
 help / color / mirror / code / Atom feed
From: Jim Porter <jporterbugs@gmail.com>
To: Corwin Brust <corwin@bru.st>, Stefan Kangas <stefankangas@gmail.com>
Cc: 62509@debbugs.gnu.org
Subject: bug#62509: 30.0.50; Changes to naming for Windows stapshots - PATCH
Date: Tue, 12 Sep 2023 21:14:34 -0700	[thread overview]
Message-ID: <5c566017-59cd-99c8-b564-8ccedda795c2@gmail.com> (raw)
In-Reply-To: <CAJf-WoSsnAbp+FVYL4QDvWrXE7OjQjjek7OXsikykY5DCnzR1g@mail.gmail.com>

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
> <REVISION>?

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. 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."





  reply	other threads:[~2023-09-13  4:14 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-03-28 22:29 bug#62509: 30.0.50; Changes to naming for Windows stapshots - PATCH Corwin Brust
2023-09-01 19:39 ` Stefan Kangas
2023-09-13  2:33   ` Corwin Brust
2023-09-13  4:14     ` Jim Porter [this message]
2023-09-13 12:12       ` Stefan Kangas
2023-09-13 13:09         ` Corwin Brust
2023-09-13 13:06       ` Corwin Brust
2023-09-13 13:11         ` Stefan Kangas
2023-09-13 16:11         ` Jim Porter

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: https://www.gnu.org/software/emacs/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=5c566017-59cd-99c8-b564-8ccedda795c2@gmail.com \
    --to=jporterbugs@gmail.com \
    --cc=62509@debbugs.gnu.org \
    --cc=corwin@bru.st \
    --cc=stefankangas@gmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

	https://git.savannah.gnu.org/cgit/emacs.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).