From owner-freebsd-ports@FreeBSD.ORG Sat May 24 04:18:56 2014 Return-Path: Delivered-To: ports@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 450D1D8; Sat, 24 May 2014 04:18:56 +0000 (UTC) Received: from mail-pb0-x22f.google.com (mail-pb0-x22f.google.com [IPv6:2607:f8b0:400e:c01::22f]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 02B5B2638; Sat, 24 May 2014 04:18:55 +0000 (UTC) Received: by mail-pb0-f47.google.com with SMTP id rp16so5038497pbb.20 for ; Fri, 23 May 2014 21:18:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=sender:message-id:date:from:reply-to:user-agent:mime-version:to:cc :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=oRkba/yvUKIFfyk/hvF0rO0kO4LyZTRWZibUbSvPqdk=; b=xO6LF0gvwpm5T/S1x7SO4yrHKFr+qWTj1MkXNkSFHdPvvaoEFdTgjO+6kdG+d8ZNUm VYXwtx8yFEAnDcpjdJDxzgAb0hq/1F+YvOhjfAELh2d8e2PSm6RMLmZ9xnyaUtyKtFkS Uf/9UTEFacn0m7Eu8QLvtyirh/cotMN9jF+AG8ch1u+dnkIH1YXpDlaJ24UbRUDB0Maq M2EQI4jEogJljvg3HisaXHkGZbsYqrER3S/yhZiVNSaHqroHXKE0MuMfjmNf74NP/VM5 velRcfTMg059VuS9iSgaL+nT8fXGaiWd6qb+GeVpA7sZChZTe15C9DLMJNtoya1nVsNW MFRQ== X-Received: by 10.66.254.166 with SMTP id aj6mr11290869pad.11.1400905135589; Fri, 23 May 2014 21:18:55 -0700 (PDT) Received: from ?IPv6:2001:44b8:31ae:7b00:24bb:8736:cc4f:f940? (2001-44b8-31ae-7b00-24bb-8736-cc4f-f940.static.ipv6.internode.on.net. [2001:44b8:31ae:7b00:24bb:8736:cc4f:f940]) by mx.google.com with ESMTPSA id io8sm7064275pbc.96.2014.05.23.21.18.53 for (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 23 May 2014 21:18:54 -0700 (PDT) Sender: Kubilay Kocak Message-ID: <53801D9E.9020604@FreeBSD.org> Date: Sat, 24 May 2014 14:18:38 +1000 From: Kubilay Kocak Reply-To: koobs@FreeBSD.org User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:30.0) Gecko/20100101 Thunderbird/30.0 MIME-Version: 1.0 To: Melvyn Sopacua Subject: Re: ACTION REQUIRED - Unstaged Ports being DEPRECATED on June 31st. References: <536E46E0.7030906@FreeBSD.org> <53707FF6.3010300@bsdforen.de> <5370843F.8070104@marino.st> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: FreeBSD Ports , portmgr-feedback@FreeBSD.org X-BeenThere: freebsd-ports@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: Porting software to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 24 May 2014 04:18:56 -0000 On 13/05/2014 4:49 AM, Melvyn Sopacua wrote: > > > On Mon, 12 May 2014, John Marino wrote: > >> I commit PR patches that are 6 to 18 months old fairly frequently. >> There is obviously a huge backlog but many PRs are processed daily. The >> PRs that aren't getting processed quickly are "[NEW PORT]" PRs (and >> apparently anything mentioning fuse-fs for some reason). A staging PR >> is going to jump the line; it has a higher priority. >> >> Why would you even entertain the idea that a staging PR will fall >> between the cracks? > > Perhaps the better question is: what are the factors that will make > committers shy away from a PR, even if it's summary contains stage? [1] > Maybe we (maintainers) can do better? That *is* a great question Melvyn, and one I imagine many maintainers have thought about. We have a ways to go in developing a proactive coaching & mentoring culture in FreeBSD, and with that in mind to start a conversation, here's a few things that come to mind that show me a PR might warrant special attention given limited time & resources: - A PR with a patch, with [patch] prefixed in the summary These are easy to identify when skimming with little effort, and shows intent and initiative from the submitter. - Build logs or URL's (eg: poudriere, redports) showing build OK This shows the submitter groks the effort required at the other end, and again initiative in arming a committer with the information they might need to get it done. These prelim QA steps also identify easy issues early in the process, helping to up-skill the submitter, developing them for greater contributions, and ultimately saves time in any potential back and forth. - porttools, portlint, port test, test port, stage, DEV_MODE = OK (even just showing these steps have been run) Again, basic proactive QA. Shows an understanding of the tools and steps involved, and a regard for quality over quantity or personal benefit only. Seeing that these steps have been already been run makes it easier to choose one PR over another that hasn't, even if we're going to run them again anyway. - Proposed commit log with explanations of non-obvious changes. This provides an insight and information to help assess/review your changes with additional context, to ensure that what you intended to do is what you actually achieved. It also opens the door for exposing the submitter to conventions or process changes within the Project they may not yet be aware of. It also means we don't need to write it. - Be vocal. Follow-up, Ask questions, Don't wait. Don't give up. The question is always "What's left before this can be committed?" and "What would I need to see if I were to take on this work?" Help answer those questions and you position your contributions in the best light for action.