Re: [RFE] Migration to gitlab

[Dmitry Gutov <dgutov@yandex.ru>]

On 21.04.2019 8:43, Eli Zaretskii wrote:

> Large parts of, if not the majority, of the areas where we don't have
> active experts are not in packages that can be moved to ELPA.  A lot
> of that is in C (and most cannot be recoded in Lisp, even if
> performance allowed that) or in core packages central to Emacs.

Some features will stagnate, some we'll have to cut out in the long run. 
That is probably inevitable as well. The most essential ones will find 
their contributors.

> The patch review process should reflect the preferences of the bulk of
> those who do the review.  It is IMO wrong and even unfair to force
> significant changes in the procedures due to requests from people who
> aren't involved enough, because (a) they don't have the right
> perspective, and (b) because they won't be there to sustain the
> consequences.

Like I said, you have the authority to strongly request the transition 
to be as smooth as possible, so that the important aspects of the 
existing workflow are retained. It's not like you actually love every 
minor detail of how we do review these days that you couldn't bear to 
part even with one of them, is it?

> Are you using the debbugs package from ELPA?  If not, I suggest giving
> it a try.

I've been around for a while, of course I have it installed. Since I 
don't have SMTP configured in Emacs anymore, though, it's become less 
useful. It cannot paper over all deficiencies of the underlying platform 
either. But it's good that we have it, of course.

>> On the other hand, discussing the possibility of a migration and
>> agreeing on some specific goals can encourage people to get more
>> familiar with Emacs development workflow, even as they try to improve
>> it. Which can increase the pool of contributors as well, by itself.
> 
> It is a bootstrap-like process, sure.  My point was that we cannot
> speed it up beyond some limit, determined by balanced progress in
> these two prongs.  I guess you are agreeing with that?

Not really. I don't really understand the idea of "reaching critical 
mass" in this discussion. When would you consider the "mass" to be 
"critical"? When somebody offers to take over as the maintainer? (I'm 
hoping for a "no" here).

I'm saying it's better to encourage the possible contributors to bring 
their own enthusiasm and expertise, even for a while. Not every 
unfinished project is a loss. Someone else can come along and continue 
it. In this case, I would expect a very wide range of people to want to 
see Emacs migrate to GitLab (or one of the competing platforms maybe; 
but mostly GitLab).

And that doesn't mean you'd have to settle for a completely alien new 
workflow that you would be uncomfortable with. Even when we discussed 
bringing over GitLab as a code review platform the previous time, we 
talked about existing Emacs packages that provide access to the features 
of the platform, as well as writing our own if the existing ones turn 
out to be inadequate. That's still feasible.

> We could discuss that, but it's IME futile to talk about the parts
> that are too far in the future, because when we get to that, both the
> people involved and the technologies will change.  So talking about
> those distant parts just facilitates long discussions with no
> conclusions.  We have past discussions to serve as examples.

The past discussion on a similar subject was relatively different, in 
that none of the people involved had both the interest, enough free time 
and expertise to see the project through.

This time we already have a GitLab installation, as well as a few people 
willing to work on integrating it with the larger infrastructure and our 
workflow requirements. An employee of GitLab among them, which likely 
means easier access to upstreaming certain features we'd need to make 
this happen. It's a pretty sweet situation for us not to take an 
advantage of, in my opinion.