Re: Gitlab Migration

[Dmitry Gutov]

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?