Date: Sat, 24 May 2014 14:18:38 +1000 From: Kubilay Kocak <koobs@FreeBSD.org> To: Melvyn Sopacua <melvyn@magemana.nl> Cc: FreeBSD Ports <ports@FreeBSD.org>, portmgr-feedback@FreeBSD.org Subject: Re: ACTION REQUIRED - Unstaged Ports being DEPRECATED on June 31st. Message-ID: <53801D9E.9020604@FreeBSD.org> In-Reply-To: <alpine.BSF.2.00.1405122042210.49377@fire.magemana.nl> References: <536E46E0.7030906@FreeBSD.org> <53707FF6.3010300@bsdforen.de> <5370843F.8070104@marino.st> <alpine.BSF.2.00.1405122042210.49377@fire.magemana.nl>
next in thread | previous in thread | raw e-mail | index | archive | help
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.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?53801D9E.9020604>