From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Stephen Leake Newsgroups: gmane.emacs.devel Subject: Re: Emacs release and bundling GNU Elpa Date: Mon, 22 Jun 2015 11:50:06 -0500 Message-ID: <86zj3r1ydd.fsf@stephe-leake.org> References: <83si9jhi5u.fsf@gnu.org> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: ger.gmane.org 1434991905 5273 80.91.229.3 (22 Jun 2015 16:51:45 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Mon, 22 Jun 2015 16:51:45 +0000 (UTC) To: emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Mon Jun 22 18:51:36 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 1Z74wa-0000Or-8y for ged-emacs-devel@m.gmane.org; Mon, 22 Jun 2015 18:51:36 +0200 Original-Received: from localhost ([::1]:41226 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Z74wZ-0000hY-P8 for ged-emacs-devel@m.gmane.org; Mon, 22 Jun 2015 12:51:35 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:40550) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Z74vZ-0008NC-UN for emacs-devel@gnu.org; Mon, 22 Jun 2015 12:50:35 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Z74vT-0007ct-U1 for emacs-devel@gnu.org; Mon, 22 Jun 2015 12:50:33 -0400 Original-Received: from gproxy1-pub.mail.unifiedlayer.com ([69.89.25.95]:57982) by eggs.gnu.org with smtp (Exim 4.71) (envelope-from ) id 1Z74vT-0007YU-N0 for emacs-devel@gnu.org; Mon, 22 Jun 2015 12:50:27 -0400 Original-Received: (qmail 10399 invoked by uid 0); 22 Jun 2015 16:50:17 -0000 Original-Received: from unknown (HELO cmgw3) (10.0.90.84) by gproxy1.mail.unifiedlayer.com with SMTP; 22 Jun 2015 16:50:17 -0000 Original-Received: from host114.hostmonster.com ([74.220.207.114]) by cmgw3 with id jajJ1q01A2UdiVW01ajMti; Mon, 22 Jun 2015 16:43:25 -0600 X-Authority-Analysis: v=2.1 cv=VdVkYjZ9 c=1 sm=1 tr=0 a=CQdxDb2CKd3SRg4I0/XZPQ==:117 a=CQdxDb2CKd3SRg4I0/XZPQ==:17 a=DsvgjBjRAAAA:8 a=f5113yIGAAAA:8 a=ywlL6poQgfEA:10 a=9i_RQKNPAAAA:8 a=hEr_IkYJT6EA:10 a=x_XPkuGwIRMA:10 a=XAFQembCKUMA:10 a=mDV3o1hIAAAA:8 a=klsy4m7Iok7XjjT5EZoA:9 Original-Received: from [76.218.37.33] (port=52831 helo=TAKVER2) by host114.hostmonster.com with esmtpa (Exim 4.84) (envelope-from ) id 1Z74vC-0002mU-Va for emacs-devel@gnu.org; Mon, 22 Jun 2015 10:50:11 -0600 In-Reply-To: <83si9jhi5u.fsf@gnu.org> (Eli Zaretskii's message of "Mon, 22 Jun 2015 18:33:33 +0300") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.5 (windows-nt) X-Identified-User: {2442:host114.hostmonster.com:stephele:stephe-leake.org} {sentby:smtp auth 76.218.37.33 authed with stephen_leake@stephe-leake.org} X-detected-operating-system: by eggs.gnu.org: GNU/Linux 3.x X-Received-From: 69.89.25.95 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:187388 Archived-At: Eli Zaretskii writes: > Fair disclosure: I don't like this "move to ELPA" attitude. I think > the net result will be more bugs because of unsynchronized development > and less exposure of packages to people who track development on > master, and more hassle due to the need to work with more than one Git > repository, multiple development philosophies, etc. > >> From: Stefan Monnier >> Date: Sun, 21 Jun 2015 20:45:36 -0400 >> Cc: emacs-devel >> >> step-1: we change the tarball-building script so as to pull some >> packages from elpa.git and include them somewhere under the `lisp' >> directory (for example) in the tarballs we distribute. >> step-2: we change the build scripts used from a Git checkout so they can >> also use those packages from elpa.git. >> step-3: we change the build scripts again so they always use those >> packages from elpa.git. >> >> At step 3, we'd have the following novelties: >> - the end user has to checkout both emacs.git and elpa.git before she >> can build Emacs (I suspect there will be some resistance, here). >> - packages in emacs/lisp can start to depend on packages from elpa.git. >> - we could even include preload some elpa.git packages (i.e. from loadup.el). >> >> I'm not exactly sure we'll ever get to step 3. > > At step 1, we'd have the following novelties: > > . Package developers will have to abide by some of the core's > development methodology, like freezing development when core does > so, perhaps using release branches, timely fixing of critical or > blocking bugs during pretests, etc., let alone abiding by style and > documentation guidelines. Only for ELPA pacakges that will be included in the Emacs tarball. These are the same requirements as on packages that are in emacs git, so it's nothing new. > . Core maintainers will probably start pushing more changes to the > packages, something I'm not sure package developers will like. That is a requirement of including a package in the tarball. Again, nothing new. > . We'd need to find a way of providing ChangeLogs for the packages, > either by merging their Git logs somehow, or by keeping their > ChangeLogs in separate directories (which would mean each package > will have its own directory, making load-path longer). Good points. > . We'd need to produce NEWS entries for the packages, which will > probably mean the packages will have to maintain their own NEWS > files, using the same methodology and style as in core development. That should be the case for ELPA packages anyway. > . If any of the packages have manuals, or are mentioned in the Emacs > manuals, changes there will have to be merged as well, and we will > have to track those updates, e.g. like we do in NEWS. yes. > . Our defcustom's have a ':version' tag, which is useful for quickly > examining new options since some release -- how will this work in > packages whose release cycle is not synchronized with Emacs? At > the very least, some changes to support that in > customize-changed-options will be needed. Similarly with > make-obsolete: we will need at least some standardized wording for > the WHEN argument, to avoid confusion between versions of Emacs and > the packages. I suggest :version contain the package version. To correlate that with an Emacs version, the NEWS entry for the package release date should be sufficient. -- -- Stephe