incubator-general mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Greg Stein <>
Subject Re: Insanity. Apache Incubator should be about education (was: [PROPOSAL][VOTE] Subversion)
Date Thu, 12 Nov 2009 17:13:51 GMT
On Wed, Nov 11, 2009 at 06:18, Niall Pemberton
<> wrote:
> On Mon, Nov 9, 2009 at 1: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 key question in my mind is "What tasks does subversion need to
> undertake as part of its moving to the ASF so that any release it
> produces conforms to the ASF's policy on releases?". This itself is
> really part of the whole IP due diligence in bringing any code base
> here to the ASF IMO.
> So for example you're going to have to go through the pain of
> conforming to the policy on license headers for source files and the
> NOTICE and LICENSE files etc. I would expect that you would do that as
> part of the incubating process. I don't know how subversion actually
> creates its source release, but I would assume its a pretty trivial
> effort to create a an example/internal source distro that could be
> reviewed.
> This is what I think Craig was asking and it seemed to me like he was
> agreeing with your *internal release* suggestion - so I think you did
> him a big disservice with this rant.
> The only way reason I can think that you would object to this (because
> of the effort) is if you didn't plan to sort out subversion to conform
> to ASF policy before graduation. If you do plan to sort out all these
> things before graduation then its simply a case of running whatever
> command(s) you use to create the source distro on subversion's trunk
> and providing it for people to review. And I assume (and I believe
> Craig did as well) that that sort of *internal release* would be a
> pretty trivial effort and not much of a burden to ask. If you don't
> plan to sort these things out prior to graduation then thats probably
> the real argument (waiver) you need to get agreement on from the IPMC
> (rather than release).

That's not a release. I've been asking to skip the *release* requirement.

Construct a tarball for legal review? Not a problem. We're going to be
integrated into the ASF buildbot network almost as soon as the
repository migrates. That thing chunks out tarballs, apparently. Not
sure if it puts those on, but that's where
I'd like to see them. One of the committers runs nightlies, so we can
easily migrate that process.


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

View raw message