From mboxrd@z Thu Jan 1 00:00:00 1970 From: David Craven Subject: Re: Tracking package submissions with Debbugs Date: Mon, 5 Sep 2016 22:39:11 +0200 Message-ID: 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> 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]:47071) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bh0fu-0004A8-7W for guix-devel@gnu.org; Mon, 05 Sep 2016 16:39:32 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1bh0fi-0004PE-OL for guix-devel@gnu.org; Mon, 05 Sep 2016 16:39:25 -0400 Received: from mail-yb0-x234.google.com ([2607:f8b0:4002:c09::234]:35439) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bh0fh-0004OI-HG for guix-devel@gnu.org; Mon, 05 Sep 2016 16:39:14 -0400 Received: by mail-yb0-x234.google.com with SMTP id g5so702344yba.2 for ; Mon, 05 Sep 2016 13:39:12 -0700 (PDT) In-Reply-To: <8760qaxfkn.fsf@gnu.org> 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: =?UTF-8?Q?Ludovic_Court=C3=A8s?= Cc: guix-devel , Alex Kost > 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 i= nstance. 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 requi= rements 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 ;-) Who wants to take on this? Any volunteers?