From mboxrd@z Thu Jan 1 00:00:00 1970 From: ludo@gnu.org (Ludovic =?utf-8?Q?Court=C3=A8s?=) Subject: Re: Tracking package submissions with Debbugs Date: Wed, 07 Sep 2016 22:38:32 +0200 Message-ID: <8760q7la2f.fsf@gnu.org> References: <874m6kbyg4.fsf@gmail.com> <57B5A049.6070206@goebel-consult.de> <87wpiwruyd.fsf@we.make.ritual.n0.is> <87inuf27h7.fsf@we.make.ritual.n0.is> <20160902002755.GA30382@jocasta.intra> <87vayfm821.fsf@we.make.ritual.n0.is> <8737liam03.fsf@gmail.com> <87fupimq6n.fsf_-_@gnu.org> <20160903210030.GE4019@macbook42.flashner.co.il> <87bn041jch.fsf@gmail.com> <20160904070509.GA1724@solar> <87oa43zjqa.fsf@we.make.ritual.n0.is> <87inubzjjq.fsf@we.make.ritual.n0.is> <87fupe5x1c.fsf@gmail.com> <8760qaxfkn.fsf@gnu.org> <87r38yszzi.fsf@we.make.ritual.n0.is> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Return-path: Received: from eggs.gnu.org ([2001:4830:134:3::10]:42807) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bhjcI-0004D7-9g for guix-devel@gnu.org; Wed, 07 Sep 2016 16:38:43 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1bhjcD-0003aT-Ak for guix-devel@gnu.org; Wed, 07 Sep 2016 16:38:41 -0400 In-Reply-To: <87r38yszzi.fsf@we.make.ritual.n0.is> (ng0@we.make.ritual.n0.is's message of "Mon, 05 Sep 2016 23:12:17 +0000") List-Id: "Development of GNU Guix and the GNU System distribution." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: guix-devel-bounces+gcggd-guix-devel=m.gmane.org@gnu.org Sender: "Guix-devel" To: ng0 Cc: guix-devel , Alex Kost ng0 skribis: > David Craven writes: > >>> 1. Our commit history is not full of merges of tiny branches, which is >>> what GitHub (and I thought Gitlab) encourages. >> >> Yes, that is right. But as I mentioned in a different thread, there >> are many projects where the maintainers agree to not use the merge >> button because of this. Since we are using gitlab we can actually go >> further than an agreement and disable the merge button entirely. >> >>> 2. Contributors can revise their patch series (by rewriting history of >>> that series), and committers can incorporate the final patch set, >>> rather than the whole sequence of iterations. This is what we >>> currently do; Gitlab should be able to recognize such patterns and >>> notice that the =E2=80=9Cmerge request=E2=80=9D can be closed, for= instance. >> >> It depends on how much modification the maintainers make before >> pushing. It's git that has to recognize the commits as being the same. >> If a contributor can rebase his branch after the PR was merged without >> getting any conflicts, gitlab will also recognize that the PR was >> merged. Since it's a lot easier to iterate without spamming the >> mailing list we can in practice ask contributors to fix issues like >> indentation themselves, and if the worst case happens, PR can be >> closed manually (in the web interface). >> >>> 3. People (especially, ahem, me!) can work from the comfort of their >>> favorite editor/terminal, or at least without having to run lots of >>> JS code and clicking around all day long. >> >> That's what we all want. The only time it's required to use the web >> interface is when creating a new issue or a new PR. After that you can >> reply via email, rebase and push via git. >> >>> I haven=E2=80=99t used Gitlab so I don=E2=80=99t know whether these req= uirements are >>> satisfied. If you set up an instance of Gitlab-free-software-edition >>> and we do not have these problems, I=E2=80=99m happy! :-) >> >> Some adjustments to the workflow might have to be made, but I think we >> have to give it a test run of at least a week or two before throwing >> the towel ;-) Sure. Thanks David for clarifying. >> Who wants to take on this? Any volunteers? > > How would we proceed with this? One of us sets up a gitlab instance on a > server under their control? > I could volunteer for a test run. Fine with me! Ludo=E2=80=99.