From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: "Drew DeVault" Newsgroups: gmane.emacs.devel Subject: Re: Gitlab Migration Date: Sun, 29 Aug 2021 08:55:41 +0200 Message-ID: References: <8d0be260-7b15-0b48-42e5-e5a4cc203e54@yandex.ru> Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="30921"; mail-complaints-to="usenet@ciao.gmane.io" Cc: theo@thornhill.no, Philip Kaludercic , danflscr@gmail.com, monnier@iro.umontreal.ca, emacs-devel@gnu.org To: "Dmitry Gutov" , "Lars Ingebrigtsen" , "Eli Zaretskii" Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Sun Aug 29 08:56:36 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 1mKEk5-0007jD-MG for ged-emacs-devel@m.gmane-mx.org; Sun, 29 Aug 2021 08:56:34 +0200 Original-Received: from localhost ([::1]:39116 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1mKEk3-0004bX-RI for ged-emacs-devel@m.gmane-mx.org; Sun, 29 Aug 2021 02:56:31 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:46758) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1mKEjO-0003vF-Rv for emacs-devel@gnu.org; Sun, 29 Aug 2021 02:55:50 -0400 Original-Received: from out1.migadu.com ([91.121.223.63]:27016) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1mKEjM-0003UI-VZ; Sun, 29 Aug 2021 02:55:50 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cmpwn.com; s=key1; t=1630220146; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=lu+tS+M/S30sD+m0tX5+cLXCezqywoN13CljXXd9g0E=; b=MYhX0Ntr2gKKJUefp5rXWmNDMhmqG3K45YpUnDTSBQdufS5L0NCLx2UPX5vZvQg6phVlO0 g3mwZkDvPEB6knqrMea0t4m7/n9UfBPsK1CzAc7+6oUhMaFxuEg344T2xUDbeNPl3aEWCX 86cveutUnScLURlMOxpqzaPkZXMT2tJNsxr1NyBggaZcmBn4iSiNiNmmMziD2pvpL+S+OA qnyClRuDh39pKAOg4Hoi9p1H6roG/wh5FSTzP4H1j3d3MdbOY3oyH6FI1GzzZv6PyqRISe 4T2SMzYKUdpLGcsnTTZHaM2Dah7yPqFo66zvzOAzrtryiI39T4BSrSH4Kls5jg== X-Report-Abuse: Please report any abuse attempt to abuse@migadu.com and include these headers. In-Reply-To: <8d0be260-7b15-0b48-42e5-e5a4cc203e54@yandex.ru> X-Migadu-Flow: FLOW_OUT X-Migadu-Auth-User: sir@cmpwn.com Received-SPF: pass client-ip=91.121.223.63; envelope-from=sir@cmpwn.com; helo=out1.migadu.com X-Spam_score_int: -27 X-Spam_score: -2.8 X-Spam_bar: -- X-Spam_report: (-2.8 / 5.0 requ) BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001 autolearn=ham autolearn_force=no X-Spam_action: no action 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:273375 Archived-At: On Sun Aug 29, 2021 at 3:56 AM CEST, Dmitry Gutov wrote: > - You need to input a correct email to send a patchset to. > This seems not too hard to fix, at least conceptually. Aye. A future enhancement will pre-fill this with the appropriate email address for the project's mailing list. > - Every version of a patchset is re-submitted as a whole. I suppose > there is some purity in that, but if for example the original submission > is big, and I only asked the author to change a few relatively minor > things, I prefer they do that in a separate commit. Then, in a git**b > workflow, I see that the branch was updated with that one commit, and I > don't have to scan the other commit(s) for any unrelated/breaking > changes. This is a bad practice for git, because it makes the history worse. This has consequences, for example, with tools like git bisect. Instead, git range-diff is helpful for comparing the previous and new version of a patch, and future improvements to the web UI will incorporate it to allow you to easily diff between patchset revisions. The idea is something similar to Gerrit's approach, you may be familiar with that. > - Rebasing. Some of our valued contributors are not 100% comfortable > with the more advanced features of Git, rebasing included. Our general > recommendation until now has been to prefer merge commits. If the > general workflow is going to require people to 'git rebase -i' on a > regular basis, it could be a problem. We wrote another tutorial about git rebase which has been very helpful: https://git-rebase.io In general we are a hard "no" on shying away from powerful tools because they are intimidating to new users. We prefer to cultivate a culture of mentorship instead. > - Can we have discussion subthreads "attached" to particular pieces of > the submitted patches? Like, a line, or a hunk. Being able to view those > in a compact fashion, right in the middle of the context, is pretty > handy. Yes, though it's based on heuristics and we're still working on it. Here's a simple example: https://lists.sr.ht/~mpu/qbe/patches/24383 > - Can I jump in in the middle of a patch discussion with a question or > an advice and have all subsequent messages in that discussion sent to me > too, if I'm not subscribed to the target mailing list? Does that depend > on all participants putting me in Cc? It depends on all of the participants Cc'ing you. It is common practice to "reply all" on mailing lists for this reason. > - Can I do that "jumping in" from the web interface? No, but this is a prioritized issue. > - Can I "unsubscribe" from replies to a topic/thread/patchset I'm not > longer interested in? In a sense. Because you don't have to subscribe to the mailing list to participate in a thread, you won't get emails unless the sender has Cc'd you. But you cannot stop them from Cc'ing you, and neither can we, unless you ask nicely - which is not a software solution. Such emails are not relayed by our mail servers, so it's out of our control. Subscribing to individual threads is also prioritized.