Re: Gitlab Migration

["Drew DeVault" <sir@cmpwn.com>]

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.