Insanity. Apache Incubator should be about education (was: [PROPOSAL][VOTE] Subversion)

[Greg Stein <gs...@gmail.com>]

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

Re: Insanity. Apache Incubator should be about education (was: [PROPOSAL][VOTE] Subversion)

[Greg Stein <gs...@gmail.com>]

On Mon, Nov 9, 2009 at 09:14, Leo Simons <ma...@leosimons.com> wrote:
> On Mon, Nov 9, 2009 at 1:25 AM, Greg Stein <gs...@gmail.com> wrote:
>> The Apache Incubator is about EDUCATION. It is about TEACHING podlings
>> how to work here at Apache.
>
> So what are you teaching with e-mails like this, Greg?
>
> When you disagree with someone, SHOUT a bit and write a long rant?

I dropped dev@subversion.tigris.org from the distribution. I was
addressing just the Incubator. It was NOT intended to be a teaching
experience, but a wake-up that I believe some of the Incubator's
purpose has been lost along the way.

> Or perhaps that using an argument based on authority is a good strategy?

I am going to be sending an official "Waiver of release" for vote to
this list. That email will contain a rationale for my request.

I also intend to request a jump straight to subversion.apache.org for
some of the items (e.g mailing lists). Again, there will be a
rationale.

So yes: I *do* intend to use solid arguments, rationale, and plain
language for the purposes of Incubation. My rant was not about
Subversion's incubation but about how this group has become
misdirected by the path to the Almighty Checklist.

> Not very good lessons either. Please kindly step off the soap box...

I will continue to raise points where I think the Incubator has become
misguided from its true purpose of helping (not hindering!) projects
into the ASF. Will my tone be proper? Maybe. Maybe not. But I stand by
my email.

Cheers,
-g

---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org

Re: Insanity. Apache Incubator should be about education (was: [PROPOSAL][VOTE] Subversion)

[Leo Simons <ma...@leosimons.com>]

On Mon, Nov 9, 2009 at 1:25 AM, Greg Stein <gs...@gmail.com> wrote:
> The Apache Incubator is about EDUCATION. It is about TEACHING podlings
> how to work here at Apache.

So what are you teaching with e-mails like this, Greg?

When you disagree with someone, SHOUT a bit and write a long rant?

Or perhaps that using an argument based on authority is a good strategy?

Not very good lessons either. Please kindly step off the soap box...

Thanks,

Leo

PS: For the record I do agree that its not really necessary for
subversion to do an incubation release. I like to think that kind of
stuff is a judgement call for the mentors.

---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org

Re: Insanity. Apache Incubator should be about education (was: [PROPOSAL][VOTE] Subversion)

[Bertrand Delacretaz <bd...@apache.org>]

On Mon, Nov 9, 2009 at 5:43 PM, Greg Stein <gs...@gmail.com> wrote:
> ...I am seeking a
> waiver of the "make a release" "requirement". And you can simply wait
> for me to send that, rather than continuing to speculate about whether
> I'm going to rely on seniority or on experience....

I like that - at first, the tone of this thread (and subject line ;-)
made me think that the subversion podling would be trying to get
through incubation based on its own perception of what's right, as
opposed to the Incubator's well-established policies.

Now, subversion is certainly not your typical podling...I totally
agree that it makes sense to handle its incubation in a slightly
different way that usual.

But as you indicate, deviations from the usual way of doing things
must be approved by this PMC. Let's discuss you concrete requests for
waivers and such once we have them.

-Bertrand

---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org

Re: Insanity. Apache Incubator should be about education (was: [PROPOSAL][VOTE] Subversion)

[Greg Stein <gs...@gmail.com>]

On Mon, Nov 9, 2009 at 11:15, Martijn Dashorst
<ma...@gmail.com> wrote:
>...
> I actually like the way you ask for waivers for stuff that is required
> by the Incubator. But this should be open to any podling, regardless

Never said it was specific to Subversion. You're just jumping up and
down about procedures without waiting to see how this shakes out.

> of the number of Members that are associated with the project, and
> should be founded on hard fact (RAT reports, vote threads), not by
> pointing at seniority or familiarity.

The simple problem is that our time in incubation does not overlap
with a scheduled release of Apache Subversion. So I am seeking a
waiver of the "make a release" "requirement". And you can simply wait
for me to send that, rather than continuing to speculate about whether
I'm going to rely on seniority or on experience.

> Would a waiver be possible for Diversity (large project dominated by 1
> or 2 vendors)? For the minimum required binding votes (small
> communities of 2 committers)?

Don't be argumentative. Any such waiver can and should be denied.

>...
>>> AFAIK releases done by podlings are legally more sound than
>>> established projects at Apache. Do you consider that a bad thing?
>>
>> We have no release planned for the timeframe that I believe we will be
>> within the Incubator. To force one does not make sense, as I've
>> stated.
>
> Then don't call it a release but a proper (legal) code review.

Feel free to perform a (legal) code review when it arrives at the ASF
repository. That was never in question.

The *only* question was putting together a bogus release for a
non-existent audience.

(if I were to guess, the code will arrive in a couple weeks; we have a
lot to synchronize with Infra -- they're going to make the repo
readonly for a while, so that requires some testing, review, and
advance warning to the committers)

>...
>>> 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?
>>
>> That is just an unfair and unfounded accusation.
>
> I see a lot of finger pointing at the long list of established Members
> of the ASF that are part of the proposal and using that as the reason
> not to have to do an incubator release or follow established incubator
> policies. While I appreciate the stature of the list of committers, I
> can't help but notice a pattern: "Policy says we have to do X. We
> don't have to do X because we have N long standing Members of the
> ASF." This reasoning doesn't fly with me. I'd rather see: "Policy says
> we have to do X. We already do (or have done) X as can be seen from
> this and that."

The implication of "long standing Members" is simply that they DO and
HAVE DONE "X" over the years.

It could be stated explicitly, but that's kind of redundant.

But again: this is time-wasting speculation. Get off this subject, and
wait for me to properly write up our waiver to skip a release.

>...
>>> Migrate all subscribers to the mailinglists from one legal
>>> organization to another? (afaik this is legally forbidden)
>>
>> Where did you ever see that we would do that?
>
> In the original proposal: "We will work with the Infrastructure team
> to transfer the subscriber listings to the new destinations."

Yah. And the answer is to invite people to the new list. You were just
too busy raising a fuss rather than to simply *ask* what the final
plans are. Of course, I would have said "dunno. I still need to ask
the svn developers since we've only been in the Incubator for two days
and don't have that answer."

I want to get out of the Incubator with all extreme haste to avoid
people who raise a fuss with all extreme haste.

>...
>> We have already conferred with Infrastructure, and they saw no problem
>> with hosting old releases on archive.apache.org.
>
> I'm just referring to my experience, and that is that software
> released by podlings built before they came to Apache doesn't belong
> on Apache hardware. If that is not the case, I stand corrected and
> will ask to host the old Wicket distributions in archive.apache.org
> along with the non-Apache Wicket websites. This will make it less
> confusing for our users. A win for all!

Great. So stop being accusatory and instead say something like, "woah.
that can be done? we didn't think so. if it is true, then we'd like to
load on wicket stuff."

I still want to double-check with legal-discuss, as stated, but I
believe there is no problem. They may have differing opinions about
types of content (releases under a clear license, vs websites).

>...
> Would you have considered waiving Wicket's community processes which
> were already in line with ASF procedures? Did we really have to vote
> in 2 additional committers before we could graduate? Are the waivers
> only available for projects with N long time Members of the ASF, or
> for any project? Would N == 0 be enough?

A waiver obviously implies a case-by-case basis. So I can't possibly
answer that.

In general, if N==0, then I'd be very reluctant. If N > 3, then
depending on the request.. sure.

-g

---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org

Re: Insanity. Apache Incubator should be about education (was: [PROPOSAL][VOTE] Subversion)

["William A. Rowe, Jr." <wr...@rowe-clan.net>]

Martijn Dashorst wrote:
> 
> Would a waiver be possible for Diversity (large project dominated by 1
> or 2 vendors)? For the minimum required binding votes (small
> communities of 2 committers)?

Such things have been requested, and granted in the past, based on the
demonstrated ability of the project to accept outside contributions and
work towards a more diverse committer base and PMC.  Should they later
fail, the board will [as it has done before] step in, dissolve the PMC
and reappoint a PMC based on actual contribution.

---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org

Re: Insanity. Apache Incubator should be about education (was: [PROPOSAL][VOTE] Subversion)

[Martijn Dashorst <ma...@gmail.com>]

On Mon, Nov 9, 2009 at 3:49 PM, Greg Stein <gs...@gmail.com> wrote:
> We certainly have no intent to bring Bad Code into the ASF!

I am sure you do. However that is not the issue I'm going against:
when Good Code is brought into the ASF in a Bad Way or in a Good Way
with Bad Reasoning.

I actually like the way you ask for waivers for stuff that is required
by the Incubator. But this should be open to any podling, regardless
of the number of Members that are associated with the project, and
should be founded on hard fact (RAT reports, vote threads), not by
pointing at seniority or familiarity.

Would a waiver be possible for Diversity (large project dominated by 1
or 2 vendors)? For the minimum required binding votes (small
communities of 2 committers)?

> In fact, we already know of a couple key points that we're bringing to
> legal-discuss. i.e. we're already ahead of the game by doing a review.
> We've already got all the IP collected. We've applied standard
> headers. We're using ALv2.

Then running RAT should not uncover anything out of the ordinary.

>> AFAIK releases done by podlings are legally more sound than
>> established projects at Apache. Do you consider that a bad thing?
>
> We have no release planned for the timeframe that I believe we will be
> within the Incubator. To force one does not make sense, as I've
> stated.

Then don't call it a release but a proper (legal) code review.

>> 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?
>
> That is just an unfair and unfounded accusation.

I see a lot of finger pointing at the long list of established Members
of the ASF that are part of the proposal and using that as the reason
not to have to do an incubator release or follow established incubator
policies. While I appreciate the stature of the list of committers, I
can't help but notice a pattern: "Policy says we have to do X. We
don't have to do X because we have N long standing Members of the
ASF." This reasoning doesn't fly with me. I'd rather see: "Policy says
we have to do X. We already do (or have done) X as can be seen from
this and that."

Show us the RAT report that has no outstanding issues. That should
mitigate any objections to skipping a release (IMO). Podlings go
through releases so that we can look at the RAT report (previously we
went through the release by hand, thank god for RAT) and ensure all
the legal bits are in the right place and contain the right
information.

>> Have an incubator release? (nah, we are better at releasing because we
>> have long standing members)
>
> Frankly: yeah. You can read my rationale when I ask for a vote. Feel
> free to vote against if you feel our waiver is unwarranted, but I do
> feel that we're quite well-experienced.
> I prefer Leo's "hey, have you checked the RAT output for svn?" than
> "you must make a release" kind of arguments. He's providing a helpful
> pointer to a tool, rather than directing us into senseless work.

Since Leo already pointed out the RAT tool, I didn't see a need. I did
see a lot of "We don't have to check our code because we are
experienced" argumentation, which I find invalid. I'm an experienced
(not as much as you, granted) developer, but that doesn't mean I don't
make mistakes, or have all the dots on the i's and /'s in the x's.

What you fail to see in your haste to get out of the incubator at
breakneck speeds is that the release is purely intended for the legal
bits. This is part of the Incubator's charter. Should we vote +1 on
graduation based on your experience, or on the hard facts that a RAT
report can provide?

>> Migrate all subscribers to the mailinglists from one legal
>> organization to another? (afaik this is legally forbidden)
>
> Where did you ever see that we would do that?

In the original proposal: "We will work with the Infrastructure team
to transfer the subscriber listings to the new destinations."

> Since you're already making false accusations, how about I just
> clarify for you: this has *already been discussed*. Our plan is to set
> up new lists and invite old list members to subscribe to the new one.

Great. No problem for me.

>> Hosting non-Apache released artifacts at Apache hardware?
>
> If you're referring to the older releases of Subversion? You bet. They
> are all with a compatible license. Have you ever noticed all those
> .jar files we host here at Apache?
> Those aren't released by us. Or how
> about the PCRE software embedded into httpd? Or that copy of Expat
> down in apr-util?
>
> We have already conferred with Infrastructure, and they saw no problem
> with hosting old releases on archive.apache.org.

I'm just referring to my experience, and that is that software
released by podlings built before they came to Apache doesn't belong
on Apache hardware. If that is not the case, I stand corrected and
will ask to host the old Wicket distributions in archive.apache.org
along with the non-Apache Wicket websites. This will make it less
confusing for our users. A win for all!

>> 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.

> Any deviation from the standard process, I intend to be asking for a
> specific waiver (much like I did before we even got here!). If
> somebody else wants to take shortcuts in the future, then they better
> have solid requests for waiving an item. But I believe that is quite
> acceptable: if there is a explainable rationale/reason for that waiver
> for any podling, then why shouldn't it be made?

Would you have considered waiving Wicket's community processes which
were already in line with ASF procedures? Did we really have to vote
in 2 additional committers before we could graduate? Are the waivers
only available for projects with N long time Members of the ASF, or
for any project? Would N == 0 be enough?

Martijn

---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org

Re: Insanity. Apache Incubator should be about education (was: [PROPOSAL][VOTE] Subversion)

[Greg Stein <gs...@gmail.com>]

On Mon, Nov 9, 2009 at 10:53, Andrus Adamchik <an...@objectstyle.org> wrote:
> On Nov 9, 2009, at 5:23 PM, Greg Stein wrote:
>> I mean, really... how many other projects that are 9.5 years old(*) do
>> we expect to see arriving here? And of those, how many *started* with
>> the ideas and precepts of the Apache Software Foundation? I suspect it
>> will be zero, so wasting a lot of time documenting (rather than
>> recognizing) exceptions might not be very useful.
>
> There were a few mature projects. Not as large as SVN, but still pretty old
> (say 5 years of track record) and with established community and market
> position. Essentially in the same category (maybe sans the ubiquity of SVN).

Yup. I definitely know about SpamAssassin. Not sure how old that
project is, but I do know they started under a different model and
license (they actually had to leave some code behind because a
contributor refused to relicense (ugh!!)).

My point was primarily, "this is a very rare event. whether it needs
little or a lot of help, large/old contributions are going to need
*different* treatment."

>> But I say "as appropriate". Sometimes it just doesn't make sense to
>> document every possible exception. But simply to note *they can
>> exist*.
>
> Agreed. Just that nobody else was able to get a waiver to date, and this was
> likely because people coming in were intimidated into thinking they have no
> other way, but follow the procedure. So unfortunately there is (and likely
> will be) a difference in treatment. I guess that's a social issue, not a
> procedural one (i.e. insider vs. outsider perception).

Yah. I think you're very right on that.

It may also be that my "Request for Waiver" concept will provide a
mechanism for other podlings in the future. They may be granted, or
they may be denied, but it could provide an avenue to query whether a
particular procedure really should be applied in the same way for
their situation.

Thanks,
-g

---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org

Re: Insanity. Apache Incubator should be about education (was: [PROPOSAL][VOTE] Subversion)

[Andrus Adamchik <an...@objectstyle.org>]

On Nov 9, 2009, at 5:23 PM, Greg Stein wrote:
>
> I mean, really... how many other projects that are 9.5 years old(*) do
> we expect to see arriving here? And of those, how many *started* with
> the ideas and precepts of the Apache Software Foundation? I suspect it
> will be zero, so wasting a lot of time documenting (rather than
> recognizing) exceptions might not be very useful.

There were a few mature projects. Not as large as SVN, but still  
pretty old (say 5 years of track record) and with established  
community and market position. Essentially in the same category (maybe  
sans the ubiquity of SVN).

> But I say "as appropriate". Sometimes it just doesn't make sense to
> document every possible exception. But simply to note *they can
> exist*.

Agreed. Just that nobody else was able to get a waiver to date, and  
this was likely because people coming in were intimidated into  
thinking they have no other way, but follow the procedure. So  
unfortunately there is (and likely will be) a difference in treatment.  
I guess that's a social issue, not a procedural one (i.e. insider vs.  
outsider perception).

Andrus

---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org

Re: Insanity. Apache Incubator should be about education (was: [PROPOSAL][VOTE] Subversion)

["William A. Rowe Jr." <wr...@rowe-clan.net>]

Greg Stein wrote:
> I have no idea why the term "Board" even comes up in your response.
> What's that got to do with my problems with the IPMC attempting to
> impose make-work on the svn podling?

Because when you post to a broad-list such as general@, you are
communicating to all incubating podlings and many graduated (or sadly,
retired) podlings as well.  This is one very broad list where it's not
possible to be a hat-flipper; your opinions necessarily carry the weight
of a Director of the Foundation (until you hide out on a dev list ;-)

Nobody was demanding make-work, you were demanding fast-track graduation.
And then you flipped off the handle after someone suggested that the
project demonstrate all the IP notices in an 'example package' had been
correctly adjusted, relative to its new home.  That was all.  Nobody was
expecting svn to do anything that hasn't been asked of all other recent
podlings, and I hope they won't still.

Please don't rant.  Tweak if the process is wrong [for every podling
to become aware of] or ask for justified exceptions, as you just did.

Bill

---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org

Re: Insanity. Apache Incubator should be about education (was: [PROPOSAL][VOTE] Subversion)

[Greg Stein <gs...@gmail.com>]

I have no idea why the term "Board" even comes up in your response.
What's that got to do with my problems with the IPMC attempting to
impose make-work on the svn podling?

On Tue, Nov 10, 2009 at 13:03, William A. Rowe Jr. <wr...@rowe-clan.net> wrote:
> Greg Stein wrote:
>> On Tue, Nov 10, 2009 at 03:59, William A. Rowe, Jr. <wr...@rowe-clan.net> wrote:
>>> Greg Stein wrote:
>>>>
>>>> Podlings should be shepherded *out* rather than held *in*.
>>> Hmmm... here you go again.  Do you really believe there's a mentor here
>>> who doesn't want to be 'done' with their task at hand, offering up a
>>> functioning project for graduation?  Mentors -do- exactly this, which
>>> is why your rants continue to read as disingenuous and insulting.
>>
>> I'm not talking about mentors' desire to do this. I'm talking about
>> the structures that appear to be in place which work *against*
>> incubation and graduation.
>>
>> And if you want to call a rant against meaningless constraints and
>> bureaucracy "insulting", then I'm okay with that.
>
> The fact is that mentors fix the process when it's broke.  If there is
> useless/worthless/redundant process going on here, then terrific!  Tell
> us, as a voice of the Board, what the Board is telling us we can drop.
>
> Or said another way, "patches welcome".
>
> I'm all for less work and less hassles.  We would be happy to rubber stamp
> our way all the way through graduation, if we believed that it build the
> projects which would remain viable and preserve ASF culture into this
> coming decade.
>
>>> We are glad the board has such confidence that the Incubator is producing
>>> effect meritocracies that collaborate effectively.  If your's is not the
>>> minority opinion, there is a much larger 'Insanity' thread to begin, which
>>> starts with [VOTE] and ends in "Dissolve Incubator?"
>>
>> My point above was the Board, at least in the past(*), has *not* been
>> happy about the average duration. Go poll the Board today, if you'd
>> like.
>
> Happiness and constructive feedback are orthogonal here.  The board (or one
> or more board members) have rang in on specific issues, and helped make some
> problems go away, and created others.  Feel free to constructively participate
> in refining that process.
>
>> AFAIK, the Board has never expressed a lack of confidence in the
>> Incubator, other than duration.
>
> That's good to hear, now bring us more suggestions that don't stack on
> additional bureaucracy or bullet items to the process :)  But don't sit and
> holler that what has evolved is worthless.  Launch a constructive dialog
> about fine tuning it; evolution is an ongoing process.
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
> For additional commands, e-mail: general-help@incubator.apache.org
>
>

---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org

Re: Insanity. Apache Incubator should be about education (was: [PROPOSAL][VOTE] Subversion)

["William A. Rowe Jr." <wr...@rowe-clan.net>]

Greg Stein wrote:
> On Tue, Nov 10, 2009 at 03:59, William A. Rowe, Jr. <wr...@rowe-clan.net> wrote:
>> Greg Stein wrote:
>>>
>>> Podlings should be shepherded *out* rather than held *in*.
>> Hmmm... here you go again.  Do you really believe there's a mentor here
>> who doesn't want to be 'done' with their task at hand, offering up a
>> functioning project for graduation?  Mentors -do- exactly this, which
>> is why your rants continue to read as disingenuous and insulting.
> 
> I'm not talking about mentors' desire to do this. I'm talking about
> the structures that appear to be in place which work *against*
> incubation and graduation.
> 
> And if you want to call a rant against meaningless constraints and
> bureaucracy "insulting", then I'm okay with that.

The fact is that mentors fix the process when it's broke.  If there is
useless/worthless/redundant process going on here, then terrific!  Tell
us, as a voice of the Board, what the Board is telling us we can drop.

Or said another way, "patches welcome".

I'm all for less work and less hassles.  We would be happy to rubber stamp
our way all the way through graduation, if we believed that it build the
projects which would remain viable and preserve ASF culture into this
coming decade.

>> We are glad the board has such confidence that the Incubator is producing
>> effect meritocracies that collaborate effectively.  If your's is not the
>> minority opinion, there is a much larger 'Insanity' thread to begin, which
>> starts with [VOTE] and ends in "Dissolve Incubator?"
> 
> My point above was the Board, at least in the past(*), has *not* been
> happy about the average duration. Go poll the Board today, if you'd
> like.

Happiness and constructive feedback are orthogonal here.  The board (or one
or more board members) have rang in on specific issues, and helped make some
problems go away, and created others.  Feel free to constructively participate
in refining that process.

> AFAIK, the Board has never expressed a lack of confidence in the
> Incubator, other than duration.

That's good to hear, now bring us more suggestions that don't stack on
additional bureaucracy or bullet items to the process :)  But don't sit and
holler that what has evolved is worthless.  Launch a constructive dialog
about fine tuning it; evolution is an ongoing process.



---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org

Re: Insanity. Apache Incubator should be about education (was: [PROPOSAL][VOTE] Subversion)

[Greg Stein <gs...@gmail.com>]

On Tue, Nov 10, 2009 at 03:59, William A. Rowe, Jr. <wr...@rowe-clan.net> wrote:
> Greg Stein wrote:
>>
>> Yup. And I'll note that that "limbo" you describe has been an issue
>> with the Board for a long while now. That is why the Board instructed
>> the IPMC to request all podlings to list two items in their reports:
>>
>> 1) when did you arrive?
>> 2) what is left?
>>
>> Specifically to focus the podling (and the IPMC) on the question of
>> "WHY are you still in the Incubator?"
>>
>> Podlings should be shepherded *out* rather than held *in*.
>
> Hmmm... here you go again.  Do you really believe there's a mentor here
> who doesn't want to be 'done' with their task at hand, offering up a
> functioning project for graduation?  Mentors -do- exactly this, which
> is why your rants continue to read as disingenuous and insulting.

I'm not talking about mentors' desire to do this. I'm talking about
the structures that appear to be in place which work *against*
incubation and graduation.

And if you want to call a rant against meaningless constraints and
bureaucracy "insulting", then I'm okay with that.

> We are glad the board has such confidence that the Incubator is producing
> effect meritocracies that collaborate effectively.  If your's is not the
> minority opinion, there is a much larger 'Insanity' thread to begin, which
> starts with [VOTE] and ends in "Dissolve Incubator?"

My point above was the Board, at least in the past(*), has *not* been
happy about the average duration. Go poll the Board today, if you'd
like.

AFAIK, the Board has never expressed a lack of confidence in the
Incubator, other than duration.

Cheers,
-g

(*) see "Incubator Reports" sent to Noel, IPMC, and board@ on Oct 12, 2006

---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org

Re: Insanity. Apache Incubator should be about education (was: [PROPOSAL][VOTE] Subversion)

["William A. Rowe, Jr." <wr...@rowe-clan.net>]

Greg Stein wrote:
> 
> Yup. And I'll note that that "limbo" you describe has been an issue
> with the Board for a long while now. That is why the Board instructed
> the IPMC to request all podlings to list two items in their reports:
> 
> 1) when did you arrive?
> 2) what is left?
> 
> Specifically to focus the podling (and the IPMC) on the question of
> "WHY are you still in the Incubator?"
> 
> Podlings should be shepherded *out* rather than held *in*.

Hmmm... here you go again.  Do you really believe there's a mentor here
who doesn't want to be 'done' with their task at hand, offering up a
functioning project for graduation?  Mentors -do- exactly this, which
is why your rants continue to read as disingenuous and insulting.

We are glad the board has such confidence that the Incubator is producing
effect meritocracies that collaborate effectively.  If your's is not the
minority opinion, there is a much larger 'Insanity' thread to begin, which
starts with [VOTE] and ends in "Dissolve Incubator?"

---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org

Re: Insanity. Apache Incubator should be about education (was: [PROPOSAL][VOTE] Subversion)

[Greg Stein <gs...@gmail.com>]

On Mon, Nov 9, 2009 at 10:11, Andrus Adamchik <an...@objectstyle.org> wrote:
> Hi Greg,
>
> I am not on either side of the debate here, but Martijn is correct in
> pointing that the formal standard was applied to *all* podlings to date.

I understand, and will simply ask "was that the right thing to do?"
I'm not looking for an answer. That's the past, so I'm unconcerned.
I'm merely (selfishly, TBH) concerned about Subversion, and making any
IPMC adjustments for future podlings who may end up in similar
circumstances.

> There's more than a few projects in the ASF that were originally developed
> in the open, with strong communities. And in those cases that I am aware of,
> no amount of reasoning from those projects would convince the IPMC to give
> them a break and just let them in. You'd have to sit in limbo forever until
> you are done with the checklist.

Yup. And I'll note that that "limbo" you describe has been an issue
with the Board for a long while now. That is why the Board instructed
the IPMC to request all podlings to list two items in their reports:

1) when did you arrive?
2) what is left?

Specifically to focus the podling (and the IPMC) on the question of
"WHY are you still in the Incubator?"

Podlings should be shepherded *out* rather than held *in*.

> So I am fine if SVN incubation would result in reasonable changes in those
> incubator policies. Unless whoever was behind those policies in the first
> place will step in and object?

Where I see something that does not make sense [for Subversion,
obviously; I don't know what may/not make sense for other podlings],
then yes: I intend to clarify that problem. I hope that my intent to
request a waiver of "standard procedure" will point out where that
procedure breaks down for certain podlings. The IPMC can then discuss
it as a whole and update process as appropriate.

But I say "as appropriate". Sometimes it just doesn't make sense to
document every possible exception. But simply to note *they can
exist*.

I mean, really... how many other projects that are 9.5 years old(*) do
we expect to see arriving here? And of those, how many *started* with
the ideas and precepts of the Apache Software Foundation? I suspect it
will be zero, so wasting a lot of time documenting (rather than
recognizing) exceptions might not be very useful.

Cheers,
-g

(*) Subversion coding was started in June 2000, one year after the ASF
itself was founded; svn started as a concept around the end of 1999

---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org

Re: Insanity. Apache Incubator should be about education (was: [PROPOSAL][VOTE] Subversion)

[Andrus Adamchik <an...@objectstyle.org>]

Hi Greg,

I am not on either side of the debate here, but Martijn is correct in  
pointing that the formal standard was applied to *all* podlings to  
date. There's more than a few projects in the ASF that were originally  
developed in the open, with strong communities. And in those cases  
that I am aware of, no amount of reasoning from those projects would  
convince the IPMC to give them a break and just let them in. You'd  
have to sit in limbo forever until you are done with the checklist.

So I am fine if SVN incubation would result in reasonable changes in  
those incubator policies. Unless whoever was behind those policies in  
the first place will step in and object?

Andrus


On Nov 9, 2009, at 4:49 PM, Greg Stein wrote:

> On Mon, Nov 9, 2009 at 09:27, Martijn Dashorst
> <ma...@gmail.com> wrote:
>> 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.
>
> We certainly have no intent to bring Bad Code into the ASF! In fact,
> we already know of a couple key points that we're bringing to
> legal-discuss. i.e. we're already ahead of the game by doing a review.
> We've already got all the IP collected. We've applied standard
> headers. We're using ALv2.
>
>> AFAIK releases done by podlings are legally more sound than
>> established projects at Apache. Do you consider that a bad thing?
>
> We have no release planned for the timeframe that I believe we will be
> within the Incubator. To force one does not make sense, as I've
> stated.
>
>> 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?
>
> That is just an unfair and unfounded accusation.
>
>> Have an incubator release? (nah, we are better at releasing because  
>> we
>> have long standing members)
>
> Frankly: yeah. You can read my rationale when I ask for a vote. Feel
> free to vote against if you feel our waiver is unwarranted, but I do
> feel that we're quite well-experienced.
>
> I prefer Leo's "hey, have you checked the RAT output for svn?" than
> "you must make a release" kind of arguments. He's providing a helpful
> pointer to a tool, rather than directing us into senseless work.
>
>> Migrate all subscribers to the mailinglists from one legal
>> organization to another? (afaik this is legally forbidden)
>
> Where did you ever see that we would do that?
>
> Since you're already making false accusations, how about I just
> clarify for you: this has *already been discussed*. Our plan is to set
> up new lists and invite old list members to subscribe to the new one.
>
>> Hosting non-Apache released artifacts at Apache hardware?
>
> If you're referring to the older releases of Subversion? You bet. They
> are all with a compatible license. Have you ever noticed all those
> .jar files we host here at Apache? Those aren't released by us. Or how
> about the PCRE software embedded into httpd? Or that copy of Expat
> down in apr-util?
>
> We have already conferred with Infrastructure, and they saw no problem
> with hosting old releases on archive.apache.org.
>
> And all that said, since you're in an argumentative mood here... sure.
> I think that is a fair topic for consideration, and possibly for
> guidance from legal-discuss. But given license compat, I'm laying odds
> that Legal will have zero problem with it.
>
>> 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.
>
> Absolutely agreed. That is *precisely* why Subversion is going through
> Incubation rather than directly approaching the Board for TLP status.
> (which was discussed by the Board and by SVN)  Myself and others felt
> it would set a bad precedent, so here we are.
>
> Any deviation from the standard process, I intend to be asking for a
> specific waiver (much like I did before we even got here!). If
> somebody else wants to take shortcuts in the future, then they better
> have solid requests for waiving an item. But I believe that is quite
> acceptable: if there is a explainable rationale/reason for that waiver
> for any podling, then why shouldn't it be made?
>
> I do not intend to progress quickly by virtue of the "old boys
> network" you accuse me and the other svn people of, but simply that we
> already conform to ASF principles already. There isn't much adjustment
> needed. I'm looking at the checklist as "right. need to talk to infra
> about that. okay. need to talk to legal-discuss. file a ticket over
> there. etc". How many projects arrive already knowing the people and
> mailing lists to contact?
>
> Cheers,
> -g
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
> For additional commands, e-mail: general-help@incubator.apache.org
>
>


---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org

Re: Insanity. Apache Incubator should be about education (was: [PROPOSAL][VOTE] Subversion)

[Greg Stein <gs...@gmail.com>]

On Mon, Nov 9, 2009 at 12:08, Niall Pemberton <ni...@gmail.com> wrote:
>...
> It seems though that all you're going to do here in the incubator is
> go through the IP clearance and ask for waivers on all the other usual
> steps that a new project goes through. Whats the point of that?
> Whether its a bad precedent or not, if you effectively want a rubber
> stamp from the IPMC then better IMO to just do the IP Clearance for
> the code base and go straight to the board to sign off on subversion
> joining as a TLP.

An IP Clearance requires a PMC first. We don't have one :-P

But to not be flippant about it: yes, I had considered that too. I
think it also sets a poor precedent, though not as bad, as going
straight to the Board for a TLP. Maybe when Subversion graduates, and
we review the process, we can establish a mechanism for doing exactly
that. But I think it is still going to be such a rare event, that we
can just recognize it when it arrives and shift gears.

That said: the checklists in the Incubation process are very good. I'm
using them to coordinate all the various bits that need to be set up
for a project. There is something to be absolutely said for
maintaining the podling status in subversion.xml. "Did you do X? How
about Y?" Getting each of those done, and communicated. There are also
a lot of coordination issues between the community and infrastructure.

And it has been a LONG time since I've set up a TLP here at the ASF.
There are lots of moving parts. I am likely to miss something, and the
Incubator PMC is here to help me with that.

Most podlings have plenty of time in the Incubator to get all their
parts in working order. And then they take another few months as they
graduate. I'm trying to run right on the edge and keep the Subversion
community from seeing as little disruption as possible, yet put
together everything that we want and need from a project here at the
ASF. The Incubator provides a structure for that.

Cheers,
-g

---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org

Re: Insanity. Apache Incubator should be about education (was: [PROPOSAL][VOTE] Subversion)

[Niall Pemberton <ni...@gmail.com>]

On Mon, Nov 9, 2009 at 2:49 PM, Greg Stein <gs...@gmail.com> wrote:
> On Mon, Nov 9, 2009 at 09:27, Martijn Dashorst
> <ma...@gmail.com> wrote:
>> 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.
>
> We certainly have no intent to bring Bad Code into the ASF! In fact,
> we already know of a couple key points that we're bringing to
> legal-discuss. i.e. we're already ahead of the game by doing a review.
> We've already got all the IP collected. We've applied standard
> headers. We're using ALv2.
>
>> AFAIK releases done by podlings are legally more sound than
>> established projects at Apache. Do you consider that a bad thing?
>
> We have no release planned for the timeframe that I believe we will be
> within the Incubator. To force one does not make sense, as I've
> stated.
>
>> 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?
>
> That is just an unfair and unfounded accusation.
>
>> Have an incubator release? (nah, we are better at releasing because we
>> have long standing members)
>
> Frankly: yeah. You can read my rationale when I ask for a vote. Feel
> free to vote against if you feel our waiver is unwarranted, but I do
> feel that we're quite well-experienced.
>
> I prefer Leo's "hey, have you checked the RAT output for svn?" than
> "you must make a release" kind of arguments. He's providing a helpful
> pointer to a tool, rather than directing us into senseless work.
>
>> Migrate all subscribers to the mailinglists from one legal
>> organization to another? (afaik this is legally forbidden)
>
> Where did you ever see that we would do that?
>
> Since you're already making false accusations, how about I just
> clarify for you: this has *already been discussed*. Our plan is to set
> up new lists and invite old list members to subscribe to the new one.
>
>> Hosting non-Apache released artifacts at Apache hardware?
>
> If you're referring to the older releases of Subversion? You bet. They
> are all with a compatible license. Have you ever noticed all those
> .jar files we host here at Apache? Those aren't released by us. Or how
> about the PCRE software embedded into httpd? Or that copy of Expat
> down in apr-util?
>
> We have already conferred with Infrastructure, and they saw no problem
> with hosting old releases on archive.apache.org.
>
> And all that said, since you're in an argumentative mood here... sure.
> I think that is a fair topic for consideration, and possibly for
> guidance from legal-discuss. But given license compat, I'm laying odds
> that Legal will have zero problem with it.
>
>> 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.
>
> Absolutely agreed. That is *precisely* why Subversion is going through
> Incubation rather than directly approaching the Board for TLP status.
> (which was discussed by the Board and by SVN)  Myself and others felt
> it would set a bad precedent, so here we are.

It seems though that all you're going to do here in the incubator is
go through the IP clearance and ask for waivers on all the other usual
steps that a new project goes through. Whats the point of that?
Whether its a bad precedent or not, if you effectively want a rubber
stamp from the IPMC then better IMO to just do the IP Clearance for
the code base and go straight to the board to sign off on subversion
joining as a TLP.

Niall

> Any deviation from the standard process, I intend to be asking for a
> specific waiver (much like I did before we even got here!). If
> somebody else wants to take shortcuts in the future, then they better
> have solid requests for waiving an item. But I believe that is quite
> acceptable: if there is a explainable rationale/reason for that waiver
> for any podling, then why shouldn't it be made?
>
> I do not intend to progress quickly by virtue of the "old boys
> network" you accuse me and the other svn people of, but simply that we
> already conform to ASF principles already. There isn't much adjustment
> needed. I'm looking at the checklist as "right. need to talk to infra
> about that. okay. need to talk to legal-discuss. file a ticket over
> there. etc". How many projects arrive already knowing the people and
> mailing lists to contact?
>
> Cheers,
> -g
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
> For additional commands, e-mail: general-help@incubator.apache.org
>
>

---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org

Re: Insanity. Apache Incubator should be about education (was: [PROPOSAL][VOTE] Subversion)

[Greg Stein <gs...@gmail.com>]

On Mon, Nov 9, 2009 at 09:27, Martijn Dashorst
<ma...@gmail.com> wrote:
> 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.

We certainly have no intent to bring Bad Code into the ASF! In fact,
we already know of a couple key points that we're bringing to
legal-discuss. i.e. we're already ahead of the game by doing a review.
We've already got all the IP collected. We've applied standard
headers. We're using ALv2.

> AFAIK releases done by podlings are legally more sound than
> established projects at Apache. Do you consider that a bad thing?

We have no release planned for the timeframe that I believe we will be
within the Incubator. To force one does not make sense, as I've
stated.

> 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?

That is just an unfair and unfounded accusation.

> Have an incubator release? (nah, we are better at releasing because we
> have long standing members)

Frankly: yeah. You can read my rationale when I ask for a vote. Feel
free to vote against if you feel our waiver is unwarranted, but I do
feel that we're quite well-experienced.

I prefer Leo's "hey, have you checked the RAT output for svn?" than
"you must make a release" kind of arguments. He's providing a helpful
pointer to a tool, rather than directing us into senseless work.

> Migrate all subscribers to the mailinglists from one legal
> organization to another? (afaik this is legally forbidden)

Where did you ever see that we would do that?

Since you're already making false accusations, how about I just
clarify for you: this has *already been discussed*. Our plan is to set
up new lists and invite old list members to subscribe to the new one.

> Hosting non-Apache released artifacts at Apache hardware?

If you're referring to the older releases of Subversion? You bet. They
are all with a compatible license. Have you ever noticed all those
.jar files we host here at Apache? Those aren't released by us. Or how
about the PCRE software embedded into httpd? Or that copy of Expat
down in apr-util?

We have already conferred with Infrastructure, and they saw no problem
with hosting old releases on archive.apache.org.

And all that said, since you're in an argumentative mood here... sure.
I think that is a fair topic for consideration, and possibly for
guidance from legal-discuss. But given license compat, I'm laying odds
that Legal will have zero problem with it.

> 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.

Absolutely agreed. That is *precisely* why Subversion is going through
Incubation rather than directly approaching the Board for TLP status.
(which was discussed by the Board and by SVN)  Myself and others felt
it would set a bad precedent, so here we are.

Any deviation from the standard process, I intend to be asking for a
specific waiver (much like I did before we even got here!). If
somebody else wants to take shortcuts in the future, then they better
have solid requests for waiving an item. But I believe that is quite
acceptable: if there is a explainable rationale/reason for that waiver
for any podling, then why shouldn't it be made?

I do not intend to progress quickly by virtue of the "old boys
network" you accuse me and the other svn people of, but simply that we
already conform to ASF principles already. There isn't much adjustment
needed. I'm looking at the checklist as "right. need to talk to infra
about that. okay. need to talk to legal-discuss. file a ticket over
there. etc". How many projects arrive already knowing the people and
mailing lists to contact?

Cheers,
-g

---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org

Re: Insanity. Apache Incubator should be about education (was: [PROPOSAL][VOTE] Subversion)

[Branko Čibej <br...@xbc.nu>]

Martijn Dashorst wrote:
> 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?
>   

I don't disagree to checking the legal bits and pieces. But what I read
up to now, in the other thread, was more to the tune of checking release
quality and procedures. I got stuck on the "quality" part; I for one
will not sign off a Subversion release if I know it's broken, and
apparently the legal bits can be verified in other ways.

Clearly it's up to the Incubator PMC and/or Mentors to decide what does
or does not make sense here. If "make a proper release" is indeed the
verdict, then Subversion will remain incubating for several months at
least. That's not necessarily a bad thing, but it does leave a strange
taste in the mouth, especially given how much effort we've already put
in running our project according to ASF standards.

Oh and by the way, ranting about old-boys networks was pretty much the
last thing I expected to read on this list. Is the meritocracy blues all
nonsense then? Just askin' ...

-- Brane, not an ASF member


---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org

Re: Insanity. Apache Incubator should be about education (was: [PROPOSAL][VOTE] Subversion)

[Martijn Dashorst <ma...@gmail.com>]

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.

Martijn

On Mon, Nov 9, 2009 at 2:25 AM, Greg Stein <gs...@gmail.com> 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 <Cr...@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-unsubscribe@incubator.apache.org
> For additional commands, e-mail: general-help@incubator.apache.org
>
>



-- 
Become a Wicket expert, learn from the best: http://wicketinaction.com
Apache Wicket 1.4 increases type safety for web applications
Get it now: http://www.apache.org/dyn/closer.cgi/wicket/1.4.0

---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org

Re: Insanity. Apache Incubator should be about education (was: [PROPOSAL][VOTE] Subversion)

[Daniel Shahaf <d....@daniel.shahaf.name>]

Craig L Russell wrote on Mon, 9 Nov 2009 at 14:12 -0800:
> Hi Greg,
> 
> I'm afraid that you have totally mistranslated my message and I have no idea
> why.
> 
> I'm not trying to pick a fight.
> 
> I'm trying to be reasonable.
> 
> I don't perceive your reaction as positive.
> 
> I'm not going to continue this discussion until you have something concrete to
> discuss. I voted to accept Subversion into the incubator. Your turn.
> 
> Craig
> 
> On Nov 8, 2009, at 5:25 PM, 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.
...
> > 
> > On Fri, Nov 6, 2009 at 20:19, Craig L Russell <Cr...@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.

Besides packaging, licensing, and notices, what else should be reviewed?

> > > 

Also:  Hyrum set up (some time ago) nightly tarballs.  IIRC they are 
generated by the same scripts used to roll our stable releases, except 
that they are rolled straight from trunk (with the usual "may not compile" 
caveats).  If packaging is the only issue, could these tarballs be 
inspected instead?

Daniel
(they're generated by tools/dist/nightly.sh.  Hyrum's server that runs the 
script daily and publishes the output tarballs is temporarily offline, so 
no link to live nightly tarballs, sorry.)

---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org

Re: Insanity. Apache Incubator should be about education (was: [PROPOSAL][VOTE] Subversion)

[Craig L Russell <Cr...@Sun.COM>]

Hi Greg,

I'm afraid that you have totally mistranslated my message and I have  
no idea why.

I'm not trying to pick a fight.

I'm trying to be reasonable.

I don't perceive your reaction as positive.

I'm not going to continue this discussion until you have something  
concrete to discuss. I voted to accept Subversion into the incubator.  
Your turn.

Craig

On Nov 8, 2009, at 5:25 PM, 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  
> <Cr...@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-unsubscribe@incubator.apache.org
> For additional commands, e-mail: general-help@incubator.apache.org
>

Craig L Russell
Architect, Sun Java Enterprise System http://db.apache.org/jdo
408 276-5638 mailto:Craig.Russell@sun.com
P.S. A good JDO? O, Gasp!

Re: Insanity. Apache Incubator should be about education (was: [PROPOSAL][VOTE] Subversion)

["William A. Rowe Jr." <wr...@rowe-clan.net>]

Joe Schaefer wrote:
> ----- Original Message ----
> 
>> From: William A. Rowe Jr. <wr...@rowe-clan.net>
>> To: general@incubator.apache.org
>> Sent: Tue, November 10, 2009 10:08:40 AM
>> Subject: Re: Insanity. Apache Incubator should be about education (was:  [PROPOSAL][VOTE] Subversion)
> 
>> Greg wrote:
>>> Look at the context. Being asked to throw together some bits for a
>>> "release". Oh, just any bits will do. But wait, since they aren't
>>> quite proper, you don't really have to announce it to users. ... come
>>> on, that is not education. That isn't teaching anybody anything.
>> We don't disagree.  So stick around long enough to make a real release that
>> the Incubator PMC can validate, or come to a reasonable exception that the
>> Incubator can accept.  But don't go flying off into rants about process that
>> the board has *charged* the Incubator with defining and enforcing :)
> 
> Wait a second Bill.  In the not-too-distant past there was no requirement
> for a podling to cut a release.  Infrastructure people pushed for there to
> be one, and pushed to have the incubator releases on the mirrors, because it
> turns out prior graduating projects needed to be trained by infra on how to do this properly.

They also needed to be alert for licensing snafus, that was why I support[ed]
the 'requirement'.

> The purpose of doing a release within the incubator has now morphed into
> something a bit different, and not entirely for the better.  I have been
> paying attention to subversion release processes for years, and frankly we
> should be adopting *their* methods here at Apache.  We don't have anything
> to teach them other than mirror mechanics, and that can be learned post-
> graduation.

Agreed in this case, w.r.t. SVN.  But in the general case, this is still best
taught while at the incubator.

I'm responding to Greg's rant, not to a well-stated, well-reasoned appeal for
an exception.


---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org

Re: Insanity. Apache Incubator should be about education (was: [PROPOSAL][VOTE] Subversion)

[Joe Schaefer <jo...@yahoo.com>]

----- Original Message ----

> From: William A. Rowe Jr. <wr...@rowe-clan.net>
> To: general@incubator.apache.org
> Sent: Tue, November 10, 2009 10:08:40 AM
> Subject: Re: Insanity. Apache Incubator should be about education (was:  [PROPOSAL][VOTE] Subversion)

> Greg wrote:
> > Look at the context. Being asked to throw together some bits for a
> > "release". Oh, just any bits will do. But wait, since they aren't
> > quite proper, you don't really have to announce it to users. ... come
> > on, that is not education. That isn't teaching anybody anything.
> 
> We don't disagree.  So stick around long enough to make a real release that
> the Incubator PMC can validate, or come to a reasonable exception that the
> Incubator can accept.  But don't go flying off into rants about process that
> the board has *charged* the Incubator with defining and enforcing :)

Wait a second Bill.  In the not-too-distant past there was no requirement
for a podling to cut a release.  Infrastructure people pushed for there to
be one, and pushed to have the incubator releases on the mirrors, because it
turns out prior graduating projects needed to be trained by infra on how to do this properly.

The purpose of doing a release within the incubator has now morphed into something a bit different, and not entirely for the better.  I have been
paying attention to subversion release processes for years, and frankly we
should be adopting *their* methods here at Apache.  We don't have anything
to teach them other than mirror mechanics, and that can be learned post-
graduation.


      

---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org

Re: Insanity. Apache Incubator should be about education (was: [PROPOSAL][VOTE] Subversion)

["William A. Rowe Jr." <wr...@rowe-clan.net>]

Greg Stein wrote:
> On Tue, Nov 10, 2009 at 03:48, William A. Rowe, Jr. <wr...@rowe-clan.net> wrote:
> 
>> Quite frankly, all svncorp releases could, with reasonable documentation
>> [read: mailing list archives, CLA's and code grant] be licensed as ASF
>> releases under the AL 2.0, irrespective of their internal artifact
>> copyright statements.
> 
> I doubt it. Those old releases are signed tarballs. We can't "reach
> in" and alter the LICENSE file without re-signing the whole tarball,
> and I think that would be a very bad idea.

We don't.  I didn't say re-licensed; I said additionally licensed.  It's as
simple as putting the tarballs into a directory which says "XYZ are further
licensed under the Apache License 2.0".  Nothing needs to be altered to give
users a license.

>> A proviso that 1.7.0 won't be approved without running it through RAT,
>> either pre or post graduation seems sufficient.  The process is better
>> documented than 95% of ASF project release processes, so there's no issue.
> 
> RAT can be run right now, and the podling can work against its
> results. No issue there. The *release* of "something" is my pain
> point.

+1; although we both know that extra artifacts 'appear' magically during
most assembly processes, and that has bit us before.

> And yes, the PMC that will manage the svn project can/should have a
> responsibility to use RAT. But if you "make that rule", then you
> better impose it upon every PMC here at the ASF. That's effectively
> what you're saying :-)

No, I'm saying give SVN a pass on demonstrating the [already demonstrated]
ability to have an effective release process; *contingent* upon running RAT
on the first release artifact created after graduation.  That's what I am
saying.

>> But ranting against your perception of Incubator's failure to EDUCATE and
>> TEACH podlings how the ASF environment works is really quite disappointing,
>> coming from you.
> 
> Look at the context. Being asked to throw together some bits for a
> "release". Oh, just any bits will do. But wait, since they aren't
> quite proper, you don't really have to announce it to users. ... come
> on, that is not education. That isn't teaching anybody anything.

We don't disagree.  So stick around long enough to make a real release that
the Incubator PMC can validate, or come to a reasonable exception that the
Incubator can accept.  But don't go flying off into rants about process that
the board has *charged* the Incubator with defining and enforcing :)





---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org

Re: Incubator Releases: mandatory or optional? Purpose?

[Robert Burrell Donkin <ro...@gmail.com>]

On Fri, Nov 13, 2009 at 6:47 PM, Noel J. Bergman <no...@devtech.com> wrote:
> Robert Burrell Donkin wrote:
>
>> IMHO a podling should know how to cut an ASF release
>> the easiest way to demonstrate this knowledge is to cut a release
>> but it's not the only way.
>
> I don't have an argument with any of those three points.
>
> I also suggest that there is a difference between preparing a release and
> actually doing a release.  In other words, one could prepare the proposed
> artifacts as if they were to be in a release, without releasing them.  That
> would allow audit of the key criteria.

this is effectively what they do now (at least for the first release)

in practice, this is too much for most podlings to get right first
time, and auditing on demand places too great a strain on the
available reviewing resources of the IPMC. so, it's slow and
difficult.

>> i'd like to see a track approach (with IPMC approval votes at each stage)
>>    [1] licensing audit
>>    [2] source audit
>>    [3] build audit
>> rather than hitting all these issues when the first release is cut.
>
> Please elaborate at your convenience.  And where do you feel that an audit
> of the release artifacts comes in?  Step 3?

the IPMC must review released artifacts to provide oversight but the
work required to approve each release could be reduce by only allowing
podlings who have demonstrated understanding to submit releases. this
could be done by using a track system containing the major checks made
at release time.

- robert

---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org

RE: Incubator Releases: mandatory or optional? Purpose?

["Noel J. Bergman" <no...@devtech.com>]

Robert Burrell Donkin wrote:

> IMHO a podling should know how to cut an ASF release
> the easiest way to demonstrate this knowledge is to cut a release
> but it's not the only way.

I don't have an argument with any of those three points.

I also suggest that there is a difference between preparing a release and
actually doing a release.  In other words, one could prepare the proposed
artifacts as if they were to be in a release, without releasing them.  That
would allow audit of the key criteria.

> i'd like to see a track approach (with IPMC approval votes at each stage)
>    [1] licensing audit
>    [2] source audit
>    [3] build audit
> rather than hitting all these issues when the first release is cut.

Please elaborate at your convenience.  And where do you feel that an audit
of the release artifacts comes in?  Step 3?

	--- Noel



---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org

Re: Incubator Releases: mandatory or optional? Purpose?

[Robert Burrell Donkin <ro...@gmail.com>]

On Fri, Nov 13, 2009 at 6:27 PM, Noel J. Bergman <no...@devtech.com> wrote:
> Greg Stein wrote:
>
>> > IIRC, Martijn has offered a proper legal review in the place of a
> "release".
>> > This sounded pretty reasonable to me. I would agree to that.
>
>> Yup. I've already stated that I have no problems with running RAT and
>> working through those issues. Might have been hard to see in this long
>> thread
>
> Ironically, when the Incubator first formed, podlings could NOT do a release
> and many yelled about it.  Accordingly, after much discussion on how, that
> rule was changed so that a podling *could* do a release.  Later, some people
> felt that it was not only possible, but should be mandatory to see a project
> go through the release process, and (in another irony), I believe that some
> of those asking to skirt the issue for Subversion were amonst those pushing
> to see the projects do a release before graduation.  Later on, there was a
> push from the Infrastructure team (as noted already by Joe), wanting to make
> sure that the podling knew the processes for doing a release on ASF
> infrastructure.

IMHO a podling should know how to cut an ASF release (IIRC i've always
been reasonably consistent on this). the easiest way to demonstrate
this knowledge is to cut a release but it's not the only way.

but releases are now too big a hurdle. i'd like to see a track
approach (with IPMC approval votes at each stage)  introduced to
increase the chances of a release passing first time and reduce the
need for an actual release to be cut. this would mean three smaller
hurdles (licensing audit, source audit and build audit) rather than
hitting all these issues when the first release is cut.

- robert

---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org

Re: Insanity. Apache Incubator should be about education (was: [PROPOSAL][VOTE] Subversion)

[Joe Schaefer <jo...@yahoo.com>]

----- Original Message ----

> From: Greg Stein <gs...@gmail.com>
> To: general@incubator.apache.org
> Sent: Tue, November 10, 2009 2:54:28 PM
> Subject: Re: Insanity. Apache Incubator should be about education (was:  [PROPOSAL][VOTE] Subversion)
> 
> On Tue, Nov 10, 2009 at 17:35, Joe Schaefer wrote:
> >...
> >> Neither 1.6.6 nor the upcoming 1.6.7 are Apache-branded releases. The
> >> input that I received was that that was insufficient -- a branded
> >> release was necessary.
> >
> > I haven't seen that discussion, but unless you actually poll general@incubator
> > for an opinion, running the idea by a few of the more vocal participants
> 
> It was right here on general@incubator. Part of the "[PROPOSAL][VOTE]
> Subversion" thread.

Oops sorry. I tend to ignore the off-topic crap here ;-)


      

---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org

Re: Insanity. Apache Incubator should be about education (was: [PROPOSAL][VOTE] Subversion)

[Greg Stein <gs...@gmail.com>]

On Tue, Nov 10, 2009 at 17:35, Joe Schaefer <jo...@yahoo.com> wrote:
>...
>> Neither 1.6.6 nor the upcoming 1.6.7 are Apache-branded releases. The
>> input that I received was that that was insufficient -- a branded
>> release was necessary.
>
> I haven't seen that discussion, but unless you actually poll general@incubator
> for an opinion, running the idea by a few of the more vocal participants

It was right here on general@incubator. Part of the "[PROPOSAL][VOTE]
Subversion" thread.

>...
> What I'm looking to see personally is the execution of votes and signature
> exchange happening on an apache list.  That way the IPMC members can ensure
> discussion is appropriate on both the private and public mailing lists
> and the process is sound.  I don't give a rat's ass how it is branded, and
> assuming the code grant from the Subversion corporation is comprehensive
> expect to vote +1 for graduation without an apache-branded release happening
> prior to graduation.  People will be more than willing to do a license
> review on a non-apache branded release.

Thanks,
-g

---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org

Re: Insanity. Apache Incubator should be about education (was: [PROPOSAL][VOTE] Subversion)

[Joe Schaefer <jo...@yahoo.com>]

----- Original Message ----

> From: Greg Stein <gs...@gmail.com>
> To: general@incubator.apache.org
> Sent: Tue, November 10, 2009 1:58:28 PM
> Subject: Re: Insanity. Apache Incubator should be about education (was:  [PROPOSAL][VOTE] Subversion)
> 
> On Tue, Nov 10, 2009 at 16:39, Joe Schaefer wrote:
> > ----- Original Message ----
> >
> >> From: Jukka Zitting 
> >> To: general@incubator.apache.org
> >> Sent: Tue, November 10, 2009 1:25:40 PM
> >> Subject: Re: Insanity. Apache Incubator should be about education (was: 
>  [PROPOSAL][VOTE] Subversion)
> >>
> >> Hi,
> >>
> >> On Tue, Nov 10, 2009 at 8:28 PM, Greg Stein wrote:
> >> > Unfortunately, some documentation needs to be brought in sync.
> >> >
> >> > See: http://incubator.apache.org/guides/graduation.html#checklist
> >>
> >> I'm nitpicking, but even there we only ask the podlings to
> >> "demonstrate ability to create Apache releases".
> >>
> >> > Per Joe, I think it makes sense to run podlings through a release to
> >> > teach them the ropes, rather than lump that onto Infrastructure. But I
> >> > also believe we should provide waivers when appropriate.
> >>
> >> Fair enough.
> >>
> >> As an alternative, how about submitting
> >> http://subversion.tigris.org/downloads/subversion-1.6.6.tar.bz2 for
> >> IPMC review? That should require no extra work from and no special
> >> waivers for Subversion.
> >
> > I think Greg and company intend to cut another subversion release in
> > the next 2-3 weeks.  If we can get some part of that carried out on
> > apache mailing lists, I think it would alleviate a lot of the initial
> > concerns.
> 
> Neither 1.6.6 nor the upcoming 1.6.7 are Apache-branded releases. The
> input that I received was that that was insufficient -- a branded
> release was necessary.

I haven't seen that discussion, but unless you actually poll general@incubator
for an opinion, running the idea by a few of the more vocal participants
or "key" people here won't get you an accurate gauge of anything.  I have
found most people at Apache to be moderate in their views and willing to compromise when given a good reason to.  That's part of our success as
an organization.

What I'm looking to see personally is the execution of votes and signature
exchange happening on an apache list.  That way the IPMC members can ensure
discussion is appropriate on both the private and public mailing lists
and the process is sound.  I don't give a rat's ass how it is branded, and
assuming the code grant from the Subversion corporation is comprehensive
expect to vote +1 for graduation without an apache-branded release happening
prior to graduation.  People will be more than willing to do a license
review on a non-apache branded release.


      

---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org

Re: Insanity. Apache Incubator should be about education (was: [PROPOSAL][VOTE] Subversion)

[Greg Stein <gs...@gmail.com>]

On Tue, Nov 10, 2009 at 16:39, Joe Schaefer <jo...@yahoo.com> wrote:
> ----- Original Message ----
>
>> From: Jukka Zitting <ju...@gmail.com>
>> To: general@incubator.apache.org
>> Sent: Tue, November 10, 2009 1:25:40 PM
>> Subject: Re: Insanity. Apache Incubator should be about education (was:  [PROPOSAL][VOTE] Subversion)
>>
>> Hi,
>>
>> On Tue, Nov 10, 2009 at 8:28 PM, Greg Stein wrote:
>> > Unfortunately, some documentation needs to be brought in sync.
>> >
>> > See: http://incubator.apache.org/guides/graduation.html#checklist
>>
>> I'm nitpicking, but even there we only ask the podlings to
>> "demonstrate ability to create Apache releases".
>>
>> > Per Joe, I think it makes sense to run podlings through a release to
>> > teach them the ropes, rather than lump that onto Infrastructure. But I
>> > also believe we should provide waivers when appropriate.
>>
>> Fair enough.
>>
>> As an alternative, how about submitting
>> http://subversion.tigris.org/downloads/subversion-1.6.6.tar.bz2 for
>> IPMC review? That should require no extra work from and no special
>> waivers for Subversion.
>
> I think Greg and company intend to cut another subversion release in
> the next 2-3 weeks.  If we can get some part of that carried out on
> apache mailing lists, I think it would alleviate a lot of the initial
> concerns.

Neither 1.6.6 nor the upcoming 1.6.7 are Apache-branded releases. The
input that I received was that that was insufficient -- a branded
release was necessary.

I also pointed the IPMC at the three (primary) emails around the
release of 1.6.6. Again, the input was "not good enough".

So then I suggest a separate legal review, and request a wavier on
making a release. Then the input is "ask us again later".

*shrug*

-g

---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org

Re: Insanity. Apache Incubator should be about education (was: [PROPOSAL][VOTE] Subversion)

[Joe Schaefer <jo...@yahoo.com>]

----- Original Message ----

> From: Jukka Zitting <ju...@gmail.com>
> To: general@incubator.apache.org
> Sent: Tue, November 10, 2009 1:25:40 PM
> Subject: Re: Insanity. Apache Incubator should be about education (was:  [PROPOSAL][VOTE] Subversion)
> 
> Hi,
> 
> On Tue, Nov 10, 2009 at 8:28 PM, Greg Stein wrote:
> > Unfortunately, some documentation needs to be brought in sync.
> >
> > See: http://incubator.apache.org/guides/graduation.html#checklist
> 
> I'm nitpicking, but even there we only ask the podlings to
> "demonstrate ability to create Apache releases".
> 
> > Per Joe, I think it makes sense to run podlings through a release to
> > teach them the ropes, rather than lump that onto Infrastructure. But I
> > also believe we should provide waivers when appropriate.
> 
> Fair enough.
> 
> As an alternative, how about submitting
> http://subversion.tigris.org/downloads/subversion-1.6.6.tar.bz2 for
> IPMC review? That should require no extra work from and no special
> waivers for Subversion.

I think Greg and company intend to cut another subversion release in
the next 2-3 weeks.  If we can get some part of that carried out on
apache mailing lists, I think it would alleviate a lot of the initial
concerns.


      

---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org

Re: Insanity. Apache Incubator should be about education

[Davanum Srinivas <da...@gmail.com>]

Jukka,

Agreed.

thanks,
dims

On 11/11/2009 01:47 AM, Jukka Zitting wrote:
> Hi,
>
> On Tue, Nov 10, 2009 at 11:53 PM, Davanum Srinivas<da...@gmail.com>  wrote:
>> Jukka,
>> Not so sure... because that dist may contain code that we may not allow.
>
> Personally I'd be happy with a plan from the Subversion team that
> shows how they're going to address any issues that may be raised in
> the review.
>
> BR,
>
> Jukka Zitting
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
> For additional commands, e-mail: general-help@incubator.apache.org
>


---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org

Re: Insanity. Apache Incubator should be about education

[Greg Stein <gs...@gmail.com>]

On Fri, Nov 13, 2009 at 12:06, Jukka Zitting <ju...@gmail.com> wrote:
> Hi,
>
> On Fri, Nov 13, 2009 at 6:51 AM, Greg Stein <gs...@gmail.com> wrote:
>> But your above paragraph is some conflation of release practices,
>> legal review, and how this fits into graduation requirements. And I
>> just got done with a frustrating several days on that issue. What do
>> you want?
>
> Sorry, I must have been unclear. Everything you've proposed sounds good to me.
>
> I wasn't trying to debate with you. My point was against people who
> wouldn't accept an existing 1.6.x release as the review target. Since
> you were already moving beyond that, I probably should have just shut
> up instead of muddying the waters. I'm sorry about that.

No worries... I'd really like your continued participation. Just
wasn't sure what you were asking for.

Cheers,
-g

---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org

Re: Insanity. Apache Incubator should be about education

[Jukka Zitting <ju...@gmail.com>]

Hi,

On Fri, Nov 13, 2009 at 6:51 AM, Greg Stein <gs...@gmail.com> wrote:
> But your above paragraph is some conflation of release practices,
> legal review, and how this fits into graduation requirements. And I
> just got done with a frustrating several days on that issue. What do
> you want?

Sorry, I must have been unclear. Everything you've proposed sounds good to me.

I wasn't trying to debate with you. My point was against people who
wouldn't accept an existing 1.6.x release as the review target. Since
you were already moving beyond that, I probably should have just shut
up instead of muddying the waters. I'm sorry about that.

Over and out.

BR,

Jukka Zitting

---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org

Re: Insanity. Apache Incubator should be about education

[Craig L Russell <Cr...@Sun.COM>]

With a few days of additional information now available, I'll stick my  
finger into the soup again.

What the incubator wants/needs/requires is that the community  
understand how to make and vote on a release,

and that the release conforms to Apache legal standards.

I would be happy to split these two items for the subversion podling  
as follows:

1. Have the podling make and vote, on the Apache mailing list, on a  
non-Apache branded release (some maintenance release that might be  
upcoming) that's made outside Apache. This is the process thing, that  
without my going through the existing archives, I assume has been done  
countless times without any Apache oversight and should simply  
demonstrate to everyone how the community works.

2. Have the podling make an Apache-branded tarball with signatures for  
legal review by the incubator. This is the thing that may very well  
contain some surprises (some unexpected LGPL dependency, missing  
license header file, or some such). There are people here who pick  
nits as entertainment. ;-)

Craig

P.S. It was never my intent that the incubator would require the  
subversion community to release some crap for the sake of releasing  
some crap.

On Nov 12, 2009, at 8:51 PM, Greg Stein wrote:

> On Thu, Nov 12, 2009 at 22:05, Jukka Zitting  
> <ju...@gmail.com> wrote:
>> Hi,
>>
>> On Wed, Nov 11, 2009 at 4:11 PM, Greg Stein <gs...@gmail.com> wrote:
>>> Plan: raise an issue, and we fix it.
>>>
>>> Not sure what else you're looking for.
>>
>> I was just pointing out that if you want to do the release review
>> based on an existing 1.6.x release, I wouldn't expect it to be fully
>> compliant with Apache policies (license headers, etc.) and would
>> accept a plan on how those issues will be (or already are being)
>> resolved in the first Apache release of Subversion (1.7.0?). To me
>> that would satisfy the release-related exit criteria we have.
>>
>> I'm also fine with the other proposed ways of satisfying or waiving
>> those exit criteria.
>
> Sigh. You've just looped right back around.
>
> I offered a demonstration of the 1.6.x releases as a demonstration of
> our *process*. But that was deemed unacceptable.
>
> The Apache-branded stuff is trunk or 1.7, which has no scheduled
> release. "No release" was deemed unacceptable.
>
> If you want to review *bits* rather than *release process*, then you
> can take a look at trunk/ or the nightlies that we'll soon produce. If
> you want release process *and* Apache-branding, then the svn community
> is not prepared to provide that, nor do I think it necessary (see the
> deferred vote for waiving a release).
>
> But your above paragraph is some conflation of release practices,
> legal review, and how this fits into graduation requirements. And I
> just got done with a frustrating several days on that issue. What do
> you want?
>
> ugh,
> -g
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
> For additional commands, e-mail: general-help@incubator.apache.org
>

Craig L Russell
Architect, Sun Java Enterprise System http://db.apache.org/jdo
408 276-5638 mailto:Craig.Russell@sun.com
P.S. A good JDO? O, Gasp!

Re: Insanity. Apache Incubator should be about education

["William A. Rowe Jr." <wr...@rowe-clan.net>]

Greg Stein wrote:
> 
> If you want to review *bits* rather than *release process*, then you
> can take a look at trunk/ or the nightlies that we'll soon produce. If
> you want release process *and* Apache-branding, then the svn community
> is not prepared to provide that, nor do I think it necessary (see the
> deferred vote for waiving a release).

Want?  I'd express that as 'demand', knowing this committee.

But don't be disheartened, I can see where 1) release process demonstration
and 2) branding demonstration are two entirely seperate processes in this
somewhat unusual case.

On your other subject, svn and lists and site at subversion.apache.org, that
is a problem but not insurmountable.

If we move 1) the lists to subversion.apache.org [it's just a discussion,
right?  Only publicized on the original site] for overview, then 2) move
the svn [so all commits track to @s.a.o discussions], and 2) stage the
final site [leaving the *current* site primary until graduation] for review,
and move that last on graduation day, I don't see a problem with not creating
a slew of incubator.apache.org/subversion/ resources.

This could all happen in weeks if not days, and should be least-disruptive
to the well-established community.  Are folks OK with this?




---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org

Re: Insanity. Apache Incubator should be about education

[Greg Stein <gs...@gmail.com>]

On Thu, Nov 12, 2009 at 22:05, Jukka Zitting <ju...@gmail.com> wrote:
> Hi,
>
> On Wed, Nov 11, 2009 at 4:11 PM, Greg Stein <gs...@gmail.com> wrote:
>> Plan: raise an issue, and we fix it.
>>
>> Not sure what else you're looking for.
>
> I was just pointing out that if you want to do the release review
> based on an existing 1.6.x release, I wouldn't expect it to be fully
> compliant with Apache policies (license headers, etc.) and would
> accept a plan on how those issues will be (or already are being)
> resolved in the first Apache release of Subversion (1.7.0?). To me
> that would satisfy the release-related exit criteria we have.
>
> I'm also fine with the other proposed ways of satisfying or waiving
> those exit criteria.

Sigh. You've just looped right back around.

I offered a demonstration of the 1.6.x releases as a demonstration of
our *process*. But that was deemed unacceptable.

The Apache-branded stuff is trunk or 1.7, which has no scheduled
release. "No release" was deemed unacceptable.

If you want to review *bits* rather than *release process*, then you
can take a look at trunk/ or the nightlies that we'll soon produce. If
you want release process *and* Apache-branding, then the svn community
is not prepared to provide that, nor do I think it necessary (see the
deferred vote for waiving a release).

But your above paragraph is some conflation of release practices,
legal review, and how this fits into graduation requirements. And I
just got done with a frustrating several days on that issue. What do
you want?

ugh,
-g

---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org

Re: Insanity. Apache Incubator should be about education

["Hyrum K. Wright" <hy...@mail.utexas.edu>]

On Nov 12, 2009, at 9:05 PM, Jukka Zitting wrote:

> Hi,
> 
> On Wed, Nov 11, 2009 at 4:11 PM, Greg Stein <gs...@gmail.com> wrote:
>> Plan: raise an issue, and we fix it.
>> 
>> Not sure what else you're looking for.
> 
> I was just pointing out that if you want to do the release review
> based on an existing 1.6.x release, I wouldn't expect it to be fully
> compliant with Apache policies (license headers, etc.) and would
> accept a plan on how those issues will be (or already are being)
> resolved in the first Apache release of Subversion (1.7.0?). To me
> that would satisfy the release-related exit criteria we have.

FWIW, the Subversion nightly server is back online:
http://orac.ece.utexas.edu/pub/svn/nightly/

The cron job used to generate those tarballs uses the exact same rolling scripts we use to generate standard releases, so those tarballs could be used to test whatever non-process-related qualifications for release people want to see.

-Hyrum

---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org

Re: Insanity. Apache Incubator should be about education

[Jukka Zitting <ju...@gmail.com>]

Hi,

On Wed, Nov 11, 2009 at 4:11 PM, Greg Stein <gs...@gmail.com> wrote:
> Plan: raise an issue, and we fix it.
>
> Not sure what else you're looking for.

I was just pointing out that if you want to do the release review
based on an existing 1.6.x release, I wouldn't expect it to be fully
compliant with Apache policies (license headers, etc.) and would
accept a plan on how those issues will be (or already are being)
resolved in the first Apache release of Subversion (1.7.0?). To me
that would satisfy the release-related exit criteria we have.

I'm also fine with the other proposed ways of satisfying or waiving
those exit criteria.

BR,

Jukka Zitting

---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org

Re: Insanity. Apache Incubator should be about education

[Greg Stein <gs...@gmail.com>]

Plan: raise an issue, and we fix it.

Not sure what else you're looking for. We have a lot of active developers.
Lots of hands to be responsive.

Cheers,
-g

On Nov 11, 2009 1:48 AM, "Jukka Zitting" <ju...@gmail.com> wrote:

Hi,

On Tue, Nov 10, 2009 at 11:53 PM, Davanum Srinivas <da...@gmail.com>
wrote: > Jukka, > Not so sur...
Personally I'd be happy with a plan from the Subversion team that
shows how they're going to address any issues that may be raised in
the review.

BR, Jukka Zitting
--------------------------------------------------------------------- To
unsubs...

Re: Insanity. Apache Incubator should be about education

[Jukka Zitting <ju...@gmail.com>]

Hi,

On Tue, Nov 10, 2009 at 11:53 PM, Davanum Srinivas <da...@gmail.com> wrote:
> Jukka,
> Not so sure... because that dist may contain code that we may not allow.

Personally I'd be happy with a plan from the Subversion team that
shows how they're going to address any issues that may be raised in
the review.

BR,

Jukka Zitting

---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org

Re: Insanity. Apache Incubator should be about education

["Hyrum K. Wright" <hy...@mail.utexas.edu>]

contrib/ has been removed from the packaging scripts, and won't ship with 1.7.

In other news, the box that builds the nightly tarballs is back online, albeit with a new disk, so it'll take me a day or two to get it back up.  When it does, I'll point people there, and you can see what a typical tarball would look like (with the caveat that a nightly is untested, not a true release, and could cause a black hole that swallows the Earth).

-Hyrum

On Nov 10, 2009, at 4:04 PM, Greg Stein wrote:

> Dims: Exactly.
> 
> The svn devs have been talking off/on what to do about contrib/ for
> nearly a year. Various options: simply toss it and wait for people to
> cry and do something to fix it; somehow get it all relicensed (one of
> the contributors already said "no"); etc etc.
> 
> Current consensus seems to be that we'll simply not package the
> contrib/ section into our 1.7 release.
> 
> Cheers,
> -g
> 
> On Tue, Nov 10, 2009 at 16:53, Davanum Srinivas <da...@gmail.com> wrote:
>> Jukka,
>> Not so sure... because that dist may contain code that we may not allow.
>> 
>> Greg,
>> Is there any code in there that is not Apache compatible? i see some in the
>> contrib section...
>> http://svn.collab.net/repos/svn/trunk/contrib/client-side/svn-clean
>> 
>> thanks,
>> dims
>> 
>> On 11/10/2009 04:25 PM, Jukka Zitting wrote:
>>> 
>>> Hi,
>>> 
>>> On Tue, Nov 10, 2009 at 8:28 PM, Greg Stein<gs...@gmail.com>  wrote:
>>>> 
>>>> Unfortunately, some documentation needs to be brought in sync.
>>>> 
>>>> See: http://incubator.apache.org/guides/graduation.html#checklist
>>> 
>>> I'm nitpicking, but even there we only ask the podlings to
>>> "demonstrate ability to create Apache releases".
>>> 
>>>> Per Joe, I think it makes sense to run podlings through a release to
>>>> teach them the ropes, rather than lump that onto Infrastructure. But I
>>>> also believe we should provide waivers when appropriate.
>>> 
>>> Fair enough.
>>> 
>>> As an alternative, how about submitting
>>> http://subversion.tigris.org/downloads/subversion-1.6.6.tar.bz2 for
>>> IPMC review? That should require no extra work from and no special
>>> waivers for Subversion.
>>> 
>>> BR,
>>> 
>>> Jukka Zitting
>>> 
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
>>> For additional commands, e-mail: general-help@incubator.apache.org
>>> 
>> 
>> 
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
>> For additional commands, e-mail: general-help@incubator.apache.org
>> 
>> 
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
> For additional commands, e-mail: general-help@incubator.apache.org
> 


---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org

Re: Insanity. Apache Incubator should be about education

[Greg Stein <gs...@gmail.com>]

Dims: Exactly.

The svn devs have been talking off/on what to do about contrib/ for
nearly a year. Various options: simply toss it and wait for people to
cry and do something to fix it; somehow get it all relicensed (one of
the contributors already said "no"); etc etc.

Current consensus seems to be that we'll simply not package the
contrib/ section into our 1.7 release.

Cheers,
-g

On Tue, Nov 10, 2009 at 16:53, Davanum Srinivas <da...@gmail.com> wrote:
> Jukka,
> Not so sure... because that dist may contain code that we may not allow.
>
> Greg,
> Is there any code in there that is not Apache compatible? i see some in the
> contrib section...
> http://svn.collab.net/repos/svn/trunk/contrib/client-side/svn-clean
>
> thanks,
> dims
>
> On 11/10/2009 04:25 PM, Jukka Zitting wrote:
>>
>> Hi,
>>
>> On Tue, Nov 10, 2009 at 8:28 PM, Greg Stein<gs...@gmail.com>  wrote:
>>>
>>> Unfortunately, some documentation needs to be brought in sync.
>>>
>>> See: http://incubator.apache.org/guides/graduation.html#checklist
>>
>> I'm nitpicking, but even there we only ask the podlings to
>> "demonstrate ability to create Apache releases".
>>
>>> Per Joe, I think it makes sense to run podlings through a release to
>>> teach them the ropes, rather than lump that onto Infrastructure. But I
>>> also believe we should provide waivers when appropriate.
>>
>> Fair enough.
>>
>> As an alternative, how about submitting
>> http://subversion.tigris.org/downloads/subversion-1.6.6.tar.bz2 for
>> IPMC review? That should require no extra work from and no special
>> waivers for Subversion.
>>
>> BR,
>>
>> Jukka Zitting
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
>> For additional commands, e-mail: general-help@incubator.apache.org
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
> For additional commands, e-mail: general-help@incubator.apache.org
>
>

---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org

Re: Insanity. Apache Incubator should be about education

[Davanum Srinivas <da...@gmail.com>]

Jukka,
Not so sure... because that dist may contain code that we may not allow.

Greg,
Is there any code in there that is not Apache compatible? i see some in the contrib section...
http://svn.collab.net/repos/svn/trunk/contrib/client-side/svn-clean

thanks,
dims

On 11/10/2009 04:25 PM, Jukka Zitting wrote:
> Hi,
>
> On Tue, Nov 10, 2009 at 8:28 PM, Greg Stein<gs...@gmail.com>  wrote:
>> Unfortunately, some documentation needs to be brought in sync.
>>
>> See: http://incubator.apache.org/guides/graduation.html#checklist
>
> I'm nitpicking, but even there we only ask the podlings to
> "demonstrate ability to create Apache releases".
>
>> Per Joe, I think it makes sense to run podlings through a release to
>> teach them the ropes, rather than lump that onto Infrastructure. But I
>> also believe we should provide waivers when appropriate.
>
> Fair enough.
>
> As an alternative, how about submitting
> http://subversion.tigris.org/downloads/subversion-1.6.6.tar.bz2 for
> IPMC review? That should require no extra work from and no special
> waivers for Subversion.
>
> BR,
>
> Jukka Zitting
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
> For additional commands, e-mail: general-help@incubator.apache.org
>


---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org

Re: Insanity. Apache Incubator should be about education (was: [PROPOSAL][VOTE] Subversion)

[Jukka Zitting <ju...@gmail.com>]

Hi,

On Tue, Nov 10, 2009 at 8:28 PM, Greg Stein <gs...@gmail.com> wrote:
> Unfortunately, some documentation needs to be brought in sync.
>
> See: http://incubator.apache.org/guides/graduation.html#checklist

I'm nitpicking, but even there we only ask the podlings to
"demonstrate ability to create Apache releases".

> Per Joe, I think it makes sense to run podlings through a release to
> teach them the ropes, rather than lump that onto Infrastructure. But I
> also believe we should provide waivers when appropriate.

Fair enough.

As an alternative, how about submitting
http://subversion.tigris.org/downloads/subversion-1.6.6.tar.bz2 for
IPMC review? That should require no extra work from and no special
waivers for Subversion.

BR,

Jukka Zitting

---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org

Re: Insanity. Apache Incubator should be about education (was: [PROPOSAL][VOTE] Subversion)

[Greg Stein <gs...@gmail.com>]

On Tue, Nov 10, 2009 at 13:02, Jukka Zitting <ju...@gmail.com> wrote:
> Hi,
>
> On Tue, Nov 10, 2009 at 7:40 PM, Greg Stein <gs...@gmail.com> wrote:
>> We're making a 1.6.7 release in the next 2-3 weeks, as I stated
>> before. The Incubator can see how that works (I also gave pointers to
>> 1.6.6).
>
> +1 Since Subversion release procedures already meet most Apache
> policies, reviewing any past release and asking the Subversion
> community for a plan on how to fix any potential issues should be
> enough to satisfy concerns about the release process.

I've formally asked for a Waiver of the release requirement. See another thread.

> In fact our formal exit criteria [1] only requires that "release plans
> are developed and executed in public by the community". There is no
> fixed requirement that at least one incubating release really must
> happen (there's just a question on whether such a requirement should
> exist). Of course for most projects doing a release is the easiest way
> to demonstrate that this and many other exit criteria have been
> satisfied.
>
> [1] http://incubator.apache.org/incubation/Incubation_Policy.html#Minimum+Graduation+Requirements

Unfortunately, some documentation needs to be brought in sync.

See: http://incubator.apache.org/guides/graduation.html#checklist

Per Joe, I think it makes sense to run podlings through a release to
teach them the ropes, rather than lump that onto Infrastructure. But I
also believe we should provide waivers when appropriate.

Cheers,
-g

---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org

Re: Insanity. Apache Incubator should be about education (was: [PROPOSAL][VOTE] Subversion)

[Jukka Zitting <ju...@gmail.com>]

Hi,

On Tue, Nov 10, 2009 at 7:40 PM, Greg Stein <gs...@gmail.com> wrote:
> We're making a 1.6.7 release in the next 2-3 weeks, as I stated
> before. The Incubator can see how that works (I also gave pointers to
> 1.6.6).

+1 Since Subversion release procedures already meet most Apache
policies, reviewing any past release and asking the Subversion
community for a plan on how to fix any potential issues should be
enough to satisfy concerns about the release process.

In fact our formal exit criteria [1] only requires that "release plans
are developed and executed in public by the community". There is no
fixed requirement that at least one incubating release really must
happen (there's just a question on whether such a requirement should
exist). Of course for most projects doing a release is the easiest way
to demonstrate that this and many other exit criteria have been
satisfied.

[1] http://incubator.apache.org/incubation/Incubation_Policy.html#Minimum+Graduation+Requirements

BR,

Jukka Zitting

---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org

Re: Incubator Releases: mandatory or optional? Purpose?

[Gurkan Erdogdu <cg...@gmail.com>]

>>>the draconian release process. ;-)
Actually it is quite true. Last  time I released OpenWebBeans, it took
nearly 1 month :) Besides, it is also very helpful to understand Apache way
release procedures.

--Gurkan
2009/11/16 Jukka Zitting <ju...@gmail.com>

> Hi,
>
> On Mon, Nov 16, 2009 at 3:11 PM, Jim Jagielski <ji...@jagunet.com> wrote:
> > On Nov 13, 2009, at 1:27 PM, Noel J. Bergman wrote:
> >> Ironically, when the Incubator first formed, podlings could NOT do a
> release
> >> and many yelled about it.
> >
> > Yes, the originally reason behind it, iirc, was so podlings had a reason
> > to graduate, the thought being if they could do a release, then what
> > incentive was there for them to ever leave? :)
>
> Nowadays it seems that one of the prime reasons for projects to leave
> the Incubator is to escape the draconian release process. ;-)
>
> BR,
>
> Jukka Zitting
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
> For additional commands, e-mail: general-help@incubator.apache.org
>
>


-- 
Gurkan Erdogdu
http://gurkanerdogdu.blogspot.com

Re: Incubator Releases: mandatory or optional? Purpose?

[Jukka Zitting <ju...@gmail.com>]

Hi,

On Mon, Nov 16, 2009 at 3:11 PM, Jim Jagielski <ji...@jagunet.com> wrote:
> On Nov 13, 2009, at 1:27 PM, Noel J. Bergman wrote:
>> Ironically, when the Incubator first formed, podlings could NOT do a release
>> and many yelled about it.
>
> Yes, the originally reason behind it, iirc, was so podlings had a reason
> to graduate, the thought being if they could do a release, then what
> incentive was there for them to ever leave? :)

Nowadays it seems that one of the prime reasons for projects to leave
the Incubator is to escape the draconian release process. ;-)

BR,

Jukka Zitting

---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org

Re: Incubator Releases: mandatory or optional? Purpose?

[Jim Jagielski <ji...@jaguNET.com>]

On Nov 13, 2009, at 1:27 PM, Noel J. Bergman wrote:

> Greg Stein wrote:
> 
>>> IIRC, Martijn has offered a proper legal review in the place of a
> "release".
>>> This sounded pretty reasonable to me. I would agree to that.
> 
>> Yup. I've already stated that I have no problems with running RAT and
>> working through those issues. Might have been hard to see in this long
>> thread
> 
> Ironically, when the Incubator first formed, podlings could NOT do a release
> and many yelled about it.

Yes, the originally reason behind it, iirc, was so podlings had a reason
to graduate, the thought being if they could do a release, then what
incentive was there for them to ever leave? :)

>  Accordingly, after much discussion on how, that
> rule was changed so that a podling *could* do a release.  Later, some people
> felt that it was not only possible, but should be mandatory to see a project
> go through the release process, and (in another irony), I believe that some
> of those asking to skirt the issue for Subversion were amonst those pushing
> to see the projects do a release before graduation.  Later on, there was a
> push from the Infrastructure team (as noted already by Joe), wanting to make
> sure that the podling knew the processes for doing a release on ASF
> infrastructure.

In general, the whole legal aspects of the ASF "kick in" when we release
code. That's what we exist to do and that when things like licensing and
the like make that connection between the development-side and the
"admin/legal"-side of the ASF.

Since releasing s/w is likely the most important and tangible thing
that ASF projects do, it is a Good Idea to ensure that projects know
how to do it, and this learning process does fit in well with the
whole goal of the Incubator.
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org

Incubator Releases: mandatory or optional? Purpose?

["Noel J. Bergman" <no...@devtech.com>]

Greg Stein wrote:

> > IIRC, Martijn has offered a proper legal review in the place of a
"release".
> > This sounded pretty reasonable to me. I would agree to that.

> Yup. I've already stated that I have no problems with running RAT and
> working through those issues. Might have been hard to see in this long
> thread

Ironically, when the Incubator first formed, podlings could NOT do a release
and many yelled about it.  Accordingly, after much discussion on how, that
rule was changed so that a podling *could* do a release.  Later, some people
felt that it was not only possible, but should be mandatory to see a project
go through the release process, and (in another irony), I believe that some
of those asking to skirt the issue for Subversion were amonst those pushing
to see the projects do a release before graduation.  Later on, there was a
push from the Infrastructure team (as noted already by Joe), wanting to make
sure that the podling knew the processes for doing a release on ASF
infrastructure.

	--- Noel



---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org

Re: Insanity. Apache Incubator should be about education (was: [PROPOSAL][VOTE] Subversion)

[Greg Stein <gs...@gmail.com>]

On Tue, Nov 10, 2009 at 11:23, Kevan Miller <ke...@gmail.com> wrote:
> On Nov 10, 2009, at 10:44 AM, Greg Stein wrote:
>...
>> And that is exactly what I'd like to do. But when the Incubator
>> *imposes* requirements of release that does not meet the project's own
>> quality guidelines, for an audience of zero, then I call that
>> "ridiculous make-work". That is my rant. That the Incubator-at-large
>> is imposing crap on the podling, rather than teaching the podling what
>> it means to be part of the ASF.
>
> IIRC, Martijn has offered a proper legal review in the place of a "release".
> This sounded pretty reasonable to me. I would agree to that. I'm surprised
> you haven't worked with his proposal, to find what I think would be a good
> compromise.

Yup. I've already stated that I have no problems with running RAT and
working through those issues. Might have been hard to see in this long
thread :-)

> I agree with you that a release shouldn't be "make-work" -- it should be the
> natural evolution of a community creating code. But I'm bit puzzled by your
> extreme urgency for a fast incubator exit. Incubator overhead would seem to
> be greatest for a release (which is not in your immediate plans, it seems).
> Until then, overhead for board reports and voting in new committers/pmc
> members would seem to be a minimal burden.

Why *stay*? Incubator is not a home... it's a school.

We're making a 1.6.7 release in the next 2-3 weeks, as I stated
before. The Incubator can see how that works (I also gave pointers to
1.6.6). But the main release, under the Apache brand, is not until
early next year sometime. I'd rather not wait until then.

The reporting doesn't bother me. You can't possibly imagine how many
reports to the Board I've read over the past 8+ years :-P

Cheers,
-g

---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org

Re: Insanity. Apache Incubator should be about education (was: [PROPOSAL][VOTE] Subversion)

[Kevan Miller <ke...@gmail.com>]

On Nov 10, 2009, at 10:44 AM, Greg Stein wrote:

> On Tue, Nov 10, 2009 at 03:48, William A. Rowe, Jr. <wrowe@rowe-clan.net 
> > wrote:
>> Greg Stein wrote:
>>> The Apache Incubator is about EDUCATION. It is about TEACHING  
>>> podlings
>>> how to work here at Apache.
>>
>> I'm a little confused.  I'm reading a really long rant here, but I  
>> expect
>> if you look at what nearly all mentors do in their respective  
>> podlings,
>> this is exactly what they provide (granted, with wildly varying  
>> degrees
>> of effort or attention).
>
> And that is exactly what I'd like to do. But when the Incubator
> *imposes* requirements of release that does not meet the project's own
> quality guidelines, for an audience of zero, then I call that
> "ridiculous make-work". That is my rant. That the Incubator-at-large
> is imposing crap on the podling, rather than teaching the podling what
> it means to be part of the ASF.

IIRC, Martijn has offered a proper legal review in the place of a  
"release". This sounded pretty reasonable to me. I would agree to  
that. I'm surprised you haven't worked with his proposal, to find what  
I think would be a good compromise.

I agree with you that a release shouldn't be "make-work" -- it should  
be the natural evolution of a community creating code. But I'm bit  
puzzled by your extreme urgency for a fast incubator exit. Incubator  
overhead would seem to be greatest for a release (which is not in your  
immediate plans, it seems). Until then, overhead for board reports and  
voting in new committers/pmc members would seem to be a minimal burden.

--kevan

---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org

Re: Insanity. Apache Incubator should be about education (was: [PROPOSAL][VOTE] Subversion)

[Greg Stein <gs...@gmail.com>]

On Tue, Nov 10, 2009 at 03:48, William A. Rowe, Jr. <wr...@rowe-clan.net> wrote:
> Greg Stein wrote:
>> The Apache Incubator is about EDUCATION. It is about TEACHING podlings
>> how to work here at Apache.
>
> I'm a little confused.  I'm reading a really long rant here, but I expect
> if you look at what nearly all mentors do in their respective podlings,
> this is exactly what they provide (granted, with wildly varying degrees
> of effort or attention).

And that is exactly what I'd like to do. But when the Incubator
*imposes* requirements of release that does not meet the project's own
quality guidelines, for an audience of zero, then I call that
"ridiculous make-work". That is my rant. That the Incubator-at-large
is imposing crap on the podling, rather than teaching the podling what
it means to be part of the ASF.

> Quite frankly, all svncorp releases could, with reasonable documentation
> [read: mailing list archives, CLA's and code grant] be licensed as ASF
> releases under the AL 2.0, irrespective of their internal artifact
> copyright statements.

I doubt it. Those old releases are signed tarballs. We can't "reach
in" and alter the LICENSE file without re-signing the whole tarball,
and I think that would be a very bad idea.

> A proviso that 1.7.0 won't be approved without running it through RAT,
> either pre or post graduation seems sufficient.  The process is better
> documented than 95% of ASF project release processes, so there's no issue.

RAT can be run right now, and the podling can work against its
results. No issue there. The *release* of "something" is my pain
point.

And yes, the PMC that will manage the svn project can/should have a
responsibility to use RAT. But if you "make that rule", then you
better impose it upon every PMC here at the ASF. That's effectively
what you're saying :-)

> But ranting against your perception of Incubator's failure to EDUCATE and
> TEACH podlings how the ASF environment works is really quite disappointing,
> coming from you.

Look at the context. Being asked to throw together some bits for a
"release". Oh, just any bits will do. But wait, since they aren't
quite proper, you don't really have to announce it to users. ... come
on, that is not education. That isn't teaching anybody anything.

Cheers,
-g

---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org

Re: Insanity. Apache Incubator should be about education (was: [PROPOSAL][VOTE] Subversion)

["William A. Rowe, Jr." <wr...@rowe-clan.net>]

Greg Stein wrote:
> The Apache Incubator is about EDUCATION. It is about TEACHING podlings
> how to work here at Apache.

I'm a little confused.  I'm reading a really long rant here, but I expect
if you look at what nearly all mentors do in their respective podlings,
this is exactly what they provide (granted, with wildly varying degrees
of effort or attention).

Quite frankly, all svncorp releases could, with reasonable documentation
[read: mailing list archives, CLA's and code grant] be licensed as ASF
releases under the AL 2.0, irrespective of their internal artifact
copyright statements.

A proviso that 1.7.0 won't be approved without running it through RAT,
either pre or post graduation seems sufficient.  The process is better
documented than 95% of ASF project release processes, so there's no issue.

But ranting against your perception of Incubator's failure to EDUCATE and
TEACH podlings how the ASF environment works is really quite disappointing,
coming from you.



---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org

Re: Insanity. Apache Incubator should be about education (was: [PROPOSAL][VOTE] Subversion)

[Greg Stein <gs...@gmail.com>]

On Wed, Nov 11, 2009 at 06:18, Niall Pemberton
<ni...@gmail.com> wrote:
> On Mon, Nov 9, 2009 at 1:25 AM, Greg Stein <gs...@gmail.com> 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 <Cr...@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 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 svn.apache.org/snapshots/, but that's where
I'd like to see them. One of the committers runs nightlies, so we can
easily migrate that process.

Cheers,
-g

---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org

Re: Insanity. Apache Incubator should be about education (was: [PROPOSAL][VOTE] Subversion)

[Niall Pemberton <ni...@gmail.com>]

On Mon, Nov 9, 2009 at 1:25 AM, Greg Stein <gs...@gmail.com> 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 <Cr...@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 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).

Niall

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

---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org

Re: Insanity. Apache Incubator should be about education (was: [PROPOSAL][VOTE] Subversion)

["William A. Rowe, Jr." <wr...@rowe-clan.net>]

Justin Erenkrantz wrote:
> On Mon, Nov 9, 2009 at 3:26 PM, Martijn Dashorst
> <ma...@gmail.com> wrote:
>> On Mon, Nov 9, 2009 at 3:15 PM, Justin Erenkrantz <ju...@erenkrantz.com> wrote:
>>> To be clear, it's on the mentors to decide what is applicable and
>>> necessary for graduation - not the IPMC as a whole.
>> Nope... The whole IPMC has been tasked with oversight. The mentors are
>> proxies for the whole IPMC.
> 
> You can't have it both ways.  By approving the proposal, the IPMC
> delegates its oversight authority to the mentors.  The IPMC then
> confirms that the proper process was followed when it votes for
> graduation.  The mentors can ask for pre-approval for certain
> 'waivers' like Greg is asking for - but it's unfair for a non-mentor
> to try to tell a podling what it can or can not do.  -- justin

Whoa.  Have you really been absent from Incubator for this long?

Granted, each mentor is only -one- voice, each IPMC member is only -one-
voice, with equal standing in the Incubator PMC and as ambassadors to the
PPMC efforts.

But a non-mentor has no less responsibility or authority to help work out
a problem than a mentor does.  Get down off the high horse before you hurt
yourself ;-)

---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org

Re: Insanity. Apache Incubator should be about education (was: [PROPOSAL][VOTE] Subversion)

[Justin Erenkrantz <ju...@erenkrantz.com>]

On Mon, Nov 9, 2009 at 3:26 PM, Martijn Dashorst
<ma...@gmail.com> wrote:
> On Mon, Nov 9, 2009 at 3:15 PM, Justin Erenkrantz <ju...@erenkrantz.com> wrote:
>> To be clear, it's on the mentors to decide what is applicable and
>> necessary for graduation - not the IPMC as a whole.
>
> Nope... The whole IPMC has been tasked with oversight. The mentors are
> proxies for the whole IPMC.

You can't have it both ways.  By approving the proposal, the IPMC
delegates its oversight authority to the mentors.  The IPMC then
confirms that the proper process was followed when it votes for
graduation.  The mentors can ask for pre-approval for certain
'waivers' like Greg is asking for - but it's unfair for a non-mentor
to try to tell a podling what it can or can not do.  -- justin

---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org

Re: Insanity. Apache Incubator should be about education (was: [PROPOSAL][VOTE] Subversion)

[Martijn Dashorst <ma...@gmail.com>]

On Mon, Nov 9, 2009 at 3:15 PM, Justin Erenkrantz <ju...@erenkrantz.com> wrote:
> To be clear, it's on the mentors to decide what is applicable and
> necessary for graduation - not the IPMC as a whole.

Nope... The whole IPMC has been tasked with oversight. The mentors are
proxies for the whole IPMC.

> The IPMC as a
> whole has only two roles: approving a proposal and recommending
> graduation - in between those two stages, it's up to the mentors to
> drive the show on behalf of the IPMC.  Non-mentors don't get to hold a
> podling hostage and all votes by the IPMC are majority-based (no vetos
> apply).

I'll vote -1 if I'm not convinced SVN is adhering to the set policies.
With the rant of Greg I'm less convinced that the project is
conducting itself as a proper Apache community (but rather as an Old
Boys Network), and I am more convinced that the incubation process for
SVN is just a lesson in rubber stamping than an actual and sincere
attempt at doing the right thing.

Martijn

-- 
Become a Wicket expert, learn from the best: http://wicketinaction.com
Apache Wicket 1.4 increases type safety for web applications
Get it now: http://www.apache.org/dyn/closer.cgi/wicket/1.4.0

---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org

Re: Insanity. Apache Incubator should be about education (was: [PROPOSAL][VOTE] Subversion)

[Martijn Dashorst <ma...@gmail.com>]

On Mon, Nov 9, 2009 at 4:24 PM, Justin Erenkrantz <ju...@erenkrantz.com> wrote:
> This is where I think the Incubator has gone awry: the claim that you
> are an IPMC member implies that you have merit on a project (in the
> form of a binding vote) is false.

Not sure if I am looking at the same incubator as you are. I am fully
aware that I don't have any technical merit with a project and refrain
from voting on technical issues. As part of the IPMC I *do* have a
binding vote, per Apache policy, on any issue (technical, legal and
communitywise).

If a podling thinks they are ready to graduate, but the mentors are
not, should they still graduate?

If a podling thinks they are ready to graduate, and the mentors are,
but they still aren't diverse? Should they still graduate?

If a podling votes +1 for a release but doesn't have NOTICE,
DISCLAIMER and LICENSE in the right places, should we still vote +1 to
release the artifacts?

Is being on the IPMC the same as being vote cattle?

> Merit should be earned and should be local - and, in that, I think
> there are some re-adjustments in order as to how the Incubator
> operates.

> I'm mildly uncomfortable with mentors who aren't actually involved in
> the project telling a community what to do - but I accept that as a
> necessity of the Incubation process.  However, I'm much more
> uncomfortable when folks who have *zero* affiliation (except for being
> on some distant "PMC") telling a podling what to do because *they*
> personally believe it is right even when others disagree.

There will always be opinions and disagreements. AFAIK only commits
are subject to VETOs, and I can't remember when an IPMC member vetoed
a commit on a podling (being mentor or not).

The only real problematic votes are release votes and graduation
votes. The latter are usually voted -1 because of diversity issues or
the lack of adding new committers to the project. The former are
usually voted -1 because of wrong contents for NOTICE files, or
missing headers and/or LICENSE, DISCLAIMER and NOTICE files.

If you have anything specific then please point it out.

Martijn

---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org

Re: Insanity. Apache Incubator should be about education (was: [PROPOSAL][VOTE] Subversion)

["William A. Rowe, Jr." <wr...@rowe-clan.net>]

Joe Schaefer wrote:
> 
>> From: Justin Erenkrantz <ju...@erenkrantz.com>
>>
>> Let me put it another way: if the IPMC accepts a proposal with one
>> mentor, then I'm fine with that one mentor acting on behalf of the
>> IPMC without the need to constantly go back to the IPMC for approval.
>> -- justin
> 
> For non-release issues, I'm fine with that.  For releases I would still insist
> on 3 +1's from IPMC members; if a podling can acquire those without coming
> to general@incubator for final approval I could live with that (I'd need to
> update the IPMC release guidelines tho).

I'm not [fine with that].  If another person or two can't be bothered to verify
the very few decisions-with-binding-votes (adding/subtracting people and of
course, releasing code) against the PPMC's decision and rational, then there is
a bigger problem that won't be addressed by just sweeping these votes out the
front door.

---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org

Re: Insanity. Apache Incubator should be about education (was: [PROPOSAL][VOTE] Subversion)

[Joe Schaefer <jo...@yahoo.com>]

----- Original Message ----

> From: Justin Erenkrantz <ju...@erenkrantz.com>
> To: general@incubator.apache.org
> Sent: Mon, November 9, 2009 7:56:53 AM
> Subject: Re: Insanity. Apache Incubator should be about education (was:  [PROPOSAL][VOTE] Subversion)
> 
> On Mon, Nov 9, 2009 at 4:39 PM, Bertrand Delacretaz
> wrote:
> > OTOH, podlings that don't have 3 active mentors can't get 3 binding
> > votes internally, so IPMC members have to jump in sometimes. Thanks to
> > those of us who do!
> 
> I view the proposal accepting the projects with the listed mentors as
> delegating the oversight to the mentors.  So, I don't know if it
> should be required that you must get three IPMC members to vote on
> every little thing a podling does.  I think it tends to let projects
> think that people who don't contribute anything deserve merit and have
> rights to tell them what to do.  I'm not sure that sets an appropriate
> precedent.
> 
> Let me put it another way: if the IPMC accepts a proposal with one
> mentor, then I'm fine with that one mentor acting on behalf of the
> IPMC without the need to constantly go back to the IPMC for approval.
> -- justin

For non-release issues, I'm fine with that.  For releases I would still insist
on 3 +1's from IPMC members; if a podling can acquire those without coming
to general@incubator for final approval I could live with that (I'd need to
update the IPMC release guidelines tho).


      

---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org

Re: Insanity. Apache Incubator should be about education (was: [PROPOSAL][VOTE] Subversion)

[Bertrand Delacretaz <bd...@apache.org>]

On Mon, Nov 9, 2009 at 4:56 PM, Justin Erenkrantz <ju...@erenkrantz.com> wrote:
> ...Let me put it another way: if the IPMC accepts a proposal with one
> mentor, then I'm fine with that one mentor acting on behalf of the
> IPMC without the need to constantly go back to the IPMC for approval....

I see your point, and that's why I've been insisting several times
that incoming podlings get three mentors. Problem is, mentors are not
always present/active when a vote needs to happen.

-Bertrand

---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org

Re: Insanity. Apache Incubator should be about education (was: [PROPOSAL][VOTE] Subversion)

[Justin Erenkrantz <ju...@erenkrantz.com>]

On Mon, Nov 9, 2009 at 4:39 PM, Bertrand Delacretaz
<bd...@apache.org> wrote:
> OTOH, podlings that don't have 3 active mentors can't get 3 binding
> votes internally, so IPMC members have to jump in sometimes. Thanks to
> those of us who do!

I view the proposal accepting the projects with the listed mentors as
delegating the oversight to the mentors.  So, I don't know if it
should be required that you must get three IPMC members to vote on
every little thing a podling does.  I think it tends to let projects
think that people who don't contribute anything deserve merit and have
rights to tell them what to do.  I'm not sure that sets an appropriate
precedent.

Let me put it another way: if the IPMC accepts a proposal with one
mentor, then I'm fine with that one mentor acting on behalf of the
IPMC without the need to constantly go back to the IPMC for approval.
-- justin

---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org

Re: Insanity. Apache Incubator should be about education (was: [PROPOSAL][VOTE] Subversion)

[Bertrand Delacretaz <bd...@apache.org>]

On Mon, Nov 9, 2009 at 4:24 PM, Justin Erenkrantz <ju...@erenkrantz.com> wrote:
> ...I'm mildly uncomfortable with mentors who aren't actually involved in
> the project telling a community what to do - but I accept that as a
> necessity of the Incubation process.  However, I'm much more
> uncomfortable when folks who have *zero* affiliation (except for being
> on some distant "PMC") telling a podling what to do because *they*
> personally believe it is right even when others disagree....

OTOH, podlings that don't have 3 active mentors can't get 3 binding
votes internally, so IPMC members have to jump in sometimes. Thanks to
those of us who do!

-Bertrand

---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org

Re: Insanity. Apache Incubator should be about education (was: [PROPOSAL][VOTE] Subversion)

[Justin Erenkrantz <ju...@erenkrantz.com>]

On Mon, Nov 9, 2009 at 4:03 PM, Leo Simons <ma...@leosimons.com> wrote:
> Also, to be clear, as an IPMC member I spend quite a bit of time with
> projects where I am not a mentor, casting (binding) votes on things
> like their releases. I will continue to do that, inline with procedure
> and policy and common sense. I'm pretty sure you're not really meaning
> to question that :)

This is where I think the Incubator has gone awry: the claim that you
are an IPMC member implies that you have merit on a project (in the
form of a binding vote) is false.

Merit should be earned and should be local - and, in that, I think
there are some re-adjustments in order as to how the Incubator
operates.

I'm mildly uncomfortable with mentors who aren't actually involved in
the project telling a community what to do - but I accept that as a
necessity of the Incubation process.  However, I'm much more
uncomfortable when folks who have *zero* affiliation (except for being
on some distant "PMC") telling a podling what to do because *they*
personally believe it is right even when others disagree.

> PS: Just make sure to keep close tabs on the bearded Slovenian ;-)

Riiiiiiight.  =)  -- justin

---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org

Re: Insanity. Apache Incubator should be about education (was: [PROPOSAL][VOTE] Subversion)

[Leo Simons <ma...@leosimons.com>]

On Mon, Nov 9, 2009 at 2:15 PM, Justin Erenkrantz <ju...@erenkrantz.com> wrote:
> To be clear, it's on the mentors to decide what is applicable and
> necessary for graduation - not the IPMC as a whole.  The IPMC as a
> whole has only two roles: approving a proposal and recommending
> graduation

Also, to be clear, as an IPMC member I spend quite a bit of time with
projects where I am not a mentor, casting (binding) votes on things
like their releases. I will continue to do that, inline with procedure
and policy and common sense. I'm pretty sure you're not really meaning
to question that :)

> I believe it's reasonable to ask for the
> trust that goes with ensuring that we'll be sure to keep Subversion in
> line with Apache practices and procedures - and we will continue to do
> so long after the Incubator has recommended Subversion for graduation.
>  =)

You have it!


cheers,


Leo

PS: Just make sure to keep close tabs on the bearded Slovenian ;-)
PPS: for clarity, that was yet another attempt at a bad joke in a post script

---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org

Re: Insanity. Apache Incubator should be about education (was: [PROPOSAL][VOTE] Subversion)

[Justin Erenkrantz <ju...@erenkrantz.com>]

On Mon, Nov 9, 2009 at 2:25 AM, Greg Stein <gs...@gmail.com> wrote:
> The Apache Incubator is about EDUCATION. It is about TEACHING podlings
> how to work here at Apache.
...
> The Incubator PMC is here to TEACH podlings. Stop and think before
> attempting to apply "rules and procedures".

+1.

The Incubation process is about certifying whether the new community
can stand on its own and follow Apache practices and procedures.

Greg has pointed at the public records and discussions surrounding
Subversion doing releases - as a mentor, I feel that these processes
are in-line (if not exceeding) the Apache practices and procedures and
no more needs to be proven here regarding releases.  If someone can
point out where that process falls noticeably short of Apache
standards, please let us know and we'll take it into consideration.

To be clear, it's on the mentors to decide what is applicable and
necessary for graduation - not the IPMC as a whole.  The IPMC as a
whole has only two roles: approving a proposal and recommending
graduation - in between those two stages, it's up to the mentors to
drive the show on behalf of the IPMC.  Non-mentors don't get to hold a
podling hostage and all votes by the IPMC are majority-based (no vetos
apply).

To be fair, there are some minor points and variations that we're
already aware of.  But, that's why Greg, Sander, Dan, and I (and
others who aren't formally named) are around to teach the more subtle
mechanics of the ASF to those within Subversion: where to submit CLAs,
how to post releases in our mirroring system, what to do with (L)GPL
scripts, etc.  Given our personal long track records within both
Apache and Subversion (nearing or surpassing a decade; geez, we've
been at this a long time!), I believe it's reasonable to ask for the
trust that goes with ensuring that we'll be sure to keep Subversion in
line with Apache practices and procedures - and we will continue to do
so long after the Incubator has recommended Subversion for graduation.
 =)  -- justin

---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org

Re: Insanity. Apache Incubator should be about education (was: [PROPOSAL][VOTE] Subversion)

[Niclas Hedhman <ni...@hedhman.org>]

On Mon, Nov 9, 2009 at 9:25 AM, Greg Stein <gs...@gmail.com> wrote:

<snip content="well said slammer" />

> The Incubator PMC is here to TEACH podlings. Stop and think before
> attempting to apply "rules and procedures".

Amen, Amin, "Quod erat demonstrandum", "So be it." or your own
favorite conclusion clause...


Let the flames soar!!!


Cheers
-- 
Niclas Hedhman, Software Developer
http://www.qi4j.org - New Energy for Java

I  live here; http://tinyurl.com/2qq9er
I  work here; http://tinyurl.com/2ymelc
I relax here; http://tinyurl.com/2cgsug

---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org