From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Tim Cross Newsgroups: gmane.emacs.devel Subject: Re: Why not set Emacs development workflow based on the popular git forges (GitHub, Bitbucket, Gitlab, ect)? Date: Thu, 09 Sep 2021 08:49:11 +1000 Message-ID: <87a6kmfz8n.fsf@gmail.com> References: <87v93gfusa.fsf@yahoo.com> <87y28ctpuo.fsf@gmail.com> <87fsufq0ya.fsf@yahoo.com> Mime-Version: 1.0 Content-Type: text/plain Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="19854"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: mu4e 1.7.0; emacs 27.2.50 To: emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Thu Sep 09 01:02:35 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 1mO6aQ-0004zi-DE for ged-emacs-devel@m.gmane-mx.org; Thu, 09 Sep 2021 01:02:34 +0200 Original-Received: from localhost ([::1]:44064 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1mO6aO-00039v-Us for ged-emacs-devel@m.gmane-mx.org; Wed, 08 Sep 2021 19:02:32 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:33636) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1mO6Zj-0002B0-9g for emacs-devel@gnu.org; Wed, 08 Sep 2021 19:01:51 -0400 Original-Received: from mail-pf1-x430.google.com ([2607:f8b0:4864:20::430]:46941) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1mO6Zh-00075K-KF for emacs-devel@gnu.org; Wed, 08 Sep 2021 19:01:51 -0400 Original-Received: by mail-pf1-x430.google.com with SMTP id y17so25336pfl.13 for ; Wed, 08 Sep 2021 16:01:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=references:user-agent:from:to:subject:date:in-reply-to:message-id :mime-version; bh=imyqwHVEDnL6VKSKDOLPIbfTpBAJvCVbWj2Xy67D83A=; b=Bf2COTY7qEAmhBmeR4QSRJamrUAYqRLGlH3yhAGO5A2dIAXNwdj6pCmeaGzGPqtFGJ +FZziwjUYxIXAIHo1Pq2b3hlgCd/oplAk5KtckCqPwI/oNUCh5pTo4lRIy42mLrjCSJs EYbZgqb/1NVAyUo05srdYzrZrc1EdkyFCFBsUg4qw+8Ozm1W8XGj0belbboo+9HZn/Qf qzWRyn25jit6dSt9ypv18qx/0Upp+pPwuQSF/IlVVXuzpeT0BC3/tFVimjnIYt/WzmXm 4ncFuLpC3zskhVOFUfdA0JPcTvIqDcb24M0cigJJLv3IhO7nQ4DVTKcDNuP3dF7rxIQU jyEg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:references:user-agent:from:to:subject:date :in-reply-to:message-id:mime-version; bh=imyqwHVEDnL6VKSKDOLPIbfTpBAJvCVbWj2Xy67D83A=; b=dqkA+MW2U2xKFpgOYzIzH0sqREebuiUk7VU36yULd/CXI25nzy6PwPz8WAJpv09VyQ c+QcMiX0y2nDrgRjbQ+a7zdcQkR6Pd/8fkDYbTtXWHWsos8twfBrStGYQs5DJFaqubsP kXqZ1JKqLTBghw+sg0hTsvqyUNkxvxkk5gOLM3eKecbdOdD1KsHQpHO9m9Lnv1C1c3ym Iw+9Jnm5eVG18EsLEgwG90w+UlKhdahREGAIdHOvCpB+979Zz8l5aJAxv2Km8ES4zbVZ eItNavRvp3XK5LzCyF3NMhFQ6ppy3tiD8u3cZx6lKWC769C+zF1ySDVxli0IJBu3q0/n //MQ== X-Gm-Message-State: AOAM531hD7lQwy5rOiTWdZBvRXVpPRY2E7+bLVBJABdpv+zGPnZPMrhl uPEIkfeOa4YRQR4Nzopq6HlyOiQLNHA= X-Google-Smtp-Source: ABdhPJw77sBLQ5g+RJ3ER3zERWv7MBN+J2fEQ5A5JtoH3lmS+2CiDs9B4NXj4n8mFqUDpqsOxus3kg== X-Received: by 2002:a63:dc03:: with SMTP id s3mr515094pgg.88.1631142107737; Wed, 08 Sep 2021 16:01:47 -0700 (PDT) Original-Received: from tim-desktop (106-69-132-138.dyn.iinet.net.au. [106.69.132.138]) by smtp.gmail.com with ESMTPSA id b20sm233417pfo.3.2021.09.08.16.01.46 for (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 08 Sep 2021 16:01:47 -0700 (PDT) In-reply-to: Received-SPF: pass client-ip=2607:f8b0:4864:20::430; envelope-from=theophilusx@gmail.com; helo=mail-pf1-x430.google.com X-Spam_score_int: -20 X-Spam_score: -2.1 X-Spam_bar: -- X-Spam_report: (-2.1 / 5.0 requ) BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001 autolearn=ham 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:274398 Archived-At: Max Nikulin writes: > On 08/09/2021 09:02, Po Lu wrote: >> Max Nikulin writes: >> >>> There is a technical reason why github is not suitable for Linux >>> kernel (and it is hardly to applicable to Emacs): it is impossible to >>> coordinate several groups of developers responsible for different >>> subsystems using github flavor of pull requests and bugs. For email it >>> is simply several Cc addresses: >> Why do you believe that is not applicable to Emacs? Similar to the >> Linux kernel, Emacs is a large project with many subsystems that stretch >> across a great amount of expertise domains. > > Sorry, I forgot that Emacs is a kind of OS, so it requires equal treatment. > > More seriously, it is no more than my impression, so I admit, it may be wrong. > > Let's leave aside web UI vs. email aspect and concentrate on joining groups and > moving discussion or bug to another group feature. > > Judging from > > git log --since 2020-09-01 --pretty="format:%an" \ > | sort | uniq -c | sort -n > > number of really active authors (and committers, %cn) is not so high (25 > developers with more than 20 commits). Development of kernel is much > more active and splitting into groups is mission critical otherwise noise for > each person would be too high. > > Does Emacs have many mail lists dedicated to *development* of subsystems (in > other words, are there several apparent groups working on the same repository)? > Traffic in emacs-devel is high enough (roughly 1500 messages per month) however > I am unsure that it is possible to split into several mail lists with more > narrow subjects. > > I do not say that discussion never moves from one group to another. E.g. > recently cause of Org mode related problem was traced down to native > compilation bug. Tight collaboration of two groups was not necessary however. > Ability to just add "Cc" is convenient but while such events are not frequent > above, cost of separate tracking and discussions is acceptable. > > There are no defined criteria when it is better to split development into > relatively independent groups. Till such groups appear the feature of > coordination is not really important. (Features necessary for Emacs developers > are highlighted in sibling threads.) I think the discussion sort of got off track from where it started. This was all kicked off by an observation that the current workflows may not be sufficiently familiar/clear for new contributors or that they discourage contributions from new contributors rather than with any perceived problem with workflows once a submission has been made. My impression is that the 20+ people who actually do all the work of reviewing and merging contributed patches are quite happy (in the main) with the current workflow. To be proposing a whole new workflow just to facilitate the first step i.e. contributing a patch, seems to be a little too much and feels like it cold run the risk of throwing the baby out with the bathwater. Perhaps the answer is to look at how things can be structured to make it easier for people to submit quality patches (patches with sufficient documentation, test cases, correct formatting etc) while minimising disruption to the rest of the workflow rather than wholesale re-engineering of the total process.