Re: [RFE] Migration to gitlab

[Dmitry Gutov <dgutov@yandex.ru>]

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. If we 
don't manage to review all patches, it means Emacs has grown larger than 
the core team can deal with. Tools can alleviate that to some extent (to 
help people stretch wider), but not infinitely.

But that's neither here nor there.

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

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.

> So personally, I don't think we are ready for another significant
> change in our procedures and infrastructure, not before we give some
> more time to these slow tendencies to develop into significant
> qualitative changes.  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.

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.

For instance, here are the steps that I personally could be happy with:

- We already have EMBA and some people proficient with keeping it 
running. We've even pushed a feature upstream, that one of our long-time 
developers requested. Let's mark this one "done".

- Figure out the timeout problems and make the builds more stable.

- Support "merge requests" submitted to EMBA as an official way to 
submit patches for Emacs, document it in Contribute, etc. Some core 
developments will probably say that they would prefer to conduct reviews 
by email anyway, or via some Emacs-based UI instead of the web UI. 
Collect the requirements, agree on necessary features, test them out 
until people are reasonably happy, adopt. Some integration with Debbugs 
and/or Savannah will also be required, I think.

- Migrate from Debbugs to GitLab Issues. The holy grail for me 
personally. But it'll still require a fair amount of work, similar to 
the previous item (but more). Probably far off to the future. We'll get 
there when we get there.