From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Alan Mackenzie Newsgroups: gmane.emacs.devel Subject: Re: Where / when Emacs on Gitlab? Date: Thu, 11 Jan 2024 10:42:32 +0000 Message-ID: References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="40191"; mail-complaints-to="usenet@ciao.gmane.io" Cc: emacs-devel@gnu.org To: Psionic K Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Thu Jan 11 11:43:37 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 1rNsX9-000AEN-Mw for ged-emacs-devel@m.gmane-mx.org; Thu, 11 Jan 2024 11:43:35 +0100 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1rNsWW-0003a1-1T; Thu, 11 Jan 2024 05:42:56 -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 1rNsWR-0003Zr-JO for emacs-devel@gnu.org; Thu, 11 Jan 2024 05:42:51 -0500 Original-Received: from mail.muc.de ([193.149.48.3]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1rNsWM-0001SI-7r for emacs-devel@gnu.org; Thu, 11 Jan 2024 05:42:50 -0500 Original-Received: (qmail 45491 invoked by uid 3782); 11 Jan 2024 11:42:33 +0100 Original-Received: from acm.muc.de (p4fe15a91.dip0.t-ipconnect.de [79.225.90.145]) (using STARTTLS) by colin.muc.de (tmda-ofmipd) with ESMTP; Thu, 11 Jan 2024 11:42:32 +0100 Original-Received: (qmail 5683 invoked by uid 1000); 11 Jan 2024 10:42:32 -0000 Content-Disposition: inline In-Reply-To: X-Submission-Agent: TMDA/1.3.x (Ph3nix) X-Primary-Address: acm@muc.de Received-SPF: pass client-ip=193.149.48.3; envelope-from=acm@muc.de; helo=mail.muc.de 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, T_SCC_BODY_TEXT_LINE=-0.01 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:314848 Archived-At: Hello, Psionic K. On Thu, Jan 11, 2024 at 15:22:12 +0900, Psionic K wrote: > I only just caught Stefan's presentation on Emacs development > https://toobnix.org/w/m4XmrmE9Geat54AKT1RQaH > I'm in favor of a relief valve for the email based workflows and > generally experienced at these sorts of CI and repo automation tools. > Most importantly in this email, I don't lurk on the mailing lists, so > someone feel free to reply to me directly to make sure we connect on > Gitlab etc whenever it's ready to happen. Are you not aware that the current workflows are a "relief valve" against web browser based workflows? > By the way, the largest downsides, which we can't see or measure on > email based systems, are representation (ad-hoc emoji votes provide a > lot of signal when following the Rust project) and survivor bias (we > never hear again from those pushed away by development style > preference). I'm not aware of anybody being so pushed away. What is your evidence for the existence of such developers? > While these web 2.0 style services have their own drawbacks for > communication that have become more clear in their 20 years of > evolution, the better systems are currently under development and we > should direct attention toward making better things rather than > applying friction to each other over the drawbacks of these soon-to-be > ancient web 2.0 platforms. Everyone go review transaction roll-ups > and CRDT's, the data structures of freedom. See > https://elpa.gnu.org/packages/crdt.html and then use web 2.0 without > guilt until we can do better. The rule of bootstrapping is to use the > merely sufficient to create the good. What is a "transaction roll-up"? What is a "CRDT"? You don't explain these obscure terms, instead expecting your readers to apply extra effort and follow a web link. > Gitlab appears allright. I had anxieties about losing familiarity > with Actions automations. My default preference would have been > Github since, if we're making a relief valve, we should choose the > most popular relief valve and then adapt from there. I read at least > one of RMS's ever abstract comments about ethics or something. Github > or Gitlab etc is a tool. Tools are meant to be used, even abused > without apology, to achieve ends. Github has severe faults. One of the biggest is that it is controlled by Microsoft, who are known as a notorious personal data slurper. They would be in a position to blackmail us in the future if we committed our developement processes to them. Tools are meant to be used, but not by other entities against us. > We should prioritize mass of purity over purity in spite of mass. A > pure but infinitesimal mass is but the ghost of departed purity. Sorry, that makes not the slightest sense to me. > By the way, a template for a Gitlab repository creation would do > wonders for asking those using Github to move away. I have created > such a template for https://github.com/positron-solutions/erk-basic > and continue to refine the critical pieces towards achieving > competitive parity with the Typescript folks at efficiently > promulgating their software. Maintaining package headers and > upgrading the local linting and emacsen testing workflows are my > priorities for that package. I support choice, and Gitlab seems to be > a choice we may see become popular in this ecosystem. > I dare mention there may have been some confusion around emojis. > People don't want to type "cat" to each other. We want to press a cat > button on a message in order to create signal about how much attention > is flowing into a topic and how much excitement, consensus, and/or > contention is present without clogging up the pipes to say, "yeah, me > too." I would prefer to type cat when I am writing about the animal, or an abbreviation for concatenate. I am literate (and numerate), and expect people corresponding with me also to be literate. Besides, emojis don't display on my terminal, and I've no way to type them. There is scope for improving our development processes. But it needs to be done in a sensible measured fashion (Emacs is well over 40 years old), not just shoehorned into the latest passing fad. Also, somebody needs to do it. -- Alan Mackenzie (Nuremberg, Germany).