From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Alexander Adolf Newsgroups: gmane.emacs.devel Subject: Re: Gitlab Migration Date: Thu, 02 Sep 2021 13:06:32 +0200 Message-ID: References: <83v93srwsp.fsf@gnu.org> <0ce705ec-3ee1-61fa-c8b8-9864e6e2a65a@yandex.ru> <83pmu0rvp8.fsf@gnu.org> <87sfywc7y3.fsf@dick> Mime-Version: 1.0 Content-Type: text/plain Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="39782"; mail-complaints-to="usenet@ciao.gmane.io" Cc: Dmitry Gutov , danflscr@gmail.com, emacs-devel@gnu.org To: dick , Eli Zaretskii Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Thu Sep 02 13:24:32 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 1mLkpb-000ACh-P1 for ged-emacs-devel@m.gmane-mx.org; Thu, 02 Sep 2021 13:24:31 +0200 Original-Received: from localhost ([::1]:41230 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1mLkpZ-0006Yj-Os for ged-emacs-devel@m.gmane-mx.org; Thu, 02 Sep 2021 07:24:29 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:44110) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1mLkYI-0003Nc-G5 for emacs-devel@gnu.org; Thu, 02 Sep 2021 07:06:38 -0400 Original-Received: from smtprelay04.ispgateway.de ([80.67.18.16]:12865) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1mLkYG-0006EP-D3; Thu, 02 Sep 2021 07:06:38 -0400 Original-Received: from [46.244.213.143] (helo=condition-alpha.com) by smtprelay04.ispgateway.de with esmtpsa (TLS1.2) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1mLkVz-00046y-6A; Thu, 02 Sep 2021 13:04:15 +0200 In-Reply-To: <87sfywc7y3.fsf@dick> X-Df-Sender: YWxleGFuZGVyLmFkb2xmQGNvbmRpdGlvbi1hbHBoYS5jb20= Received-SPF: pass client-ip=80.67.18.16; envelope-from=alexander.adolf@condition-alpha.com; helo=smtprelay04.ispgateway.de X-Spam_score_int: -18 X-Spam_score: -1.9 X-Spam_bar: - X-Spam_report: (-1.9 / 5.0 requ) BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_PASS=-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:273700 Archived-At: dick writes: > * Newcomer suggests PR-based workflow citing youth. Check. > > * Veterans chime in, citing the obvious reasons-for and the > political reasons-against. Check. > > * EZ cites his *sui generis* argument that a web-based workflow is actually > *more* work than mailing patches around. Check. > > * Someone announces his intention to begin the necessary work. Check. > > * Someone remarks how discussion on emacs-devel repeats itself. Now checked. Nice. Thanks for the laugh! But back to serious business. This is a long thread (297 on m y machine at the time of this writing), and - in all honesty - that's not entirely unexpected. There is merit in both, keeping long-timers happy, and in lowering the perceived entry barriers for potential new contributors. I would assume that the smallest common denominator, which we all can agree to, would be: "must not alienate/deter neither long-timers, nor newbies". Thus, the magic words would seem to be "backwards compatibility", and "migration path". "backwards compatibility" := Everything that works via email now, must equally work via email with the new system. "migration path" := It must be possible to try out one function on the new system, whilst still using all other functions via email. If the new system has more functions, or makes some things easier, then there could even be an incentive for the long-timers to look into the new system. Finally, a remark on issue/bug tracking. I have used a great many trackers, and debbugs and Bugzilla stand out from the crowd. By a huge margin. The differentiating feature is blocks/depends-on. Many issue trackers (including those in the various git hosting platforms) lack this feature altogether. Those trackers who have it, often provide a limited flavour, e.g. limiting it to one level (i.e. a bug that blocks another bug, can itself not be blocked by other bugs), or make it awkward to use (e.g. you have to create a new bug as a subtask of an existing one, and existing bugs cannot be made into subtasks any more once created). Hence my plea: debbugs ought to remain part of whatever any new system might be. Just my two cents anyway. Many thanks and looking forward to your thoughts, --alex