From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Dmitry Gutov Newsgroups: gmane.emacs.devel Subject: Re: Gitlab Migration Date: Mon, 30 Aug 2021 02:17:38 +0300 Message-ID: <9b839e28-e406-ff4d-0c1e-0bdb9d397f96@yandex.ru> References: <8d0be260-7b15-0b48-42e5-e5a4cc203e54@yandex.ru> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="20654"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.11.0 Cc: theo@thornhill.no, Philip Kaludercic , danflscr@gmail.com, monnier@iro.umontreal.ca, emacs-devel@gnu.org To: Drew DeVault , Lars Ingebrigtsen , Eli Zaretskii Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Mon Aug 30 01:18:22 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 1mKU4D-0005Av-S6 for ged-emacs-devel@m.gmane-mx.org; Mon, 30 Aug 2021 01:18:21 +0200 Original-Received: from localhost ([::1]:54350 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1mKU4C-0002Ci-Lr for ged-emacs-devel@m.gmane-mx.org; Sun, 29 Aug 2021 19:18:20 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:53560) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1mKU3d-0001V3-Li for emacs-devel@gnu.org; Sun, 29 Aug 2021 19:17:45 -0400 Original-Received: from mail-wm1-x335.google.com ([2a00:1450:4864:20::335]:55147) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1mKU3a-0000th-T4; Sun, 29 Aug 2021 19:17:45 -0400 Original-Received: by mail-wm1-x335.google.com with SMTP id g138so7624846wmg.4; Sun, 29 Aug 2021 16:17:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=sender:subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=PiY+sSEU1gPN5q/qDyxM4T+CmsWG7F9wgnVNH1HIcyM=; b=tnRjVoibiL1Ha5V7hk+LPz9GuchfAJz7+BzhVkgE+w/MIIWCLYrZioeFhCgjyvmWj+ bJhEnkOmh0D0ZTsXArGYmJNbdLT1yMDVBvj1wqeo5w+i201YIUJFxXSQ/eqcy2eI7hAN F/C6hghqS1A+LtwTYvyisAItznRoaGJiUIZVJo1HARGArfxtzwpQKgcJcPCKim9vh62I AB3CF/B2cwNl+0HPSTWRthhtL8xCu0feaAhKYi2sFCY7tHkvd/+ONwxmTKirdZwjtAu8 +1Cot9ThwWxRstsCl+FjDItZjXkIyzEmeKnP8Ptgkz3oNyE5m3IF+mWtncL1udn5ddec Wwig== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:sender:subject:to:cc:references:from:message-id :date:user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=PiY+sSEU1gPN5q/qDyxM4T+CmsWG7F9wgnVNH1HIcyM=; b=Iz22Q5z9A1ZKtbm7namqxskTa2Sb9xc+GLLXuKalvMstnO1VjJW3ci1k0t0l2rveoq BZs2AKF5MsaOQ8vevT/Psb9C7IaxrKt7RG75A92mGXokbSglxSse9YN083ybp2heApMw HzDhqI5XVcyA7LWx06DMMrH9BAXXcZPnylsNAi5q3sgR7e4TmA9i0mDpQ2WP5karXq2f xCtj7+T+EJgyHp+rgva+H4JPVMEXbkRwYjMVgJD83D9opD0oqlM++044rRr60BU5TeP2 DtXjlp3/MeXKyJaD84JtFnsz2PsAhQAKg1iaesLiUq8iC/L0FeFdi1cfUetezc7Yyz0V 7Zxg== X-Gm-Message-State: AOAM531zgfE9r8m/Ror0p3UJQPkNBgLv+6LypiA7YTUr0wppeLndw7Vc T0Ajfdi2q/3g1VH/gNyFFGnde0Lv9wY= X-Google-Smtp-Source: ABdhPJx4nZIyzDAtKkgJbEbVdGyCOZpd9h9t9R01UBpOL1nsLrFAopR16OGYBoAUgtB8OEsg0GXWdA== X-Received: by 2002:a05:600c:14c6:: with SMTP id i6mr11476884wmh.99.1630279060919; Sun, 29 Aug 2021 16:17:40 -0700 (PDT) Original-Received: from [192.168.0.6] ([46.251.119.176]) by smtp.googlemail.com with ESMTPSA id w9sm11730858wmc.19.2021.08.29.16.17.39 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Sun, 29 Aug 2021 16:17:40 -0700 (PDT) In-Reply-To: Content-Language: en-US Received-SPF: pass client-ip=2a00:1450:4864:20::335; envelope-from=raaahh@gmail.com; helo=mail-wm1-x335.google.com X-Spam_score_int: -20 X-Spam_score: -2.1 X-Spam_bar: -- X-Spam_report: (-2.1 / 5.0 requ) BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.249, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.25, NICE_REPLY_A=-0.58, RCVD_IN_DNSWL_NONE=-0.0001, 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:273439 Archived-At: On 29.08.2021 09:55, Drew DeVault wrote: >> - 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. Depends on how the changes are organized, whether there will be breaking builds, and whether commits include back-and-forth changes in the same place. In the end, a branch-driven workflow can ask for a single rebase before the changes are merged to master (with fixups, squashes, etc). Which should fix the later problems with bisecting and give cleaner history, without having all the patches resent for every round of review. > 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. Haven't used Gerrit (or Phabricator, which I understand includes a similar feature). Good to know there is a plan for it, though. >> - 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. All right. I can live with that. Just want to make sure everybody's on the same page about the tradeoffs. >> - 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 Thanks. I'm curious to see how it turns out. >> - 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. Sure, I'm familiar with it. Hence the questions. >> - 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. Consider adopting a "common practice" from the Web UI world: every discussion (issue/PR/etc) has a unique email address. Every participant receives messages "From:" a common address (like notifications@sr.ht) but the Reply-To header includes the unique address which will let the mail processor on the server associate the reply with the corresponding thread and resend it to all participants. Then anybody will be able to subscribe or unsubscribe from a thread without others' cooperation (with different levels, even, where e.g. they still get a notification when "mentioned" personally). As a bonus, it solves the problem of some mail servers/hostings not talking to some other mail servers: if you can send an email to sr.ht, all others will see it. If you can receive emails from sr.ht, you will get all messages. But it might feel a tad impersonal, I guess. And user error (including misbehaving MUAs) can break this approach too.