From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED.blaine.gmane.org!not-for-mail From: Eli Zaretskii Newsgroups: gmane.emacs.devel Subject: Re: [RFE] Migration to gitlab Date: Fri, 10 May 2019 23:43:09 +0300 Message-ID: <83woiydorm.fsf@gnu.org> References: <1552789070.5272.1@yandex.ru> <87imwhmmt8.fsf@gmail.com> <87y347g1l3.fsf@iotcl.com> <9ac21e82-8e47-f9b5-f88d-23c0c56946d1@yandex.ru> <87pnpc1lby.fsf@iotcl.com> <83zhoezdqc.fsf@gnu.org> <87imuivfcr.fsf@iotcl.com> <83k1eyfxls.fsf@gnu.org> <3b8e2195-07c0-a240-6164-8d34bcca344f@yandex.ru> <83ftpmfp0y.fsf@gnu.org> <838svefl3p.fsf@gnu.org> <658fcd11-dfad-2060-c84b-5da938d506b7@yandex.ru> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Injection-Info: blaine.gmane.org; posting-host="blaine.gmane.org:195.159.176.226"; logging-data="65198"; mail-complaints-to="usenet@blaine.gmane.org" Cc: toon@iotcl.com, monnier@iro.umontreal.ca, agrambot@gmail.com, emacs-devel@gnu.org To: Dmitry Gutov Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Fri May 10 22:43:57 2019 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([209.51.188.17]) by blaine.gmane.org with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:256) (Exim 4.89) (envelope-from ) id 1hPCN3-000Gl1-0m for ged-emacs-devel@m.gmane.org; Fri, 10 May 2019 22:43:57 +0200 Original-Received: from localhost ([127.0.0.1]:49664 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1hPCN1-0004Iq-Ia for ged-emacs-devel@m.gmane.org; Fri, 10 May 2019 16:43:55 -0400 Original-Received: from eggs.gnu.org ([209.51.188.92]:40256) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1hPCMR-0004Ij-Lm for emacs-devel@gnu.org; Fri, 10 May 2019 16:43:22 -0400 Original-Received: from fencepost.gnu.org ([2001:470:142:3::e]:54267) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1hPCMO-0007Ag-Et; Fri, 10 May 2019 16:43:16 -0400 Original-Received: from [176.228.60.248] (port=4825 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256) (Exim 4.82) (envelope-from ) id 1hPCMN-0003Va-QP; Fri, 10 May 2019 16:43:16 -0400 In-reply-to: <658fcd11-dfad-2060-c84b-5da938d506b7@yandex.ru> (message from Dmitry Gutov on Fri, 10 May 2019 19:33:56 +0300) X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.21 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Original-Sender: "Emacs-devel" Xref: news.gmane.org gmane.emacs.devel:236392 Archived-At: > Cc: toon@iotcl.com, emacs-devel@gnu.org, monnier@iro.umontreal.ca, > agrambot@gmail.com > From: Dmitry Gutov > Date: Fri, 10 May 2019 19:33:56 +0300 > > On 10.05.2019 17:19, Eli Zaretskii wrote: > > > Yes, my point was that having to work via a Web browser will need to > > switch frequently between it and Emacs. Which is an annoyance, to say > > the least. > > I can believe that, even if I don't really understand it. Let me try to explain. In any editing environment that is not Emacs I lack many features that make my work significantly more efficient. I miss the almost instant completion with M-/ (since I have the Emacs manuals and the TAGS tables loaded into Emacs at all times, all the symbols are instantly found, and I seldom if ever need to type long names like mark_window_display_accurate_1). I miss my abbrevs (which also allow me to fix some of my more frequent typos, or type stuff like "naïve" o "façade" without switching keyboard). I miss the convenience of being able to jump to any function/macro/typedef with just "C-u M-." (or even just M-. if I'm in a code buffer). I miss the multi-buffer search capabilities and Grep. I miss a more-or-less immediate access to the Git repository. I miss the capability to apply a patch which I'm looking at, and be able to compile the result right after that, right from the editor. And these are just the tools I use almost all the time. Instead, GitLab wants me to use the Web browser for most of these. This means the Web browser now becomes a very important program for me, I need to start learning it much more than I bothered until now, I need to keep it updated at all times, I need to customize it (more things to learn and try), etc. And after all that I still get an abysmally inadequate text editing widget, lacking most if not all of the features I mentioned above, while for tasks other than writing/editing text you ask me to switch between the browser and Emacs. That's a massive degradation of my quality of life. I wonder if I'm the only one here who feels that way. I mean, one of the more important advantages of Emacs is that it lets you do many things only tangentially related to editing program sources, and now we suddenly are willing to give that up? Really?? > Anyway, IIRC your current stance on that issue is that we'll need an > Emacs-based client anyway, even just for the issues tracker. I don't have a "stance". My personal preference is to do as much as possible from within Emacs, certainly any significant text/source code editing related to Emacs maintenance. I would be very unhappy if forced instead to use a text-editing widget of a browser, and its rudimentary email capabilities. Two possible ways of working with an issue tracker that don't require me to switch from Emacs are: (1) email and (2) an Emacs front-end. Either one, or even a combination of them, will, for me, be much better than a pure Web UI. I'm very interested in hearing opinions of other core maintainers and developers. > >>> MR reassignments are important to just 2 people: the old and the new > >>> assignee, possibly just the latter. I certainly don't want to know > >>> about all the reassignments of all the issues. > >> > >> I don't know if I agree, but hopefully it can be configured this way. > > > > I hoped someone will explain how. No one did. > > If you log into EMBA (you might have to register first (*)) and navigate > to this page: https://emba.gnu.org/profile/notifications > > you will see two "notification level" dropdowns, one Global, and one for > 'emacs'. I think you can change either. > > Click on one of them and choose the last item: Custom. You will then be > able to choose the events to get notifications for. > > MR reassignments are in that list. I cannot see it, because I cannot log in. Are there only 2 possibilities: all or nothing? I do want to see reassignments to myself. > Here's also the same information on the API level: > https://docs.gitlab.com/ee/api/notification_settings.html Where is each value described? The names are not descriptive enough, and I couldn't find any details about them. Did I miss something? > Not sure if that list is exhaustive, or if there are emails we'd want to > configure off but cannot. That would, again, be something to ask the > GitLab developers for. If there's no more detailed documentation, I think we should ask them now what does exist and what is possible to have given some small effort. > >> If the email workflow is used, though, you can also do what I've seen > >> many people recommend to others who complained about excessive emails > >> here (or being Cc'd on discussions they do not want to read, which is > >> more of a problem, IMHO): set up email filters. Decent MUAs support that. > > > > Email filters are the last resort in my book. It would also be in > > yours, if you considered a possibility to work via email. > > But I already do, here. I never needed to set up any filters. Never. It sounds very wrong to me that I need to set up a filter to defend myself against my own project. > >> Whenever you feel like it, we can go ahead and experiment with the bug > >> tracker that's part of the EMBA installation. And see how far we can go > >> with email-only workflow, without an Emacs-based client. > > > > I don't think I understand what such an experiment would mean. Do you > > mean we will have to deal with each bug twice? And what would be the > > workflow in that case? can someone post some instructions? > > No, I'm suggesting to use it as a sandbox at first. Post some random > issues, close them, reopen them, write some comments, receive comments > from others, respond to them over email, etc, and see how well that > works, and what the main problems are. > > To post a new issue, you can navigate to > https://emba.gnu.org/emacs/emacs/issues and click "New issue". This also > requires registration (at least, for now (**)). I will try to find time for this, but it won't happen soon: there are several urgent tasks on my plate. Perhaps someone else could do that and post the experiences. Thanks.