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.