Re: [PROPOSAL] Validation incubator for JSR-303 Bean Validation

[Phil Steitz]

Joe Schaefer wrote:
> - Original Message 
> 
>> From: ant elder 
>> To: general@incubator.apache.org
>> Sent: Fri, December 11, 2009 5:22:13 AM
>> Subject: Re: [PROPOSAL] Validation incubator for JSR-303 Bean Validation
>>
>> On Fri, Dec 11, 2009 at 9:56 AM, Niall Pemberton
>> wrote:
>>> On Fri, Dec 11, 2009 at 7:56 AM, ant elder wrote:
 A quick search so there has been some discussion on commons-dev - [1]

 Does this really need to be incubated - the proposal says its intended
 to graduate to Apache Commons and replace the existing Validator 1.x
 component as a new 2.0 codebase, from the discussion on commons-dev
 everyone seems fine with that out come, and only 2 of the 7 proposed
 committers are not existing Validator or ASF committers - so couldn't
 this just go straight to commons as a code grant and make the two new
 guys committers in recognition of contibuting the new code?
>>> I raised this on priv...@commons and reported back to d...@commons on
>>> that discussion here:
>>>
>>> http://markmail.org/message/lkyjl6gaxawspgdt
>>>
>>> In summary though, there was very little support to go that route and
>>> some objections.
>>>
>>> All commons components share the same set of mailing lists which makes
>>> it easier for PMC members to provide oversight for the 30+ components
>>> that live there. As part of this proposal we want to use the commons
>>> mailing lists for commits and discussion so that by the time this
>>> podling is ready to graduate the new committers and Commons PMC will
>>> have a better knowledge of each other and there will be no issue with
>>> voting in the new committers.
>>>
>>> The use of the commons mailing lists is in the proposal and was part
>>> of the vote held on d...@commons to sponsor this incubation effort:
>>>
>>> http://markmail.org/message/mqdft736b5vasezs
>>>
>>> Niall
>>>
>> From the first email referenced was Roman ever asked if he'd mind
>> submitting patches for a while to earn Karma if the code did go
>> straight to commons? Seems a bit a of a shame to need to go the whole
>> incubation process just for one commit access.
>>
>> Re the the poddling use the existing commons mailing lists its may be
>> worth pointing out this recent thread:
>> http://apache.markmail.org/message/ifinvq7wqmeoo5ix
> 
> Commons is badly busted if it can't allow a new person access to his/her
> own code in a fucking sandbox.  Incubating this project because some weenies 
> are
> uncomfortable about the nature of the meritocracy over in commons isn't the 
> solution:
> have commons hold a public vote and make an actual decision.  If they vote to
> incubate the damned thing, it's an incredibly stupid decision, but so be it.
> 

Hey Joe, the language could be toned down a bit, but I see your
point.  On the other hand, here is the problem as I see it.

In Commons, like other non-Incubator projects, we welcome new
contributors and encourage them to get involved in the community and
stick around long enough to earn ASF commit.  When people show up
with significant patches, we ask them to file CLAs before we commit
their code and if the contribution is "big" (not precisely defined,
but we have been able to agree in all cases), we ask for a software
grant and go through Incubator IP clearance.  We have several
examples of people showing up with large amounts of code, engaging
in the community and contributing patches to their own and other
code and earning commit that way.  This has worked for us in the
past and is consistent with how things are supposed to work - at
least as I understand it - at the ASF, outside of the Incubator.  If
we have changed our (ASF) view on what it means to become a
committer, then maybe we are behind the times in Commons.  That
would be somewhat ironic, since in the Jakarta days we were
regularly accused of having too low a bar for commit.

What we would have no problem at all with is following the process
described above - just do IP clearance / code grant for the code and
let the non-ASF committers earn commit.  This does not take forever
and is not as terrible as some seem to think it is.  I can't recall
a single "failure" (someone getting discouraged and giving up) and
several successes over the past 6 years.

I understand that in the Incubator people get commit immediately and
that makes it easier for both them and the mentors.  As I understand
it, part of the reason we have the Incubator is so that people who
have no experience with the ASF and have not earned merit can both
gain experience and demonstrate merit in a "mentored" environment.
The mentoring and graduation requirements ensure that when projects
graduate, their committers have earned full ASF commit.

It could be that I have this wrong and just arriving with a lump of
code that a project wants to incorporate is enough to earn ASF
commit outside the Incubator nowadays.  If we collectively agreed to
that and I missed the conversation, then I apologize for t

Re: [PROPOSAL] Validation incubator for JSR-303 Bean Validation

[Phil Steitz]

Joe Schaefer wrote:
> - Original Message 
> 
>> From: Phil Steitz 
>> To: general@incubator.apache.org
>> Sent: Wed, December 30, 2009 1:30:13 PM
>> Subject: Re: [PROPOSAL] Validation incubator for JSR-303 Bean Validation
>>
>> Joe Schaefer wrote:
>>> - Original Message 
>>>
>>>> From: ant elder 
>>>> To: general@incubator.apache.org
>>>> Sent: Fri, December 11, 2009 5:22:13 AM
>>>> Subject: Re: [PROPOSAL] Validation incubator for JSR-303 Bean Validation
>>>>
>>>> On Fri, Dec 11, 2009 at 9:56 AM, Niall Pemberton
>>>> wrote:
>>>>> On Fri, Dec 11, 2009 at 7:56 AM, ant elder wrote:
>>>>>> A quick search so there has been some discussion on commons-dev - [1]
>>>>>>
>>>>>> Does this really need to be incubated - the proposal says its intended
>>>>>> to graduate to Apache Commons and replace the existing Validator 1.x
>>>>>> component as a new 2.0 codebase, from the discussion on commons-dev
>>>>>> everyone seems fine with that out come, and only 2 of the 7 proposed
>>>>>> committers are not existing Validator or ASF committers - so couldn't
>>>>>> this just go straight to commons as a code grant and make the two new
>>>>>> guys committers in recognition of contibuting the new code?
>>>>> I raised this on priv...@commons and reported back to d...@commons on
>>>>> that discussion here:
>>>>>
>>>>> http://markmail.org/message/lkyjl6gaxawspgdt
>>>>>
>>>>> In summary though, there was very little support to go that route and
>>>>> some objections.
>>>>>
>>>>> All commons components share the same set of mailing lists which makes
>>>>> it easier for PMC members to provide oversight for the 30+ components
>>>>> that live there. As part of this proposal we want to use the commons
>>>>> mailing lists for commits and discussion so that by the time this
>>>>> podling is ready to graduate the new committers and Commons PMC will
>>>>> have a better knowledge of each other and there will be no issue with
>>>>> voting in the new committers.
>>>>>
>>>>> The use of the commons mailing lists is in the proposal and was part
>>>>> of the vote held on d...@commons to sponsor this incubation effort:
>>>>>
>>>>> http://markmail.org/message/mqdft736b5vasezs
>>>>>
>>>>> Niall
>>>>>
>>>> From the first email referenced was Roman ever asked if he'd mind
>>>> submitting patches for a while to earn Karma if the code did go
>>>> straight to commons? Seems a bit a of a shame to need to go the whole
>>>> incubation process just for one commit access.
>>>>
>>>> Re the the poddling use the existing commons mailing lists its may be
>>>> worth pointing out this recent thread:
>>>> http://apache.markmail.org/message/ifinvq7wqmeoo5ix
>>> Commons is badly busted if it can't allow a new person access to his/her
>>> own code in a fucking sandbox.  Incubating this project because some 
>>> weenies 
>> are
>>> uncomfortable about the nature of the meritocracy over in commons isn't the 
>> solution:
>>> have commons hold a public vote and make an actual decision.  If they vote 
>>> to
>>> incubate the damned thing, it's an incredibly stupid decision, but so be it.
>>>
>> Hey Joe, the language could be toned down a bit, but I see your
>> point.  On the other hand, here is the problem as I see it.
>>
>> In Commons, like other non-Incubator projects, we welcome new
>> contributors and encourage them to get involved in the community and
>> stick around long enough to earn ASF commit.  When people show up
>> with significant patches, we ask them to file CLAs before we commit
>> their code and if the contribution is "big" (not precisely defined,
>> but we have been able to agree in all cases), we ask for a software
>> grant and go through Incubator IP clearance.  We have several
>> examples of people showing up with large amounts of code, engaging
>> in the community and contributing patches to their own and other
>> code and earning commit that way.  This has worked for us in the
>> past and is consistent with how things are supposed to work - at
>> least as I understand it - at the A

Re: [PROPOSAL] Validation incubator for JSR-303 Bean Validation

[Phil Steitz]

Joe Schaefer wrote:
> - Original Message 
> 
>> From: Phil Steitz 
>> To: general@incubator.apache.org
>> Sent: Wed, December 30, 2009 3:10:47 PM
>> Subject: Re: [PROPOSAL] Validation incubator for JSR-303 Bean Validation
>>
>> Joe Schaefer wrote:
>>> ----- Original Message 
>>>
>>>> From: Phil Steitz 
>>>> To: general@incubator.apache.org
>>>> Sent: Wed, December 30, 2009 1:30:13 PM
>>>> Subject: Re: [PROPOSAL] Validation incubator for JSR-303 Bean Validation
>>>>
>>>> Joe Schaefer wrote:
>>>>> - Original Message 
>>>>>
>>>>>> From: ant elder 
>>>>>> To: general@incubator.apache.org
>>>>>> Sent: Fri, December 11, 2009 5:22:13 AM
>>>>>> Subject: Re: [PROPOSAL] Validation incubator for JSR-303 Bean Validation
>>>>>>
>>>>>> On Fri, Dec 11, 2009 at 9:56 AM, Niall Pemberton
>>>>>> wrote:
>>>>>>> On Fri, Dec 11, 2009 at 7:56 AM, ant elder wrote:
>>>>>>>> A quick search so there has been some discussion on commons-dev - [1]
>>>>>>>>
>>>>>>>> Does this really need to be incubated - the proposal says its intended
>>>>>>>> to graduate to Apache Commons and replace the existing Validator 1.x
>>>>>>>> component as a new 2.0 codebase, from the discussion on commons-dev
>>>>>>>> everyone seems fine with that out come, and only 2 of the 7 proposed
>>>>>>>> committers are not existing Validator or ASF committers - so couldn't
>>>>>>>> this just go straight to commons as a code grant and make the two new
>>>>>>>> guys committers in recognition of contibuting the new code?
>>>>>>> I raised this on priv...@commons and reported back to d...@commons on
>>>>>>> that discussion here:
>>>>>>>
>>>>>>> http://markmail.org/message/lkyjl6gaxawspgdt
>>>>>>>
>>>>>>> In summary though, there was very little support to go that route and
>>>>>>> some objections.
>>>>>>>
>>>>>>> All commons components share the same set of mailing lists which makes
>>>>>>> it easier for PMC members to provide oversight for the 30+ components
>>>>>>> that live there. As part of this proposal we want to use the commons
>>>>>>> mailing lists for commits and discussion so that by the time this
>>>>>>> podling is ready to graduate the new committers and Commons PMC will
>>>>>>> have a better knowledge of each other and there will be no issue with
>>>>>>> voting in the new committers.
>>>>>>>
>>>>>>> The use of the commons mailing lists is in the proposal and was part
>>>>>>> of the vote held on d...@commons to sponsor this incubation effort:
>>>>>>>
>>>>>>> http://markmail.org/message/mqdft736b5vasezs
>>>>>>>
>>>>>>> Niall
>>>>>>>
>>>>>> From the first email referenced was Roman ever asked if he'd mind
>>>>>> submitting patches for a while to earn Karma if the code did go
>>>>>> straight to commons? Seems a bit a of a shame to need to go the whole
>>>>>> incubation process just for one commit access.
>>>>>>
>>>>>> Re the the poddling use the existing commons mailing lists its may be
>>>>>> worth pointing out this recent thread:
>>>>>> http://apache.markmail.org/message/ifinvq7wqmeoo5ix
>>>>> Commons is badly busted if it can't allow a new person access to his/her
>>>>> own code in a fucking sandbox.  Incubating this project because some 
>>>>> weenies 
>>>> are
>>>>> uncomfortable about the nature of the meritocracy over in commons isn't 
>>>>> the 
>>>> solution:
>>>>> have commons hold a public vote and make an actual decision.  If they 
>>>>> vote 
>> to
>>>>> incubate the damned thing, it's an incredibly stupid decision, but so be 
>>>>> it.
>>>>>
>>>> Hey Joe, the language could be toned down a bit, but I see your
>>>> point.  On the other hand, here is the problem as I see it.

Re: Voting waiting period

[Phil Steitz]

On 2/5/11 4:16 PM, Scott O'Bryan wrote:
> Bertrand,
>
> I agree.  The good thing about a vibrant community is that they
> generally enforce this.  All I'm saying is this shouldn't be a "must"
> requirement, rather it should be a shall and we can let the individual
> communities work out what exceptions they allow.
+1 - but so the whole community can follow what is going on, it is
best to be open about what the "exceptions" can be and also to
include end dates in posts that kick off VOTEs.

Phil
> On Feb 5, 2011, at 2:13 PM, Bertrand Delacretaz  
> wrote:
>
>> On Sat, Feb 5, 2011 at 2:56 PM, Scott O'Bryan  wrote:
>>> ...I think it's important to keep things flexible because, as much as we
>>> would like everything to fit the same rules, some communities need to
>>> be a bit more dynamic and we need to trust the project PMC's and
>>> members to do what's best for the project and community.
>>>
>>> 72 hours is a good suggestion, but it shouldn't be mandatory...
>> A PMC that consistently uses voting periods shorter than 72 hours
>> would disempower people who cannot check the project lists every day.
>>
>> So I think 72 hour must be the rule, though exceptions are ok as you mention.
>>
>> -Bertrand
>>
>> -
>> To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
>> For additional commands, e-mail: general-h...@incubator.apache.org
>>
> -
> To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
> For additional commands, e-mail: general-h...@incubator.apache.org
>
>


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

Re: [DISCUSS] Apache OGNL

[Phil Steitz]

On 4/8/11 7:06 AM, Ralph Goers wrote:
> I don't recall the Commons PMC saying the project needs to be renamed when it 
> voted to sponsor this project.  If that is necessary I'm sure they will let 
> the project know.  
We voted to sponsor OGNL.  Martin is right that our policy is to
avoid the cutesy names, favoring descriptive names instead.  EL and
SCXML are two examples of spec-related Commons components whose
names - conveniently for users - describe what they are.  Unless
there really is a compelling need to change the name from OGNL, it
should stay as is.

Phil
> Ralph
>
> On Apr 8, 2011, at 6:37 AM, Martin Cooper wrote:
>
>> On Fri, Apr 8, 2011 at 12:57 AM, Jeremias Maerki  
>> wrote:
>>> I'm sorry that I can't help out but when reading this I thought that
>>> using the spec name as the project name is probably not ideal. How about
>>> calling it Apache (Commons) Ogranal? Hopefully, this doesn't have any
>>> strange meaning in some language. Just a thought.
>> Commons has a policy of using descriptive names. Yes, there are a few
>> existing projects that don't fit this - ones that were grandfathered
>> in when the policy was introduced - but it would be better to start
>> incubation with a name that would meet Commons' criteria rather than
>> one that will need changing yet again on graduation.
>>
>> A lot of people both within and outwith the ASF know the name OGNL, so
>> unless there's a pressing need, it would make sense to keep it.
>>
>> --
>> Martin Cooper
>>
>>
>>> On 08.04.2011 09:26:43 Simone Tripodi wrote:
 Hi all guys,
 I'm almost ready to submit a new proposal I'm preparing on Wiki[1] for
 Apache OGNL.
 The idea is importing the OGNL project under the Apache umbrella and,
 once/if ready, be promoted in Apache Commons - the Commons PMC already
 voted to be the Sponsor.
 All legal issues have been resolved, we have the Champion - Lukasz
 Lenart - and a great Mentor - Olivier Lamy - what we miss are 2 more
 mentors... any volunteer? :)
 It would be nice also if you can provide your feedbacks, once raw the 
 proposal.
 Many thanks in advance, have a nice day!!!
 Simo

 [1] http://wiki.apache.org/incubator/OGNLProposal

 http://people.apache.org/~simonetripodi/
 http://www.99soft.org/
>>>
>>>
>>> Jeremias Maerki
>>>
>>>
>>> -
>>> To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
>>> For additional commands, e-mail: general-h...@incubator.apache.org
>>>
>>>
>> -
>> To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
>> For additional commands, e-mail: general-h...@incubator.apache.org
>>
>
> -
> To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
> For additional commands, e-mail: general-h...@incubator.apache.org
>
>


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

Re: OpenOffice: were are we now?

[Phil Steitz]

On 6/5/11 11:21 AM, Niall Pemberton wrote:
> On Sun, Jun 5, 2011 at 1:02 PM, Christian Grobmeier  
> wrote:
>> Hi all,
>>
>> I have tried to follow as much as emails as possible but it's
>> overwhelming. Anyway I feel that several questions do not longer
>> belong to the pre-incubation phase but should be clarified after we
>> have accepted the podling. Many questions are around "Can/Should we
>> have a second office community?", "is ASL better or GPL", "can we
>> handle all the dependencies" or "what direction should it go". I mean
>> "svn vs git" is really a topic for the openopffice-dev list.
>>
>> Most of them are all questions we can answer when have a podling - we
>> need votes to decide and a podling population. At the moment its just
>> noise. And to be honest, a separate ML for these issues would be also
>> cool.
>>
>> My question: are we already able to vote for the podling or not?
>>
>> If no - what questions need to be answered before we vote?
> This proposal raises lots of questions, but the requirements for
> entering the incubator are not high and so IMO don't need to be
> answered before a vote. The only reason I believe for rejecting this
> proposal would be because it would be in the best interests of the
> community to not split the FOSS development and compete with
> LibreOffice.
>
> I think we should seriously consider that before voting.
>
> I agree with all the arguments that ASF members have been putting
> forward about the good things for an OO project here at the ASF. I
> much prefer the Apache License and the freedom it provides to that of
> copyleft licenses. The ASF is a great home for projects and has a long
> history with established processes and policies. However, I have great
> respect for what LibreOffice have done and the community they have
> established. The copyleft license isn't ideal IMO, but other than that
> I have great respect for what they've managed to setup and the vibrant
> community that they've established. If LibreOffice hadn't happened
> then I think it would be better to have an OO project here at the ASF.
> But it has and they are too far down the road and have expended too
> much effort to make it appealing for them to join in here.
>
> We should also remember that, with Oracle abandoning OO, we are being
> used to facilitate their business relations with IBM. IBM could (and
> still can) decide to put its efforts into LibreOffice and while we may
> have philosophical differences over license, they surely don't as we
> witnessed when they transferred their efforts from our Harmony project
> to the GPL'd OpenJDK.

Interesting point.  I wonder if there is an explanation for this
inconsistency from the IBM perspective.

> IMO the only negative thing then about LibreOffice is the copyleft
> license - everything else about them is great. When deciding whether
> to accept OO we should consider whether that and facilitating BigCos
> interests is worth splitting the FOSS community.
>
> I am considering voting -1 to this proposal for those reasons.

I share your concerns; but the fact is we have no "content"
requirements in the Incubator.  We have never imposed technical,
political or business requirements on podlings.  As a result, we
have been "used" to promote silly (IMO) middleware bloat and
proprietary code dumps.  On the other hand, we have grown some
decent communities around stuff that smelled at first.  Each time
something smelly like this shows up, I ask myself whether it makes
sense to push for "standards," but I have a hard time coming up with
a set of principles that we would likely agree on.  Can you?

Phil
> Niall
>
>
>> I saw there is a lot of support for this proposal and the initial
>> committers list has grown immense in just a few days. There is already
>> a good amount of mentors and I will add myself too. Code grant seems
>> to be OK and all the other entry criterias seem to be taken. If the
>> would vote would be today, I would vote +1 clearly, because everything
>> we want in the Incubator seem to be solved.
>>
>> Again are we able to vote on the podling? If no, please specifiy why?
>>
>> Cheers,
>> Christian
>>
>> -
>> To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
>> For additional commands, e-mail: general-h...@incubator.apache.org
>>
>>
> -
> To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
> For additional commands, e-mail: general-h...@incubator.apache.org
>
>


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

Re: OpenOffice: were are we now?

[Phil Steitz]

On 6/5/11 3:51 PM, Niall Pemberton wrote:
> On Sun, Jun 5, 2011 at 9:27 PM, Phil Steitz  wrote:
>> On 6/5/11 11:21 AM, Niall Pemberton wrote:
>>> On Sun, Jun 5, 2011 at 1:02 PM, Christian Grobmeier  
>>> wrote:
>>>> Hi all,
>>>>
>>>> I have tried to follow as much as emails as possible but it's
>>>> overwhelming. Anyway I feel that several questions do not longer
>>>> belong to the pre-incubation phase but should be clarified after we
>>>> have accepted the podling. Many questions are around "Can/Should we
>>>> have a second office community?", "is ASL better or GPL", "can we
>>>> handle all the dependencies" or "what direction should it go". I mean
>>>> "svn vs git" is really a topic for the openopffice-dev list.
>>>>
>>>> Most of them are all questions we can answer when have a podling - we
>>>> need votes to decide and a podling population. At the moment its just
>>>> noise. And to be honest, a separate ML for these issues would be also
>>>> cool.
>>>>
>>>> My question: are we already able to vote for the podling or not?
>>>>
>>>> If no - what questions need to be answered before we vote?
>>> This proposal raises lots of questions, but the requirements for
>>> entering the incubator are not high and so IMO don't need to be
>>> answered before a vote. The only reason I believe for rejecting this
>>> proposal would be because it would be in the best interests of the
>>> community to not split the FOSS development and compete with
>>> LibreOffice.
>>>
>>> I think we should seriously consider that before voting.
>>>
>>> I agree with all the arguments that ASF members have been putting
>>> forward about the good things for an OO project here at the ASF. I
>>> much prefer the Apache License and the freedom it provides to that of
>>> copyleft licenses. The ASF is a great home for projects and has a long
>>> history with established processes and policies. However, I have great
>>> respect for what LibreOffice have done and the community they have
>>> established. The copyleft license isn't ideal IMO, but other than that
>>> I have great respect for what they've managed to setup and the vibrant
>>> community that they've established. If LibreOffice hadn't happened
>>> then I think it would be better to have an OO project here at the ASF.
>>> But it has and they are too far down the road and have expended too
>>> much effort to make it appealing for them to join in here.
>>>
>>> We should also remember that, with Oracle abandoning OO, we are being
>>> used to facilitate their business relations with IBM. IBM could (and
>>> still can) decide to put its efforts into LibreOffice and while we may
>>> have philosophical differences over license, they surely don't as we
>>> witnessed when they transferred their efforts from our Harmony project
>>> to the GPL'd OpenJDK.
>> Interesting point.  I wonder if there is an explanation for this
>> inconsistency from the IBM perspective.
>>
>>> IMO the only negative thing then about LibreOffice is the copyleft
>>> license - everything else about them is great. When deciding whether
>>> to accept OO we should consider whether that and facilitating BigCos
>>> interests is worth splitting the FOSS community.
>>>
>>> I am considering voting -1 to this proposal for those reasons.
>> I share your concerns; but the fact is we have no "content"
>> requirements in the Incubator.  We have never imposed technical,
>> political or business requirements on podlings.  As a result, we
>> have been "used" to promote silly (IMO) middleware bloat and
>> proprietary code dumps.  On the other hand, we have grown some
>> decent communities around stuff that smelled at first.  Each time
>> something smelly like this shows up, I ask myself whether it makes
>> sense to push for "standards," but I have a hard time coming up with
>> a set of principles that we would likely agree on.  Can you?
> No I can't - but if enough people have concerns then theres probably a
> good reason for it. If not then it deserves to pass.

Agreed.  I wish I had a clearer idea of what constitutes a good
reason to reject an incubator proposal on principle, though - even
just a good enough reason to reject this one.  As long as there is
some promise of building a community and IP / gr

Re: OpenOffice: were are we now?

[Phil Steitz]

On 6/5/11 10:16 PM, William A. Rowe Jr. wrote:
> On 6/5/2011 11:43 PM, Phil Steitz wrote:
>> Agreed.  I wish I had a clearer idea of what constitutes a good
>> reason to reject an incubator proposal on principle, though - even
>> just a good enough reason to reject this one.  As long as there is
>> some promise of building a community and IP / grant issues are not
>> insurmountable, we tend to say yes.  In the present case, we are
>> avoiding discussion of two core issues:
>>
>> 0) Where do we draw the line in terms of commercial exploitation of
>> the ASF and the apache brand - and how do we even define "exploitation"?
>> 1) Do we feel obligated to "do no harm" to OSS communities outside
>> of the ASF?
>>
>> I know there is an easy answer to 1) that "competition is OK; we
>> have that inside the ASF ... blah, blah" but that is rationalization
>> in this case.  We are talking about *the same codebase* and
>> basically forking the community.  Is that consistent with our
>> mission?   If not, is that inconsistency a "good reason" to reject
>> an incubator proposal?
> Actually, we aren't, and the TDF/LO project will tell you as much.
> They have made a great deal of progress and diverged from Oracle's
> code.  In the interim, contributors continue to patch OOo code.  So
> these are not the same, now.  But even if they were, every fork
> starts at the same place as its parent; you comment is nonsense.
>
> A TDF package would likely leverage GPL resources such as icon sets,
> fonts, and other desktop elements that we routinely reject from the
> ASF code.  An ASF package would likely leverage BSD licensed icon
> sets and the like (or at least under an appropriate CC license, not
> NoDerivatives).  These have diverged and will continue to diverge.
>
> There is a host of code at the center that can, and should continue
> to be commons, for the benefit of everyone, and that's what these
> lengthy discussions are all about.
>
> If you want examples of commercial "exploitation", we aught to have
> rejected stdcxx (used ongoing by RougeWave after graduation), and
> Geronmio (used ongoing by IBM after graduation) etc etc etc.
>
> There is a real question here; does the fork at the incubator seek
> to do something that can't be accomplished at the parent (child, in
> this case) project?  The answer is yes, the licensing differs, and
> the ASF is in a position to obtain the entire codebase under more
> liberal license terms than existing commercial exploiters had paid
> for, previously.  That is a quantitative and qualitative difference.
>
> But what if a dozen committers came to us from project X, and asked
> to begin a fork, for the only reason that they couldn't get along
> with the personalities at the existing project.  Would we say no?
> I tend to doubt it; if there were willing mentors and it appeared
> that the proposers were serious in moving the code forward, I guess
> that the incubator would say yes.  And this is extreme example is
> clearly not what we are talking about with OOo.
>
>> Item 0) is harder.  I don't think we have anything close to
>> consensus on what is OK.  Many of us seem to have just accepted the
>> fact that companies use the ASF to "collaborate as peers" and there
>> is nothing wrong with BigCos using the ASF as a low risk, low cost
>> environment for commercial software development.  As long as
>> individuals can at least in theory also get involved and the paid
>> developers play by the ASF rules, many (most?) of us seem to be OK
>> with it.  So other than exclusionary practices or smoke-filled room
>> decision-making what do we object to?  Projects that produce only
>> cripple-ware or encourage lock-in to closed source commercial
>> products?  Projects that damage other OSS communities?
>>
>> I admit that I am more conservative than most on the issues of
>> growth and commercialization that we have been wrestling with
>> @apache for as long as I have had the privilege of being involved 
>> here.  That conservatism leads me to recommend strongly that we take
>> the items above very seriously and consider taking a more selective
>> approach to what we allow in the incubator and a more hard line
>> approach on how we engage with commercial entities.  I am on the
>> fence in the present case.  Personally, I think we do have an
>> obligation to "do no harm" or at least "do no harm needlessly" to
>> external OSS communities and there is more to the ASF that the ASL. 
>> I also think it is appropriate for us to consider whether we, the

Re: OpenOffice: were are we now?

[Phil Steitz]

On 6/5/11 11:02 PM, William A. Rowe Jr. wrote:
> On 6/6/2011 12:47 AM, Phil Steitz wrote:
>> On 6/5/11 10:16 PM, William A. Rowe Jr. wrote:
>>> ASF members wish to devote considerable time and energy to this
>>> project, so exactly who the hell are you to decide what they should
>>> and shouldn't devote that time and energy to?
>> I am just a volunteer who has seen the ASF struggle with
>> growth-related issues for several years now.  I think it is a fair
>> question to ask whether we should think about different / more
>> selective criteria for entrance to the incubator.  Sorry if asking
>> that question offends you.
> To clarify this, because we have so many guests and observers trying
> to figure out the ASF...
>
> Sufficient numbers of board members, ASF members and even incubator
> team members have signed up as mentors.
>
> But more to the point, the central premise of the ASF is to facilitate
> developers to scratch their own itch.  If improving particular processes,
> code or documentation interests you, by all means, do it.  If some part
> of the code holds no interest to you, let someone else.  And if you come
> to the ASF (even as a user) complaining about a particular piece of code,
> bring a patch, not a complaint, if you "expect" it to be fixed.
>
> The mentor list suggests to me that there are enough volunteers for
> this particular itch to accept it for graduation.  Phil, you are not
> responsible and should not feel responsible to follow the activities of
> this project if it truly isn't your itch.

Sorry, Bill, but as an ASF member I am in fact responsible for
everything that the foundation does, including what we decide to
accept into the Incubator.  Of course, I am just one member, and we
make these decisions by consensus.  If the consensus is to accept
this podling, I will welcome the project and accept the
responsibility that we all will share having made that decision.
> To address your concern, we should raise this issue to the board and
> set a policy of accepting no further projects, if your opinion is shared
> by the rest of the incubator PMC. 

I did not suggest that we stop accepting projects.  Read the post. 
I suggested that we try to come up with some principles governing
what we accept into the incubator.

>  That concern need not be applied on
> a project-by-project basis (except to ensure there are sufficient number
> of interested mentors).
Whatever principles we end up agreeing on should be applied to all
candidate podlings.  If just having enough mentors willing to sign
up were sufficient, there would be no need for a vote of the IPMC.  

Phil
> -
> To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
> For additional commands, e-mail: general-h...@incubator.apache.org
>
>


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

Re: OpenOffice: were are we now?

[Phil Steitz]

On 6/5/11 11:26 PM, William A. Rowe Jr. wrote:
> On 6/6/2011 1:06 AM, Sanjiva Weerawarana wrote:
>> On Mon, Jun 6, 2011 at 11:17 AM, Phil Steitz  wrote:
>>
>>> On 6/5/11 10:16 PM, William A. Rowe Jr. wrote:
>>>> Wow.  Did it occur to you that the original project, Apache httpd,
>>>> was commercially exploited by vendors *even prior to the creation
>>>> of the Apache Software Foundation*?
>>> There is a difference between commercial entities using code vs
>>> manipulating communities.  Clearly we disagree on this and what the
>>> ASF is for.  Fine.  I hope there is room for both of our views.
>> I'm totally in agreement with Phil. There is a BIG difference in the two
>> positions and I for one would not support ASF being exploited. ASF products
>> being used for commercial success is absolutely superb.
> Let's clarify exploitation.  This is a code dump (exploitative) with
> another group (IBM folks + OOo folks) to accept responsibility for it
> (counter-exploitative).
>
> No exceptions are made to our process, changes to the language of the
> the grant letter were not accepted.  The proposers submit their idea
> to the incubator, just as all others must submit their ideas for the
> incubator to consider, vote upon, mentor and guide, and hopefully,
> graduate to a TLP.  No exceptions.
>
> The code is not available to developers under a permissive license,
> this offer is to incubate the code under a permissive license.  It has
> willing committers, and mentors.
>
> So what I'm asking is, what is the exploitation?  That is a charged
> allegation.  I initially thought the same until I read all of the
> background on the history and current composition of OOo consumers.
>
>>>> ASF members wish to devote considerable time and energy to this
>>>> project, so exactly who the hell are you to decide what they should
>>>> and shouldn't devote that time and energy to?
>> Um Bill you really should cool it a bit .. why are you getting so hot about
>> it? Phil too is a long standing member of the ASF and has every right to
>> comment on this!
> Yes, if he will clarify what is exploitative, otherwise the post is FUD.
>
> To be clear; OOo was not part of LO, although it was consumed by LO.
> OOo has players which use the code differently and under more flexible
> license than LO has.  If Oracle incorporated OOo as a 501(c) and granted
> OOo an AL to all of the code and divested itself of the OOo foundation,
> would that have been exploitative?  If not, then where is the exploitation
> of the ASF facing the same prospects as an independent OOo organization?
>
>>> I am just a volunteer who has seen the ASF struggle with
>>> growth-related issues for several years now.  I think it is a fair
>>> question to ask whether we should think about different / more
>>> selective criteria for entrance to the incubator.  Sorry if asking
>>> that question offends you.
>> +1. Those (esp. members) who find that question offensive need to take a
>> cold shower.
> Or rather, the incubator needs to evaluate current proposals on its current
> methodology, and (in a quiet time between proposals) generate more specific
> criteria for incubation, independent of any particular proposal.  I just
> find it rude to change the rules of the game during the match.

That is a fair point and I will shut up about this now, other than
to answer your question about "exploitation" that is germane to this
proposal.   One way to look at this proposal is to see it as an
attempt to use the ASF brand and infrastructure to fork a
community.  That is exploitative.  Other threads have argued both
sides of this fully.  People can come to their own conclusions. My
point was that we can't really assess this without getting clearer
on what we mean by exploitation and how much of it we are willing to
tolerate.  Again, read the post carefully and you will understand my
intent. 

Phil
>
> -
> To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
> For additional commands, e-mail: general-h...@incubator.apache.org
>
>


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

Re: [VOTE] Accept OpenOffice.org for incubation

[Phil Steitz]

-1

I do not think that accepting this podling is in the best interest
of the ASF.   Absent explicit criteria / principles governing what
we accept into the Incubator, I have to apply informal judgment here
and I am voting -1 for the following reasons:

0) I think the ASF has a responsibility to consider the broader
community impacts of our actions.  Arguments have been presented on
both sides of this issue here and elsewhere.  My personal conclusion
is that this is not a *good thing* for the ASF to do.

1) The Incubator exists to provide a means for communities to join
the ASF.   I am not comfortable that this proposal is consistent
with that mission.  I know this proposal is not unique in
representing a commercial collaboration and we have never drawn any
lines defining what is acceptable / not acceptable in commercial
exploitation of the ASF brand and infrastructure.  Absent that, I
have to apply judgment here and my personal opinion is that this
proposal crosses the line.

I respect and acknowledge the efforts of the ASF and other
volunteers working to build a community around this proposal and
should this VOTE pass, I will join the other ASF members in
welcoming the new volunteers to the ASF.

Please respect the VOTE subject line above and refrain from
responding to this post in the same thread.  Please also review the
links Sam posted before repeating arguments already presented. 

Phil

 

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

Re: [DISCUSS] Sanselan as a Commons library

[Phil Steitz]

Craig L Russell wrote:

Hi,

The Sanselan podling [1] has been incubating since 2007 and has 
achieved most of the goals in incubation:


Code has been released [2] according to the incubator release guidelines
Status is up to date [3]
Community mailing lists are responded to promptly [5]
JIRA issue tracking is in use [4]
Web site with sample code and download is available

The last item before graduation is activity and diversity, which are 
lacking. There were a few developers during the project but now we 
have only one active developer. And it's not clear that we will be 
able any time soon to attract more developers to fulfill the 
requirements.


While discussing Sanselan in the incubator, it appears that there are 
three end points for the podling:


1. Fail incubation and reject Sanselan
2. Continue (indefinitely?) to incubate Sanselan
3. Graduate Sanselan as a sub-project of another TLP

It appears to many of us that option 3 is the best way forward.

It also appears that Commons might be a good fit for the project.
Before getting into the administrative questions below, the first 
question to ask is can we grow a community around this component in 
commons.  The lack of activity is a concern.  Is anyone interested in 
coding on this? 


Phil


I have some questions to kick off a discussion:

1. It appears that d...@commons is the general mailing list for all 
commons projects. Would a small project like sanselan get lost in the 
traffic?


2. Most commons components have a "functional" name instead of a "fun" 
name. Would Sanselan need to be renamed, e.g. Commons Image, or would 
it be ok to have the sub-project called Sanselan, or Commons Sanselan?


3. Would any changes be required from the existing packaging of 
Sanselan? For example, packages are named org.apache.sanselan. Would 
these need to be renamed to org.apache.commons.sanselan (or less fun 
name as above)?


If any additional oversight is needed to accept Sanselan, I'd be happy 
to contribute as PMC member.


Thanks,

Craig

References:
[1] http://incubator.apache.org/projects/sanselan.html
[2] http://incubator.apache.org/sanselan/site/index.html
[3] http://svn.apache.org/repos/asf/incubator/sanselan/board/
[4] https://issues.apache.org/jira/browse/SANSELAN
[5] http://mail-archives.apache.org/mod_mbox/incubator-sanselan-dev/

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




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

Re: [Proposal] Jini Project

[Phil Steitz]

+1 (as in "will help").

From the text below and the comments in

,
I assume that the scope of the project will just be the core
infrastructure.  But you also mention "related utilities and tools."
Can you clarify a little more how the scope is defined?

Phil

On 6/19/06, Jim Hurley <[EMAIL PROTECTED]> wrote:

This proposal seeks to create a project within the Apache Software
Foundation to continue the development and advancement of Jini
technology. It has broad backing from the Jini Community, and
includes core developers from Sun Microsystems (original developer
of the technology) as well as Community technical leaders.

Thank you for your consideration.


---
JiniProposal

*Proposal for new project Jini*

19 June 2006
---

(0) rationale

Jini technology is a service oriented architecture that defines a programming
model which both exploits and extends Java technology to enable the construction
of secure, distributed systems consisting of federations of services and
clients. Jini technology can be used to build adaptive network systems that are
scalable, evolvable and flexible as typically required in dynamic computing
environments.

Quoting from The Jini Specifications 
book:
  "Jini technology is a simple infrastructure for providing services in a
   network, and for creating spontaneous interactions between programs that
   use these services. Services can join or leave the network in a robust
   fashion, and clients can rely upon the availability of visible services,
   or at least upon clear failure conditions. When you interact with a service,
   you do so through a Java object provided by that service. This object is
   downloaded into your program so that you can talk to the service even if
   you have never seen its kind before - the downloaded object knows how to
   do the talking. That's the whole system in a nutshell."

Sun Microsystems originally introduced the technology in January, 1999 by
providing a Jini Technology Starter Kit . This
includes a contributed implementation of all of the specifications, as well as
helpful utilities and tools. The source code was made available through the Sun
Community Source License (SCSL) as an attempt to make the code widely available
and accessible to both individuals and companies. Sun has continued to innovate
throughout the years, releasing many versions of the starter kit. The license
associated with the starter kit was changed

in March, 2005 to the Apache License, Version 2.0.

Since its beginning, there was desire and effort to form a developer community
around the technology. This has helped to create an interesting, active, and
passionate community - the Jini Community. This global Community has engaged on
technology projects, discussions and debates, events, and a decision making
process. It has contributed to, and helped influence the direction of the
starter kit. Some of the collaborative technology projects have led to key
contributions being used by other technology projects as well as commercial
products. One example is the Service UI API 
,
which is a way to attach user interfaces to Jini services.

Despite the obvious successes of the technology and Community, some changes are
in store as outlined in a recent note to the Community: "A New Day"
.
The most critical part of the new plan is to find the right place for the future
development and advancement of the core Jini technology. We wanted an
environment that was synergistic with our exisiting Community culture -- so one
that is active, with open communication and collaboration, and a reputation for
producing high quality software. We think we've found that place with the Apache
Software Foundation.

(0.1) criteria

/Meritocracy:/

The Jini project will be meritocractic. The project will follow the guidelines
 of the Apache
Software Foundation. In order to achieve this, we plan on proactively recruiting
individuals in the Community to get involved in the project: specifying work
that needs to be done, encouraging bug fixes, enhancements, and advancements,
and engaging in discussion on how the code works and is structured. In the end,
we are committed to creating an environment to foster a meritocracy.

/Community:/

There has been a diverse and active Community built around Jini technology since
it was first introduced in January, 1999. The Jini Community consists of a
global set of individuals, companies, non-profit organizations, and
universitie

Re: [Proposal] Jini Project

[Phil Steitz]

On 6/21/06, Geir Magnusson Jr <[EMAIL PROTECTED]> wrote:



Leo Simons wrote:
> On Mon, Jun 19, 2006 at 10:15:38AM -0400, Jim Hurley wrote:

>
> Let the records show that Geir is listed as initial committer too yet probably
> doesn't work at sun, unless he switched companies again :)

Hey, it's been 6 months already, but no, I'm still at Intel. :)

>
>> * Mentor
>> - Geir Magnusson Jr.
>
> Lately popular opinion seems to be that it'd be good if there were at least
> three mentors. Any others?

The snippet you quoted is bait :)

We figured that we'd have people volunteering once this was proposed and
 people saw that there was only me.

So please, volunteers for mentor wanted and very welcome!  At least 3 more!


I will volunteer to be a mentor for this.

Phil

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: [Proposal] Jini Project

[Phil Steitz]

On 6/22/06, Mark Brouwer <[EMAIL PROTECTED]> wrote:

Niclas Hedhman wrote:
> On Wednesday 21 June 2006 19:19, Leo Simons wrote:
>
>> What I'm missing is an idea of the interaction between jini.org and this
>> proposed new apache project, and an idea of the interaction between the JCP
>> process and the apache project. Eg is the apache project a (reference?)
>> implementation of a bunch of JCP specs managed through jini.org (in which
>> case I'd say it needs a new name), is it a 'full' move from jini.org to
>> jini.apache.org, or something else?
>
> It has been discussed that jini.org will serve as a "information portal", with
> links to docs, specs, implementations, the starter kit, and so forth.
> The Apache project will first be the center of coding of the starter kit, and
> other useful generic tools.
>
> It has not yet been decided what exactly should happen to the specifications
> and related process (JDP). Many people like the JDP, but also recognizes the
> overhead needed to keep it running. One alternative that has been discussed
> is to let the Jini TLP manage the JDP (with a couple of amendments) as well.

I think it is good to mention there is a distinction between
specifications and standards in the Jini community. Most of the Jini
related specifications were developed by Sun in a way that allowed input
of others, but Sun was the sole entity that made the decision about
what went into these specifications. The Jini community has a democratic
process (JDP) that provides balance between commercial and individual
stakeholders and to which people could submit their specification to
have that blessed as a community approved standard (all got accepted so
far, so Sun did apparently well).

The initial goals of Jini can only be reached if compatibility is high
on the agenda of everybody involved and standards were a way to achieve
that, in the past there was even a license that commanded compatibility
but that one has been replaced by the Alv2. Also at the start of the
Jini community in 1999 it was thought of that a democratic process such
as the JDP was the best way to ensure that all stakeholders could have
their say in whether some specification would be approved as standard
and that it would unity us instead of divide.

Bringing the Jini specs (the community approved standards) into an ASF
project without a JDP like process can IMHO be seen as monopolizing
what is perceived as Jini. Whether that is a good thing or a bad thing
is up to the reader ;-)

> My personal stance is that it is an issue that is not urgent, and can be
> discussed through incubation.

I disagree here, some people in the Jini community find it important to
know in advance which way this is heading, e.g. to hedge their risks
using or investing in this technology and determine their own future path.


I think Niclas' point is that this can be discussed and decided during
incubation, along with lots of other things about how the project and
community are going to work, as opposed to having to be determined in
advance.  Since it seems to be an important issue in the community,
though, we should probably discuss it early on.  One thing to keep in
mind is that assuming successful incubation, the Jini community will
have broad latitude in terms of decision-making processes.  Part of
the incubation process is setting these things up.

Phil

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: primary email, balanced use of IRC

[Phil Steitz]

On 6/23/06, David Crossley <[EMAIL PROTECTED]> wrote:



Being there in real time is also difficult.



This effectively cuts out a lot of people.  For partly selfish
reasons, I would hate to see apache projects trend toward more
synchronous communications requirements.


That is why the summary is so important.






Have any communities consistently turned summaries into discussions?
Have people been able to "jump in" to archived IRC log discussions
meaningfully?  Take these as naive questions from someone with limited
experience reading / interacting with IRC logs or participating in IRC
discussions.

Phil

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

[IP Clearnance] Jakarta Commons - Mantissa donation

[Phil Steitz]

The Jakarta Commons community has voted to accept a donation from Luc
Maisonoble of the Mantissa math library, for inclusion in Jakarta
Commons Math.

The IP clearance form is checked into /ip-clearance as
jakarta-commons-mantissa.xml.

The source is here:
http://www.spaceroots.org/software/mantissa/mantissa-for-commons-math.zip

Luc has submitted an CLA and software grant, both of which have been
acked and recorded.  The grant was updated to refer to the final
codebase (excluding some classes for which he could not claim sole
ownership) and MD5.  Ack of the modified grant is still pending.

We would like to bring the code into Jakarta svn.  If there are no
objections before 15-Oct-06, I will commit the code into jakarta svn
and we will begin the process of repackaging and incorporating
selected modules into commons-math.

Thanks!

Phil

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: [VOTE] Incubate new podling, "River" (nee Braintree, nee..., nee Jini)

[Phil Steitz]

+1

Phil

On 12/20/06, Niclas Hedhman <[EMAIL PROTECTED]> wrote:

On Thursday 21 December 2006 11:46, Geir Magnusson Jr. wrote:
 [x] +1 Accept River as a new podling as described below
 [ ] -1 Do not accept the new podling (provide reason, please)

non-binding.


Cheers
Niclas

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]




-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Request to be added to Incubator PMC

[Phil Steitz]

I would like to join the Incubator PMC.  I am an ASF member and,
pending a positive acceptance vote, will be serving as a mentor for
the new "River" project.

Thanks!

Phil

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: [VOTE] Graduate Synapse

[Phil Steitz]

On 12/26/06, Paul Fremantle <[EMAIL PROTECTED]> wrote:


The Synapse incubator is therefore asking the Incubator PMC to graduate
the
Synapse project into the Apache Web Services PMC. Synapse heavily
integrates with other WS projects including Axis2, Axiom, Sandesha,
Rampart.

Please send in your +1/0/-1 to approve/abstain/disapprove.



+1

Phil

Re: [VOTE] Should we treat incubator releases differently to normal releases

[Phil Steitz]

On 3/21/07, robert burrell donkin <[EMAIL PROTECTED]> wrote:


On 3/19/07, Ted Husted <[EMAIL PROTECTED]> wrote:
> On 3/15/07, Craig McClanahan <[EMAIL PROTECTED]> wrote:
> > If these are indeed going to be official releases, we should totally
> > dispense with the requirements for "-incubating" in artifact filenames
> > and version numbers, let them announce the releases on announcements@
> > mailing lists, and all the other accouterments of a normal project
> > release.  If they are not going to be official releases, the state of
> > the world before this vote seems to make sense.
>
> I'd say that they are not official releases of the podling, but they
> are official releases of the Incubator PMC. Therefore, appending or
> prefixing the releases with "-incubating" or "incubator-" is
> appropriate.

+1

(saves me posting this point :-)



+1 for keeping -incubating and disclaimer notices
+1 for putting tarballs into /dist (they are releases)
+1 for eliminating unmirrored m2 repo

I agree with Craig that our decision to allow incubating projects to cut
releases means that we can't consider them "quasi-nightlies" - i.e., they
are either ASF releases or they are not.  Assuming they are, infra@ makes
the call where they live, and that is /dist.

Phil

[Proposal] Java Resource Simulator (JRS)

[Phil Steitz]

mmitters, with one being
an active ASF member. All have been involved with source code that has
been released under an open source license and with internal open
source projects.

Homogeneous developers
--
Since the Java Resource Simulator has been developed to date by
American Express, the initial contributors to the project are
associated with that corporation, though not all are employees of
American Express. They are experienced working in a geographically
distributed and diverse team and they have a broad range of
experiences with open source, industry standards, emerging
technologies and product development. Furthermore, our strong
intention is to attract a diverse set of additional committers, beyond
the initial contributors and current Apache committers listed below.

Reliance on salaried developers
-
It is expected that, at the beginning, JRS development will occur on
both salaried time and on volunteer time, after hours. While there is
reliance on developers associated with American Express, through the
incubation process, we expect the independent Community to become
actively involved in the project.

No ties to other Apache products
---
JRS currently uses or is planned to use a number of Apache and other
open source projects. These have been outlined above.

A fascination with the Apache brand
---
JRS has been started as a response to real and critical needs of
development projects over many years. The originating environment has
been IT internal of a non-software company, as such there was/is no
need to associate the Apache brand with JRS. We believe that JRS will
solve in an elegant and lightweight manner development lifecycle
problems and, as such, we are interested in the best way for the
project to develop and flourish. We have no interest or intention of
"productizing" JRS for commercial purposes or offering paid services
associated with its use; though part of our motivation for pursuing
open development of JRS under the ASL is that this will not prevent
others from doing so.

Scope of the project

The scope of the JRS project at ASF would be to continue the product
development and would include adding new features and improving
performance, scalability, quality, and extensibility.

Documentation
-
Documentation is available on request. See below.

Initial source
-
Until the project has been accepted, code grant executed and ASL
applied, we do not want to make the sources publicly available. This
is in part because the sources currently include license headers
inconsistent with public distribution. Interested parties may
individually contact the proposal Champion below to work out the
logistics of access to the source code during proposal review.

Source and Intellectual Property Submission Plan
---
American Express is prepared to submit a code grant and a CCLA and to
license all JRS code under the ASL. All rights to the current codebase
are owned by American Express. The initial committers have or will all
submit ICLAs.

External Dependencies
--
The current implementation depends on the following components:
   * XStream- BSD- [WWW] http://xstream.codehaus.org/license.html
   * JUnit- CPL - [WWW] http://www.opensource.org/licenses/cpl.php
   * Maven - ASF
   * Log4J - ASF
   * J2EE API - CDDL
   * XPP3 - [WWW]
http://www.extreme.indiana.edu/viewcvs/~checkout~/XPP3/java/LICENSE.txt
All dependencies have ASL or ASL-compatible licenses.

Cryptography
-
JRS currently makes no direct use of cryptographic functions.

Required resources
---
Mailing lists

   * jrs-private (with moderated subscriptions)
   * jrs-dev
   * jrs-commits
   * jrs-user

Subversion or CVS repositories
-
JRS would like to use a Subversion repository: [WWW]
https://svn.apache.org/repos/asf/incubator/jrs

Issue tracking

Since JRS would have its own release cycle, it should have its own JIRA project
  * Project Name: JRS
  * Project Key: JRS

Initial set of committers
---
   * Brendan McCarthy (brendan_dot_mccarthy_at_ gorillalogic_dot_com)
   * Tony Ambrozie (tony_dot_a_dot_ambrozie_at_aexp_dot_com)
   * Phil Steitz (psteitz_at_apache_dot_org)
   * Ian Gray (ian_dot_d_dot_gray_at_aexp_dot_com)
   * Rahul Akolkar (rahul_at_apache_dot_org)
   * Sebastian Bazley (sebb_at_apache_dot_org)
   * Martin van den Bemt (mvdb_at_apache_dot_org)
   * Henri Yandell (bayard_at_apache_dot_org)

Affiliations
-
Tony Ambrozie, Phil Steitz and Ian Gray are employees of American
Express. Brendan McCarthy is an employee of Gorilla Logic, w

Re: [Proposal] Java Resource Simulator (JRS)

[Phil Steitz]

On 6/24/07, Leo Simons <[EMAIL PROTECTED]> wrote:

On Jun 24, 2007, at 8:24 PM, Phil Steitz wrote:
> This is a proposal to develop a Java-based interface response
> capture/playback tool.

Interesting proposal. Seems useful.

> Documentation
> -
> Documentation is available on request. See below.
>



> Initial source
> -
> Until the project has been accepted, code grant executed and ASL
> applied, we do not want to make the sources publicly available. This
> is in part because the sources currently include license headers
> inconsistent with public distribution. Interested parties may
> individually contact the proposal Champion below to work out the
> logistics of access to the source code during proposal review.

I don't think we've done it this way before. I can understand not
wanting to make source openly available, but I don't like that "to
work out logistics of access" happens individually, and the "on
request" makes me a bit itchy, too.



Its not really a matter of not wanting to, just the current license
headers make posting it publicly dicey and there is also the issue of
where to put it.  I am assuming that until the grant is executed
~psteitz is not OK.


I think if you do things this way you should at least implement a
clear, open, privacy-respecting, documented and non-discriminating
logistics thingie (along the lines of "tarball is at https:///,
contact me for username/password. We won't use your contact details
in any way except to provide you the username/password.").


Agreed.  There is no intention to discriminate or limit in any way.

What have others done to workaround the bootstrapping problem for code
that is currently internally licensed / restricted distribution before
the proposal is accepted and a grant can be executed?

Phil

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: [Proposal] Java Resource Simulator (JRS)

[Phil Steitz]

On 6/24/07, Eelco Hillenius <[EMAIL PROTECTED]> wrote:

> What have others done to workaround the bootstrapping problem for code
> that is currently internally licensed / restricted distribution before
> the proposal is accepted and a grant can be executed?

My understanding is that whether projects get accepted for incubation
don't have to do much with the code you currently have, but rather
about the motivations, community aspects etc. So why include this
clause in the first place? Why not say you start with a clean slate
and start adding source to the repository when they are deemed ready
for that?


In retrospect, that may have been a better approach.  The value of
making the code available is to clarify the technical ideas in the
proposal.  Looking at the initial source code in an incubator proposal
can make it clearer where the project is starting from.  In this case,
there is a working code base to start from and I thought it would be
good to make it available for people to look at.  Unfortunately, I
can't just post the code on a public web site at this point, so I
probably should have just said it was not available.  Unless anyone
has better suggestions than what I put in the proposal, I will modify
the proposal to just state that there is a working initial codebase
that will be granted, relicensed and reviewed for acceptance by the
ppmc assuming the project is accepted, but the initial source is not
available for review at this time.

Phil


Eelco

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]




-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: [Proposal] Java Resource Simulator (JRS)

[Phil Steitz]

On 6/24/07, Henning Schmiedehausen <[EMAIL PROTECTED]> wrote:

Is this a legal issue (you need clearance) or just a matter of "well,
there are a bazillion of wrong/strange/bad license headers with (C)'s
inside that we want to clean up first and need time"?



We have clearance to execute a code grant and CCLA.  That is not a
problem.  It is more the latter, making sure what we make publicly
available is appropriately licensed.

Phil

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

[Vote] Accept JRS project for incubation

[Phil Steitz]

oject are
associated with that corporation, though not all are employees of
American Express. They are experienced working in a geographically
distributed and diverse team and they have a broad range of
experiences with open source, industry standards, emerging
technologies and product development. Furthermore, our strong
intention is to attract a diverse set of additional committers, beyond
the initial contributors and current Apache committers listed below.

Reliance on salaried developers
-
It is expected that, at the beginning, JRS development will occur on
both salaried time and on volunteer time, after hours. While there is
reliance on developers associated with American Express, through the
incubation process, we expect the independent Community to become
actively involved in the project.

No ties to other Apache products
---
JRS currently uses or is planned to use a number of Apache and other
open source projects. These have been outlined above.

A fascination with the Apache brand
---
JRS has been started as a response to real and critical needs of
development projects over many years. The originating environment has
been IT internal of a non-software company, as such there was/is no
need to associate the Apache brand with JRS. We believe that JRS will
solve in an elegant and lightweight manner development lifecycle
problems and, as such, we are interested in the best way for the
project to develop and flourish. We have no interest or intention of
"productizing" JRS for commercial purposes or offering paid services
associated with its use; though part of our motivation for pursuing
open development of JRS under the ASL is that this will not prevent
others from doing so.

Scope of the project

The scope of the JRS project at ASF would be to continue the product
development and would include adding new features and improving
performance, scalability, quality, and extensibility.

Documentation
-
Documentation is available on request. See below.

Initial source
-
Initial source code for the project will be granted (see next section)
to the ASF on acceptance of this proposal and once granted it will be
made publicly available and the normal Incubator IP Clearance process
will be followed to approve inclusion of the initial sources in the
project source repository.

Source and Intellectual Property Submission Plan
---
American Express is prepared to submit a code grant and a CCLA and to
license all JRS code under the ASL. All rights to the current codebase
are owned by American Express. The initial committers have or will all
submit ICLAs.

External Dependencies
--
The current implementation depends on the following components:
  * XStream- BSD- [WWW] http://xstream.codehaus.org/license.html
  * JUnit- CPL - [WWW] http://www.opensource.org/licenses/cpl.php
  * Maven - ASF
  * Log4J - ASF
  * J2EE API - CDDL
  * XPP3 - [WWW]
http://www.extreme.indiana.edu/viewcvs/~checkout~/XPP3/java/LICENSE.txt
All dependencies have ASL or ASL-compatible licenses.

Cryptography
-
JRS currently makes no direct use of cryptographic functions.

Required resources
---
Mailing lists

  * jrs-private (with moderated subscriptions)
  * jrs-dev
  * jrs-commits
  * jrs-user

Subversion or CVS repositories
-
JRS would like to use a Subversion repository: [WWW]
https://svn.apache.org/repos/asf/incubator/jrs

Issue tracking

Since JRS would have its own release cycle, it should have its own JIRA project
 * Project Name: JRS
 * Project Key: JRS

Initial set of committers
---
  * Brendan McCarthy (brendan_dot_mccarthy_at_ gorillalogic_dot_com)
  * Tony Ambrozie (tony_dot_a_dot_ambrozie_at_aexp_dot_com)
  * Phil Steitz (psteitz_at_apache_dot_org)
  * Ian Gray (ian_dot_d_dot_gray_at_aexp_dot_com)
  * Rahul Akolkar (rahul_at_apache_dot_org)
  * Sebastian Bazley (sebb_at_apache_dot_org)
  * Martin van den Bemt (mvdb_at_apache_dot_org)
  * Henri Yandell (bayard_at_apache_dot_org)

Affiliations
-
Tony Ambrozie, Phil Steitz and Ian Gray are employees of American
Express. Brendan McCarthy is an employee of Gorilla Logic, working
under contract to American Express. The rest are ASF committers
working for distinct companies. As individuals, none of the ASF
committers have any contract or employment relationship with American
Express.

Sponsors
-
Champion
---
 * Phil Steitz

Nominated Mentors

  * Phil Steitz
  * Sebastian Bazley
  * Martin van den Bemt
  * Henri Yandell

Sponsoring Entity
--

[Result] [Vote] Accept JRS project for incubation

[Phil Steitz]

This vote has passed.

Incubator PMC (binding)
8 +1 votes (martinc, mvdb, pzf, jukka, brett, rdonkin, leosimons, clr)
no - votes

5 +1 non-binding votes, no non-binding - votes

I will start the process of making infrastructure requests and clearing IP.

Thanks!

Phil

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: [PROPOSAL] PMC Vote to incubate Directory Project

[Phil Steitz]

I have been following this thread with interest and have found the 
discussion very informative. Thanks to all who have provided insight for 
those of us with less knowledge and experience with the Apache way.

I have been a bit surprised by the lack of discussion about the merits 
of the proposal per se.  Does this mean that all are agreed that a 
directory services implementation as described in the proposal would 
make a good asset for Apache?

As an Apache committer (not an ASF member or even PMC member) who is 
committed to supporting the project, I would at least like to express my 
strong opinion that this would be a good thing for Apache.  Here are 
just a few reasons (mostly covered in the Proposal):

* Several Apache projects (Geronimo, James, Tomcat) either have direct
  immediate need or could be nicely extended by a robust, embeddable
  directory serices implementation for JNDI, configuration management,
  or identity management/authentication.
* In addition to the basic JNDI and LDAP functionality described in the
  proposal, platform independent identity management/SSO solutions
  could be built on top of/natually extend this, providing
  benefits/extension possibilities for WS, HTTP Server and other
  projects. An ASF-licensed, "Apache-grade" directory implementation
  could form the basis for Apache XACML, Liberty, WSS and/or other
  emerging identity/auth related spec implementations. The embeddability
  and extended APIs being planned by this project may open up some
  exciting opportunities for efficient and scalable implementations of
  these and other specs.
* This project has already attracted significant interest and is likely
  to attract a strong community (just my HO, of course :-)
So, non-binding as my humble +1 may be, I think that this project has 
the makings of a very good asset for Apache, and I hope that we can sort 
out the organizational issues necessary to bring it in to the incubator.

Phil



-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: [PROPOSAL] PMC Vote to incubate Directory Project

[Phil Steitz]

Stephen McConnell wrote:
Phil:

Greg posted a message back on the 18th noting that a PMC vote on the 
entry of the project to the incubator would be kicked off under the 
private [EMAIL PROTECTED] list.  I don't know the specifics of Incubator 
voting policies but I guessing we will see a vote result early next week.

Stephen.


I saw that.  Nonetheless, I still find it odd that there has been 
virtually no "public" discussion of the merits of the proposal and I 
felt the need to express my opinion.  No disrespect for the process, de 
facto or documented, intended.

I would humbly suggest that there is no harm in public discussion of 
incubator project proposals, understanding that the voting is private, 
by the PMC. Public discussion and nonbinding statements of 
support/non-support by non-PMC members could provide valuable 
information to the PMC in their decision-making.

If others disagree, I would appreciate being (gently) enlightened on 
this point.

Phil





-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: [PROPOSAL] PMC Vote to incubate Directory Project

[Phil Steitz]

Roy T. Fielding wrote:
Greg posted a message back on the 18th noting that a PMC vote on the 
entry of the project to the incubator would be kicked off under the 
private [EMAIL PROTECTED] list.  I don't know the specifics of Incubator 
voting policies but I guessing we will see a vote result early next 
week.


I saw that.  Nonetheless, I still find it odd that there has been 
virtually no "public" discussion of the merits of the proposal and I 
felt the need to express my opinion.  No disrespect for the process, 
de facto or documented, intended.


Hmm, in general, the only discussions we ever hold in private are those
relating to non-disclosure issues or personnel issues.  We would have a
discussion and vote about the directory project on the general list.
The reason we haven't is because it is being suggested to incubator itself
rather than some other project or the board, which means it is waiting for
us to arrange for a new chair.
FTR, there is no such vote taking place in private.
Thanks for explaining this.

Personally, I think it is an excellent proposal except for one item:
Java is not the center of the universe.  Either this project should
consider all languages (seems unlikely, unless you already have those
other people in place), or the project should be named after the
product name and not the whole category of software.  A name like
"jeldap" (I've only seen that word used in relation to turbine)
would get you past a number of hurdles.
After re-reading it, I agree that the proposal does emphasize the Java 
aspects a bit more than the "Apache Directory" name would suggest. 
There are three reasons for this: first, the initial code base is Java, 
second JNDI and some of the extended APIs that the project will support 
are Java APIs and third there is no small measure of delight being 
expressed over the fact that recent JDK advances make a high-performance 
Java-based LDAP server thinkable :-))

I would personally have no problem with changing the name to reflect the 
Java/JNDI emphasis. While I would personally favor a nice animal (e.g. 
or culturally neutral place name, I could also support a JAMES-like 
moniker that brings the "J" out.  I don't much like "jeldap" or "JLDAP" 
or anything else based on LDAP by itself, because I expect the naming 
and identity services to emerge as equally important parts of the 
project, enabled by the core directory services.  The only ideas that I 
can come up with immediatedly are JANIS (Java Apache Naming and Identity 
Server), which is a bit extreme (not mentioning LDAP at all) or JED 
(Java Enterprise Directory), which doesn't say much. Any better ideas?

Thanks for the feedback.

Phil
Roy

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]




-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Getting the distribution onto a download site somewhere ...

[Phil Steitz]

Jochen Wiedmann wrote:
Noel J. Bergman wrote:

I am not on the Incubator PMC, but I feel that a project still bearing
incubator status should not be permitted to make a Release.


I do not know what exactly you define as a "release". Is that more than 
a distribution?

An incubator project is expected to build a community. I doubt it can do 
so from the CVS only: That would put the entry level for new users too 
high.
Agreed. Some Apache projects satisfy this need by making nightly builds 
available for download.  I don't know how this works in the incubator, 
but setting up a nightly build process and making the nightlies 
available for download could satisfy this need.

Phil



Jochen



-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]




-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: [PROPOSAL] PMC Vote to incubate Directory Project

[Phil Steitz]

See comments inline

Noel J. Bergman wrote:
I have no problem with protocol-centric projects, and no problem with
language-centric projects, but I do have a problem with protocol-centric
projects that assume one implementation language is "best".


OK, I've seen enough language wars to understand your a priori concern.
Mind you, not everyone who uses Java is a language zealot.

So, if the project is going to be language-agnostic, then
I want that written into the charter and growth anticipated.


We tried to anticipate this issue when preparing the proposal, and did
intentionally focus on the problem domain, rather than the platform,
excepting where the platform permitted *additional* synergies with other
projects (code sharing and embedding with related Java projects).
Apparently we did not do it sufficiently, but the intent is there, as is the
willingness to resolve the matter.
The dodgy bit is defining what is core and what is not. See below.



If someone else comes to Apache and says they want to start
an LDAP server project using, for example, the Netscape code
base (C++, I think) and another comes in wanting to establish
a Python library for builtin calls to LDAP, should the ASF
direct those projects to this same group or to their own projects?


Aren't Xerces-[C|J] and Xalan-[J|C] under the XML banner?  Not being a
member of those projects, I'd appreciate hearing the experiences of those
who are, and from their PMC.
Yes, I can see the potential of possibly growing too big for proper
oversight, and needing to split out, leaving the language-agnostic items in
the language-agnostic location.  But, in a sense, haven't those things
already happened, as projects were refactored from Jakarta to XML to
elsewhere (e.g., their own TLP or Web Services)?
On the other hand, when(if) matured to TLP status, I'd imagine that there
would be some infrastructure related to particular implementations, and
parts related to all sorts of portable issues, such as schema, RFCs, ASN,
protocol testing, etc., that are common ground.  And, quite honestly, I do
not see that type of collaboration happening if the semantic domain isn't
given a home.
I don't think that we have really answered Roy's question, but digging 
into what exactly we mean by the "semantic domain" is a step in the 
right direction. The "easy" answer is that the semantic domain equals 
LDAP-exposed directory services, which is fully specification-driven, 
platform- and language independent, etc; but the project already 
includes more than that.

We should ask ourselves if we expect to provide a home for extended 
Perl, C or whatever APIs, naming services for those languages, etc.  If 
the answer is "yes", then fine, we can all agree and move forward.  If 
the answer is no, however, I agree with Roy that we should acknowledge 
the scope limitation.

FWIW, my opinion is that standards-based Directory + Identity services 
could make up a natural "semantic domain" (actually more natural than 
"XML") and we should focus on defining this domain, rather than what 
languages or language-specific extensions will be supported (much as 
that diminishes the importance of JNDI and the extended Java APIs that I 
am personally looking forward to ;-)). Then we need to make the explicit 
commitment that the core solutions implemented and the eventual TLP will 
support *all* languages and *all* computing platforms. Can we all agree 
to this?

Phil

	--- Noel

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]




-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: [PROPOSAL] PMC Vote to incubate Directory Project

[Phil Steitz]

Noel J. Bergman wrote:
We should ask ourselves if we expect to provide a home for extended
Perl, C or whatever APIs, naming services for those languages, etc.  If
the answer is "yes", then fine, we can all agree and move forward.


my opinion is that standards-based Directory + Identity services
could make up a natural "semantic domain" (actually more natural than
"XML") and we should focus on defining this domain, rather than what
languages or language-specific extensions will be supported (much as
that diminishes the importance of JNDI and the extended Java APIs that I
am personally looking forward to ;-)). Then we need to make the explicit
commitment that the core solutions implemented and the eventual TLP will
support *all* languages and *all* computing platforms. Can we all agree
to this?


Yes, with the clarification added by Roy that the project only has to be
welcoming and supportive of people who want to work on such things.
Yes, that's what I meant to say, with the additional commitment that the 
core server products should not be designed or implemented in such a way 
as to discourage or make non-Java extensions difficult. As long as we 
keep things standards-based, that should not be a problem.

But I don't believe that you need to feel that it diminishes "the importance
of JNDI and the extended Java APIs that I am personally looking forward to
;-))" because *you* (and others) represent such a community to be welcomed
and supported within the domain.
Thanks. Believe me, "we" feel very welcome here.  I just want to make 
sure that in defining the domain we stay focused on the core services 
and define and implement them in such a way that non-Java 
extensions/applications also make sense, given the positive answer above.

Phil

	--- Noel

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]




-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Add 'practice' PMC structure to projects in incubation

[Phil Steitz]

Roy T. Fielding wrote:
[Moved from the PMC list -- folks have got to stop proposing such
things on the wrong list.]
A long time ago, the name PMC was created in an attempt to genericize
the way that the Apache Group operated, using terminology that would be
easily understood by a judge or IRS inspector.  Unfortunately, the
name seems to have overwhelmed its history.  I described that in a
message to the members on March 12, 2003, which I'll include below.
However, I've been so overwhelmed with issues/fires this past year
that I never got around to fixing it.
Geir has proposed that we create practice PMCs (a.k.a. subprojects)
as part of incubation, and that we call them "Project Committers"
lists rather than PMCs.  I am +1 on the notion in general, but I
would prefer to call them core groups instead.  My rationale is that
"committer" privilege is a mechanism that we frequently give to
people on the basis of what they are planning to do, whereas the
core group are those people who have earned long-term voting rights
whether or not they happen to code.  Jakarta got into a weird state
wherein committer == voter and commit-access was given out like candy,
thus leading to the notion that committers run ASF projects.  I don't
believe it is appropriate to link voting with cvs access.
Are you proposing that committers who are not PMC members or "Project 
Committers" should not have voting rights?

The key thing to note is that voting is a decision-making process
and we want that decision to be an ASF decision.  Furthermore, we want
the decision to be made as close to the volunteers doing the work as
possible, preferably by the volunteers themselves, whatever that work
may be.
Seems to conflict with the statement above (unless I misunderstood).

The ability to make ASF decisions starts with the board and is
delegated to officers and their associated committees.  Anyone casting
binding votes (meaning votes that are counted toward making a decision)
must be listed as a member of the committee on which they are voting,
even if their votes are limited to a subcommittee.  Therefore, my
preference is for a fluid structure of incubating subprojects wherein
every voter is listed as being in one or more core groups and the
entire set of voters is listed as the incubator pmc.
I am aware that this would mean incubating projects would be able to
vote themselves out of incubation.  I think that if such a project had
their shit together to the extent that they could run such a vote and
get it past the majority of incubator members, then they no longer
need to be incubated.
Roy
Thanks for sharing the post below. This clears up a few things for me at 
least.  At the risk of appearing dense, however, I am still not 
understanding exactly why "The PMC must equal the voters on a given 
project"  It seems to me that it *might* be possible (safe?) to have 
all *decisions* approved by the PMC, while the process (voting) to 
arrive at those decisions could include [binding?] input from non-PMC 
members. What am I missing?

Phil
===
From: "Roy T. Fielding" <[EMAIL PROTECTED]>
Date: Wed Mar 12, 2003  9:46:04  PM America/Los_Angeles
To: members   at  apache.org
Subject: PMCs gone wild
I am getting a bit frustrated at what appears to be a serious attitude
problem within the Apache projects.  A lot of people seem to wait around
until "the man" makes a decision, sometimes doing nothing other than
gripe about the lack of concern that "the man" has for their pet issue,
or simply believing that they are not allowed to do anything until
"the man" says it's okay to start.  I am not just talking about the
newer Jakarta projects: this attitude has become endemic throughout
the ASF, and folks are far-too-frequently suggesting that decisions
should be relegated to "subprojects" or that projects should be
"managed" by only a subset of the voters.
"the man" is usually their perception of a PMC as some other-worldly
land where benevolent beings ponder deep issues and create solutions.
[Sometimes "the man" is the ASF board, but that is very rare -- most
people have the sense to realize that the board's solution to a
squeeky wheel is to yank it off, throw it away, and install a new
wheel -- which usually isn't the effect desired by most wheels.]
I think I know what is causing this attitude, and sadly it points
back to one of the decisions I thought was a good idea when we were
crafting the ASF bylaws.  You have to understand some background
on that first...
The ASF bylaws were crafted by Drew Wright using a Delaware
nonprofit template and a ton of input from more than a year of
discussion amongst the Apache Group (circa 1998), discussion at
the post-ApacheCon'98 group meeting, and yet more discussion on the
old apache-core mailing list.  Our goal was to create a legitimate
corporate infrastructure around Apache without changing how Apache
decisions were made or the volunteer nature of the foundation.
By legitimate, I mean something that w

Re: Add 'practice' PMC structure to projects in incubation

[Phil Steitz]

Noel J. Bergman wrote:
Nicola Ken Barozzi wrote:


Committers could be given commit access long before having project
member status, and would thus be able to commit but not vote. This
makes it possible to keep a high bar for membership of the project but
a lower bar for committing.
Is this possible/wanted?


As I understand it, this was the initial structure.  A Contributor posts a
patch, the patch is reviewed and committed.  At some point, a frequent
Contributor is offered the opportunity to become a Committer.  The Committer
is allowed to commit a change, but the PMC is still responsible to review
the commit.  At some point, hopefully not too far down the pike, the
Committer is voted into the PMC.  Until that happens, the Committer does not
have a binding vote.  Cannot have a binding vote, because to have one
outside of the legal structure would expose the Committer.
Can you explain exactly what you mean by the last sentence above?

Phil

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: PPMCs and oversight

[Phil Steitz]

A couple of times on this thread, Berin and others have pointed out that 
"regular status reporting" is not all that incubating projects need.  I 
think that this is an important point.

The ever-present, never-defined "oversight" term seems to imply more of an 
event interface -- "raise issues," "notify PMC," "make sure things happen" 
-- than just passive review / reporting.  However you slice it, knowing 
when to "jump in" (maybe less and less over time if the mentors are not 
active / become inactive in the coding) is key.  That's what we should be 
able to count on from the ASF members involved with incubating projects 
(mentors, PPMC members, others).

I also agree with Noel's points about not building excessive dependencies 
or artificial roles for individual members.  Therefore, IMO what is 
required is *multiple* ASF members / experienced committers participating 
actively on each of the different PPMCs and some means of tracking who is 
looking after what.  As long as we can ensure this, the community (for 
successful incubating projects) should naturally be absorbed into the 
"strange attractor" of a healthy ASF project and Berin's concerns about 
things being missed should be addressed.

Phil

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: [VOTE] Accept MyFaces for Incubation

[Phil Steitz]

Noel J. Bergman wrote:
See: http://wiki.apache.org/incubator/MyFacesProposal
[X] Accept MyFaces into the Incubator
One small comment: since Wiki pages can change at any time, in the future 
it might be best to have votes reference static html (or inlined) 
proposals instead of wiki pages.  The +1 above is for the 2004-07-09 
10:21:07 version.

In any case, looks like a great addition addition to Apache.
--Phil
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: [VOTE] Directory project releases II

[Phil Steitz]

+1
Phil
Alex Karasulu wrote:
Hello again,
It looks like lots of people are away and we're going to have to wait 
for some clarification on whether or not we can release kerberos, eve, 
janus, and seda as is or change their names.  So in the mean time I 
think we can separately release the following:

ldap (0.8)  - common LDAP libraries  - 
http://incubator.apache.org/directory/subprojects/directory-ldap/index.html

naming (0.8)  - a lightweight, in-memory JNDI service provider  - 
http://incubator.apache.org/directory/subprojects/directory-naming/index.html 

asn1 (0.2)  [previously called snickers]
 - high performance non-blocking replacement for the Snacc4J runtime 
(ASN.1 runtime)  - 
http://incubator.apache.org/directory/subprojects/asn1/index.html

Note:
Snickers has been renamed to the Apache ASN.1 project.  ASN, ASN.1, "ASN 
One" all are not trademarked.  The website has been updated as well as 
all the code within the directory project that depends on this code.  
Package names have been changed as well.  There is no trace of Snickers 
anymore.

[ ] +1 Approve the request to release
[ ] -1 Reject the request to release
[ ] +0 Abstain
Again have a Happy New Year!
The Directory Project Team

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

[RESULT] [VOTE] Release [naming] 0.8

[Phil Steitz]

The vote on directory-dev to release a "technology preview" release of 
directory-naming 0.8 from the incubator has passed, with 6 +1 votes 
(Phil Steitz, Enrique Rodriguez, Brett Porter, Alex Karasulu, Stephen 
McConnell, Vince Tence) and one +0 (Niclas Hedhman).  The full vote 
thread is here:
http://mail-archives.apache.org/eyebrowse/[EMAIL PROTECTED]&by=thread&from=970545

Assuming no -1 votes arrive before Friday, the signed release will be 
posted to cvs.apache.org/dist/incubator/directory over the weekend.

Thanks!
Phil
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: [VOTE][release] [ApacheDS] 0.8

[Phil Steitz]

---
[X] +1  I support this release and am willing to help
[ ] +0  I support this release but am unable to help
[ ] -0  I do not support this release
[ ] -1  I do not support this release, and here are my reasons
---
Phil
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

RE: [VOTE] Directory exiting Incubator

[Phil Steitz]

[ X] Graduate the Directory Project
[ ] Abstain
[ ] Keep incubating the Directory Project

--Phil
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: [PROPOSAL] Apache TSIK

[Phil Steitz]

+1

Phil

Granqvist, Hans wrote:

Proposal

This is a proposal to submit the Trust Services Integration 
Toolkit (TSIK) to ASF.  TSIK is a Java toolkit that VeriSign 
has been developing since 2001, and it is the basis of several 
products developed by VeriSign.


The intent with Apache TSIK is to create a web services project 
to implement standards as defined by W3C, OASIS, and others:


*  Basic XML security standards (XML signature, XML encryption) 
*  WS-* standards, and

*  Other related standards (for example XKMS and SAML)

A full list of standards can be found at the end of the email. 
Emphasis has so far been placed on security-related standards.


TSIK is a toolkit that is suitable for implementing client as 
well as server side components.  Several commercial products built 
using TSIK are in current use.



Rationale
-
It is easy to misunderstand the sometimes complex XML security 
standards. We have found that improper use of APIs inadvertently 
cause most security issues.


TSIK was therefore designed to be simple and easy to use. Rather 
than trying to implement 100% of a specific standard, we wanted to
provide simplified APIs that would make sense in most use cases. 
However, what's implemented will always be to specification. 


VeriSign believes the slow pace of adoption of Web Services can be
attributed partly to the lack of open source toolkits. We believe 
that making a toolkit like TISK available to the community will 
increase the momentum.


Currently Apache offers two projects related to Web Services 
security: 

a. The XML security project, which implements basic XML signature 
   and XML encryption, and


b. The WS-FX project, which aims at implementing existing WS* 
   standards.


The WS-FX project is an umbrella for several sub projects. The 
composability of WS standards means that a division into a 
subproject structure is reasonable.  WS-FX's main emphasis, though 
not the only way of deployment, is by way of Axis filters.


We propose TSIK as a separate project, somewhat competitive to 
WS-FX, but focused more on a toolkit usage model. Within the ASF, 
there are already examples of more or less competing projects 
(e.g., XML parsers). There is a belief that such internal 
competition is healthy.


There are a number of Java Community Process JSR's in various stages 
of development.  These JSR APIs will probably end up in ASF projects, 
some sooner than later.  For example, JSR-105 (XML digital signature) 
is already in the final stages and its APIs will likely in time 
supplant or complement the current Apache XML security suite. 

Other JSR's of interest include JSR-106 (XML encryption) and JSR-183 
(WS-Security), which will also migrate to a set of APIs that will find 
their way into Apache.


The JSR APIs often strive to completely implement each specification. 
While this is sometimes valuable, few applications use more than the 
most common functions.  Again, TSIK is designed to simplify security 
usage as much as possible. 

The long term goal of TSIK could be to use existing underlying 
Apache projects, such as XML security suite.


The initial implementation will be in Java, with support for J2SE 
1.3 and up. 

As a main author of many WS standards, VeriSign will also work to 
resolve the IP issues regarding some WS* standards.



Scope
--
TSIK will implement the WS-* stack of standards.  To do this, basic 
XML security standards need to be implemented, as discussed above 
in the introduction.  Most of this functionality already exists in 
TSIK.


Our initial plan is to implement support for the following 
specifications in this order: WS-Security, WS-Trust, 
WS-SecureConversation (WS-Addressing), WS-SecurityPolicy (WS-Policy), 
WS-Reliable-Messaging, WS-Federation (Liberty) and SAML 2.0., but 
what gets implemented will in the end be decided by the community 
process.


TSIK should also make it easy to conform to WS-I profiles, for 
instance, the Basic Security Profile.


We believe in an active participation in interop events. There will 
be APIs for use cases as defined by interop events in OASIS, W3C, 
etc., as well as profiles issues discussed via WS-I.


Interoperability is paramount and the TSIK test suites shall strive 
to always interoperate with other implementations.



Known risks


---Orphaned products
TSIK has always been distributed in binary form.  Many customers have
requested access to the source to add functionality to the TSIK code 
base.  


---Commercial interest
The current commercial products built on TSIK have been found to
have no claims on the source code.  VeriSign does not plan to develop
parallel in-house versions of TSIK, but spend all efforts on the ASF 
TSIK project.


---Inexperience with Open Source
Some TSIK developers are already in OS-based businesses.  However,
VeriSign has limited experience working on open source projects, but
has extensive experience in creating many open WS* standards, and

Re: JDO2 Snapshots

[Phil Steitz]

Dittert, Eric wrote:

From: Noel J. Bergman [mailto:[EMAIL PROTECTED] Sent: Monday,
August 08, 2005 6:40 PM

As I said, it is about balance.  The community that we most care
about during Incubation is the developer community, not the
end-user community. I could go so far as to say that a bit of
inconvenience for end-users is not a bad thing because we don't
want *widespread* adoption by end-users until the project completes
Incubation.  And we certainly want end-users to know what they are
getting into if/when they choose to adopt a project in the 
Incubator.


I have *never* seen strong user adoption listed as a criteria.  Not
once. Nor would I support it as a requirement.




I don't have as much historical context as others on this discussion
but here are a few (possibly naïve) thoughts:

1) If you discourage making releases while in incubation, aren't you
effectively preventing projects that have, through whatever
mechanism, already acquired a significant user base from entering the
Apache fold (or at least making life much more difficult for them)?


Valid point here - good motivation for getting through incubation.  The 
problem is that we can't make apache releases until all the IP has been 
cleared and the project has become an apache project (see below).


2) It seems that perhaps some people see widespread adoption as a
good way to get more developers involved, and thus as a way to meet
the community-building requirements.  Certainly it seems to me that
the user-turned-contributor is part of the common vision/folklore of
OSS.  Is there a subtle distinction of some kind that is being
missed?


At the risk of attracting flames, I would like to ask out of curiosity 
what evidence we have that "release early" and "gain widespread adoption 
quickly" are indispensable prerequisites for successful *community* 
gestation. Consider maven, struts, geronimo, as examples of successful 
apache projects (from community standpoint at least ;-) that did not cut 
early releases. Has anyone ever gathered data on this?



3) If the point is to get projects out of incubation, aren't there
better management techniques than restricting the ability to do
releases?  It seems that you might be better off setting positive
goals and demanding that they be met.


There are such goals:
http://incubator.apache.org/incubation/Incubation_Policy.html#Minimum+Exit+Requirements

IMHO, no community that has not met these requirements should be allowed 
to cut apache releases.


Phil


-- Eric


-
 To unsubscribe, e-mail: [EMAIL PROTECTED] For
additional commands, e-mail: [EMAIL PROTECTED]




-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]