[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Gitlab Migration
From: |
Theodor Thornhill |
Subject: |
Re: Gitlab Migration |
Date: |
Fri, 27 Aug 2021 23:04:55 +0200 |
Eli Zaretskii <eliz@gnu.org> writes:
[...]
>
> Would it be possible to have a more detailed review, like short
> description of what is available for each of the requirements in the
> GitLab issue? That should give us a good idea of how close we are to
> the goal.
>
Sure, I can try. At the minimum, it can serve as a starting point from
which Drew can correct all my mistakes when he chimes in. Firstly, I'll
say that it in general offers a similar workflow to what emacs
developers already use. It also has an explicit goal of not being too
GitHub/GitLab-like, where pull requests are the default way to
contribute. However, there are some key differences. You don't need a
user account to use it, though that gives you some benefits like cloning
repos etc. It is and always will be (I think) emailbased rather than
forms on the web. That means using `git am` and friends to push and
pull the code.
About payment - all users should be able to report bugs when it hits
beta. The paid features is for the cloning and personal repo hosting, I
think. Also not sure if this applies when sourcehut is self hosted.
As for the specific points in the gitlab issue, let me make an effort:
* Email workflow
This is a given. Patches and discussions are all first class citizens,
meaning that it is all backed by email. You can open, close, adjust and
respond to issues using email.
** Submitting patches by email.
It is possible to send patches using a web interface. It works by using
the `prepare a patchset` button on your own clone. So the process
is usually:
- clone the repo
- pull it locally
- do the work
- push the work
- use the `prepare a patchset` button or `git format-patch`
It is then sent to the respective mailing list
** Offline review
An issue (if not already subscribed to all) can be subscribed to your
own email and be sent to you. The whole thing or parts of it can be
downloaded as an mbox.
** Reviewing by email
You can use inline comments [1]
** Merge request creation
Honestly I don't really understand this one...
* Code should be accompanied by documentation
This seems trivial, and can be done using the CI on patch submission
running a job, if I understand that point correctly?
* Formatting code commits
Same as above
* Diff mailing list
This I don't know
* Traceability of Merge Requests
There is at least a basic web search available on the web client for
this, but seeing how the only repo I maintain with actual contributors I
maintain is on GitHub I don't have much first hand experience here.
* Continuous integration
This is one of sourcehuts strong points, as I see it. Jobs can be run on
patch submission and on commits, and is also inspectable through ssh
should something break. Arbitrary stuff can be done here.
* Closely integrated bugtracker
automated tasks for patch application and status updates exist here
...
There seems to be some more points here that could be covered by CI, so
I'll jump a little
...
* Licensing
No js is needed
Captcha is not used
GNU criteria for ethics I cannot say anything about. Though it would
surprise me if it didn't score well.
* Integration with savannah
I can't say anything about this
* Integration with debbugs
Seeing how both use mbox this should be trivial to do
* Bug reporting
`report-emacs-bug` can still be used, as well as clicking in the web
ui. This is where I'm not sure about not using email. I think you still
need to mail the bug, opened by a mailto:
I hope this helps a little.
--
Theodor
[1]: https://lists.sr.ht/~technomancy/fennel/patches/24386
- Re: Merges from release branch, (continued)
- Re: Merges from release branch, João Távora, 2021/08/29
- Re: Merges from release branch, Eli Zaretskii, 2021/08/29
- Re: Merges from release branch, João Távora, 2021/08/29
- Re: Merges from release branch, Eli Zaretskii, 2021/08/29
- Re: Merges from release branch, Eli Zaretskii, 2021/08/29
- Re: Gitlab Migration, David Engster, 2021/08/29
- Re: Gitlab Migration, Eli Zaretskii, 2021/08/29
- Re: Gitlab Migration, Lars Ingebrigtsen, 2021/08/29
- Re: Gitlab Migration, Eli Zaretskii, 2021/08/29
- Re: Gitlab Migration, Dmitry Gutov, 2021/08/29
- Re: Gitlab Migration,
Theodor Thornhill <=
- Re: Gitlab Migration, Eli Zaretskii, 2021/08/28
- Re: Gitlab Migration, Theodor Thornhill, 2021/08/28
- Re: Gitlab Migration, Drew DeVault, 2021/08/28
- Re: Gitlab Migration, Daniel Fleischer, 2021/08/28
- Re: Gitlab Migration, Drew DeVault, 2021/08/28
- Re: Gitlab Migration, Jean-Christophe Helary, 2021/08/28
- Re: Gitlab Migration, Alan Third, 2021/08/28
- Re: Gitlab Migration, Theodor Thornhill, 2021/08/28
- Re: Gitlab Migration, Jean-Christophe Helary, 2021/08/28
- Re: Gitlab Migration, Theodor Thornhill, 2021/08/28