From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Eli Zaretskii Newsgroups: gmane.emacs.devel Subject: Re: ELPA policy Date: Mon, 09 Nov 2015 20:45:24 +0200 Message-ID: <83lha7m2pn.fsf@gnu.org> References: <87ziyuaqhl.fsf@petton.fr> <87fv0labbf.fsf@web.de> <87y4eda0kl.fsf@petton.fr> <22074.42230.156669.584780@retriever.mtv.corp.google.com> <87ziyoxvdp.fsf@Rainer.invalid> <83k2psnzyh.fsf@gnu.org> <87mvuorz7n.fsf@gmail.com> <8337wfon3f.fsf@gnu.org> <87h9kvyqv9.fsf@Rainer.invalid> Reply-To: Eli Zaretskii NNTP-Posting-Host: plane.gmane.org X-Trace: ger.gmane.org 1447094773 10369 80.91.229.3 (9 Nov 2015 18:46:13 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Mon, 9 Nov 2015 18:46:13 +0000 (UTC) Cc: emacs-devel@gnu.org To: Achim Gratz Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Mon Nov 09 19:46:02 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 1ZvrS2-0001bn-IR for ged-emacs-devel@m.gmane.org; Mon, 09 Nov 2015 19:45:58 +0100 Original-Received: from localhost ([::1]:54970 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZvrS1-00054Z-TL for ged-emacs-devel@m.gmane.org; Mon, 09 Nov 2015 13:45:57 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:33344) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZvrRc-00053j-1T for emacs-devel@gnu.org; Mon, 09 Nov 2015 13:45:32 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1ZvrRX-0008Bu-M7 for emacs-devel@gnu.org; Mon, 09 Nov 2015 13:45:31 -0500 Original-Received: from mtaout20.012.net.il ([80.179.55.166]:49435) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZvrRX-0008Ax-Di for emacs-devel@gnu.org; Mon, 09 Nov 2015 13:45:27 -0500 Original-Received: from conversion-daemon.a-mtaout20.012.net.il by a-mtaout20.012.net.il (HyperSendmail v2007.08) id <0NXK0090094D2V00@a-mtaout20.012.net.il> for emacs-devel@gnu.org; Mon, 09 Nov 2015 20:45:24 +0200 (IST) Original-Received: from HOME-C4E4A596F7 ([84.94.185.246]) by a-mtaout20.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0NXK008UP9FOW3A0@a-mtaout20.012.net.il>; Mon, 09 Nov 2015 20:45:24 +0200 (IST) In-reply-to: <87h9kvyqv9.fsf@Rainer.invalid> X-012-Sender: halo1@inter.net.il X-detected-operating-system: by eggs.gnu.org: Solaris 10 X-Received-From: 80.179.55.166 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:193737 Archived-At: > From: Achim Gratz > Date: Mon, 09 Nov 2015 19:22:50 +0100 > > Eli Zaretskii writes: > > The suggestion was to move _all_ of them, except the few that are > > needed for bootstrap, out of the Emacs repository. > > You keep arguing about things that realistically aren't even on the > table yet (I don't want to prevent that discussion, mind you). If that's not on the table, then please tell what in your opinion _is_ on the table. You did want to propose something practical that could be done soon, right? Because this discussion was about what we want to do from now on with ELPA, not what we might want considering in some distant future that might never come. So please, let's be practical and consider alternatives that realistically can be taken soon. Like tomorrow or the next month. Okay? > There'd certainly be a transition period with some pilot packages, I'd > probably pick Org, CEDET and Tramp based on the list traffic. Moving out a few large packages that are developed outside Emacs anyway is a no-brainer, provided that their developers agree. I already said I'll probably agree, and no one else objected. The only question is what is the opinion of the respective developers: we cannot move the packages if they disagree. Is there some other alternative on the table? If not, we can finally agree about something, I think. Thanks.