From owner-freebsd-ports@FreeBSD.ORG Sat Jan 25 18:26:31 2014 Return-Path: Delivered-To: freebsd-ports@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 4536B8E0; Sat, 25 Jan 2014 18:26:31 +0000 (UTC) Received: from elvis.mu.org (elvis.mu.org [192.203.228.196]) by mx1.freebsd.org (Postfix) with ESMTP id C3A6B16F9; Sat, 25 Jan 2014 18:26:30 +0000 (UTC) Received: from Alfreds-MacBook-Pro-9.local (c-76-21-10-192.hsd1.ca.comcast.net [76.21.10.192]) by elvis.mu.org (Postfix) with ESMTPSA id A1F0E1A3C19; Sat, 25 Jan 2014 10:26:30 -0800 (PST) Message-ID: <52E401D6.8060908@freebsd.org> Date: Sat, 25 Jan 2014 10:26:30 -0800 From: Alfred Perlstein User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:24.0) Gecko/20100101 Thunderbird/24.2.0 MIME-Version: 1.0 To: Baptiste Daroussin Subject: Re: What is the problem with ports PR reaction delays? References: <52E2FA36.5080106@marino.st> <52E303CB.6020304@marino.st> <52E30990.2060903@marino.st> <52E33AA7.3080205@freebsd.org> <52E3719B.3040503@rawbw.com> <52E37C71.1060906@freebsd.org> <20140125175150.GB67191@ithaqua.etoilebsd.net> In-Reply-To: <20140125175150.GB67191@ithaqua.etoilebsd.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Yuri , freebsd-ports@FreeBSD.org X-BeenThere: freebsd-ports@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Porting software to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 25 Jan 2014 18:26:31 -0000 On 1/25/14 9:51 AM, Baptiste Daroussin wrote: > On Sat, Jan 25, 2014 at 12:57:21AM -0800, Alfred Perlstein wrote: >> On 1/25/14, 12:11 AM, Yuri wrote: >>> On 01/24/2014 20:16, Alfred Perlstein wrote: >>>> (maybe there is some great ports system that I'm not aware of that >>>> makes this all as easy github, but I somehow doubt that.) >>> github itself is closed source, but 95% of its functionality is based >>> on git which is open. One only needs to invoke 3-4 git operations to >>> support what it does on the website side. Register on the site, fork >>> the project under user's login, submit a pull request, merge a fork's >>> branch to the main branch. All these are basically git commands. >>> Without the glossiness of github, this is not that large of a project. >>> Submitters will do the rest through git. >>> >>> I think, instead of tediously going through the PRs by hand, it is >>> wiser to set up some system like this. >>> >> Agreed. +1000 >> >> Although if we go down the rabbit hole of building something "like >> github" that might take a while. For now prototyping using the github >> pull methods might be a good proof of concept. I may look into doing a >> github pull request -> GNATS (src) PR gateway if time allows. > Once again github pull request is the worst way of merging patches that exists. > > We already have problem with ugly and inaccurate logs, such pull request will > make it even worse. > > Making proper merge from github pull request it not that easy, you will need to > fetch pull request as custom branches and cherry-pick them. That is really not > convenient. Probably a dozen lines of shell. -Alfred