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: Mon, 05 Sep 2016 22:22:00 +0200 Message-ID: <8760qaxfkn.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> 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]:42422) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bh0PA-00080O-6K for guix-devel@gnu.org; Mon, 05 Sep 2016 16:22:09 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1bh0P5-0000pB-Vv for guix-devel@gnu.org; Mon, 05 Sep 2016 16:22:07 -0400 In-Reply-To: <87fupe5x1c.fsf@gmail.com> (Alex Kost's message of "Mon, 05 Sep 2016 15:52:15 +0300") 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: Alex Kost Cc: guix-devel Hello! Alex Kost skribis: > David Craven (2016-09-04 20:09 +0300) wrote: > >> Why is the gitlab not including the rebase feature a deal breaker? > > I'm wondering too. > >> It's open source, so disabling the merge button in the ui isn't a big >> deal. We can continue using git push like we've been doing so far... > > I also don't see a problem, it's just a missing button in the web > interface, and it doesn't prevent us from using "git rebase" or whatever > is needed to adjust a patch before pushing it to the guix repo. What I would like to ensure is that: 1. Our commit history is not full of merges of tiny branches, which is what GitHub (and I thought Gitlab) encourages. 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 ins= tance. 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. I haven=E2=80=99t used Gitlab so I don=E2=80=99t know whether these require= ments 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! :-) Ludo=E2=80=99.