emacs-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [RFE] Migration to gitlab


From: Eli Zaretskii
Subject: Re: [RFE] Migration to gitlab
Date: Wed, 20 Mar 2019 09:23:08 +0200

> Date: Wed, 20 Mar 2019 09:56:34 +0300
> From: Konstantin Kharlamov <address@hidden>
> Cc: address@hidden, address@hidden, address@hidden
> 
> > And my point is that we are once again arguing about very much minor
> > issues, without doing anything about, nor even touching, the more
> > important ones.  E.g., I asked up-thread whether you knew how many
> > people review patches for Emacs; did you follow up on that?  This is
> > IMO much more important for Emacs development and eventually for its
> > future than whether our CI will be from Gitlab or from somewhere else,
> > definitely more important than the commit hooks issue.
> 
> I didn't reply this point because I don't know what to add. I get that 
> there's not much people doing review, but it's a pain present in most 
> projects. Even some Linux kernel subsystems often lacks proper review, 
> I regularly see articles about that on LWN popping up — and the 
> kernel has thousands of contributors, most of them are paid ones.

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.

> Undoubtedly this is important for Emacs future, but where do you think 
> new people can appear from?

Yes, this is a bootstrap-type of problem, and such problems can never
be solved by taking care only of some of the aspects in isolation.
Instead, each advance in some aspect must be followed by corresponding
advances in the other aspects, before the next step forward is taken.

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.

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.



reply via email to

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