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: Sun, 29 Aug 2021 04:56:04 +0300 Message-ID: <8d0be260-7b15-0b48-42e5-e5a4cc203e54@yandex.ru> References: 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="13952"; 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 Sun Aug 29 03:57:08 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 1mKA4K-0003Ou-4Q for ged-emacs-devel@m.gmane-mx.org; Sun, 29 Aug 2021 03:57:08 +0200 Original-Received: from localhost ([::1]:39428 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1mKA4I-00089f-EP for ged-emacs-devel@m.gmane-mx.org; Sat, 28 Aug 2021 21:57:06 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:44986) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1mKA3Q-0006dI-5u for emacs-devel@gnu.org; Sat, 28 Aug 2021 21:56:12 -0400 Original-Received: from mail-wm1-x32a.google.com ([2a00:1450:4864:20::32a]:44023) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1mKA3N-00062H-RR; Sat, 28 Aug 2021 21:56:11 -0400 Original-Received: by mail-wm1-x32a.google.com with SMTP id o39-20020a05600c512700b002e74638b567so6997312wms.2; Sat, 28 Aug 2021 18:56:08 -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=Y9+KC/ojgZit0l5LfPG75HaVIIDYFch5Lf5DGCeZSTw=; b=G/gDlf76zA72+BwGusgC1D1661Rq8Onq625rMwjwP8QwX4Il/WqXH6Orw7vEnv64Jn tMVxRnkGhwuGwyOtvE6K/2Oro9Rn44MUf0fZz5iOWA9J+I/WZIFFMzJMw8unjVjesqlu mxaiKmFlN9NSBkc2uIzlSjT5RN2CffXtx5I3aulvnHNkRpJ5tZ0/ESC3ol87lNlnxjao ctS2qmjYVQpLpNUxYxw4Be99QtYDx6dexbO1cI2vaNWB15hhLX1sHRxXRgVkev9OV//C mywDJ1BrdCaB1TkArBETwNe2lOKVpNYfVCZaRn/VtLxPklCl/X9z284MdcT3wiGeheEO ACTA== 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=Y9+KC/ojgZit0l5LfPG75HaVIIDYFch5Lf5DGCeZSTw=; b=r21Rf5iJiiHJ8y3kLGN4QsCt6t6tP1Tgv/I4YTIB3tC+iNXMCOh81Z2Em2NFmTd2bY 5V0Nn1uBtztHg8yvZ1ieBGswkK8AAWAkVZTpdt6Mb3TCSDKDncqQcNnXfeaIW49YDQc/ OFoa7lcZ2uPc6QoeC8x85D7w/56zWgcHwvMM7MDN5C6jydB5HkpzQNIh1EIuDhDTrBBR usHCjaCMCXQtnUTae0xQ/6Uw+FSbQ1An4VC89RFl0ch2TCSaiCpnzXa9a9zVnKErch/c dG3hVDJQG50Ck7hcg9nWTjTEP7xOAl6MnP2l6WwaJs94rGL414637+gkzn/euUXUUOqw PrQw== X-Gm-Message-State: AOAM533Tow3L8pqVlDuFE3GbJZg2ZX4CLzdmaZnHOieBqPaZwDvdYM4T BnoNwkq6L9hGHZwaLLwEpDWiRYx+72o= X-Google-Smtp-Source: ABdhPJyOj+l2KS1pH5NoUfI1Q1pmFGzeqD2Rx2cFmSXKnvvKmm331Pp5lE3lFN1g8XsV8q8I5+AbwA== X-Received: by 2002:a1c:c913:: with SMTP id f19mr15335253wmb.86.1630202167050; Sat, 28 Aug 2021 18:56:07 -0700 (PDT) Original-Received: from [192.168.0.6] ([46.251.119.176]) by smtp.googlemail.com with ESMTPSA id g1sm10956886wrb.27.2021.08.28.18.56.05 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Sat, 28 Aug 2021 18:56:06 -0700 (PDT) In-Reply-To: Content-Language: en-US Received-SPF: pass client-ip=2a00:1450:4864:20::32a; envelope-from=raaahh@gmail.com; helo=mail-wm1-x32a.google.com X-Spam_score_int: 1 X-Spam_score: 0.1 X-Spam_bar: / X-Spam_report: (0.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.248, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.249, NICE_REPLY_A=-0.437, PDS_OTHER_BAD_TLD=1.997, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001 autolearn=no 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:273358 Archived-At: On 28.08.2021 19:04, Drew DeVault wrote: > On Sat Aug 28, 2021 at 5:20 PM CEST, Lars Ingebrigtsen wrote: >> That's also my impression. That is, SourceHut supports our current work >> flow very well, but it doesn't really give us the popular Github/Lab >> work flow: fork the repo, work on something, push it, and then do a >> "pull request" towards the original repo by clicking a button, without >> sending any emails to any person? >> >> Because that's really what we want to add as an option. > Here is a video of the sourcehut equivalent of the github/lab > pull/merge-request flow: > > https://spacepub.space/videos/watch/ad258d23-0ac6-488c-83fc-2bacf578de3a Thanks for the video. AFAICT it shows a workflow that follows what the Linux kernel and associated projects do, so it's clearly workable. But compared to "the Git**b workflow", here are a few frictions/downsides that came to mind: - You need to input a correct email to send a patchset to. First, it's a step where the contributor would have to stop and look stuff up (which email indeed to use?), and then they might end up sending the whole thing to one of the contributors directly. Whereas, with rare exceptions, we probably want to have a section on our "sourcehut project page" which lists all current and past submissions. This seems not too hard to fix, at least conceptually. - 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 kind of back-and-forth can go for several rounds (minor change here, minor change there). If the user has to rebase and resend their whole branch every time, and if the branch has multiple commits, that's a lot of extra traffic. Of course, some users want to rebase anyway (and I rarely bother asking them to stop), so it only really applies to some submissions. But I'd generally prefer to see some fixup commits (during the review rounds), and then a rebase at the end of the review. Or just merge the whole branch, with fixes and all (this too can make sense, depending on the nature of the requested changes). This seems to require less work from everybody involved. - 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. Bonus questions: - 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. - 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? - Can I do that "jumping in" from the web interface? - Can I "unsubscribe" from replies to a topic/thread/patchset I'm not longer interested in?