incubator-general mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Martijn Dashorst <>
Subject [IMO] There are no Incubator issues
Date Thu, 07 Nov 2013 23:34:50 GMT
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

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.


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

View raw message