From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Tim Cross Newsgroups: gmane.emacs.devel Subject: Re: Gitlab Migration Date: Fri, 27 Aug 2021 16:10:03 +1000 Message-ID: <87o89jqseb.fsf@gmail.com> References: <87h7fcnmq0.fsf@posteo.net> <28953ac9-60e5-7583-6297-750c04ca3748@gmail.com> <83fsuwrps6.fsf@gnu.org> <767b2e84-be1b-de7a-40d0-4e1432fcce35@gmail.com> <837dg7saet.fsf@gnu.org> 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="7331"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: mu4e 1.6.5; emacs 27.2.50 To: emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Fri Aug 27 09:06:23 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 1mJVwV-0001fg-JG for ged-emacs-devel@m.gmane-mx.org; Fri, 27 Aug 2021 09:06:23 +0200 Original-Received: from localhost ([::1]:51376 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1mJVwU-0006Rf-Lz for ged-emacs-devel@m.gmane-mx.org; Fri, 27 Aug 2021 03:06:22 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:51278) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1mJVvq-0005Pk-6C for emacs-devel@gnu.org; Fri, 27 Aug 2021 03:05:42 -0400 Original-Received: from mail-pj1-x1035.google.com ([2607:f8b0:4864:20::1035]:42712) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1mJVvo-0003Xr-EC for emacs-devel@gnu.org; Fri, 27 Aug 2021 03:05:41 -0400 Original-Received: by mail-pj1-x1035.google.com with SMTP id w19-20020a17090aaf9300b00191e6d10a19so4195581pjq.1 for ; Fri, 27 Aug 2021 00:05:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=references:user-agent:from:to:subject:date:in-reply-to:message-id :mime-version:content-transfer-encoding; bh=s8dGbAWgtqGzN6rmevT90CbgqvbcQodMfGSi6VsKGMk=; b=ShKoXfQzeDZGYJ8PbXyVD7mDoepF8hzed/gkqaAb+TH7VSjG0MRsqlvRpzgLrxWcMW D4qmJ7jX7oA9AJBrS9RhnPbkuSlGAP+s/hbIA3XE9xxfT1igTxsSU8K2ndQDgGbUBQXl Cb/tLfPg0jZpUZEAx2FodnK2vZJD2GAi/5Wte8Y/qMkQdDGruwgqu/ZUHIFxFN3eLdCT SzCM0OfslqAd5EhDtErI8qv07nXDFDKotHgfeOOHbf6orFyZY8rJfL0Ur5Hfg1vLKkrA ilX4m0+WQbLRa3aupUwJmEvxiwqLUgEq6D/KFhvM+6tJGY6aelBWIcK9yeA+3YTCg9Gk LGtA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:references:user-agent:from:to:subject:date :in-reply-to:message-id:mime-version:content-transfer-encoding; bh=s8dGbAWgtqGzN6rmevT90CbgqvbcQodMfGSi6VsKGMk=; b=Qcc1Zlwx7/C1EiW6c1zrlfIiDDM5ADGFk4Za6MRIu0la0NoNrc91cvm2K1wD6sWa9c xODAivvMF1QBuGupA1+Qh5j+eprV/nLpDNo0ci248F11HaQbRvjnW0Ql3UV6tcwHzdk9 J4894oWv7stX3lqwptlsB9d1Yww7mk5uoYyAcvM5U2TrmuxoJVnOSZLqkC7J1Dr6VsRc YMJ0aLT5VpnwYkvwcBi/abrI3DhgsCsCYWtjwbN8uc+/ICyG+MZUFG4dYQvV8lntoikE H4fhKOQYm8eHlVgyYpR7fzwVx4zBYkafB23ecQRpcL+tfNkq/Q2SYm1FdEJ1Xq86uJvS JaIw== X-Gm-Message-State: AOAM5326Pg2o1Hv8Y652O/5km7hU2NxItedNkU+p+RUDmIcUrgD4nDI+ rLNjgaEalAzBzFYoUEEyaKcTIVGVJu0= X-Google-Smtp-Source: ABdhPJzEs6SQc8Fx6+EN4U6ZkwxEkbU0qIL5VD5dpvYyzQ9AGTgkekf1YKfiZy2TTkWg2iWcT5LCSA== X-Received: by 2002:a17:902:aa06:b0:12f:66dc:be7f with SMTP id be6-20020a170902aa0600b0012f66dcbe7fmr7444545plb.9.1630047937461; Fri, 27 Aug 2021 00:05:37 -0700 (PDT) Original-Received: from tim-desktop (106-69-92-233.dyn.iinet.net.au. [106.69.92.233]) by smtp.gmail.com with ESMTPSA id o11sm5208117pfd.124.2021.08.27.00.05.36 for (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 27 Aug 2021 00:05:37 -0700 (PDT) In-reply-to: <837dg7saet.fsf@gnu.org> Received-SPF: pass client-ip=2607:f8b0:4864:20::1035; envelope-from=theophilusx@gmail.com; helo=mail-pj1-x1035.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_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, 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:273127 Archived-At: Eli Zaretskii writes: >> Cc: emacs-devel@gnu.org >> From: Cl=C3=A9ment Pit-Claudel >> Date: Thu, 26 Aug 2021 16:09:32 -0400 >>=20 >> 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. >>=20 >> Oh, that's not how it typically works in the project that I contribute t= o (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. > It is really up to the individual. Github for exmaple, provides instructions for merging PRs using either the web UI or the command line. For the CLI, you are adding the remote PR as a 'remote' to your local git repository. You can then check it out as a branch, review, modify and test. If satisfied, you then just merge into your main branch (or whatever branch is appropriate), push it up and close the PR. Many people will just use the web UI. Personally, I prefer the CLI approach as I like the additional control. At this level, it isn't much different to how I imagine Emacs maintainers currently deal with email patches i.e. checkout a fresh branch, apply the patch to that branch, evaluate and if appropriate, merge into main branch. The PR approach does have advantages, especially for those submitting the PR. It can provide some useful immediate feedback (especially if some of the advanced actions are used to perform common checks or policy validation), provides a single definitive place, potentially including review/comment history and changes and could be setup to help reduce demands on core maintainers (for example, might require review by one or more reviewers, who could be trusted volunteers who are comfortable to assist with reviewing, but perhaps not with the responsibility of merging). Core maintainers can then focus on just those PRs which have been reviewed and avoiding wasting their limited time on things others can deal with. However, it seems the main issue isn't whether these so called 'modern' workflows are a bad idea, but rather whether there is software which implements these workflows which is FSF compliant. The best course of action might be for those who would like to see adoption of these workflows contribute to projects which are FSF compliant - perhaps projects like sourceHut and help get a solution to a satisfactory standard that it could be used by Emacs (and other GNU projects). Until software is identified which meet FSF requirements, little can change and debating the merits is largely pointless.=20