Re: Gitlab Migration

[Tim Cross]

Eli Zaretskii <eliz@gnu.org> writes:

>> Cc: emacs-devel@gnu.org
>> From: Clément Pit-Claudel <cpitclaudel@gmail.com>
>> Date: Thu, 26 Aug 2021 16:09:32 -0400
>> 
>> 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.
>> 
>> Oh, that's not how it typically works in the project that I contribute to 
>> (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.