From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Philip Kaludercic Newsgroups: gmane.emacs.devel Subject: Re: Gitlab Migration Date: Fri, 27 Aug 2021 20:58:01 +0000 Message-ID: <87pmty1u7a.fsf@posteo.net> References: <87h7fcnmq0.fsf@posteo.net> <83tujbqg4j.fsf@gnu.org> <874kbbosht.fsf@gnus.org> <8335qur9h7.fsf@gnu.org> <831r6er6rz.fsf@gnu.org> Mime-Version: 1.0 Content-Type: text/plain Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="39118"; mail-complaints-to="usenet@ciao.gmane.io" Cc: danflscr@gmail.com, Theodor Thornhill , emacs-devel@gnu.org, monnier@iro.umontreal.ca, larsi@gnus.org, sir@cmpwn.com To: Eli Zaretskii Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Fri Aug 27 22:58:59 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 1mJiwD-0009ws-7p for ged-emacs-devel@m.gmane-mx.org; Fri, 27 Aug 2021 22:58:57 +0200 Original-Received: from localhost ([::1]:38130 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1mJiwB-0003yp-BT for ged-emacs-devel@m.gmane-mx.org; Fri, 27 Aug 2021 16:58:55 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:58152) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1mJivU-0003ID-Nc for emacs-devel@gnu.org; Fri, 27 Aug 2021 16:58:12 -0400 Original-Received: from mout02.posteo.de ([185.67.36.66]:38847) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1mJivO-0006Kf-UE for emacs-devel@gnu.org; Fri, 27 Aug 2021 16:58:12 -0400 Original-Received: from submission (posteo.de [89.146.220.130]) by mout02.posteo.de (Postfix) with ESMTPS id 4AF0D240103 for ; Fri, 27 Aug 2021 22:58:04 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=posteo.net; s=2017; t=1630097884; bh=C6a8duktQPcHtDSbkVgz3XXSYFhtdAVFJ+PQv6BOWSY=; h=From:To:Cc:Subject:Autocrypt:Date:From; b=rk+iG6xl2Rj/r87eUk81iAuCIjC5yYCtVCV2+DmxeNbuJfQuUPCDAhW4sNQF7nMqV kG0oIzU2E6MhSP0U98WgG6xmCK17t4CDz5hF1FdOYzFjCcHTbFjme9gkQWnBbUPrcR ciXMvpNZsu47UcpxORLM1Fd4t5N1JWDB153jVl/bB+hWKJWbJtWueYz+BEyBY7fWS4 H60bJZhwWijZmDZKz/qiCq/JIgprC2MO4DpA1qx4sr6L8NSwamGk7OOoGTFNGp/Y6Y +/40DmNay5Y91Gk303qf0e2kNZ2uwvzz1MWt1YYB/UGnh9O1yc7SNq4LmGsGrsFcn5 CYDezX1v7lBAg== Original-Received: from customer (localhost [127.0.0.1]) by submission (posteo.de) with ESMTPSA id 4GxBrB62yhz9rxB; Fri, 27 Aug 2021 22:58:02 +0200 (CEST) Autocrypt: addr=philipk@posteo.net; prefer-encrypt=mutual; keydata= mDMEYHHqUhYJKwYBBAHaRw8BAQdAp3GdmYJ6tm5McweY6dEvIYIiry+Oz9rU4MH6NHWK0Ee0QlBo aWxpcCBLYWx1ZGVyY2ljIChnZW5lcmF0ZWQgYnkgYXV0b2NyeXB0LmVsKSA8cGhpbGlwa0Bwb3N0 ZW8ubmV0PoiQBBMWCAA4FiEEDM2H44ZoPt9Ms0eHtVrAHPRh1FwFAmBx6lICGwMFCwkIBwIGFQoJ CAsCBBYCAwECHgECF4AACgkQtVrAHPRh1FyTkgEAjlbGPxFchvMbxzAES3r8QLuZgCxeAXunM9gh io0ePtUBALVhh9G6wIoZhl0gUCbQpoN/UJHI08Gm1qDob5zDxnIHuDgEYHHqUhIKKwYBBAGXVQEF AQEHQNcRB+MUimTMqoxxMMUERpOR+Q4b1KgncDZkhrO2ql1tAwEIB4h4BBgWCAAgFiEEDM2H44Zo Pt9Ms0eHtVrAHPRh1FwFAmBx6lICGwwACgkQtVrAHPRh1Fw1JwD/Qo7kvtib8jy7puyWrSv0MeTS g8qIxgoRWJE/KKdkCLEA/jb9b9/g8nnX+UcwHf/4VfKsjExlnND3FrBviXUW6NcB In-Reply-To: <831r6er6rz.fsf@gnu.org> (Eli Zaretskii's message of "Fri, 27 Aug 2021 23:07:12 +0300") Received-SPF: pass client-ip=185.67.36.66; envelope-from=philipk@posteo.net; helo=mout02.posteo.de X-Spam_score_int: -43 X-Spam_score: -4.4 X-Spam_bar: ---- X-Spam_report: (-4.4 / 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, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001 autolearn=unavailable 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:273181 Archived-At: Eli Zaretskii writes: >> From: Theodor Thornhill >> Cc: emacs-devel@gnu.org, larsi@gnus.org, monnier@iro.umontreal.ca, >> danflscr@gmail.com, philipk@posteo.net, sir@cmpwn.com >> Date: Fri, 27 Aug 2021 21:38:43 +0200 >> >> >> https://lists.gnu.org/archive/html/emacs-devel/2020-09/msg00534.html >> > >> > That was almost a year ago, and the discussion is thin on actual >> > details. Support for email-based workflow is a good start, and is one >> > of the main requirements, but what about the GitLab/Github-like >> > features? if they are missing or incomplete, we will be trading >> > debbugs for something that is basically the same beast in a different >> > wrapping. And what about the other requirements we collected and >> > documented in the GitLab issue about this? >> > >> >> It seems like Sourcehut supports everything requested, but I might be >> missing something, of course. In particular the CI is very nice and >> simple, at least for the hosted version at https://sr.ht. It also >> supports running without javascript at all, so the libreJS debate should >> be settled right there. Instead of me speaking on sourcehuts behalf, >> with which I have no affiliation outside of being a happy customer >> myself, I'll ping the creator. > > Would it be possible to have a more detailed review, like short > description of what is available for each of the requirements in the > GitLab issue? That should give us a good idea of how close we are to > the goal. Here is my take: + Email workflow Is supported as a first-class interaction method + Reduce email noise The mailing lists are just mailing lists, from what I know the only "spam" might be CI responding with the results of a test + Submitting patches by email Is supported as part of the email workflow + Offline review Same as above + Reviewing patches by email Ditto, and the comments are rendered properly in the web UI. * Merge request creation Not sure if this is applicable, you'd usually just send a patch and not create a format "merge request". * Code should be accompanied by documentation Here too I cannot say for sure, but I can imagine integrating checkdoc into a CI that automatically warns a patch-submitter if something isn't documented properly. * Formatting code commits Same as above. * Traceability of Merge Requests Again, merge requests are not formal but just a message on the mailing list, usually generated by git send-email. (There might be an issue here if users just attach patches as they do now.) + Continuous integration Is given ? Closely integrated bugtracker I haven't used "todo" (the issue tracker, https://man.sr.ht/todo.sr.ht/) enough to really comment on this. My general understanding is that this, integration between the different components, is one of the things that remain in need of improvement before the project leaves the beta stage * Spell & grammar checking Again, could be done with CIs. Assuming one has a grammar checker. - Branch rules I don't know of any mechanism to limit access to branches. * Copyright assignments CI should be able to handle this. + Licensing Yes! - Integration with savannah Is not implemented, but the question is if the existing infrastructure should be extended or replaced. - Integration with debbugs Same as above. - Emacs frontend for bug tracker There is no package for sourcehut comparable to debbugs, but it shouldn't be hard to implement considering that. + Bug reporting The mailing list should be able to handle bugs M-x report-emacs-bug. > I tried to find answers to those questions myself, but there doesn't > seem to be any detailed documentation that describes the setup and > usage from the routine user POV (or maybe I missed it?). I did find a > heads-up that "from the beta onwards, unpaid accounts will be limited > to read-only access to their own projects", so I wonder what that > means for us. It also says that "web-based workflow for submitting > and reviewing patches" is still under development. It shouldn't mean anything, if GNU decides to host their own instance. Otherwise, every project member would have to play to have an account, but I assume mailing list contributors could continue accessing the mailing list without any issue. -- Philip Kaludercic