From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Stefan Monnier Newsgroups: gmane.emacs.devel Subject: Re: [elpa] scratch/email-revision-details Date: Sat, 07 Aug 2021 18:38:42 -0400 Message-ID: References: <20210806151651.16524.53159@vcs0.savannah.gnu.org> <20210806151653.0F131203E8@vcs0.savannah.gnu.org> <5ddc43060bafb79337ee410c8a70574d@webmail.orcon.net.nz> Mime-Version: 1.0 Content-Type: text/plain Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="21081"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/28.0.50 (gnu/linux) Cc: emacs-devel@gnu.org, Phil Sainty To: Phil Sainty Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Sun Aug 08 00:39:34 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 1mCUyb-0005F8-V9 for ged-emacs-devel@m.gmane-mx.org; Sun, 08 Aug 2021 00:39:34 +0200 Original-Received: from localhost ([::1]:49224 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1mCUyZ-0002Yg-Nu for ged-emacs-devel@m.gmane-mx.org; Sat, 07 Aug 2021 18:39:31 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:48606) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1mCUxv-0001ln-Kf for emacs-devel@gnu.org; Sat, 07 Aug 2021 18:38:51 -0400 Original-Received: from mailscanner.iro.umontreal.ca ([132.204.25.50]:57399) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1mCUxs-0008NF-Bl for emacs-devel@gnu.org; Sat, 07 Aug 2021 18:38:50 -0400 Original-Received: from pmg1.iro.umontreal.ca (localhost.localdomain [127.0.0.1]) by pmg1.iro.umontreal.ca (Proxmox) with ESMTP id 7FCBF1001F4; Sat, 7 Aug 2021 18:38:45 -0400 (EDT) Original-Received: from mail01.iro.umontreal.ca (unknown [172.31.2.1]) by pmg1.iro.umontreal.ca (Proxmox) with ESMTP id 0D69D1000CF; Sat, 7 Aug 2021 18:38:44 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=iro.umontreal.ca; s=mail; t=1628375924; bh=XpD7Tez0weTtTx85ly4FY+/f67X8KGYrRU3841EeuOU=; h=From:To:Cc:Subject:References:Date:In-Reply-To:From; b=id7G+33t9OATgezebKCZ/ewR2i+IhYORF8iubbL34leVUHsvLlErge1ATFQxugvhb UvxEPYxtLPK8iolmcXwWDoQrLiJQri0RzE/2zyCGO4NkS6q/mHSrJ8Senn+3MPHqeW 1IsQFQ5DG/dmmROk2hcNweTSW3oiZdUGzNqJ/VeyarAam0d66PsVFDp6M2+v6zMGC5 z91LBlG3Xfh8I5Xcql9+zPrSdBhiJ07uZuasQMZEXrfP5UZcm8tL+Ovq3j81AL9Xak ydmq2kHlC5nhU90prKe1n6/Z44seO8YM1/MIbYrdHfbxWCcYgMq5hfhX1+9nnUV9x9 k40gPqWIvrnkg== Original-Received: from alfajor (unknown [216.154.29.138]) by mail01.iro.umontreal.ca (Postfix) with ESMTPSA id C536E120346; Sat, 7 Aug 2021 18:38:43 -0400 (EDT) In-Reply-To: <5ddc43060bafb79337ee410c8a70574d@webmail.orcon.net.nz> (Phil Sainty's message of "Sun, 08 Aug 2021 01:45:20 +1200") Received-SPF: pass client-ip=132.204.25.50; envelope-from=monnier@iro.umontreal.ca; helo=mailscanner.iro.umontreal.ca X-Spam_score_int: -42 X-Spam_score: -4.3 X-Spam_bar: ---- X-Spam_report: (-4.3 / 5.0 requ) BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, 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:272181 Archived-At: Phil Sainty [2021-08-08 01:45:20] wrote: > On 2021-08-07 03:30, Stefan Monnier wrote: >> Feel free to push this to `master`, it looks good to me. > Done. Thanks. > (Well, pushed to elpa-admin.) Oops, indeed. > For the other commit (just re-pushed to my scratch branch, but > the code is unchanged), I'm not sure how to test it, aside from > testing in isolation the part which actually gets the revision > details from git for a given `release-rev' value (which I've > tested against so-long.el). I think you can test it as follows: - Add to `elpa-config` the following elements: (email-to "Phil Sainty ") (email-from "Phil Sainty ") (email-reply-to "Phil Sainty ") [ Or use some other email address, of course. ] - `rm archive/*` - `make build/so-long` This should presumably build a "new" release tarball and send an email to the `email-to` address (with Cc to the package's maintainer). The email is sent by Emacs, so the actual sending may fail depending on how your Emacs config is setup. > I've gone with the full compliment of author+commit timestamps > in both relative and absolute formats, which looks like this: > > ; * lisp/so-long.el: Bump version for the GNU ELPA build > Authored 3 days ago on Wed, 4 Aug 2021 17:17:23 +1200 > Committed 3 days ago on Wed, 4 Aug 2021 17:17:23 +1200 > Revision b84986af52d4e9debace2850a5ec106f51e38e61 That looks great (I like those times). I'd just add a short line before that explaining what those lines represent (for the non-expert user who's not familiar with VCS), and add some indentation to clarify that the lines belong together. Maybe something like: Built from revision : ; * lisp/so-long.el: Bump version for the GNU ELPA build Authored 3 days ago on Wed, 4 Aug 2021 17:17:23 +1200 Committed 3 days ago on Wed, 4 Aug 2021 17:17:23 +1200 If we wanted to get fancy we could remove one of the two last lines in case (like here) the times are equal (since that should be a fairly common case). > If the code looks sane to you, are you able to test it, or > let me know how to safely do that? I see the commented debug > line ahead of the (message-send) call, but I don't know whether > that's the only code that I'd need to be concerned about. You could uncomment that line and then instead of `make build/so-long` I think you can use emacs -l $(pwd)/admin/elpa-admin.el \ -f elpaa-batch-make-one-package so-long But I'm not completely sure: when I used that debug line, I think I called internal functions more directly from an interactive Emacs session (I had those things still fairly fresh in my mind). Looking at my question/suggestion not to use a global var and to fetch the commit's info only when we actually send the message, I see that `elpaa--release-email` can't easily do that right now because it doesn't know the commitid. I think the best way to do that is: - Make it so `elpaa--release-email` is called directly from `elpaa--make-one-tarball` when `revision-function` is non-nil. [ AFAICT `elpaa--release-email` is called if-and-only-if `revision-function` is non-nil and always in the same way, so this would improve/simplify the code. ] - Change `elpaa--make-one-tarball` to remember the commit id returned by `revision-function`, so we can pass it to `elpaa--release-email`. - Then we can write a new function to get the commitid's data using the same (let* ((mainfile (file-truename (expand-file-name (elpaa--main-file pkg-spec) (elpaa--dirname dir)))) (default-directory (file-name-directory mainfile)) as in `elpaa--get-release-revision`. - use that function from `elpaa--release-email`. Stefan