From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Oleh Krehel Newsgroups: gmane.emacs.devel Subject: Re: New ELPA policy proposal Date: Mon, 09 Nov 2015 16:02:01 +0100 Message-ID: <87r3jzdxna.fsf@gmail.com> 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> <56401834.8080402@yandex.ru> <87611bh19q.fsf_-_@gmail.com> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: ger.gmane.org 1447081377 4588 80.91.229.3 (9 Nov 2015 15:02:57 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Mon, 9 Nov 2015 15:02:57 +0000 (UTC) Cc: emacs-devel To: Artur Malabarba Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Mon Nov 09 16:02:48 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 1Zvnxy-00068f-K9 for ged-emacs-devel@m.gmane.org; Mon, 09 Nov 2015 16:02:42 +0100 Original-Received: from localhost ([::1]:53271 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Zvnxy-0000zY-2i for ged-emacs-devel@m.gmane.org; Mon, 09 Nov 2015 10:02:42 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:45538) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZvnxK-0000pK-5S for emacs-devel@gnu.org; Mon, 09 Nov 2015 10:02:06 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1ZvnxG-0007TS-Oi for emacs-devel@gnu.org; Mon, 09 Nov 2015 10:02:02 -0500 Original-Received: from mail-wm0-x22e.google.com ([2a00:1450:400c:c09::22e]:33577) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZvnxG-0007TO-G3 for emacs-devel@gnu.org; Mon, 09 Nov 2015 10:01:58 -0500 Original-Received: by wmec201 with SMTP id c201so84148211wme.0 for ; Mon, 09 Nov 2015 07:01:57 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:to:cc:subject:references:date:in-reply-to:message-id :user-agent:mime-version:content-type; bh=064sSWmAjUteUoXmvjRZYQJ6RbpzHht1psAUnpQTvTw=; b=TXPeLQ8sPlXAZubkjQBTcGbcfixZbLTm+Hc+Dw8X/H+aiy1vSXR4UJ6h2NB5+wgek/ N1H/j1QdJaoozoTi1aFehB+1e/0pE2lc+FClOnDwGL+uCUgJRE7E6VmNM6jks7TdSNO/ vj47nWePgUte/3uoWYa9/7VB+vXs7vyngM0hNwYnfGFbm2bXQzv7h0+Xe3CFAjNzEYWV AFMolvlpI95cjYk0IFVxd1HzpLBKRe7hLtgWcbR7WOsKxNk9NoEQ33Ve7GkbiWmhYk++ VqJbAGqCEKw1uFDI0jImV40CfBnZfJSjPOjmSBgzcyzs7A/sh6+tK2ZhWmh3vrL1ctXx GyLA== X-Received: by 10.194.87.39 with SMTP id u7mr7085396wjz.11.1447081317634; Mon, 09 Nov 2015 07:01:57 -0800 (PST) Original-Received: from firefly (dyn069045.nbw.tue.nl. [131.155.69.45]) by smtp.gmail.com with ESMTPSA id ft4sm15829327wjb.37.2015.11.09.07.01.56 (version=TLSv1.2 cipher=RC4-SHA bits=128/128); Mon, 09 Nov 2015 07:01:56 -0800 (PST) In-Reply-To: (Artur Malabarba's message of "Mon, 9 Nov 2015 13:51:31 +0000") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/25.0.50 (gnu/linux) X-detected-operating-system: by eggs.gnu.org: Error: Malformed IPv6 address (bad octet value). X-Received-From: 2a00:1450:400c:c09::22e 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:193711 Archived-At: Artur Malabarba writes: > Two Things: > > * The first and simplest issue here is that we would lose control over > the code on Gelpa. > > We can still remove any package from Gelpa entirely, of course. But it > would be difficult for the Emacs maintainers to edit a package on > Gelpa that's doing something wrong. For instance, Stefan has edited > several of my packages in the past (which I'm grateful for), and he > wouldn't have been able to do that if the source wasn't on elpa.git. > > But maybe that's just a cost that needs to be paid if we want Gelpa to scale. This doesn't have to be so. GELPA is a git repository on Savannah. Anyone with proper SSH keys can edit it. What I propose is to split GELPA into 130 git repositories on Savannah (or separate git branches of one repository if that's more convenient). All Emacs devs will still have the same access to every package. But the commit log won't be a mingled mess: each package will have its own commit log and its own version - the latest version tag on the appropriate branch. Then the main ELPA directory will hold the current version hashes for each ELPA package. And the main Emacs repository will hold one ELPA hash snapshot for each Emacs release. > * Another thing to remember is that we need to be able to trust that > code made available by Gelpa has been properly copyright assigned. > > The current way we do that is to: > 1. Only make available code that has been pushed to elpa.git. > 2. We trust those with push access to only push code that's been > assigned (to the best of their knowledge). > 3. We trust that those who submit code are not lying about its origins. > > IIUC, your proposal is that new releases would be marked by editing a > file in the Gelpa repo and adding a hash of the relevant commit. > This sounds more or less ok: > 2. The manual edit of a hash would still have to be done by people > with push access, so only they could ultimately make new code > available on Gelpa. > 3. The act of a developer asking us to edit a hash could be considered > analogous to the act submitting a package (i.e., they are declaring > that all the new code in that commit has been properly assigned, just > like they originally declared so when first submitting the package). I assume the process could have several tiers. tier 1: I edit my package in a Git repository on my machine and accept contributions with CA. tier 2: I sync my Git repository with its Git repository on Savannah (a sub-directory of GELPA) tier 3: The main directory of GELPA should always hold the hashes of all packages, the stable versions that are to be published to https://elpa.gnu.org/packages/. This information will be updated with each new release of any package. tier 4: On release of a new Emacs version, a snapshot of GELPA hashes will be committed into Emacs. All code that corresponds to that snapshot will be bundled with emacs-with-elpa.tar. Currently, tier 3 is done with ";; Version: ..." cookie. I propose that we do it with git tags and hashes instead/additionally. As for tier 4, the package maintainers take the responsibility to ensure that the package hash included into Emacs works correctly around the time when each feature freeze is announced. The above system can solve an inconvenience that I've occasionally run into with the current GELPA setup: the "git subtree merge" doesn't allow me to easily pull anyone's changes done in GELPA back into my package. In fact, at times I haven't noticed a change for a month, committed a bunch on top of the version in GELPA, and then had to do a rebase and resolve merge conflicts. In the end, I'd like to setup a workflow where my package has two identical public fronts: one on Github and one on Savannah. Pushing to one should push to the other one. And if I pull from both, I'll be immediately notified if any other Emacs developer edited my package on Savannah, and I'll just commit on top of these changes. Here's a visual representation of the ELPA directory on Savannah that I propose: |-elpa/ |--.git/ |--ace-window/ |---./git/ |--ack/ |---.git/ ... |--.gitignore |--package-list Everyone that currently has access to ./elpa/ will automatically have access to ./elpa/*. Each sub-directory is its own git repository, and ./.gitignore will ignore everything except ./package-list, and maybe some auxiliary scripts. ./package-list could have the following structure: ace-window: eef897e590c4ce63c28fd29ebff3c97aec8a69ae ack: 1487ae155ccc2a3099b8e0f20334a79fa8f5b9a8 ... In the end, ./package-list could simply be built automatically by a shell command examining each repository for a version tag. But it might be good to have each new version release accompanied by a commit to ./package-list.