Re: Gitlab Migration

[Arthur Miller]

Eli Zaretskii <eliz@gnu.org> writes:

>> From: Arthur Miller <arthur.miller@live.com>
>> Cc: dgutov@yandex.ru,  philipk@posteo.net,  danflscr@gmail.com,
>>   larsi@gnus.org,  emacs-devel@gnu.org
>> Date: Sat, 28 Aug 2021 03:51:40 +0200
>> 
>> >> and debbugs package for browsing bugs directly from Emacs?
>> >
>> > The debbugs package has several non-trivial dependencies, like email,
>> > and is probably not the first or the second thing newcomers should be
>> > messing with.
>> 
>> Maybe, but if somoeone is developer who would like to send in patch to Emacs
>> than they can probably setup email? Newcomer to Emacs dev, does not mean
>> newcomer to computing.
>
> The main purpose of the Emacs debbugs package is not to send patches.
> Sending patches when you have email set up is trivial and doesn't need
> the debbugs package.

About debbugs, I meant for exploration of bugs. Someone mentioned that web based
interface offers "issues" lists where people easily can see if their issue is
already repported or not. My argument is that debbugs with Emacs interface
offers as easy such interface. Though search is not as easy since Emacs fetches
data only on request. One can use C-s to search between titles in debbugs
buffer, but it does not seem to possible to search in-depth in articles, at
least I don't know how. I guess I would have to download entire database to the
harddrive. I don't understand why would peopel prefer to search issues in web
browser, if they can do it faster in Emacs. We just need better interface.

>> What about automating it for them?
>> 
>> Is this too wild: when someone signs FSF copyrights assignement, create
>> automatic "development mail account", which will work only to send and 
>> recieve
>> emails between certain addresses, the person and those used for Emacs
>> devs? We could then write a small pacakge to auto-setup persons account in
>> his/her Emacs that would work for bug repporting, debbugs, sending patches 
>> etc.
>> 
>> Limitiation because I guess FSF/GNU does not have resources to host free 
>> email
>> accounts for everyone.
>
> You mean, set up email account on GNU servers?  That's problematic in
> more than one sense, some of which you mention above.
>
> And what would be the advantages?

The advantage would be that we could have a package in Emacs that sets
everythign up for making it easy for newcomers to contribute so they don't need
to bother with setuing up mail to work with emacs. We could also possibly create
more github/gitlab similar workflow in emacs directly if people could
participate in email-based workflow out of the box so to say. It is lots of
"could" I am aware of.

>> We could then abstract parts of PR based worklfow on top of email.
>
> For people who are familiar with, and used to, the PR workflow using
> Web forms, I don't think this would be an advantage.  The main purpose
> of moving to a service we are discussing is to provide a familiar UI
> to those contributors, with a special emphasis on occasional
> contributors who don't have time, or don't want, to learn a new UI
> just to contribute to Emacs.

Yes, but sh does not look familiar to people who are using github or gitlab. The
risk is also, that you may invest a lot of time, just to find that people are
still opposing because they are taken outside their common environment, required
to create account on new service, adapt to different workflow etc.

Unique selling point of Emacs is integration. I mean, I don't need to leave
Emacs to contribute to Emacs at all. I use same shortcuts for everything, same
familiar interface etc. That's Emacs strength.

Some people are not familiar with the concept, but it can be simplified. Maybe
we need to work better on emphasizing Emacs strengths and help people to use
emacs more effectively.