incubator-general mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Martijn Dashorst <>
Subject Re: Insanity. Apache Incubator should be about education (was: [PROPOSAL][VOTE] Subversion)
Date Mon, 09 Nov 2009 14:27:55 GMT
Yes, *AND* ensuring legal dots are put on the i's and j's. This is
done through checking the release and ensuring that it is in adherence
to our policies which you and others have crafted. *All* podlings have
to ensure they have the correct licensing headers, notices and other
bits in place before they can graduate.

AFAIK releases done by podlings are legally more sound than
established projects at Apache. Do you consider that a bad thing?
What strikes me is that because the SVN project has many old boys
network guys on board, somehow the policy to what all podlings are
subjected to is no longer valid?

Have an incubator release? (nah, we are better at releasing because we
have long standing members)
Migrate all subscribers to the mailinglists from one legal
organization to another? (afaik this is legally forbidden)
Hosting non-Apache released artifacts at Apache hardware?

These things are/were off-limits to podlings that were established and
functioning outside Apache just fine. Wicket's incubation was rather
painful due to not being able to transfer subscribers and hosting old
releases and websites at Apache.

I'm fine with short circuiting all the red tape associated with the
incubator, but be warned: this will open up doors for other podlings
as well. When the next established open source project comes along
they expect (rightfully so) the same treatment as Subversion.


On Mon, Nov 9, 2009 at 2:25 AM, Greg Stein <> wrote:
> The Apache Incubator is about EDUCATION. It is about TEACHING podlings
> how to work here at Apache.
> It is not about making podlings thoughtlessly follow checklists.
> It is about TEACHING them what are the important aspects of
> development at Apache. About SHOWING them each of the items to be
> aware of.
> It is not about blind adherence to rules and procedure without regard
> to the podling's experience.
> It is about LEARNING who the podling is, what they do, what they have
> done, and what they are capable of, and producing a TEACHING
> experience for that podling so that they can be an effective and
> proper project here at the ASF.
> ---
> I was thinking, "hey. no problem. we can go a bit out of our way and
> produce a release tuned for the Incubator needs" and made a
> suggestion. That didn't satisfy some people, so further requirements
> were thrown in. "hmm", I thought, "well... that shouldn't be too much
> more of a burden".
> And then I received Craig's email below, and it brought me back to
> sanity. I had been forced off the path, and now realize just how crazy
> it is.
> On Fri, Nov 6, 2009 at 20:19, Craig L Russell <> wrote:
>> As I thought I said earlier, *any* release that has proper Apache packaging,
>> licensing, and notices is fine with me. We've had this discussion in the
>> incubator before, for similar reasons, and I think there is consensus that a
>> formal review of a podling release is a reasonable gate for graduation. No
>> one needs to believe that the release is stable, tested, reliable, etc.; it
>> just needs to be reviewed.
> Please let me translate:
> "ANY release is fine, even if that release DOES NOT satisfy the
> project's ESTABLISHED LEVELS OF QUALITY. Shoot. All we want is
> *something*. Oh, and since it has completely inferior quality, it
> doesn't even have to be distributed! See how easy that is! Oh, never
> mind, that if we don't put it into the regular distribution channels,
> and don't make the regular announcements, then YOU'RE NOT DOING A REAL
> Nope. No way.
> The Subversion developers have years of experience releasing code here
> at Apache. Personally, I've been involved in releases of httpd and apr
> for the past ELEVEN years. Then we can talk about the additional
> years/decades of experience brought by Sander, Justin and DLR. Oh, and
> did I mention that Garrett was the VP of APR? That he was on the hook
> for making releases here at Apache?
> If a relatively new committer on the APR project wanted to make a
> release, then they would get handheld by the old-timers. They would
> make mistakes, but those would be caught before final release. That
> newbie does not come here and subject themselves to the oversight of
> the Incubator PMC. They are subject to the APR PMC itself. It makes no
> sense to apply hand-holding to a project that already has old-timers.
> Forget the hand-holding, and TEACH the arriving project about the
> overall guidelines. Point them at the ASF's release guidelines, maybe
> note where there are differences from the existing guidelines, and
> then let the PMC apply the correct oversight.
> If there are no old-timers, or if the project wants to make a release
> *while* in the Incubator? Then sure... apply the release guidelines.
> But applying the thumbscrews now is no indicator of future compliance.
> At the ASF, we make the PMCs responsible. *LET* them be responsible.
> The suggestion of a sub-par release, that should be hidden from the
> public is just ridiculous on the face of it. It teaches the incoming
> podling several things:
> * there are people who follow rules rather than solving a problem
> * you will want to route around those people, which means politicking
> * satisfying a checklist is more important than teaching
> I don't want to see those principles taught to Subversion. I don't
> want to see those taught to ANY podling.
> The Incubator PMC is here to TEACH podlings. Stop and think before
> attempting to apply "rules and procedures".
> -g
> ---------------------------------------------------------------------
> To unsubscribe, e-mail:
> For additional commands, e-mail:

Become a Wicket expert, learn from the best:
Apache Wicket 1.4 increases type safety for web applications
Get it now:

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

View raw message