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: Proposal for an Emacs User Survey Date: Mon, 19 Oct 2020 19:42:42 +0300 Message-ID: <20201019164242.GH19325@protected.rcdrun.com> References: <20201013052736.GE31408@protected.rcdrun.com> <20201016130235.06218dae@argon> <87eelvplvh.fsf@posteo.net> <10bdf4ea-e365-cc3d-ec03-4348946fadbe@yandex.ru> 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="36981"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Mutt/1.10.1 (2018-07-13) Cc: "Philip K." , rms@gnu.org, thibaut.verron@gmail.com, mve1@runbox.com, emacs-devel@gnu.org, Dmitry Gutov To: Drew Adams Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Mon Oct 19 18:56:07 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 1kUYS6-0009UJ-Oc for ged-emacs-devel@m.gmane-mx.org; Mon, 19 Oct 2020 18:56:06 +0200 Original-Received: from localhost ([::1]:49212 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1kUYS5-0002S8-Ry for ged-emacs-devel@m.gmane-mx.org; Mon, 19 Oct 2020 12:56:05 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:35638) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1kUYFG-0000CD-2w for emacs-devel@gnu.org; Mon, 19 Oct 2020 12:42:50 -0400 Original-Received: from static.rcdrun.com ([95.85.24.50]:47449) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1kUYFE-00071Q-9X; Mon, 19 Oct 2020 12:42:49 -0400 Original-Received: from localhost ([::ffff:41.202.241.51]) (AUTH: PLAIN admin, TLS: TLS1.2,256bits,ECDHE_RSA_AES_256_GCM_SHA384) by static.rcdrun.com with ESMTPSA id 00000000002A0BF2.000000005F8DC205.0000033D; Mon, 19 Oct 2020 16:42:45 +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-detected-operating-system: by eggs.gnu.org: First seen = 2020/10/19 12:25:27 X-ACL-Warn: Detected OS = Linux 3.11 and newer [fuzzy] X-Spam_score_int: -18 X-Spam_score: -1.9 X-Spam_bar: - X-Spam_report: (-1.9 / 5.0 requ) BAYES_00=-1.9, SPF_HELO_PASS=-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:258135 Archived-At: * Drew Adams [2020-10-19 18:48]: > > MELPA to a large part consists of a database of "recipes", one for each > > package that it builds and distributes. This tag can be put inside > > recipes, and thus be controlled by MELPA maintainers, and not by the > > packages authors themselves. > > > > If we provide some well-defined criteria for such tags, and pick a > > neutral-enough name, I don't see why the MELPA maintainers (who are > > quite reasonable people IME) wouldn't go for it. > > Just a minor comment/question about this, which > I think would be the first time such a thing > would be happening: > > Do we really want to set a precedent that > someone other than the code author fiddles with > their code, adding comments or whatever? > > Sure, the maintainers of a repo are, in a way, > administrators. But should such administrators > be changing source code? Adding other code or > whatever, to administer, label, treat, etc. the > code is, at least conceptually, different from > changing the source code itself. > > No, adding a field/tag in a comment is not a big > deal. And yes, GPL code is open to modification. > > Still, is this a good door to open? That is similar to how many GNU/Linux software packages are maintained, often they are modified before such enter distribution for final users. I do not care if package is original, not original, forked or not forked, modified, what I care is which group of people is making it trusted and by which principles. If nobody is making package verifications by looking into it, then such package is not trusted to me, with or without PGP signature, it does not matter any more. That is why some GNU/Linux distributions have so many maintainers, each is responsible for some packages, there is no warranty, but there is some implied moral obligation at least. Some OS like OpenBSD have better security policies, they verify the code for security, not just package and wrap it for delivery.