Hi all,
I want to comment on the "ongoing analysis" that's being done regarding
the new collaboration platform. For Sourcehut, you listed
No Web merge request UI. A Web merge request can be done by
creating a ticket and including the forked git repo url and branch
name, but this missing feature seems like a key thing we are looking
for.
as a bad thing. Let's discuss the "forking" and "merge request" ideas a
little further.
Following the canonical GitHub model, a fork represents a copy of a
repository from one user/organization to another user's/organization's
account. Notice that it is essential that the forker has an account on
the platform the process is done, otherwise this wouldn't work.
Forcing people to have an account on your code hosting platform for
basic things like filing a bug report/feature request or sending patches
doesn't benefit the users at all. It ties all of their actions to a
specific workflow, basically locking them in. Compare these two
workflows:
1) I want to fix a stack overflow bug in a Rust project hosted on
GitHub. The actions I need to take are, in order: log in, fork, clone
the fork locally, make the changes, commit, push, go back to the web UI,
figure out how the hell the pull request interface works, send a pull
request and wait for response.
2) I want to add a package to GNU Guix. I go to their Savannah page to
find the link I need to clone. No account required. I clone the repo,
make the changes, commit, `git format-patch` and send an email with the
patch either in the email body or as an attachement to
[email protected] and wait for response.
The most distributed and inclusive method is the second. That way,
anyone who has an email account (and anyone has those, including the
people that use the first workflow) can send in their contributions. It
makes the whole process feel more personal also. There isn't a single
step where you're required to use some overly specific tooling -- you
write the code however you want, generate the patches however you want
and send them however you want, as long as it reaches the maintainers.
But what if, in any of those two cases presented above, I would have to
revise my contribution -- maybe I made a typo or I created a WIP thread
and I'm now sending more progress.
1) I continue making changes to my fork, and the pull request follows
whatever branch I set it to look at so it automatically updates with the
latest commits when I push them. I don't know how one would gracefully
handle amending the last commit with a PR system though.
2) I continue making changes to my local repository and commit them.
When done, I send more emails, one per patch, to the already opened
thread. If I want to revise my first patch, I can easily amend that
commit in my local repository and send a second, improved version of the
first patch without thinking about having to use --force.
One of the common so called "counter-arguments" to proposing email-based
collaboration is "but email is antiquated". Email is indeed something
that's been around for a long time, yet that doesn't make it bad. It
encourages sending thoughtful messages, rather than short replies that
lack important information. Furthermore, most people already have have
an email address and, if not, it's very easy to obtain one -- from
whatever provider you want.
We should keep in mind that we shouldn't be adopting the GitHub model
just because that's what most people are familiar with. We should search
for the best platform, not the most familiar. I am aware that
email-based collaboration is alien to a big part of the people working
in tech, but that doesn't mean it's bad or worse than the alternatives.
In my opinion, it's the best thing we have yet. Simple, efficient,
decentralized.
If anyone says that it's hard because they're not used to it, we
shouldn't drop the idea. Instead, we should create better documentation,
tutorials and guides to support people coming from the GitHub model or
people that are totally new to contributing to free software projects.
If anyone reading this is interested in a taste of collaboration by
email for git-based projects, check out this cool guide for using git
send-email: https://git-send-email.io/
Note that the fact that I'm pushing for "email-based" collaboration
makes this look more shallow than it is. If I know a maintainer I can
drop him patches as letters to his door if I want to. I really need to
stress out the fact that git patches can be sent exactly however you
want -- they're just text.
Another reason to like patches is the fact that they can live outside
the "official" project, too. Look at the suckless software -- st (simple
terminal) doesn't include the ability to have transparency by default,
yet they distribute a patch that, when applied, can make it go
transparent.
I think everyone can agree that a clear git history is important for
projects of any sizes. Unlike merge/pull requests, applied patches don't
pollute your git history -- each patch is a commit, as it was in the
patch-sender's tree, and that's it.
I remember a discussion about pull requests vs patches where someone
said: "Let git do its job. No need for pull requests." I totally agree.
I'd like to hear your thoughts on this, especially about why "this
missing feature seems like a key thing we are looking for".
Cheers,
Alexandru-Sergiu Marton
