[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: Sun, 21 Apr 2019 02:26:44 +0300
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.6.1

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

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.

reply via email to

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