From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Eli Zaretskii Newsgroups: gmane.emacs.devel Subject: Re: Gitlab Migration Date: Fri, 27 Aug 2021 08:51:06 +0300 Message-ID: <837dg7saet.fsf@gnu.org> References: <87h7fcnmq0.fsf@posteo.net> <28953ac9-60e5-7583-6297-750c04ca3748@gmail.com> <83fsuwrps6.fsf@gnu.org> <767b2e84-be1b-de7a-40d0-4e1432fcce35@gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="18078"; mail-complaints-to="usenet@ciao.gmane.io" Cc: emacs-devel@gnu.org To: =?utf-8?Q?Cl=C3=A9ment?= Pit-Claudel Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Fri Aug 27 07:52:53 2021 Return-path: Envelope-to: ged-emacs-devel@m.gmane-mx.org Original-Received: from lists.gnu.org ([209.51.188.17]) by ciao.gmane.io with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1mJUnM-0004V7-WF for ged-emacs-devel@m.gmane-mx.org; Fri, 27 Aug 2021 07:52:53 +0200 Original-Received: from localhost ([::1]:41838 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1mJUnL-0006sS-6g for ged-emacs-devel@m.gmane-mx.org; Fri, 27 Aug 2021 01:52:51 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:39284) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1mJUlx-0005z6-RP for emacs-devel@gnu.org; Fri, 27 Aug 2021 01:51:27 -0400 Original-Received: from fencepost.gnu.org ([2001:470:142:3::e]:39722) by eggs.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1mJUlx-0007rT-H4; Fri, 27 Aug 2021 01:51:25 -0400 Original-Received: from 84.94.185.95.cable.012.net.il ([84.94.185.95]:2833 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1mJUlw-0004o3-VE; Fri, 27 Aug 2021 01:51:25 -0400 In-Reply-To: <767b2e84-be1b-de7a-40d0-4e1432fcce35@gmail.com> (message from =?utf-8?Q?Cl=C3=A9ment?= Pit-Claudel on Thu, 26 Aug 2021 16:09:32 -0400) X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.23 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-mx.org@gnu.org Original-Sender: "Emacs-devel" Xref: news.gmane.io gmane.emacs.devel:273115 Archived-At: > Cc: emacs-devel@gnu.org > From: Clément Pit-Claudel > Date: Thu, 26 Aug 2021 16:09:32 -0400 > > On 8/26/21 3:04 PM, Eli Zaretskii wrote: > > It's actually the other way around, at least in some cases. With > > patches that are emailed to me, I can fix some simple issues, such as > > commit log messages or simple typos, myself, before applying. With > > merging via Web UI, I need to push another commit, which is a waste, > > and also breaks what should have been a single commit into several > > ones. So with Web UI, I expect _more_ requests to contributors to get > > their act together, where automated fixups are impossible, because > > there's little I can do myself. > > Oh, that's not how it typically works in the project that I contribute to (and that I maintain): the maintainer often makes small fixes before merging, amends the relevant commits with those changes, and then merge using "git merge". Did I misunderstand? AFAIK, merging a PM is usually a UI action. But if it is done manually like you describe, then there's no difference, and no advantage to either method. > >> - Responding to old bugs is easier. With a mailing list, it's no necessarily clear what the process is. Should I send a new message to the bug address? Or does it need the right response headers? In that case should I download the mbox first and import it into my email client? > > > > I think you see problems where there are none. If you have an email > > message that belongs to a bug, reply to it; otherwise simply write to > > the bug address. admin/notes/bugtracker explains this within its > > first dozen of lines. > > This is in line with what I wrote above: there is a process that is specific to Emacs, and it requires reading a document that is specific to Emacs to get it right (and you have to find that document). I've yet to see a serious project of reasonably large size and age that didn't have such a document. Coding conventions and patch submission conventions vary among projects and change with time, and keeping them unwritten is not a good idea. > >> I'm sure there are many other pros and cons, but email isn't necessarily particularly easy when you want to do more than send messages. > > > > I realize that some people who want to contribute don't like emacs or > > are intimidated by it. > > I would be surprised if anyone who wants to contribute patches to Emacs doesn't like Emacs. Maybe I'm misunderstanding what you're saying. I meant email. Sometimes my fingers think they know better what I mean. > > That's an important reason to provide the UI > > to which they are more accustomed. But let's not exaggerate the > > advantages of these platforms for the Emacs developers: though some > > advantages exist, they are not that significant, at least IMO, and > > there are disadvantages (described in the GitLab issue). > > And yet few of the packages hosted on MELPA — even those that don't get many external contributions — are developed using mailing lists (not sure about GNU ELPA). That might suggest that even Emacs veterans see value in these online systems (?) I didn't say there was no value, I said let's not exaggerate the advantages. And there's a difference between maintaining a project with perhaps several Ks or several dozen Ks of lines, and maintaining Emacs. With Emacs we need all the power of the development environment conveniently integrated in the same place; we need Emacs itself.