From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Stefan Monnier Newsgroups: gmane.emacs.devel Subject: Re: Adding the `prescient` packages to NonGNU ELPA? Date: Sun, 20 Nov 2022 10:19:41 -0500 Message-ID: References: <16193c73-ab80-04c9-558f-d5e6142f38f3@protonmail.com> <871qpydllo.fsf@posteo.net> Mime-Version: 1.0 Content-Type: text/plain Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="18053"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Gnus/5.13 (Gnus v5.13) Cc: Philip Kaludercic , Okamsn , emacs-devel@gnu.org To: Stefan Kangas Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Sun Nov 20 16:20:50 2022 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 1owm7l-0004UG-5Z for ged-emacs-devel@m.gmane-mx.org; Sun, 20 Nov 2022 16:20:49 +0100 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1owm7C-0000hh-SB; Sun, 20 Nov 2022 10:20:14 -0500 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1owm73-0000fq-4U for emacs-devel@gnu.org; Sun, 20 Nov 2022 10:20:13 -0500 Original-Received: from mailscanner.iro.umontreal.ca ([132.204.25.50]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1owm6x-0005ot-WB for emacs-devel@gnu.org; Sun, 20 Nov 2022 10:20:04 -0500 Original-Received: from pmg3.iro.umontreal.ca (localhost [127.0.0.1]) by pmg3.iro.umontreal.ca (Proxmox) with ESMTP id 7874644091A; Sun, 20 Nov 2022 10:19:54 -0500 (EST) Original-Received: from mail01.iro.umontreal.ca (unknown [172.31.2.1]) by pmg3.iro.umontreal.ca (Proxmox) with ESMTP id 2447A440850; Sun, 20 Nov 2022 10:19:49 -0500 (EST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=iro.umontreal.ca; s=mail; t=1668957589; bh=lffVe3TTo7q8r5rbWtyuDTyGose6HunHBaI7orBIjoA=; h=From:To:Cc:Subject:In-Reply-To:References:Date:From; b=HC1Ih+UULhxEW5s4JI7+ZlpYpCGDeS62kiTkZR+i/4a/+Tajn8DpSOxs0xCeuc0j/ 13MlMWuBaglodQzCkqqe0V8/PywYUSSS0mLlxvoG8LvXhimZ1Wk2LmQmN6WNUWDTEu CIs+RhisYE+WPzMfeoyNP1kbH5+BXnQ98kKm4rYLbk1+eHzQOBkP04uw/wgzBZEyBy 35lqdWD7DffKczTZBa3Bq1AmxBzo51mzHvMBPBQpoEvjeSi3XSugeb0lQtOntV/eUO Po/TBiHHOQ/+88josq/mgVu8rWEsdYUi55936BBzDj4uwhSA6IitRzc1HuCOf2d7MK uKu/8kzzkKrrQ== Original-Received: from pastel (unknown [104.247.241.157]) by mail01.iro.umontreal.ca (Postfix) with ESMTPSA id D3D1012027C; Sun, 20 Nov 2022 10:19:48 -0500 (EST) In-Reply-To: (Stefan Kangas's message of "Sun, 20 Nov 2022 03:23:09 -0800") Received-SPF: pass client-ip=132.204.25.50; envelope-from=monnier@iro.umontreal.ca; helo=mailscanner.iro.umontreal.ca X-Spam_score_int: -42 X-Spam_score: -4.3 X-Spam_bar: ---- X-Spam_report: (-4.3 / 5.0 requ) BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=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.29 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-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Xref: news.gmane.io gmane.emacs.devel:300250 Archived-At: Stefan Kangas [2022-11-20 03:23:09] wrote: > Philip Kaludercic writes: >>> All of these packages live in the same repository in the link below. >> >> Would it be possible to change this? E.g. by making each project live >> on it's own branch. That would make the :ignored-files rules below a >> lot simpler. > > We could also make the rules simpler by adding support for the inverse > of :ignored-packages. Multi-package repositories are fundamentally incompatible with `package-vc` (they kind of work, but with various caveats). So I think we definitely don't want to support them better, but instead we should discourage them. If we want to invest efforts in that direction it should be efforts to make it easier to "re-merge" packages so as to move away from the problem. Stefan