From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Max Nikulin Newsgroups: gmane.emacs.devel Subject: Re: Why not set Emacs development workflow based on the popular git forges (GitHub, Bitbucket, Gitlab, ect)? Date: Mon, 20 Sep 2021 00:01:41 +0700 Message-ID: References: <87v93gfusa.fsf@yahoo.com> <87y28ctpuo.fsf@gmail.com> <87fsufq0ya.fsf@yahoo.com> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="27892"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.13.0 To: emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Sun Sep 19 19:04:55 2021 Return-path: Envelope-to: ged-emacs-devel@m.gmane-mx.org Original-Received: from lists.gnu.org ([209.51.188.17]) by ciao.gmane.io with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1mS0FJ-0006xb-HK for ged-emacs-devel@m.gmane-mx.org; Sun, 19 Sep 2021 19:04:53 +0200 Original-Received: from localhost ([::1]:53352 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1mS0FG-0000WP-Hn for ged-emacs-devel@m.gmane-mx.org; Sun, 19 Sep 2021 13:04:50 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:46534) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1mS0Ca-0006aa-Gm for emacs-devel@gnu.org; Sun, 19 Sep 2021 13:02:05 -0400 Original-Received: from ciao.gmane.io ([116.202.254.214]:55006) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1mS0CW-0007PT-JU for emacs-devel@gnu.org; Sun, 19 Sep 2021 13:02:03 -0400 Original-Received: from list by ciao.gmane.io with local (Exim 4.92) (envelope-from ) id 1mS0CS-0003TO-IP for emacs-devel@gnu.org; Sun, 19 Sep 2021 19:01:56 +0200 X-Injected-Via-Gmane: http://gmane.org/ In-Reply-To: Content-Language: en-US Received-SPF: pass client-ip=116.202.254.214; envelope-from=ged-emacs-devel@m.gmane-mx.org; helo=ciao.gmane.io X-Spam_score_int: 28 X-Spam_score: 2.8 X-Spam_bar: ++ X-Spam_report: (2.8 / 5.0 requ) BAYES_00=-1.9, DKIM_ADSP_CUSTOM_MED=0.001, FORGED_GMAIL_RCVD=1, FORGED_MUA_MOZILLA=2.309, FREEMAIL_FORGED_FROMDOMAIN=0.249, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.25, NICE_REPLY_A=-0.001, NML_ADSP_CUSTOM_MED=0.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001 autolearn=no autolearn_force=no X-Spam_action: no action X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.23 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-mx.org@gnu.org Original-Sender: "Emacs-devel" Xref: news.gmane.io gmane.emacs.devel:275065 Archived-At: On 17/09/2021 04:03, chad wrote: > This is a small thing, but: > > On Thu, Sep 16, 2021 at 10:25 AM Max Nikulin wrote: > >  My opinion is the following: > [...] > - The reason why current web UIs are not sufficient for Linux kernel >    is not applicable for Emacs. There are a lot of independent groups >    involved into kernel development while Emacs does not have such >    fragmentation so flexibility in respect to groups is unnecessary. > > I suspect that people who think this have never tried to follow, for > example, gnus, CEDET, or org development as part(s) of GNU emacs. These > are more common in the Linux kernel, but the core motivations exist in > both projects, and it would be great to have improvements even if they > aren't adopted by both. Is it frequent enough case that some feature requires synchronous changes in Emacs core and Org (similar to changes in drivers and subsystems of Linux kernel)? If not, projects may be considered rather independent. Some linux drivers are independent to some degree as well, however changes in some kernel subsystem may require support of several versions of driver with different ranges of compatible kernel versions. Sometimes fixes in Org are necessary in response to changes in Emacs to avoid compiler warnings. On the other hand Org still declares compatibility with Emacs-24.3 that, in my opinion, means quire loose coupling. If tight collaboration is required only in rare cases, cost of tracking of bug/feature in an "external" project is not significant. It is not unusual when developers from one project to interact with developers of e.g. completely independent library. Some tools may be handy though, e.g. bugs.launchpad.net subscribes to external bug trackers to show discussion as comments to "local" issue. I have an example of change in Emacs that can make Org better. Several hundred of markers severely slows down regexp searches in the buffer (at least in Emacs-26.3). Org may cache e.g. heading positions using markers. Improving handling of markers in Emacs will make Org more responsive. No action on the Org side is required though (besides a bug report). It just will work faster with new Emacs versions than with older ones. I believe, it is great that each project (Emacs, Org mode) can have own pace of development making requirements for development tools not so strict.