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: contributing to Emacs Date: Sun, 18 Jun 2023 13:59:41 +0300 Message-ID: <83jzw1nihu.fsf@gnu.org> References: <83v8fnslfz.fsf@gnu.org> <87v8fnh1h2.fsf@web.de> <83mt0zs9rc.fsf@gnu.org> <0a968a4e1b267c0f15dd237e6ea12a709fc06d5e.camel@yandex.ru> <838rcisj7o.fsf@gnu.org> <6537fa5fa5c1fe8437ed99ee0988e35895f5a54b.camel@yandex.ru> <8423a35750d8d8e0437c7708f6b4d0bbdfdb7fe0.camel@yandex.ru> <87o7ldf7ky.fsf@web.de> <8cc19084ab18d0adb0f2cee4af14aa1b1d914a83.camel@yandex.ru> <83sfapnl57.fsf@gnu.org> <83pm5tnk78.fsf@gnu.org> <73cbe80096cd97728fcdaccf9f9badeea606570b.camel@yandex.ru> <83mt0xnjl6.fsf@gnu.org> <6e122f89169630efcde23f23f8b799924c2eb3c8.camel@yandex.ru> Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="36699"; mail-complaints-to="usenet@ciao.gmane.io" Cc: arne_bab@web.de, ams@gnu.org, luangruo@yahoo.com, emacs-devel@gnu.org To: Konstantin Kharlamov Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Sun Jun 18 12:59:58 2023 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 1qAq8T-0009M0-PB for ged-emacs-devel@m.gmane-mx.org; Sun, 18 Jun 2023 12:59:57 +0200 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1qAq8I-00042K-3U; Sun, 18 Jun 2023 06:59:46 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1qAq8G-00042C-Sl for emacs-devel@gnu.org; Sun, 18 Jun 2023 06:59:44 -0400 Original-Received: from fencepost.gnu.org ([2001:470:142:3::e]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1qAq8G-0002jo-Jc; Sun, 18 Jun 2023 06:59:44 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org; s=fencepost-gnu-org; h=References:Subject:In-Reply-To:To:From:Date: mime-version; bh=7To8vWZ9XEIcV1WppggZUHttEi2PYkVfgAuox28zcmQ=; b=fMcAsCUpl6yG thrW398kgQUWMK8N6wTCrtW34EMwk8i8wdS+rI176ba1MTSXuzU+ApERLvPgo9FMHbyOhMHV6Ae6R RxLdd0iXqRuOsC2/q43KM2rGVl7GUYye5Ea9rGdJu9/JHbEOUIn8mMoCXd39Kbjqh9a46EgK8nzrD orO5kuixCWAdgWF7h/LMHDGg0yCXhrEfAWhNGYYYbJLBuP3hY2Gn0o5bsMXJumO6DsOC/LZnftdWj wNkWTP5XNCqqCGvRbvQYtpFIDvVQkm+kdA51PrqMTNJCbv3pTjxpKZzs2H4WXTBP+glh94vkaGuob vNGLP3nmdM9NkxY/E/8xRg==; Original-Received: from [87.69.77.57] (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 1qAq8C-0003XV-Dg; Sun, 18 Jun 2023 06:59:44 -0400 In-Reply-To: <6e122f89169630efcde23f23f8b799924c2eb3c8.camel@yandex.ru> (message from Konstantin Kharlamov on Sun, 18 Jun 2023 13:44:59 +0300) X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.29 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-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Xref: news.gmane.io gmane.emacs.devel:306963 Archived-At: > From: Konstantin Kharlamov > Cc: arne_bab@web.de, ams@gnu.org, luangruo@yahoo.com, emacs-devel@gnu.org > Date: Sun, 18 Jun 2023 13:44:59 +0300 > > > > Well, you see, the "sending patches" section has no mention that a series is > > > unwelcome. > > > > They aren't "unwelcome", please don't misquote what I write. > > Hmm, I feel like there's some confusion. You said that a single patch is > preferred over a series, right? "Preferred", yes. That's a far cry from "unwelcoming" patch series. > And then you said it is the reason we don't need > to do anything about the problem with sending a series to bug-gnu-emacs@gnu.org > > But the problem exists, so I'm suggesting that if you don't want it to be fixed, > perhaps we should put some docs about that. The problem, such as it exists, is mine and of other people who review patches. It isn't the problem of those who _submit_ patches. Therefore, there is no need to make the instructions longer on behalf of what isn't the contributor's problem. In the rare case that a first-time contributor submits a whole series of patches, he or she will be told that we prefer a single patch. That's all, end of story. Most contributors will never even bump into this, because it is rare for a casual contributor to submit such complex patches. > > It sounds like you have just asked us to make that section larger, is > > that right? > > Yes, but it can still be easier to read than it is now. A few mails above I put > a suggestion to separate "how to send a patch" and "what changes should it > contain" to different chapters (ideally contained on a single page though). I > can rewrite the section and send it here if there's any interest. I didn't get > any reply if such change is welcome or not, but I imagine it would simplify the > page a lot. So when we write text that explains our conventions, it's "too long", but when you suggest to add more stuff, that makes it "easier to read"? Doesn't sound consistent to me. We only describe in the instructions stuff that is important enough, and try to keep the details to the absolute minimum that is necessary. You may think that other aspects are more important, but, with all due respect, it isn't your call.