Re: Gitlab Migration

[Philip Kaludercic]

Eli Zaretskii <eliz@gnu.org> writes:

>> From: Theodor Thornhill <theo@thornhill.no>
>> Cc: emacs-devel@gnu.org, larsi@gnus.org, monnier@iro.umontreal.ca,
>>  danflscr@gmail.com, philipk@posteo.net, sir@cmpwn.com
>> Date: Fri, 27 Aug 2021 21:38:43 +0200
>> 
>> >> https://lists.gnu.org/archive/html/emacs-devel/2020-09/msg00534.html
>> >
>> > That was almost a year ago, and the discussion is thin on actual
>> > details.  Support for email-based workflow is a good start, and is one
>> > of the main requirements, but what about the GitLab/Github-like
>> > features? if they are missing or incomplete, we will be trading
>> > debbugs for something that is basically the same beast in a different
>> > wrapping.  And what about the other requirements we collected and
>> > documented in the GitLab issue about this?
>> >
>> 
>> It seems like Sourcehut supports everything requested, but I might be
>> missing something, of course.  In particular the CI is very nice and
>> simple, at least for the hosted version at https://sr.ht.  It also
>> supports running without javascript at all, so the libreJS debate should
>> be settled right there. Instead of me speaking on sourcehuts behalf,
>> with which I have no affiliation outside of being a happy customer
>> myself, I'll ping the creator.
>
> 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.

Here is my take:

+ Email workflow

  Is supported as a first-class interaction method

+ Reduce email noise

  The mailing lists are just mailing lists, from
  what I know the only "spam" might be CI responding with the results of
  a test

+ Submitting patches by email

  Is supported as part of the email workflow

+ Offline review

  Same as above

+ Reviewing patches by email

  Ditto, and the comments are rendered properly in the web UI.

* Merge request creation

  Not sure if this is applicable, you'd usually just send a patch and
  not create a format "merge request".

* Code should be accompanied by documentation

  Here too I cannot say for sure, but I can imagine integrating checkdoc
  into a CI that automatically warns a patch-submitter if something
  isn't documented properly.

* Formatting code commits

  Same as above.

* Traceability of Merge Requests

  Again, merge requests are not formal but just a message on the mailing
  list, usually generated by git send-email. (There might be an issue
  here if users just attach patches as they do now.)

+ Continuous integration

  Is given

? Closely integrated bugtracker

  I haven't used "todo" (the issue tracker,
  https://man.sr.ht/todo.sr.ht/) enough to really comment on this. My
  general understanding is that this, integration between the different
  components, is one of the things that remain in need of improvement
  before the project leaves the beta stage

* Spell & grammar checking

  Again, could be done with CIs. Assuming one has a grammar checker.

- Branch rules

  I don't know of any mechanism to limit access to branches.

* Copyright assignments

  CI should be able to handle this.

+ Licensing

  Yes!

- Integration with savannah

  Is not implemented, but the question is if the existing infrastructure
  should be extended or replaced.

- Integration with debbugs

  Same as above.

- Emacs frontend for bug tracker

  There is no package for sourcehut comparable to debbugs, but it
  shouldn't be hard to implement considering that.
  
+ Bug reporting

  The mailing list should be able to handle bugs M-x report-emacs-bug.
  
> I tried to find answers to those questions myself, but there doesn't
> seem to be any detailed documentation that describes the setup and
> usage from the routine user POV (or maybe I missed it?).  I did find a
> heads-up that "from the beta onwards, unpaid accounts will be limited
> to read-only access to their own projects", so I wonder what that
> means for us.  It also says that "web-based workflow for submitting
> and reviewing patches" is still under development.

It shouldn't mean anything, if GNU decides to host their own
instance. Otherwise, every project member would have to play to have an
account, but I assume mailing list contributors could continue accessing
the mailing list without any issue.

-- 
        Philip Kaludercic