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 <craig.russ...@sun.com> 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
APACHE RELEASE."

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: general-unsubscr...@incubator.apache.org
For additional commands, e-mail: general-h...@incubator.apache.org

Reply via email to