From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED.blaine.gmane.org!not-for-mail From: Philippe Vaucher Newsgroups: gmane.emacs.devel Subject: Re: [RFE] Migration to gitlab Date: Thu, 21 Mar 2019 18:54:32 +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: multipart/alternative; boundary="000000000000d2cfff05849e6fb6" Injection-Info: blaine.gmane.org; posting-host="blaine.gmane.org:195.159.176.226"; logging-data="183887"; mail-complaints-to="usenet@blaine.gmane.org" Cc: Eli Zaretskii , Tim Cross , Dmitry Gutov , Konstantin Kharlamov , Emacs developers To: Tadeus Prastowo Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Thu Mar 21 19:01:09 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 1h7204-000lgq-TF for ged-emacs-devel@m.gmane.org; Thu, 21 Mar 2019 19:01:09 +0100 Original-Received: from localhost ([127.0.0.1]:44151 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1h7203-0001aG-QZ for ged-emacs-devel@m.gmane.org; Thu, 21 Mar 2019 14:01:07 -0400 Original-Received: from eggs.gnu.org ([209.51.188.92]:36884) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1h71uH-0004bM-W3 for emacs-devel@gnu.org; Thu, 21 Mar 2019 13:55:12 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1h71uF-0000KE-Tg for emacs-devel@gnu.org; Thu, 21 Mar 2019 13:55:09 -0400 Original-Received: from mail-lj1-x22f.google.com ([2a00:1450:4864:20::22f]:44880) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1h71u8-0000D6-QM; Thu, 21 Mar 2019 13:55:01 -0400 Original-Received: by mail-lj1-x22f.google.com with SMTP id n18so6010639ljg.11; Thu, 21 Mar 2019 10:55:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=aP0pBqVSWzwsFL7bJ629/CkSsrEDoQJo5MurW00sHm4=; b=pPHHve0FPP90jUtcly2xR3UIiKDiYzq58AONqISikvyQJcB3qXDNhZM3Idq92QyXBl 26w5D/DugKJdGnrItJ1svRrpW9Xo5YLxyzbO6h9+YFZt1Z3RW673WKy3iwD6hKI8BKAf lDLxtjIGStH18P3QFIFw1SViYC9BesjIr2UkUoLVHCf7XIm6tUUU87x0Ias+F+45VwAL RPj5wVfHHegryoRf2AXaVBrnUZdkU4/gjYOWM143mPk8tAqbju7CJvsBjfP7xG+s3Y2a D4z4bjqXmPsgPIkDPhSeJVSAwFyOYAVdazTwpROIAvG45tiRY6SUrKBxEqaj8qj7fwvQ O/tw== 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=aP0pBqVSWzwsFL7bJ629/CkSsrEDoQJo5MurW00sHm4=; b=e3hcqkWKL3nVnxlg0L+VTLjyeE1FfYW0lYM5znA3DS3b6Z21ZS3zkUmZhj6pXPGYPH wQa+oObGI/YHXR2O63T7H8dHo7MEu+FEJRapGhmr1sxGG37O1iUYDeGiJUheDLjvTgrN ySezF1BjRmAf9reHDDkE4leWdUQrz3EmLaBH+4ysdvrQotkQI3/qvuzLmopra7IPsTwz XIammo2H0CBDmpJCtBCOyi6Fsk/+GM8Pxy97qYD7E4goxmJZRGynPPCnSCPiKqPRX8y1 94sDXwol3xUoQKnRrNdR/4jFbECUd0ujhfI2FJCsdvzfceLFH6TFlzvnF9Kc/reHVyKR BLXw== X-Gm-Message-State: APjAAAXgXyXq2eF6fb5XhHW5r5JBtP5CQXflkbLkCSmj9xP+FdIMZATq RfwVFLz8bb4k0T+weV3RZ984v7NWE47P7WCgnxw= X-Google-Smtp-Source: APXvYqxskthLrAkpPfN4kHKyM29PgdUfejKsYhgwMRwIM8ZSliEE2axo0SlRSif+8G0yP3rg+iLECT7ybUXsQJ/nLv0= X-Received: by 2002:a2e:380c:: with SMTP id f12mr2709787lja.116.1553190899337; Thu, 21 Mar 2019 10:54:59 -0700 (PDT) In-Reply-To: X-detected-operating-system: by eggs.gnu.org: Genre and OS details not recognized. X-Received-From: 2a00:1450:4864:20::22f 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:234474 Archived-At: --000000000000d2cfff05849e6fb6 Content-Type: text/plain; charset="UTF-8" > > >> 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? > > > > > > I'm sorry but I don't understand this question. We are talking about > adding a gitlab workflow to the existing mailing list workflow so that > gitlab/github users are happier and more prone to contributing. I don't > understand what you are asking about this topic. > > You gave the following links as examples that I suppose are intended > to strengthen your argument: > > https://github.com/bbatsov/projectile/pull/1386 > > https://github.com/moby/moby/pull/38823 > > https://github.com/Silex/docker-emacs/pull/24 > > AFAIK, those three links have nothing to do with the things that are > discussed in this mailing list, which mostly concerns the Emacs core. > Yes, they are examples about how things are done elsewhere, to illustrate how things could be if we added the gitlab workflow. I suspect that maybe many people here don't really realise what the gitlab workflow is or how it looks, so I wanted to show examples. The gitlab workflow that is proposed in this thread, however, is > concerned with the things that are discussed in this mailing list > (Emacs core). Hence, I expect that the links given as examples would > be about pull requests for things related to Emacs core that had not > been taken upstream by those in this mailing list. > Well I cannot show examples of something that does not exist, you cannot do github/gitlab pull requests to the emacs core, you can only go through the mailing list (or other non-pull-request means). > >> 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? > > > > > > Again I don't understand what external packages have to do with the > topic. We are not talking about including external packages to core Emacs. > > No, we are not talking about including external packages. Hence, do > you have examples that support your argument that there are people out > there who would contribute to the Emacs core provided that the Emacs > core development adopts the gitlab model? Again I cannot have examples of something that does not exist. As I said earlier, it's possible that adding the gitlab workflow would yield 0 additional contributors, the only way to know for sure would be to try it. Personnally I believe that at least for "typo fixes" and tiny changes you'd get more contributions, because proposing a change on the gitlab model is trivial (browse to the correct file, click "edit", edit the file in your browser, press "propose changes", done). Anway, what I am sure of is that if the gitlab workflow was added there would be contributors on this ML (including me) that would use it instead of the mailing list workflow. If the Emacs maintainers decide not to add the gitlab workflow it's fine by me, I'm not on a quest to convince everyone. I think you should, but I understand if you don't. Kind regards, Philippe --000000000000d2cfff05849e6fb6 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
>> May I know why instead of an RFE for a migratio= n 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?<= br> >
>
> I'm sorry but I don't understand this question. We are talking= about adding a gitlab workflow to the existing mailing list workflow so th= at gitlab/github users are happier and more prone to contributing. I don= 9;t understand what you are asking about this topic.

You gave the following links as examples that I suppose are intended
to strengthen your argument:
> https://github.com/bbatsov/projectile/pull/1386<= /a>
> https://github.com/moby/moby/pull/38823
> https://github.com/Silex/docker-emacs/pull/24<= br>
AFAIK, those three links have nothing to do with the things that are
discussed in this mailing list, which mostly concerns the Emacs core.

Yes, they are examples about how things are = done elsewhere, to illustrate how things could be if we added the gitlab wo= rkflow. I suspect that maybe many people here don't really realise what= the gitlab workflow is or how it looks, so I wanted to show examples.


The gitlab workflow that is proposed in this thread, however, is
concerned with the things that are discussed in this mailing list
(Emacs core).=C2=A0 Hence, I expect that the links given as examples would<= br> be about pull requests for things related to Emacs core that had not
been taken upstream by those in this mailing list.
Well I cannot show examples of something that does not exist, y= ou cannot do github/gitlab pull requests to the emacs core, you can only go= through the mailing list (or other non-pull-request means).

=
=C2=A0
&g= t;> 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?
>
>
> Again I don't understand what external packages have to do with th= e topic. We are not talking about including external packages to core Emacs= .

No, we are not talking about including external packages.=C2=A0 Hence, do you have examples that support your argument that there are people out
there who would contribute to the Emacs core provided that the Emacs
core development adopts the gitlab model?

A= gain I cannot have examples of something that does not exist.
As I said earlier, it's possible that adding the gitlab workflow would= yield 0 additional contributors, the only way to know for sure would be to= try it. Personnally I believe that at least for "typo fixes" and= tiny changes you'd get more contributions, because proposing a change = on the gitlab model is trivial (browse to the correct file, click "edi= t", edit the file in your browser, press "propose changes", = done).

Anway, what I am sure of is that if the git= lab workflow was added there would be contributors on this ML (including me= ) that would use it instead of the mailing list workflow.

If the Emacs maintainers decide not to add the gitlab workflow it&#= 39;s fine by me, I'm not on a quest to convince everyone. I think you s= hould, but I understand if you don't.

Kind reg= ards,
Philippe


--000000000000d2cfff05849e6fb6--