Where / when Emacs on Gitlab?

Where / when Emacs on Gitlab?

[Psionic K]

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.

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

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.

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.  We should prioritize mass of purity
over purity in spite of mass.  A pure but infinitesimal mass is but
the ghost of departed purity.

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

Re: Where / when Emacs on Gitlab?

[tomas]

[-- Attachment #1: Type: text/plain, Size: 884 bytes --]

On Thu, Jan 11, 2024 at 03:22:12PM +0900, Psionic K wrote:
> I only just caught Stefan's presentation on Emacs development
> https://toobnix.org/w/m4XmrmE9Geat54AKT1RQaH

[...]

> 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 [...]

You align things along a "worse...better" line, but let me say
that this valuation corresponds to your opinion, which I do
respect but I don't share at all.

For me, a good mail workflow is way better than any of the Web 2.0
alternatives available (and yes, I do have experience with Gitlab).

Cheers
-- 
t

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 195 bytes --]

Re: Where / when Emacs on Gitlab?

[Uwe Brauer via Emacs development discussions.]

[-- Attachment #1: Type: text/plain, Size: 1517 bytes --]

>>>   <tomas@tuxteam.de> writes:

> On Thu, Jan 11, 2024 at 03:22:12PM +0900, Psionic K wrote:
>> I only just caught Stefan's presentation on Emacs development
>> https://toobnix.org/w/m4XmrmE9Geat54AKT1RQaH

> [...]

>> 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 [...]

> You align things along a "worse...better" line, but let me say
> that this valuation corresponds to your opinion, which I do
> respect but I don't share at all.

> For me, a good mail workflow is way better than any of the Web 2.0
> alternatives available (and yes, I do have experience with Gitlab).

I agree completely. When I have to deal with gitlab/github issues (which
can be done partially by email), I have the feeling of a huge step
backwards.

Maybe if there were a sophisticated emacs interface for these
gitlab/github-issus, things might be different but right now, I find it
too restricted and to clumsy to use.
> Cheers

-- 
I strongly condemn Hamas heinous despicable pogroms/atrocities on Israel
I strongly condemn Putin's war of aggression against Ukraine.
I support to deliver weapons to Ukraine's military. 
I support the EU and NATO membership of Ukraine. 


[-- Attachment #2: smime.p7s --]
[-- Type: application/pkcs7-signature, Size: 5673 bytes --]

Re: Where / when Emacs on Gitlab?

[Po Lu]

Psionic K <psionik@positron.solutions> writes:

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

Without entering into detail, on every occasion where someone proposes
that we move to this or that development process or software, the
proposals and responses abound in praise of such software, but never
offer to bring them into practice, whether by assisting with deploying
the software or by developing new software to integrate it with our
existing practices and procedures.  Several lengthy discussions of this
nature unfold every year in identical fashion, from which discussions
the same conclusions are drawn and the same requests made, all of which
have yet to be realized.

The praise is written as though it makes up for the lack of initiative
on the part of such proponents, and its subjects can range from features
that could plausibly benefit us to functionality so far removed from
actual software development that one wonders whether they are used for
the novelty (or absurdity) factor alone.  I mention this to point out
that it's completely unnecessary--we don't need to be convinced by new
additions to the litany of advantages that have already been cited as
reasons to adopt such software, since the preferences some of our users
have expressed are reason enough.

What remains is to install the new software, so that these proposals can
be implemented, and to take measures to guarantee continued access over
existing interfaces to anyone who wants it, both to avoid disrupting
existing habits and that more developers might be accommodated, instead
of sacrificing one cohort for another.

For this discussion to be productive, then, please resist the temptation
to belabor the pros and cons of the workflows concerned, and focus on
meeting the requirements we agreed on in its numerous predecessors
instead.

Thanks.

Re: Where / when Emacs on Gitlab?

[Eli Zaretskii]

> From: Psionic K <psionik@positron.solutions>
> Date: Thu, 11 Jan 2024 15:22:12 +0900
> 
> 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.

Gitlab has issues, and at least some of them need to be resolved
before we could switch.  For the details, see

  https://gitlab.com/gitlab-org/gitlab/-/issues/28152

Other similar tools and services were proposed over the years, but
they all share the same problem: some aspects that we require are
either absent or buggy or fall short of what we need.

Past discussions concluded that there's no resistance to migrating to
one of those tools/services as long as the minimum requirements are
fulfilled.

So for something like this to happen, motivated individuals should
step forward and provide the missing features in some of these tools,
at which point we could start the process of migrating to that tool.

Re: Where / when Emacs on Gitlab?

[Alan Mackenzie]

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

Re: Where / when Emacs on Gitlab?

[Psionic K]

[-- Attachment #1: Type: text/plain, Size: 139 bytes --]

I'll have to pass on this one.  I'm still digesting the advanced sense of
comedy that has evolved since my last journey through this land.

[-- Attachment #2: Type: text/html, Size: 185 bytes --]

Re: Where / when Emacs on Gitlab?

[T.V Raman]

To me the biggest issue with Web-2.0 style solutions is that they force
you into a JS-obligatory browsers with all the other downsides that that
brings along. So, yes, let's use a web-2.0 or even 3.0? where we make
forward progress, but for emacs, perhaps e can use emacs/eww as the acid
test for does it "keep us free of the so-called mainstream browser
trap"?

-- 

Re: Where / when Emacs on Gitlab?

[Psionic K]

> where we make forward progress

So who here has the game plan to turn the tide?

Re: Where / when Emacs on Gitlab?

[tomas]

[-- Attachment #1: Type: text/plain, Size: 630 bytes --]

On Fri, Jan 12, 2024 at 07:37:25AM +0900, Psionic K wrote:
> > where we make forward progress
> 
> So who here has the game plan to turn the tide?

You have. You just have to convince people that "turning the tide" is
a good idea.

Currently you aren't doing a good job at this, as far as I am concerned.
Possibly others feel similarly.

In other words: you seem to be convinced that Yor Way is the Right Way.
Nothing wrong with that. But you don't seem willing to listen to others
why they think Their Way seems the Right Way for them.

That may just be my impression, and I'm willing to learn.

Cheers
-- 
t

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 195 bytes --]

Re: Where / when Emacs on Gitlab?

[Emanuel Berg]

tomas wrote:

> In other words: you seem to be convinced that Yor Way is the
> Right Way. Nothing wrong with that. But you don't seem
> willing to listen to others why they think Their Way seems
> the Right Way for them.

Optimally one would have systems that are interface-agnostic
to the point everyone could use whatever they wanted to
access the same thing.

E-mail, interactive homepages, smartphone services, whatever
the future holds.

The data would be packaged and repackaged and bounced between
those systems so that everyone could both contribute and
"consume" material in their prefered way.

Yet another protocol or gateway, or maybe half a dozen, but
still shouldn't be that hard to do in terms of computing?

-- 
underground experts united
https://dataswamp.org/~incal

Re: Where / when Emacs on Gitlab?

[tomas]

[-- Attachment #1: Type: text/plain, Size: 1172 bytes --]

On Fri, Jan 12, 2024 at 06:19:05AM +0100, Emanuel Berg wrote:
> tomas wrote:
> 
> > In other words: you seem to be convinced that Yor Way is the
> > Right Way. Nothing wrong with that. But you don't seem
> > willing to listen to others why they think Their Way seems
> > the Right Way for them.
> 
> Optimally one would have systems that are interface-agnostic
> to the point everyone could use whatever they wanted to
> access the same thing.

This is an interesting idea; in practice, it is more difficult
than expected. I've observed that several times: the "medium"
(presentation, whatever) does influence communication style
and patterns, and you "feel" bumps at medium boundaries.

I've seen that with a mail capable forum (Discourse), which I've
been taking part for five years. Heck, I've seen that with plain
old mail, using mutt and immersed in an Outlook environment.

It'll take a lot of thought and design to overcome that. I even
think that the very thought of "media agnostic" will be a challenge
to most users ("this red thingy on the upper right").

Nevertheless, I'm interested in ideas/papers/thoughts on it,

Cheers
-- 
t

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 195 bytes --]

Re: Where / when Emacs on Gitlab?

[Emanuel Berg]

tomas wrote:

> This is an interesting idea; in practice, it is more
> difficult than expected. I've observed that several times:
> the "medium" (presentation, whatever) does influence
> communication style and patterns, and you "feel" bumps at
> medium boundaries.

It also has pitfalls, e.g. everyone spends time polishing
their own workflow clients, and the communication between
them, instead of doing actual work on the project.

No, if one just cares about everyone being the most productive
as they can possible can, I think huge modern GUI systems with
little buttons for everything is preferable to people
discussing everything like we do with text and e-mails.
So instead of saying, "thank you, that worked" on just pushes
a button to indicate problem solved - much like the SX sites
has been operating a long time by now BTW.

One would then go on to integrate everything even more and
eliminate ever single bottleneck.

However it will be the corporate streamlined conveyor belt way
of doing things, with no room for anything else. It will just
be about productivity, the production of code as good and as
fast as possible and that is it. And soon AI will enter those
systems as well.

But it still possible for a project like Emacs to continue
using git and mailing lists the way it is done today even in
the near future, since that is something that generally
appeals to people that are typically appealed by Emacs.
Even in the distant future, there will be people appealed by
that but yes, I think they will be fewer and fewer.

-- 
underground experts united
https://dataswamp.org/~incal

Re: Where / when Emacs on Gitlab?

[Psionic K]

[-- Attachment #1: Type: text/plain, Size: 1407 bytes --]

> You have. You just have to convince people that "turning the tide" is
> a good idea.

> Currently you aren't doing a good job at this, as far as I am concerned.
> Possibly others feel similarly.

In the interest of us all spending our time well, can other people  who
feel this way please filter my address?  I don't have the benefit of a long
history of well-known incompatible relationships that enable us to live
independently of one another in this vibrant pond of ideas yet.

I did find Eli's reply helpful to begin catching up on others' inputs.
Most of the others, not so much.

Thanks.

On Fri, Jan 12, 2024 at 2:01 PM <tomas@tuxteam.de> wrote:

> On Fri, Jan 12, 2024 at 07:37:25AM +0900, Psionic K wrote:
> > > where we make forward progress
> >
> > So who here has the game plan to turn the tide?
>
> You have. You just have to convince people that "turning the tide" is
> a good idea.
>
> Currently you aren't doing a good job at this, as far as I am concerned.
> Possibly others feel similarly.
>
> In other words: you seem to be convinced that Yor Way is the Right Way.
> Nothing wrong with that. But you don't seem willing to listen to others
> why they think Their Way seems the Right Way for them.
>
> That may just be my impression, and I'm willing to learn.
>
> Cheers
> --
> t
>


-- 

남백호
대표 겸 공동 창업자
포지트론

[-- Attachment #2: Type: text/html, Size: 2335 bytes --]