Re: [RFE] Migration to gitlab

[Dmitry Gutov]

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

Sure.

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

Let's!

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