From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Achim Gratz Newsgroups: gmane.emacs.devel Subject: Re: Supporting multiline Package-Requires header Date: Mon, 24 Aug 2015 08:56:25 +0200 Organization: Linux Private Site Message-ID: <87614518fa.fsf@Rainer.invalid> References: <87si7rjqmp.fsf@newcastle.ac.uk> <87fv3rjogj.fsf@newcastle.ac.uk> <87fv3po7ss.fsf@russet.org.uk> <87lhd2h5ug.fsf@Rainer.invalid> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: ger.gmane.org 1440429875 19327 80.91.229.3 (24 Aug 2015 15:24:35 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Mon, 24 Aug 2015 15:24:35 +0000 (UTC) To: emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Mon Aug 24 17:24:24 2015 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1ZTtbi-000278-MF for ged-emacs-devel@m.gmane.org; Mon, 24 Aug 2015 17:24:22 +0200 Original-Received: from localhost ([::1]:53364 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZTtbc-00026b-Rw for ged-emacs-devel@m.gmane.org; Mon, 24 Aug 2015 11:24:16 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:47631) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZTlgP-00062H-D8 for emacs-devel@gnu.org; Mon, 24 Aug 2015 02:56:42 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1ZTlgM-00054s-6W for emacs-devel@gnu.org; Mon, 24 Aug 2015 02:56:41 -0400 Original-Received: from plane.gmane.org ([80.91.229.3]:53577) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZTlgL-00054k-V9 for emacs-devel@gnu.org; Mon, 24 Aug 2015 02:56:38 -0400 Original-Received: from list by plane.gmane.org with local (Exim 4.69) (envelope-from ) id 1ZTlgJ-0002N7-Bp for emacs-devel@gnu.org; Mon, 24 Aug 2015 08:56:35 +0200 Original-Received: from p54b4794e.dip0.t-ipconnect.de ([84.180.121.78]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Mon, 24 Aug 2015 08:56:35 +0200 Original-Received: from Stromeko by p54b4794e.dip0.t-ipconnect.de with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Mon, 24 Aug 2015 08:56:35 +0200 X-Injected-Via-Gmane: http://gmane.org/ Original-Lines: 46 Original-X-Complaints-To: usenet@ger.gmane.org X-Gmane-NNTP-Posting-Host: p54b4794e.dip0.t-ipconnect.de User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/25.0.50 (gnu/linux) Cancel-Lock: sha1:Y0tQebjTP44do74oJ86ployREgE= X-detected-operating-system: by eggs.gnu.org: Genre and OS details not recognized. X-Received-From: 80.91.229.3 X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.14 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.org@gnu.org Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.devel:189103 Archived-At: Stefan Monnier writes: > Why? We're talking about the org.el that's in the tarball you send us. > It doesn't have to be identical to the org.el in your VCS. Yes, it should very much be identical. If you look in org-version.el you'll find the exact commit to check out from Git and any user would have to expect that the files installed on her machine would match up with the files in that tree. > This said, it could also be identical to the one in your VCS without > needing an extra commit: just make sure the version is changed as part > of the last commit (since it's the last commit before a new release, > it's not completely extravagant to expect that you'd often/usually know > this commit will be used for a release and hence needs a change in the > org.el's Version: header). No, that simply doesn't work and I'm really not sure why you even suggest it might. The ELPA archive is created by a cron job every Monday and we don't have a commit to org.el exactly every Monday, nor would anyone touching org.el know if his commit is going to be the last one before the tarball is created. Again, this being a distributed VCS with many developers hacking away on their own boxes and time and merging their stuff with both maint and master, it would also ensure lots or merge conflicts that someone would have to manually try and confine to the maint branch (each commit to maint is expected to be merged into master as well). No thanks, it was a major improvement to get rid of this nonsense (also in the texinfo files if you'd care to look) and we really don't want to go back there for whatever reason. As I said, if you insist on this we'll move to generate org.el and put it's current content to a new file, but that will either take time or a decision by Bastien that it's OK to do on maint. Again, I can also put these headers in any other generated file, be it org-pkg.el org-version.el or anything else you want, which would be easier for us to do and hence I expect it to be faster. Regards, Achim. -- +<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+ Factory and User Sound Singles for Waldorf Q+, Q and microQ: http://Synth.Stromeko.net/Downloads.html#WaldorfSounds