Re: Where / when Emacs on Gitlab?

[Alan Mackenzie <acm@muc.de>]

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).