GNU bug report logs - #62509
30.0.50; Changes to naming for Windows stapshots - PATCH

Previous Next

To reply to this bug, email your comments to 62509 AT debbugs.gnu.org.

Toggle the display of automated, internal messages from the tracker.

Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):

From: Corwin Brust <corwin <at> bru.st>
To: bug-gnu-emacs <at> gnu.org
Subject: 30.0.50; Changes to naming for Windows stapshots - PATCH
Date: Tue, 28 Mar 2023 17:29:54 -0500

[Message part 1 (text/plain, inline)]

Today I put an initial set of Emacs 30 "snapshot" binaries for Windows
on GNU alpha.  In the process, I created a new folder for emacs-30[0].
At the moment, this folder is without the customary README.

I've attached a patch that suggests changes based on how I name the
snapshots, locally, when building them.  All of this is totally open
to discussion :)

Previously snapshot builds included a (rather nebulous) date, e.g.:
  emacs-30-YYYY-MM-DD-no-deps.zip.

Locally, my snapshots, instead of any date, include the git revision
short-code effective in the source tree where the build is taking
place, e.g.:
  emacs-30-28a9438169f-no-deps.zip

TIA for sharing your thoughts; I can easily rename files, including
those already posted if necessary.

Background:

The file admin/nt/dist-build/README-windows-binaries is usually placed
at the root of each new folder that will contain windows binaries, for
example the "emacs-30" folder for snapshot (and eventually pre-release)
builds from (as currently called) "master".

The attached patch updates this file to reflect a change in how I've
been naming snapshot binaries, locally.

Snapshot binaries are in-tree source builds, rather than being made
from a release --or prerelease-- tarball.

[0] https://alpha.gnu.org/gnu/emacs/pretest/windows/emacs-30

In GNU Emacs 30.0.50 (build 1, x86_64-w64-mingw32) of 2023-03-27 built
 on AVALON
Repository revision: 0bd2bbc0c2cb06cd254bf67f75d284f4c16f45a8
Repository branch: master
Windowing system distributor 'Microsoft Corp.', version 10.0.19043
System Description: Microsoft Windows 10 Home (v10.0.2009.19043.2364)

Configured using:
 'configure --with-modules --without-dbus --with-native-compilation
 --without-compress-install --with-tree-sitter CFLAGS=-O2'

Configured features:
ACL GIF GMP GNUTLS HARFBUZZ JPEG JSON LCMS2 LIBXML2 MODULES NATIVE_COMP
NOTIFY W32NOTIFY PDUMPER PNG RSVG SOUND SQLITE3 THREADS TIFF
TOOLKIT_SCROLL_BARS TREE_SITTER WEBP XPM ZLIB

Important settings:
  value of $LANG: ENU
  locale-coding-system: cp1252

Major mode: Lisp Interaction

Minor modes in effect:
  tooltip-mode: t
  global-eldoc-mode: t
  eldoc-mode: t
  show-paren-mode: t
  electric-indent-mode: t
  mouse-wheel-mode: t
  tool-bar-mode: t
  menu-bar-mode: t
  file-name-shadow-mode: t
  global-font-lock-mode: t
  font-lock-mode: t
  blink-cursor-mode: t
  line-number-mode: t
  indent-tabs-mode: t
  transient-mark-mode: t
  auto-composition-mode: t
  auto-encryption-mode: t
  auto-compression-mode: t

Load-path shadows:
None found.

Features:
(shadow sort mail-extr emacsbug message mailcap yank-media puny dired
dired-loaddefs rfc822 mml mml-sec password-cache epa derived epg rfc6068
epg-config gnus-util text-property-search time-date mm-decode mm-bodies
mm-encode mail-parse rfc2231 mailabbrev gmm-utils mailheader cl-loaddefs
comp comp-cstr warnings icons subr-x rx cl-seq cl-macs gv cl-extra
help-mode bytecomp byte-compile cl-lib sendmail rfc2047 rfc2045
ietf-drums mm-util mail-prsvr mail-utils rmc iso-transl tooltip cconv
eldoc paren electric uniquify ediff-hook vc-hooks lisp-float-type
elisp-mode mwheel dos-w32 ls-lisp disp-table term/w32-win w32-win
w32-vars term/common-win tool-bar dnd fontset image regexp-opt fringe
tabulated-list replace newcomment text-mode lisp-mode prog-mode register
page tab-bar menu-bar rfn-eshadow isearch easymenu timer select
scroll-bar mouse jit-lock font-lock syntax font-core term/tty-colors
frame minibuffer nadvice seq simple cl-generic indonesian philippine
cham georgian utf-8-lang misc-lang vietnamese tibetan thai tai-viet lao
korean japanese eucjp-ms cp51932 hebrew greek romanian slovak czech
european ethiopic indian cyrillic chinese composite emoji-zwj charscript
charprop case-table epa-hook jka-cmpr-hook help abbrev obarray oclosure
cl-preloaded button loaddefs theme-loaddefs faces cus-face macroexp
files window text-properties overlay sha1 md5 base64 format env
code-pages mule custom widget keymap hashtable-print-readable backquote
threads w32notify w32 lcms2 multi-tty make-network-process
native-compile emacs)

Memory information:
((conses 16 80396 28348)
 (symbols 48 7205 0)
 (strings 32 21339 1787)
 (string-bytes 1 629300)
 (vectors 16 16571)
 (vector-slots 8 333592 20388)
 (floats 8 30 52)
 (intervals 56 245 0)
 (buffers 984 10))

[0001-update-FTP-download-instructions-for-Windows.patch (application/octet-stream, attachment)]

Message #8 received at 62509 <at> debbugs.gnu.org (full text, mbox):

From: Stefan Kangas <stefankangas <at> gmail.com>
To: Corwin Brust <corwin <at> bru.st>
Cc: 62509 <at> debbugs.gnu.org
Subject: Re: bug#62509: 30.0.50;
 Changes to naming for Windows stapshots - PATCH
Date: Fri, 1 Sep 2023 21:39:28 +0200

Corwin Brust <corwin <at> bru.st> writes:

> Today I put an initial set of Emacs 30 "snapshot" binaries for Windows
> on GNU alpha.  In the process, I created a new folder for emacs-30[0].
> At the moment, this folder is without the customary README.
>
> I've attached a patch that suggests changes based on how I name the
> snapshots, locally, when building them.  All of this is totally open
> to discussion :)
>
> Previously snapshot builds included a (rather nebulous) date, e.g.:
>   emacs-30-YYYY-MM-DD-no-deps.zip.
>
> Locally, my snapshots, instead of any date, include the git revision
> short-code effective in the source tree where the build is taking
> place, e.g.:
>   emacs-30-28a9438169f-no-deps.zip
>
> TIA for sharing your thoughts; I can easily rename files, including
> those already posted if necessary.

How about

    emacs-30-YYYY-MM-DD-REVISION-no-deps.zip.

> Background:
>
> The file admin/nt/dist-build/README-windows-binaries is usually placed
> at the root of each new folder that will contain windows binaries, for
> example the "emacs-30" folder for snapshot (and eventually pre-release)
> builds from (as currently called) "master".
>
> The attached patch updates this file to reflect a change in how I've
> been naming snapshot binaries, locally.
>
> Snapshot binaries are in-tree source builds, rather than being made
> from a release --or prerelease-- tarball.
>
> [0] https://alpha.gnu.org/gnu/emacs/pretest/windows/emacs-30

Please skip this chunk, though:

@@ -91,4 +100,4 @@ MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
 GNU General Public License for more details.

 You should have received a copy of the GNU General Public License
-along with GNU Emacs.  If not, see https://www.gnu.org/licenses/.
+along with GNU Emacs.  If not, see https://www.gnu.org/licenses/.
\ No newline at end of file

Message #11 received at 62509 <at> debbugs.gnu.org (full text, mbox):

From: Corwin Brust <corwin <at> bru.st>
To: Stefan Kangas <stefankangas <at> gmail.com>
Cc: 62509 <at> debbugs.gnu.org
Subject: Re: bug#62509: 30.0.50;
 Changes to naming for Windows stapshots - PATCH
Date: Tue, 12 Sep 2023 21:33:48 -0500

On Fri, Sep 1, 2023 at 2:39 PM Stefan Kangas <stefankangas <at> gmail.com> wrote:
>
> Corwin Brust <corwin <at> bru.st> writes:
>
> >
> > Locally, my snapshots, instead of any date, include the git revision
> > short-code effective in the source tree where the build is taking
> > place, e.g.:
> >   emacs-30-28a9438169f-no-deps.zip
> >
> > TIA for sharing your thoughts; I can easily rename files, including
> > those already posted if necessary.
>
> How about
>
>     emacs-30-YYYY-MM-DD-REVISION-no-deps.zip.

I'd prefer not; however, it seems possible you can see use from the
date there which I cannot.

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

Moveover, considering viewing a given version subfolder over HTTP,
sorting by the date column must surely give the same order as name
after adding this, reducing the utility of sorting by name that
otherwise helps quickly find binaries corresponding to a given
revision.

In any case, although I don't prefer it, it is not a problem to resume
including a common date in the file names constituting a release given
I know what date to use.

>
> @@ -91,4 +100,4 @@ MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
>  GNU General Public License for more details.
>
>  You should have received a copy of the GNU General Public License
> -along with GNU Emacs.  If not, see https://www.gnu.org/licenses/.
> +along with GNU Emacs.  If not, see https://www.gnu.org/licenses/.
> \ No newline at end of file
>

Yes, thanks; I see to that in a next version once we've confirmed on
how to name the files :blush:

Message #14 received at 62509 <at> debbugs.gnu.org (full text, mbox):

From: Jim Porter <jporterbugs <at> gmail.com>
To: Corwin Brust <corwin <at> bru.st>, Stefan Kangas <stefankangas <at> gmail.com>
Cc: 62509 <at> debbugs.gnu.org
Subject: Re: bug#62509: 30.0.50; Changes to naming for Windows stapshots -
 PATCH
Date: Tue, 12 Sep 2023 21:14:34 -0700

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

Message #17 received at 62509 <at> debbugs.gnu.org (full text, mbox):

From: Stefan Kangas <stefankangas <at> gmail.com>
To: Jim Porter <jporterbugs <at> gmail.com>, Corwin Brust <corwin <at> bru.st>
Cc: 62509 <at> debbugs.gnu.org
Subject: Re: bug#62509: 30.0.50;
 Changes to naming for Windows stapshots - PATCH
Date: Wed, 13 Sep 2023 05:12:20 -0700

Jim Porter <jporterbugs <at> gmail.com> writes:

> 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'd probably prefer UTC, as it's less US-centric, but I don't think it's
super important.  As you say, it's more to give a rough indicator of the
age of a tarball, and the SHA is there too if anyone wants the details.

Message #20 received at 62509 <at> debbugs.gnu.org (full text, mbox):

From: Corwin Brust <corwin <at> bru.st>
To: Jim Porter <jporterbugs <at> gmail.com>
Cc: 62509 <at> debbugs.gnu.org, Stefan Kangas <stefankangas <at> gmail.com>
Subject: Re: bug#62509: 30.0.50;
 Changes to naming for Windows stapshots - PATCH
Date: Wed, 13 Sep 2023 08:06:12 -0500

On Tue, Sep 12, 2023 at 11:14 PM Jim Porter <jporterbugs <at> gmail.com> 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
> > <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.

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?

Message #23 received at 62509 <at> debbugs.gnu.org (full text, mbox):

From: Corwin Brust <corwin <at> bru.st>
To: Stefan Kangas <stefankangas <at> gmail.com>
Cc: Jim Porter <jporterbugs <at> gmail.com>, 62509 <at> debbugs.gnu.org
Subject: Re: bug#62509: 30.0.50;
 Changes to naming for Windows stapshots - PATCH
Date: Wed, 13 Sep 2023 08:09:17 -0500

On Wed, Sep 13, 2023 at 7:12 AM Stefan Kangas <stefankangas <at> gmail.com> wrote:
>
> Jim Porter <jporterbugs <at> gmail.com> writes:
>
> > 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'd probably prefer UTC, as it's less US-centric, but I don't think it's
> super important.  As you say, it's more to give a rough indicator of the
> age of a tarball, and the SHA is there too if anyone wants the details.
>

I prefer UTC also.

Message #26 received at 62509 <at> debbugs.gnu.org (full text, mbox):

From: Stefan Kangas <stefankangas <at> gmail.com>
To: Corwin Brust <corwin <at> bru.st>, Jim Porter <jporterbugs <at> gmail.com>
Cc: 62509 <at> debbugs.gnu.org
Subject: Re: bug#62509: 30.0.50;
 Changes to naming for Windows stapshots - PATCH
Date: Wed, 13 Sep 2023 06:11:28 -0700

Corwin Brust <corwin <at> bru.st> writes:

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

Sounds good.

Message #29 received at 62509 <at> debbugs.gnu.org (full text, mbox):

From: Jim Porter <jporterbugs <at> gmail.com>
To: Corwin Brust <corwin <at> bru.st>
Cc: 62509 <at> debbugs.gnu.org, Stefan Kangas <stefankangas <at> gmail.com>
Subject: Re: bug#62509: 30.0.50; Changes to naming for Windows stapshots -
 PATCH
Date: Wed, 13 Sep 2023 09:11:09 -0700

On 9/13/2023 6:06 AM, Corwin Brust wrote:
> 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.

Well, I think this would mainly be useful for the more-enthusiastic 
users who want to try out new things or are impatiently waiting for some 
bugfix only on the dev version. I'm not sure whether the actual Emacs 
maintainers would direct users to the snapshots, but third-party package 
authors might.

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

Including the time is fine too. I'm not sure how much value there is in 
that (personally, I'd only ever use the date for an approximate value of 
"how new is this"), but it doesn't cause any harm.

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.