A month.. aha. :-) 08.11.2013 3:35 пользователь "Martijn Dashorst" <martijn.dasho...@gmail.com> написал:
> 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 > >
