From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Jean Louis Newsgroups: gmane.emacs.devel Subject: Re: NonGNU ELPA Date: Fri, 27 Nov 2020 17:56:32 +0300 Message-ID: References: <87o8k7yt7n.fsf@gnu.org> <87ima56h1a.fsf@gnu.org> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="34814"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Mutt/2.0 (3d08634) (2020-11-07) Cc: emacs-devel@gnu.org, bandali@gnu.org, Richard Stallman , Stefan Kangas To: Stefan Monnier Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Fri Nov 27 16:28:21 2020 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 1kiffY-0008vV-3T for ged-emacs-devel@m.gmane-mx.org; Fri, 27 Nov 2020 16:28:20 +0100 Original-Received: from localhost ([::1]:45108 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1kiffX-00018B-4n for ged-emacs-devel@m.gmane-mx.org; Fri, 27 Nov 2020 10:28:19 -0500 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:40078) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1kifEN-0002gU-Je for emacs-devel@gnu.org; Fri, 27 Nov 2020 10:00:15 -0500 Original-Received: from static.rcdrun.com ([95.85.24.50]:59855) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1kifEL-00084F-71; Fri, 27 Nov 2020 10:00:15 -0500 Original-Received: from localhost ([::ffff:197.157.0.29]) (AUTH: PLAIN admin, TLS: TLS1.2,256bits,ECDHE_RSA_AES_256_GCM_SHA384) by static.rcdrun.com with ESMTPSA id 00000000002C0003.000000005FC11479.00001421; Fri, 27 Nov 2020 15:00:09 +0000 Content-Disposition: inline In-Reply-To: Received-SPF: pass client-ip=95.85.24.50; envelope-from=bugs@gnu.support; helo=static.rcdrun.com X-Spam_score_int: -3 X-Spam_score: -0.4 X-Spam_bar: / X-Spam_report: (-0.4 / 5.0 requ) BAYES_00=-1.9, RCVD_IN_SORBS_WEB=1.5, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001 autolearn=no 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:259894 Archived-At: * Stefan Monnier [2020-11-26 17:20]: > > Yes, we should do that. It should state the full rules, which > > I've posted here, adding some details from my previous message. > > I'll do make that and send it to you. > > FWIW, I've put that in the README.org of nongnu.git > (http://git.savannah.gnu.org/cgit/emacs/nongnu.git/tree/README.org) in > the "Guidance for accepting packages" Thank you Stefan. I may have just few thoughts on README.org and I know it is in progress to be polished. - head is missing to explain in brief what is nonGNU ELPA - Regarding heading "The Emacs maintainers will decide what packages to put in NonGNU ELPA." as this heading comes so early in "Guidance for accepting packages", I would say that the tone of that heading gives on me as non native English speaker somewhat negative or little bit unwelcoming impression. Maybe it can be said that everybody is welcome to apply to include packages in nonGNU ELPA and that Emacs maintainers will have final decision based on various GNU free software policies. Something like that should or could be the first what users read. - The Org headings are made so that it is not really heading rather begin of a sentence. Heading should be summary of a paragraph below. I know this is all in progress. - I feel this sentence as defensive and reiteration what was previously said: "** If an ELisp package follows the rules below, we can add it to NonGNU ELPA if we want to." -- Instead one could formulate it in some positive manner: "Please review the rules below and align your package to conform to it to help maintainers make a decision" -- something like that, but maybe better formulated. - "We may also change the code in NonGNU ELPA for other reasons, technical or not. After all, it is free software." -- that is all clear and good, I just feel it is defensive for no apparent reason. In my opinion it requires some adaptations similar to above. - "let's discuss it" should have clear pointers which communication lines to use, for example there could be hyperlins to the mailing list, or how to subscribe to mailing list, or some other communication lines. Among thousands of authors it is so that only subset of them is participating in GNU mailing lists. They need not know how to contact. Also website should give pointers on how to contact Emacs maintainers. - README.org for nonGNU ELPA once polished could be included in etc/ in distribution - "FSF conventions" should be maybe hyperlinked to FSF and conventions as this way we give some references for further learning as maybe people wish to apply with their packages directly to GNU ELPA as well and may wish to contribute to Emacs directly. References and pointers to that type of contribution should also be included. - In general I would myself hyperlink many terms such as GNU operating system, GNU/Linux to reference on GNU with differences in terms of Linux and GNU - I would exclude the Savannah rule about advertisement as if it is general rule than those who advertise may be later warned why, as if it is final decision of Emacs maintainers then maintainers will handle those incidents. This paragraph is IMHO not necessary as may drive people away. It is easy to warn somebody. Advertising could be construed as simple placing of a hyperlink. Or telling "Copyright Free Software or ABC Foundation". Or otherwise one should clearly define what advertisement means. When one say "you may not advertise anything commercial" does it mean that some commercially sold free software cannot be placed in the repository? Then there are exeption cited about fan items that one may sell directly to user which is somehow contradictory. In general that section should be maybe defined better or removed and defined in general Savannah rules. As README.org could be eventually distributed or mirrored, it can get wide distribution. That is why is better to now revise whatever maintainers wish to revise. - "Adding a package" is there, and fine, but nothing says about how authors or other people may propose packages to be included. That is missing as first step for people to contribute. - in general it should be more welcoming for contributors to feel more free to apply and contribute and to have references how to apply and how to contribute. While this is explained partially, it may need more description and clarifications. - There shall be more references to GNU ELPA, to Emacs Lisp manual and section Packaging and GNU website. Thank you for considerations, Jean