incubator-general mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Eric Johnson <>
Subject Re: [IMO] There are no Incubator issues
Date Fri, 08 Nov 2013 17:49:11 GMT
"Welcome to the community. Go read the wiki. Follow the mailing list. 
Figure out everything else by yourself! Good luck. Let us know when you 
think you're ready to be a TLP."


One of my co-workers hit me with the line one:

"Is that your best work?"


On 11/7/13, 3:34 PM, Martijn Dashorst wrote:
> 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:
> For additional commands, e-mail:

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message