From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 29821 invoked by alias); 22 Apr 2014 15:40:21 -0000 Mailing-List: contact gdb-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-owner@sourceware.org Received: (qmail 29810 invoked by uid 89); 22 Apr 2014 15:40:21 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=4.2 required=5.0 tests=AWL,BAYES_20,FREEMAIL_FROM,RCVD_IN_DNSWL_LOW,SPAM_BODY1,SPF_PASS autolearn=no version=3.3.2 X-HELO: mail-qa0-f44.google.com Received: from mail-qa0-f44.google.com (HELO mail-qa0-f44.google.com) (209.85.216.44) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES128-SHA encrypted) ESMTPS; Tue, 22 Apr 2014 15:40:20 +0000 Received: by mail-qa0-f44.google.com with SMTP id hw13so5267939qab.31 for ; Tue, 22 Apr 2014 08:40:18 -0700 (PDT) MIME-Version: 1.0 X-Received: by 10.140.16.198 with SMTP id 64mr52923699qgb.10.1398181217976; Tue, 22 Apr 2014 08:40:17 -0700 (PDT) Received: by 10.140.92.41 with HTTP; Tue, 22 Apr 2014 08:40:17 -0700 (PDT) In-Reply-To: <20140422130652.GG5790@adacore.com> References: <20140402100842.GA956@blade.nx> <533F3713.40700@earthlink.net> <20140417135040.GA891@blade.nx> <20140422130652.GG5790@adacore.com> Date: Tue, 22 Apr 2014 15:51:00 -0000 Message-ID: Subject: Re: Patchwork patch tracking system From: Eric Christopher To: Joel Brobecker Cc: Gary Benson , Stan Shebs , "gdb@sourceware.org" Content-Type: text/plain; charset=UTF-8 X-IsSubscribed: yes X-SW-Source: 2014-04/txt/msg00074.txt.bz2 On Tue, Apr 22, 2014 at 6:06 AM, Joel Brobecker wrote: >> > So if we try it and like it, how does one go about transitioning >> > from "trial" to "real"? >> >> I guess by the people doing the reviewing deciding to use it. >> It may be it is useful even with only a subset of reviewers >> using it. I can't determine this myself, I need feedback from >> people who are reviewing regularly. > > In my opinion, the GDB project is in dire need of a way to track > patches. Using one's mailbox to track patches just does not work. > But I think that we would need full commitment to the tool from > the project, or else it'd quickly start overflowing with stale > info. > > There is a tool that we use internally at AdaCore which I was starting > to think of proposing for GDB, called geritt. From what I have been > able to see from patchwork's webpage, geritt seems like a much more > advanced system compared to patchwork. But the tradeoff is that using > geritt requires a bit more work as well, and that part or all of > the review process would happen on geritt, rather than the mailing-list. > It's not very intuitive at first, but it is very easy and lightweight. > > I personally believe geritt's approach to be better in the long run. > But, while I am worried about having communication and patch handling > be done via two distinct systems, patchwork's simpler approach might be > working well enough without requiring the big shift in patch-reviewing > paradigm. > FWIW we (some of the google folk) looked at geritt for LLVM and discarded in favor of phabricator. It seemed to solve a lot of the problems that we had and allowed communication to and from the mailing lists for patches which was key for us as we have a similar review style to gcc/gdb/binutils. We didn't want to remove the ability for people to send patches to the mailing lists, but yet get a better review mechanism for large patches/queuing/etc. Just piping in since we recently did some of this work. Feel free to let me know if you have any questions on our experiences. -eric