Re: [RFE] Migration to gitlab

[Eli Zaretskii <eliz@gnu.org>]

> Cc: theophilusx@gmail.com, emacs-devel@gnu.org
> From: Dmitry Gutov <dgutov@yandex.ru>
> Date: Sun, 21 Apr 2019 02:26:44 +0300
> 
> On 20.03.2019 9:23, Eli Zaretskii wrote:
> 
> > Unlike in many other projects, I consider the situation with patch
> > review, and more generally with the number of domain experts we have
> > on board in Emacs, a disaster.
> 
> Personally, I expect a lot more packages to be retired or moved from the 
> core into ELPA in the future, perhaps tagged as unmaintained.

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.

> > Recent years saw a lot of change in Emacs infrastructure and
> > maintenance procedures -- we moved from CVS to Bazaar to Git, we
> > removed some of the obstacles to newcomers, such as ChangeLog files,
> > we codified the most important parts of the procedures in CONTRIBUTE,
> > etc.  This indeed brought welcome new contributors, but the growth is
> > very slow, and the impact on the patch review process and on the
> > number of people who are proficient in core parts of the internals is
> > still very much minor and inadequate, IMO.  E.g., the backlog in patch
> > review and in solving reported issues is still unsatisfactory.
> 
> You're mentioning some changes, but the patch review process itself has 
> changed very little in the last... how many years?

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.

> And speaking of backlogs in patch/bug review, I'm personally unsure how 
> many bug reports and patches are out there unattended that relate to the 
> files that I maintain. The tagging system is barely adequate, and every 
> time I use Debbugs I have to rediscover it (as well as search, with its 
> bugs) all over again.

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

> > People who want those infrastructure changes should become more
> > involved, so that we reach the critical mass sooner.
> 
> People work on what they want to work on. Even if they somehow feel more 
> encouraged to contribute, not many people are going to work on arbitrary 
> pieces of Emacs, or review random patches.
> 
> 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?

> I think it will be helpful to outline and agree on some rough migration 
> plan which can be enacted. With steps and conditions for the "people who 
> want" to know what to work on.

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.