From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED.blaine.gmane.org!not-for-mail From: Tadeus Prastowo Newsgroups: gmane.emacs.devel Subject: Re: [RFE] Migration to gitlab Date: Thu, 21 Mar 2019 10:02:29 +0100 Message-ID: References: <1552789070.5272.1@yandex.ru> <1552791707.5272.2@yandex.ru> <1552793646.5272.3@yandex.ru> <1552821396.21432.0@yandex.ru> <83imwhwf4x.fsf@gnu.org> <837ecvux2q.fsf@gnu.org> <9c7cf558-a2d3-951e-d6e1-31b3ad5900cf@yandex.ru> <1553064994.13109.0@yandex.ru> <831s32t3fn.fsf@gnu.org> Mime-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Injection-Info: blaine.gmane.org; posting-host="blaine.gmane.org:195.159.176.226"; logging-data="230980"; mail-complaints-to="usenet@blaine.gmane.org" Cc: Eli Zaretskii , Tim Cross , Dmitry Gutov , Konstantin Kharlamov , Emacs developers To: Philippe Vaucher Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Thu Mar 21 10:02:52 2019 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([209.51.188.17]) by blaine.gmane.org with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:256) (Exim 4.89) (envelope-from ) id 1h6tb9-000xwN-NO for ged-emacs-devel@m.gmane.org; Thu, 21 Mar 2019 10:02:51 +0100 Original-Received: from localhost ([127.0.0.1]:33519 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1h6tb8-0003Uv-OW for ged-emacs-devel@m.gmane.org; Thu, 21 Mar 2019 05:02:50 -0400 Original-Received: from eggs.gnu.org ([209.51.188.92]:55068) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1h6tb1-0003UX-IF for emacs-devel@gnu.org; Thu, 21 Mar 2019 05:02:44 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1h6tb0-0005im-4n for emacs-devel@gnu.org; Thu, 21 Mar 2019 05:02:43 -0400 Original-Received: from mail-io1-xd2e.google.com ([2607:f8b0:4864:20::d2e]:43612) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1h6taz-0005hk-JS for emacs-devel@gnu.org; Thu, 21 Mar 2019 05:02:42 -0400 Original-Received: by mail-io1-xd2e.google.com with SMTP id x3so4574630iol.10 for ; Thu, 21 Mar 2019 02:02:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=unitn.it; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=Qanq9ZVYX4moNbQriu1gRWIS2mYn/GDGKhFqFc7KXec=; b=a1hf7Cv0cPTQMNoeW0SPiga24G5sPr8EJvOe6Am4TRLw0nzF7JSS/B5IWdLLiNJEy1 KY7HW4nIRJ9/hXuwYP+nCwrRr12hzwhFK6aLUh2m2aDuOpbZAH184TvAVlDbF0jRWC1+ DhrR5gf7N4BDuj3Q18Z+fLcgjVfpqodDkFxAU= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=Qanq9ZVYX4moNbQriu1gRWIS2mYn/GDGKhFqFc7KXec=; b=lj3FGdWk+FyuhPGp+qsPhZGIAZb4GRHyWkW5G2DxP5QURlXRkhibKZUnfuvPg0EzxM Y03K8K28NHA+01XuIjPlStNtGabAjS16d5daumOQBaXX/y5CdL65BSZN2wbVN+affecP Qtmo8rEoasQtKmHZAm4v/+OVEE9KMxf8m58+uUiE8DRx5ALXyDnH6ngfrIPCT90MUtW9 hur+VZdSg0nm5rPk8YuLdSfievG2D+g6i4LSyAfvXPbSpKWy4XLfj8MHC1BXdOAarimv yWSzzx7+cWRDUPPtOd0ptO8xFNA8tzke6R2Utyruwlhue9VtHho+tE1AVbSY61IGhMLP B1wA== X-Gm-Message-State: APjAAAUT4fBWiz+KcmQT+eaNcSgkz/jwqkmUOk104HsVURaI4UeymUtd 80CY14Fqx6Z2Ox/ICLcQYw5rwkL69N9aj52t0mAa X-Google-Smtp-Source: APXvYqwMg8iu6ONd1qh1tQqvUhzo6b4eNtpcUdzxUhTs9U9k/xMASvCr4wgbnRAtlSYRl5gMmD1FNQPP4k7fDfn5FUY= X-Received: by 2002:a5e:c110:: with SMTP id v16mr1854546iol.289.1553158960405; Thu, 21 Mar 2019 02:02:40 -0700 (PDT) In-Reply-To: X-detected-operating-system: by eggs.gnu.org: Genre and OS details not recognized. X-Received-From: 2607:f8b0:4864:20::d2e X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.21 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Original-Sender: "Emacs-devel" Xref: news.gmane.org gmane.emacs.devel:234454 Archived-At: On Thu, Mar 21, 2019 at 9:44 AM Philippe Vaucher wrote: >> >> 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. > > > It was a nice effort on your part but I feel those changes are unlikely to really bring a lot of newcomers. Github/Gitlab users want to have things like this: > > https://github.com/bbatsov/projectile/pull/1386 > https://github.com/moby/moby/pull/38823 > https://github.com/Silex/docker-emacs/pull/24 > > Things to watch for: > > Contributions templates (checkboxes, descriptions) > Tags/Labels for easier filtering of issues that affect X or Y > Inline code review, with code highlighting, which you can then "resolve" and push new versions that are hidden by default so you only see the latest relevant > CI bots that builds & tests your change, report breakage (travis-ci) or display code coverage changes (codedov) > Tabs at the top for status of the PR, commits, files changed, checks done > Quickly view modified file history / filtering which files to display > Cross referencing of issues > > I could go on & on about things that the tool does for you instead of you having to grep, find-name-dired, find-file, magit-log-buffer-file etc. > > With the mailing list the number of things you have to keep in your head or do manually is huge compared to when using these tools. > > Now, I understand that you probably see all this as more work, without any guarantee that the number of contributors will increase... so you are right to ask for people wanting these changes to become more involved. > > I hope I helped a bit in painting a better picture of why these tools feel "essential" to us, but they are also tied to a more general workflow/mindset and that is probably the crux of the issue. May I know why instead of an RFE for a migration to have those features, haven't you already set up one much like what a GNU/Linux distro usually sets up to collect things pending upstream intake? Additionally, if some packages are better maintained external to the core Emacs, why not let them be so rather than trying to bringing them contributing directly to the core? > Kind regards, > Philippe -- Best regards, Tadeus