emacs-devel
[Top][All Lists]
Advanced

[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



reply via email to

[Prev in Thread] Current Thread [Next in Thread]