[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [RFE] Migration to gitlab

From: Dmitry Gutov
Subject: Re: [RFE] Migration to gitlab
Date: Thu, 25 Apr 2019 04:06:28 +0300
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.6.1

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

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.

reply via email to

[Prev in Thread] Current Thread [Next in Thread]