ACTION REQUIRED - Unstaged Ports being DEPRECATED on June 31st.
koobs at FreeBSD.org
Sat May 24 04:18:56 UTC 2014
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? 
> 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.
More information about the freebsd-ports