Re: Gitlab Migration

["João Távora" <joaotavora@gmail.com>]

Dmitry Gutov <dgutov@yandex.ru> writes:

> A move that will at least bring us a functioning bug tracker is a plus
> in my book.

We are in agreement. 

> That's an odd statement. First of all, why would quality of code
> change? Whatever linters you institute to run on a CI, can run locally
> as well. Quality of discussions is also on you.
>
> gitlab/github/gogs/etc give you tools to make code reviews easier, and
> an opportunity to attract many new contributors, but then it's on you
> to make them feel welcome, so that they stay around.

I'm telling you that code reviews and the ensuing code quality didn't
become specially easier when comparing GH/GL to non-GH/GL.  There were
code reviews with and without these platforms and there were newcomers
with and without them.  There was no perceptual (from my POV) difference
in discussion or proficiency.  This was presented as anecdoctal evidence
and my subjective judgement, of course.  If it sounds "odd" to you, it's
totally understandable.

> Better "quality of code" can result from attracting strong new
> contributors, and looking at how, for example, bug#47711 ended up (a
> smart, prolific developer who has authored a number of popular
> third-party packages in the same area has now sworn off contributing
> to Emacs),

Shooting from the hip, heh :-) Well, if you are so troubled by bug#47711
I encourage you to reply there.  Not only am I waiting your promised
feedback but also it's got absolutely nothing do to with this
thread. (IIUC the participants in that bug are familiar and proficient
with Emacs's workflows and practices).

Bugs don't have to "end up" anywhere without discussion, opposition or
study of alternatives: Daniel wants to deprecate a part of Emacs and
substitute it with a new one.  To my eyes, that's a good idea.  I merely
had time and means to demonstrate that his patch made Icomplete run
about 10% slower.  He later thanked me for spotting this regression.  I
also asked to split up the patch, which is very long and seemed to do
many things at once, so that I could more easily review it.  After
providing an alternative patch, I'm waiting from you and Daniel a
translucid demonstration of the somewhat callous claims leveled at it.
It's short and speeds up icomplete-mode and flex by about 30%, as
requested by none other than you.  Indeed, I have been waiting for these
things and other things for about 2 weeks, and haven't heard a peep.

> or the atmosphere around Eglot, I find it hard to trust your
> experience here.

Intrigued about the amospheric conditions around Eglot.  Should I bring
umbrella or sunscreen?

>> methods used in Emacs development may in fact be "aces up our
>> sleeve", not just a means to appease those that have been using them
>> for a number of years.
> Sure, let's keep the barriers to contribution, both formal and
> informal ones. That will serve us well.

I'll just make one last effort to explain my position here.  You may
legitimately think they e-mail, debbugs, non-modern websites etc are
barriers, that they are "bad" to newcomers.  That is true, and I agree
in part, but it is not the whole story.  Some of us are trying to tell
you that that manichaeism is an oversimplification: these things are
_also_ "good", they are points of interest and value to veterans and at
least a certain class of newcomers, perhaps the newcomers that Emacs is
interested in attracting.

It goes both ways, too: I was once a newcomer and the development
practices that I've learned (and still learn) here specifically over the
years have been very valuable in my programming career.  Just some
examples: the deft use of boring old email to structure programming
ideas is very very good here.  The much-ridiculed GNU-style ChangeLog
commit messages are a superb way to review one's own work before
presenting it.  And I don't miss emojis, thumbsup likes and animated
gifs a bit, have to say.

João