In my opinion it is always a failure of a podling when they can't get a release out of the door, or are unable to vote in new committers.
"The future is not something we enter. The future is something we create." --Leonard I. Sweet As a podling is waiting for its release to be approved, I sure hope they aren't holding their breath. If they have missing mentors, then prod the mentors. If the mentors don't react, prod general@ (in a polite way). If that doesn't help prod private@ or send a message to VP incubator. Is it frustrating that a first release can take a month to get to your users? Yup. But consider that if it takes a month, your release and your release process had many issues. Your next release should go much faster (you did automate the release building, did you?). Is it frustrating that nobody wants to look at your release? Yup. But ask politely: you are asking volunteers their time–time they can spend with their children, spouses, parents, friends or with their existing projects. Time they will never get back. So spend that time wisely! Outside the incubator you will find that it is still hard to get a release vetted. People get swamped in work. They move houses. Life happens. The incubator won't the last time you will struggle to get the required +3 binding votes. Outside the incubator you also need to make it happen, so show that you are able to do so! If/when a drive by review unveils some things that are wrong with a release (even minutia) go fix them, automate them and respin the release. Do the work and get the release up to standards. You got the attention, someone put the time in to review your release, the onus is on you to fix it. Do it quickly and you'll have a review that much faster. Even better if you can prove that you fixed the discovered issues (show a rat report, a diff of the archive structure, etc). Subscribe to the general@ list and read the things that are uncovered for failed releases. Fix that too in your release. This way you learn from other folks' mistakes. Fill in your board reports on time. Prod your mentors to sign off the reports. Do the trademark search. Fix the licensing. Expand your community. Self governance doesn't just mean the ability to answer messages on users@ or to have civil discourse on dev@, or the ability to commit code without having too many merge conflicts. It also means taking responsibility for your project. You are responsible for getting a release out of the door: it is your project! You are responsible for ensuring the status page is completely checked off: it is your project! You are responsible for completing a trademark search: it is your project! You are responsible for filing a board report on time: it is your project! And yes I speak from my own experience. With Wicket we were living in a slum for half a year. But finally we got our own act together to get a release out the door, to vote in new committers, to fix our status page, to fix our licensing issues etc. That is hard work and you have to spend the time and energy to complete those tasks. But when you have everything in order, you can graduate with confidence. The short guide to graduation: do the work, see it through, persevere and graduate. Martijn --------------------------------------------------------------------- To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
