Re: [RFE] Migration to gitlab

[Eli Zaretskii]

> Cc: address@hidden, address@hidden, address@hidden
> From: Dmitry Gutov <address@hidden>
> Date: Thu, 25 Apr 2019 04:06:28 +0300
> 
> 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. 

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.

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

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.

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.

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

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

> I'm saying it's better to encourage the possible contributors to bring 
> their own enthusiasm and expertise, even for a while.

Better than what?

And anyway, the issue at hand is not a general one: we all agree that
contributors should be encouraged.  The issue is what to do in
practice to encourage them, and the specific part of that discussed
here is significant changes in the workflow.  It is unclear to me what
practical criteria you are proposing for this trade-off.  It's not an
easy decision, and just the desire to encourage is not enough.

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

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