emacs-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Gitlab Migration


From: Philip Kaludercic
Subject: Re: Gitlab Migration
Date: Thu, 26 Aug 2021 17:24:07 +0000

Hi,

Daniel Fleischer <danflscr@gmail.com> writes:

> One issue which I think is important is the move to a new VC system,
> e.g. Gitlab. I started reading the relevant threads and I'm not sure
> where the issue stands today. Let me recap the benefits:
>
> 1 The need for new people to join the community and help. Newer
>  (younger) people will be more familiar with the newer VC platforms
>  (github/lab and similar). These are not only developers but regular
>  users who want to report an issue (bug) or suggest a feature.

Shouldn't it be easier to send an email than create an account, navigate
some web UI and fill in some form? The same goes for
patches. Git{Lab,Hub} usually requires leaving the development context,
to prepare a patch online, that requires "forking", more navigation and
more fora. Just today I tried preparing a "pull request" on GitLab and
didn't manage to do so, because it insisted on merging the commit into
my own repository, no matter what I did. Just attaching a git patch
seems much easier.

>  Lowering the bar for participation is the key to growing Emacs and
>  the community.

I think that showing people that they biases against mailing list
development might be illegitimate would be a viable alternative.

> 2 Having the code + issues + discussions in the same place as opposed
>  to now, where the code and discussions (lists) are in 3 different
>  places (Savannah, Gnu mailing lists and Gnu bug tracker). With a
>  modern VC system, one can jump easily between issues, discussions,
>  code commits back and forth easily as opposed to now, where if it's a
>  bug you can use its number to search lists and commits messages but
>  if it's a discussion, it's not "connected" to anything.

Correct me if I am wrong, but all the discussions are at least mirrored
on the mailing lists. Savannah is just for project management and the
GNU bug tracker uses the mailing list too. It is more uniform too, as
everything is just a mail-message, not part of a forcefully linearized
thread. Commenting on a issue, "pull request" or a patch is always just
responding to a message.

That being said, I wouldn't mind prettier web interface for the mailing
list (I think that the Guix project is doing well on that front).

> Possible issue:
>
> 1 Being able to use Emacs for all these needs. One way is being able to
>  interact with the VC system using emails, i.e. issues, features,
>  discussions should have a nice and efficient email interface in
>  addition to using a website. Another approach is using the wonderful
>  Magit and Forge packages. Forge currently is lacking the discussions
>  feature but has a very good git + pull-requests + org-mode
>  integration abilities.

I remember Sourceforge being suggested as an alternative to Gitlab, but
the software is currently still in a beta stage (AFAIR).

> 2 Changing processes, how people operate. Whether it's the technical
>  aspect of a pull-request approval vs. patch submission to the more
>  conceptual change of dealing with "issues" representing bugs, ideas,
>  feature requests or general discussions instead of mailing lists.
>  These changes shouldn't be too disruptive. However I do believe a
>  small price has to be paid in order to go from one local minima of
>  effort in a given practice to another, hopefully better local minima.
>
> Does this describe well the current situation?
> What areas need attention in order to facilitate the change?
>
> Thanks for any feedback.
>
> Daniel Fleischer
>

-- 
        Philip Kaludercic



reply via email to

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