[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 13:35:01 +0300
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.6.1

On 25.04.2019 12:22, Eli Zaretskii wrote:

Some features will stagnate, some we'll have to cut out in the long run.

This loses context and perspective.  The context was patch review, not
development.  If someone submits a patch that touches on one of those
areas, do you propose to tell them to drop the patch because no one
really understands its implications?  I doubt that.  The person who
submits the patch might just be that future expert, and we don't want
to scare them away.  So we must review the patch as best as we can,
and that takes an inordinate amount of time and effort.

True. In the past, I have reviewed patches in the areas I knew little about. The process mostly consists of asking lots of silly questions, and if the reporter is patient enough, that can get the patch approved, and the reporter can indeed become someone who takes care of a particular feature.

That's the optimistic side of the coin.

My authority, whether real or imaginary, aside, it's not just me and
my habits.  There are others involved, and by looking at how they
format their messages and how they find related issues, I can guess
that they, too, have efficient workflows in place that will have to be


I hope my other message could be a good starting point for figuring
out what exactly will constitute a smooth transition, and what are the
necessary conditions for such a transition.

That is exactly the change in the tone of this discussion I've been hoping to enact.

When close to 80% of bugs and patches posted to the issue tracker will
wait less than a week before they get responded in some meaningful way
(excluding a mere acknowledge of seeing the report), and not
necessarily by yours truly.  Sounds good?

You mean only after that we can consider changing workflows? A lot of big, popular projects (and especially those) have huge numbers of untriaged bugs because it's simply a function of a project's popularity.

I honestly do not know what improvement is possible with our current resources. The only way I know of improving the situation is to try, and try, to attract new contributors. And that can happen if we use newer tools which increase visibility into our development process, and makes it more approachable for a new contributor.

When somebody offers to take over as the maintainer? (I'm
hoping for a "no" here).

Feel free to do that as well, it will make me a happier person.

Much as a like my opinion being heeded, and even the lack of expertise aside, it's simply not possible for me to rival the amount of effort you are putting into the project. Not in the next several years anyway.

So I'm really thankful you are doing that, even if I don't agree with some decisions. Hope you know that.

Not every unfinished project is a loss. Someone else can come along
and continue it.

Examples from Emacs?  I'm not aware of any, but maybe I missed some.

Well, not sure what examples you're expecting, but I've picked up some features that others started work on (ruby-mode, xref, project.el). And the work on the NS port, for instance, has moved between maintainers several times on my memory.

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

I'm not sure we understand the practical aspects and consequences of
this.  At least I don't.  Let's see what comes out of the list of
issues I posted in my other message.  I'm especially interested in
hearing opinions of other active developers.


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.

I certainly hope so.  But still, IMO we should discuss steps we intend
to be able to take soon, not something for the distant future.

If you look back at the list I wrote, only the step of Migration off Debbugs (the last one) should be considered distant.

reply via email to

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