From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Philip Kaludercic Newsgroups: gmane.emacs.devel Subject: Re: having emacs-matlab in ELPA, finally. FSF paper signed Date: Mon, 12 Aug 2024 15:06:47 +0000 Message-ID: <87le1193w8.fsf@posteo.net> References: <871q37um8q.fsf@mat.ucm.es> <87v80cp8nx.fsf@mat.ucm.es> <877ccmkmwy.fsf@posteo.net> <87bk1y0wcm.fsf@mat.ucm.es> <87o75xkjpj.fsf@posteo.net> <87sev9zt31.fsf@mat.ucm.es> Mime-Version: 1.0 Content-Type: text/plain Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="39493"; mail-complaints-to="usenet@ciao.gmane.io" Cc: Andrea Corallo , To: Uwe Brauer Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Mon Aug 12 17:08:20 2024 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 1sdWee-000A1U-VD for ged-emacs-devel@m.gmane-mx.org; Mon, 12 Aug 2024 17:08:17 +0200 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1sdWdY-000363-Mt; Mon, 12 Aug 2024 11:07:08 -0400 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 1sdWdW-00035s-HJ for emacs-devel@gnu.org; Mon, 12 Aug 2024 11:07:06 -0400 Original-Received: from mout02.posteo.de ([185.67.36.66]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1sdWdJ-0005Cq-9H for emacs-devel@gnu.org; Mon, 12 Aug 2024 11:07:06 -0400 Original-Received: from submission (posteo.de [185.67.36.169]) by mout02.posteo.de (Postfix) with ESMTPS id C3278240103 for ; Mon, 12 Aug 2024 17:06:49 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=posteo.net; s=2017; t=1723475209; bh=BTNVkZeAfwvp+dnBMMysVD/i7zF4CbHgWv9JmNXDqM0=; h=From:To:Cc:Subject:Autocrypt:OpenPGP:Date:Message-ID:MIME-Version: Content-Type:From; b=VA6CYST8QdKypoJQnGsWyZepnp8zZmMepDFZDQYFtdWD6jUI5jONPtG24ftvt4syB ETzYIBKsJcK4UILS7DKWJWSeAgLfGEdNL8d/ob6dzKiN8pgrj7RPTHcwlXJ4bgXcmj HgdDva3AJZCM+3/kl9jp08VHNTgv++AjkiDL04tyn8iVF7W4bZHAiQoPnwtmGtM+Qd hOXuYq2LmvS5HCn1y7RHsOqFy3x52NFaWFO6JgHRsMW2O7Me7dl04acAJ8nQtOa5zP nxJgt1gZMyybpjBrBVy+KpvrD9J3YOzhPdZ0sGABuK/dEKz2oAzcPmtREXm/XpjCCU qFiG011nN052Q== Original-Received: from customer (localhost [127.0.0.1]) by submission (posteo.de) with ESMTPSA id 4WjHt10q92z9rxL; Mon, 12 Aug 2024 17:06:48 +0200 (CEST) In-Reply-To: <87sev9zt31.fsf@mat.ucm.es> (Uwe Brauer's message of "Mon, 12 Aug 2024 16:58:10 +0200") Autocrypt: addr=philipk@posteo.net; keydata= mDMEZBBQQhYJKwYBBAHaRw8BAQdAHJuofBrfqFh12uQu0Yi7mrl525F28eTmwUDflFNmdui0QlBo aWxpcCBLYWx1ZGVyY2ljIChnZW5lcmF0ZWQgYnkgYXV0b2NyeXB0LmVsKSA8cGhpbGlwa0Bwb3N0 ZW8ubmV0PoiWBBMWCAA+FiEEDg7HY17ghYlni8XN8xYDWXahwukFAmQQUEICGwMFCQHhM4AFCwkI BwIGFQoJCAsCBBYCAwECHgECF4AACgkQ8xYDWXahwulikAEA77hloUiSrXgFkUVJhlKBpLCHUjA0 mWZ9j9w5d08+jVwBAK6c4iGP7j+/PhbkxaEKa4V3MzIl7zJkcNNjHCXmvFcEuDgEZBBQQhIKKwYB BAGXVQEFAQEHQI5NLiLRjZy3OfSt1dhCmFyn+fN/QKELUYQetiaoe+MMAwEIB4h+BBgWCAAmFiEE Dg7HY17ghYlni8XN8xYDWXahwukFAmQQUEICGwwFCQHhM4AACgkQ8xYDWXahwukm+wEA8cml4JpK NeAu65rg+auKrPOP6TP/4YWRCTIvuYDm0joBALw98AMz7/qMHvSCeU/hw9PL6u6R2EScxtpKnWof z4oM OpenPGP: id=philipk@posteo.net; url="https://keys.openpgp.org/vks/v1/by-email/philipk@posteo.net"; preference=signencrypt Received-SPF: pass client-ip=185.67.36.66; envelope-from=philipk@posteo.net; helo=mout02.posteo.de X-Spam_score_int: -43 X-Spam_score: -4.4 X-Spam_bar: ---- X-Spam_report: (-4.4 / 5.0 requ) BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, RCVD_IN_VALIDITY_RPBL_BLOCKED=0.001, RCVD_IN_VALIDITY_SAFE_BLOCKED=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01 autolearn=unavailable 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:322677 Archived-At: Uwe Brauer writes: >> Uwe Brauer writes: > >> I am afraid I don't understand what you are trying to say here. It is >> true that you should check if new contributors have signed the FSF CA, >> but how does that related to Git branches? > > Sorry for not having explained this better. Once we have moved to github > (which I hoped to have done already), BTW, I forgot to mention that I can also recommend Codeberg, if it is just the UI you care about. > there are two scenarios > > 1. We proceed as before, that is around 4 authors, all of them > having signed the FSF paper, continue to contribute. > > 2. Out of sudden, because it is github and a people love pull > requests, a lot of contributions pop up, maybe from people > working for matlab, or for any other reasons. These contributions > might introduce new sexy features or bug fixes or both, but the > authors are somehow lazy to sign the FSF papers (it was quite a > bit of ordeal to have all contributors signed). In that scenario, > it might be a good idea to have 2 branches, > > 1. one for commits with authos having signed the FSF papers > > 2. One for commits with new contributions but with non-FSF > authors. Hmm, I have never heard of this kind of a model, usually a pull request would just stay open until the person has signed the documents. The main issue I'd anticipate is that it would become difficult to keep an overview of what was contributed by someone having signed the CA and not, causing fragmentation and a higher burden of maintenance. > > From experience it is best to be prepared. I know git is flexible: I can > create, rename and delete branches, but because git is so flexible the > process is not failsafe, name-rev does not always assign to a commit the > correct branch, which makes me nervous (being a mercurial user). > > >> Disregard this, I seem to have attached the wrong diff. > > Ok. > >> OK, just ping me when you think the cleanup process is done, and I can >> tell you if anything remains to be done before adding the package. > > Hopefully soon. -- Philip Kaludercic on peregrine