Re: [VOTE] Apache CXF Graduation as TLP

[Dan Diephouse]

+1!

Has it really been 20 months? I feel older all of a sudden.

Dan

Daniel Kulp wrote:
After 20 months in the incubator, 6 releases complete and 2 more on the 
way shortly, several new committers, and too much email traffic :-), the 
Apache CXF community (with support from our mentors) feels that we are 
ready to graduate to an official top level project at Apache as 
indicated by the community vote recorded at:

http://www.nabble.com/-VOTE--Graduate-Apache-CXF-as-a-top-level-project-to15812722.html

We would like the resolution attached to this email to be presented to 
the board for consideration at the next possible board meeting. 

For additional information, the CXF status file is here: 
http://incubator.apache.org/projects/cxf.html


Thank you in advance for your time and consideration. 


[ ] +1
[ ] +0 
[ ] -1  



-- Dan (on behalf of the entire Apache CXF team and with permission from 
the CXF mentors to call this vote.)



==

 Establish the Apache CXF project

 WHEREAS, the Board of Directors deems it to be in the best
 interests of the Foundation and consistent with the
 Foundation's purpose to establish a Project, to be known as
 "Apache CXF Project", related to a framework for creating,
 deploying, and consuming services based on SOA design 
 principles for distribution at no charge to the public.


 NOW, THEREFORE, BE IT RESOLVED, that a Project Management
 Committee (PMC) is hereby established pursuant to Bylaws
 of the Foundation; and be it further

 RESOLVED, that the Apache CXF PMC be and hereby is
 charged with the creation and maintenance of "Apache CXF";
 and be it further

 RESOLVED, that the office of "Vice President, Apache CXF" be and
 hereby is created, the person holding such office to serve at
 the direction of the Board of Directors as the chair of the
 Apache CXF PMC, and to have primary responsibility for
 management of the projects within the scope of responsibility
 of the Apache CXF PMC; and be it further

 RESOLVED, that the persons listed immediately below be and
 hereby are appointed to serve as the initial members of the
 Apache CXF PMC:

  * Ulhas Bhole <[EMAIL PROTECTED]>
  * Sean O'Callaghan <[EMAIL PROTECTED]>
  * Dan Diephouse <[EMAIL PROTECTED]>
  * Freeman Yue Fang <[EMAIL PROTECTED]>
  * Jarek Gawor <[EMAIL PROTECTED]>
  * Jeff Genender <[EMAIL PROTECTED]>
  * Eoghan Glynn <[EMAIL PROTECTED]>
  * Jim Jagielski <[EMAIL PROTECTED]>
  * Willem Ning Jiang <[EMAIL PROTECTED]>
  * Eric Johnson <[EMAIL PROTECTED]>
  * Peter Jones <[EMAIL PROTECTED]>
  * Daniel Kulp <[EMAIL PROTECTED]>
  * Bozhong Lin <[EMAIL PROTECTED]>
  * Jervis Liu <[EMAIL PROTECTED]>
  * Jim Ma <[EMAIL PROTECTED]>
  * James Maode Mao <[EMAIL PROTECTED]>
  * Benson Margulies <[EMAIL PROTECTED]>
  * Glen Mazza <[EMAIL PROTECTED]>
  * Guillaume Nodet <[EMAIL PROTECTED]>
  * Ajay Paibir <[EMAIL PROTECTED]>


 NOW, THEREFORE, BE IT FURTHER RESOLVED, that Daniel Kulp
 be appointed to the office of Vice President, Apache CXF, to serve
 in accordance with and subject to the direction of the Board of
 Directors and the Bylaws of the Foundation until death,
 resignation, retirement, removal or disqualification, or until
 a successor is appointed; and be it further

 RESOLVED, that the Apache CXF Project be and hereby
 is tasked with the migration and rationalization of the Apache
 Incubator CXF podling; and be it further

 RESOLVED, that all responsibilities pertaining to the Apache
 Incubator CXF podling encumbered upon the Apache Incubator
 PMC are hereafter discharged.

 ==

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

  



--
Dan Diephouse
MuleSource
http://mulesource.com | http://netzooid.com 



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

[VOTE] Approve the release of Apache Abdera 0.4.0-incubating

[Dan Diephouse]

The Apache Abdera project has voted to release the 0.4.0-incubating 
release [1]. The vote passed with 7 +1s. Two of these were IPMC votes, 
Garrett Rooney and Davanum Srinivas.


Binary distributions:

http://people.apache.org/~dandiep/abdera-take4/org/apache/abdera/apache-abdera/0.4.0-incubating/apache-abdera-0.4.0-incubating.zip
http://people.apache.org/~dandiep/abdera-take4/org/apache/abdera/apache-abdera/0.4.0-incubating/apache-abdera-0.4.0-incubating.tar.gz

Source distributions:

http://people.apache.org/~dandiep/abdera-take4/org/apache/abdera/apache-abdera/0.4.0-incubating/apache-abdera-0.4.0-incubating-src.zip
http://people.apache.org/~dandiep/abdera-take4/org/apache/abdera/apache-abdera/0.4.0-incubating/apache-abdera-0.4.0-incubating-src.tar.gz

Maven Repository: http://people.apache.org/~dandiep/abdera-take4/

Please take a look and cast your vote!

- Abdera Team

1. 
http://mail-archives.apache.org/mod_mbox/incubator-abdera-dev/200803.mbox/[EMAIL PROTECTED]


--
Dan Diephouse
MuleSource
http://mulesource.com | http://netzooid.com 



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

Re: Confluence Based Website Access Control

[Dan Diephouse]

Also the other wiki at http://wiki.apache.org/general/ doesn't follow 
this policy AFAICT. Why does confluence have to?


Luciano Resende wrote:

Based on previous discussion [1], the Tuscany PPMC has voted to grant
some some community members, with proper CLA on file, to have write
access to the Confluence wiki website. Is this NOT acceptable anymore
?

[1] http://www.mail-archive.com/general@incubator.apache.org/msg14390.html

On Sun, Mar 23, 2008 at 1:55 PM, Noel J. Bergman <[EMAIL PROTECTED]> wrote:
  

Just a reminder to all PMC Members and podlings: no one is to have write
 access to a Confluence-backed web site who is not a Committer on the
 project.

--- Noel



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







  



--
Dan Diephouse
MuleSource
http://mulesource.com | http://netzooid.com 



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

Re: [VOTE] Approve the release of Apache Abdera 0.4.0-incubating

[Dan Diephouse]

These things are my fault, I think I screwed up the last cut. We'll fix 
up the license and distro issues and get try again :-)


I used:

http://svn.apache.org/repos/asf/incubator/abdera/java/branches/abdera-0.4.0-incubating/

I haven't made the tag as its not officially released.

Dan

sebb wrote:

Which SVN tag was used to create the distribution?

On 24/03/2008, sebb <[EMAIL PROTECTED]> wrote:
  

That's not the only problem.

 The source zip file seems to contain quite a few odd files:

 derby.log
 .lock
 redo.log
 locks
 db.lck
 log.ctrl
 logmirror.ctrl
 log1.dat

 Not sure what all the .dat files are for. They don't look like source...

 Also contains couchdb4j-0.1.2.jar which itself has some rather odd
 content, and does not have a NOTICE file even though it appears to be
 an ASF jar. Also its manifest is incomplete.

 The source zip file seems to contain two copies of NOTICE and LICENSE
 at the top level.
 Maybe this is an artefact of Winzip.


 On 24/03/2008, James M Snell <[EMAIL PROTECTED]> wrote:
 > Good catch; sorry for missing that.  Will get those fixed shortly.
 >
 >
 >  - James
 >
 >
 >  Luciano Resende wrote:
 >  > Have you guys run RAT over the release ? I tried it over the source
 >  > distribution and various source files are missing ASF license header.
 >  >
 >  > [1] http://people.apache.org/~lresende/abdera/rat.log
 >  >
 >  > On Sun, Mar 23, 2008 at 3:37 PM, Dan Diephouse
 >  > <[EMAIL PROTECTED]> wrote:
 >  >> The Apache Abdera project has voted to release the 0.4.0-incubating
 >  >>  release [1]. The vote passed with 7 +1s. Two of these were IPMC votes,
 >  >>  Garrett Rooney and Davanum Srinivas.
 >  >>
 >  >>  Binary distributions:
 >  >>
 >  >>  
http://people.apache.org/~dandiep/abdera-take4/org/apache/abdera/apache-abdera/0.4.0-incubating/apache-abdera-0.4.0-incubating.zip
 >  >>  
http://people.apache.org/~dandiep/abdera-take4/org/apache/abdera/apache-abdera/0.4.0-incubating/apache-abdera-0.4.0-incubating.tar.gz
 >  >>
 >  >>  Source distributions:
 >  >>
 >  >>  
http://people.apache.org/~dandiep/abdera-take4/org/apache/abdera/apache-abdera/0.4.0-incubating/apache-abdera-0.4.0-incubating-src.zip
 >  >>  
http://people.apache.org/~dandiep/abdera-take4/org/apache/abdera/apache-abdera/0.4.0-incubating/apache-abdera-0.4.0-incubating-src.tar.gz
 >  >>
 >  >>  Maven Repository: http://people.apache.org/~dandiep/abdera-take4/
 >  >>
 >  >>  Please take a look and cast your vote!
 >  >>
 >  >>  - Abdera Team
 >  >>
 >  >>  1.
 >  >>  
http://mail-archives.apache.org/mod_mbox/incubator-abdera-dev/200803.mbox/[EMAIL 
PROTECTED]
 >  >>
 >  >>  --
 >  >>  Dan Diephouse
 >  >>  MuleSource
 >  >>  http://mulesource.com | http://netzooid.com
 >  >>
 >  >>
 >  >>  -
 >  >>  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]
 >
 >




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

  



--
Dan Diephouse
MuleSource
http://mulesource.com | http://netzooid.com 



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

Re: [VOTE] Approve the release of Apache Abdera 0.4.0-incubating (updated)

[Dan Diephouse]

sebb wrote:

On 31/03/2008, James M Snell <[EMAIL PROTECTED]> wrote:
  



-1: There are MD5 and SHA1 digests in the directory, but the archives
have no signatures.

  

OK, I will fix this.

 Maven Repository: http://people.apache.org/~dandiep/abdera-take6/




-0: The abdera-bundle-0.4.0-incubating-sources.jar does not appear to
have any content - only the META-INF directory is present. Is that
correct?
  

This is just a by-product of Maven. We can delete it.

-1: The NOTICE files in that jar (and others) contains far too much.
The NOTICE file is for required attribtions ONLY (e.g. as per an About box)
There's really no need to repeat ASF for each project used by Abdera.
  
Having too much information in the NOTICE files is not a crime. The 
Maven remote-resources plugin aggregates all this stuff for us so we 
never miss any notice that we need to put in.

-1: The LICENSE files need to either contain copies of the 3rd party
licenses, or they need to have a reference to the 3rd party licences.
Equally, there is no need for the lib directory to contain copies of
the AL for every ASF product.
  
Why does the LICENSE file need to have a copy of all the other licenses? 
These are contained in the lib/ directory like many other ASF projects.


Re: the ASL license in lib/ - once again having too much information is 
not a crime. This is a service to uesrs so they know where the libraries 
came from.

-1: RAT report says:

99 Unknown Licenses

Some of these are trivial, but most require an AL header.
  
Not true - there is not consensus that properties/xml files need to have 
headers. All the Java source code files have headers. If there are 
specific files that you feel should have a license that don't please 
list them and explain why. I'm not saying that we didn't miss something, 
but I am saying that the ones that I know about don't necessarily 
require a header.

What is the SVN tag that corresponds with the archives?

  

the branch will be tagged once its released.

Dan

--
Dan Diephouse
MuleSource
http://mulesource.com | http://netzooid.com 



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

Re: [VOTE] Approve the release of Apache Abdera 0.4.0-incubating (updated)

[Dan Diephouse]

I removed the empty sources jar and tagged the release:

Dan Diephouse wrote:

sebb wrote:

On 31/03/2008, James M Snell <[EMAIL PROTECTED]> wrote:
 



-1: There are MD5 and SHA1 digests in the directory, but the archives
have no signatures.

  

OK, I will fix this.

 Maven Repository: http://people.apache.org/~dandiep/abdera-take6/




-0: The abdera-bundle-0.4.0-incubating-sources.jar does not appear to
have any content - only the META-INF directory is present. Is that
correct?
  

This is just a by-product of Maven. We can delete it.

-1: The NOTICE files in that jar (and others) contains far too much.
The NOTICE file is for required attribtions ONLY (e.g. as per an 
About box)

There's really no need to repeat ASF for each project used by Abdera.
  
Having too much information in the NOTICE files is not a crime. The 
Maven remote-resources plugin aggregates all this stuff for us so we 
never miss any notice that we need to put in.

-1: The LICENSE files need to either contain copies of the 3rd party
licenses, or they need to have a reference to the 3rd party licences.
Equally, there is no need for the lib directory to contain copies of
the AL for every ASF product.
  
Why does the LICENSE file need to have a copy of all the other 
licenses? These are contained in the lib/ directory like many other 
ASF projects.


Re: the ASL license in lib/ - once again having too much information 
is not a crime. This is a service to uesrs so they know where the 
libraries came from.

-1: RAT report says:

99 Unknown Licenses

Some of these are trivial, but most require an AL header.
  
Not true - there is not consensus that properties/xml files need to 
have headers. All the Java source code files have headers. If there 
are specific files that you feel should have a license that don't 
please list them and explain why. I'm not saying that we didn't miss 
something, but I am saying that the ones that I know about don't 
necessarily require a header.

What is the SVN tag that corresponds with the archives?

  

the branch will be tagged once its released.

Dan




--
Dan Diephouse
MuleSource
http://mulesource.com | http://netzooid.com 



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

Re: [VOTE] Approve the release of Apache Abdera 0.4.0-incubating (updated)

[Dan Diephouse]

Oops hit "ctrl enter" instead of "ctrl-v enter".  Here's the tag:

http://svn.apache.org/repos/asf/incubator/abdera/java/tags/abdera-0.4.0-incubating/

Dan

Dan Diephouse wrote:

I removed the empty sources jar and tagged the release:

Dan Diephouse wrote:

sebb wrote:

On 31/03/2008, James M Snell <[EMAIL PROTECTED]> wrote:
 



-1: There are MD5 and SHA1 digests in the directory, but the archives
have no signatures.

  

OK, I will fix this.

 Maven Repository: http://people.apache.org/~dandiep/abdera-take6/




-0: The abdera-bundle-0.4.0-incubating-sources.jar does not appear to
have any content - only the META-INF directory is present. Is that
correct?
  

This is just a by-product of Maven. We can delete it.

-1: The NOTICE files in that jar (and others) contains far too much.
The NOTICE file is for required attribtions ONLY (e.g. as per an 
About box)

There's really no need to repeat ASF for each project used by Abdera.
  
Having too much information in the NOTICE files is not a crime. The 
Maven remote-resources plugin aggregates all this stuff for us so we 
never miss any notice that we need to put in.

-1: The LICENSE files need to either contain copies of the 3rd party
licenses, or they need to have a reference to the 3rd party licences.
Equally, there is no need for the lib directory to contain copies of
the AL for every ASF product.
  
Why does the LICENSE file need to have a copy of all the other 
licenses? These are contained in the lib/ directory like many other 
ASF projects.


Re: the ASL license in lib/ - once again having too much information 
is not a crime. This is a service to uesrs so they know where the 
libraries came from.

-1: RAT report says:

99 Unknown Licenses

Some of these are trivial, but most require an AL header.
  
Not true - there is not consensus that properties/xml files need to 
have headers. All the Java source code files have headers. If there 
are specific files that you feel should have a license that don't 
please list them and explain why. I'm not saying that we didn't miss 
something, but I am saying that the ones that I know about don't 
necessarily require a header.

What is the SVN tag that corresponds with the archives?

  

the branch will be tagged once its released.

Dan







--
Dan Diephouse
MuleSource
http://mulesource.com | http://netzooid.com 



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

Re: [VOTE] Approve the release of Apache Abdera 0.4.0-incubating (updated)

[Dan Diephouse]

sebb wrote:



 > The NOTICE file is for required attribtions ONLY (e.g. as per an About box)
 > There's really no need to repeat ASF for each project used by Abdera.
 >

Having too much information in the NOTICE files is not a crime. The
 Maven remote-resources plugin aggregates all this stuff for us so we
 never miss any notice that we need to put in.



Unfortunately the plugin generates incorrect information.
  
It does NOT generate incorrect information. It simply generates extra 
attributions for all the ASF projects we reuse. 

It *is* a problem having all the redundant information.

See for example:

http://www.apache.org/legal/src-headers.html
also
http://wiki.apache.org/legal/3party/notice
http://wiki.apache.org/legal/3party/notice/discuss
  
It says "should" not requires w.r.t. the mandatory license attributions. 
Once again, I maintain that this is not a problem.



-1: The LICENSE files need to either contain copies of the 3rd party
  

 > licenses, or they need to have a reference to the 3rd party licences.
 > Equally, there is no need for the lib directory to contain copies of
 > the AL for every ASF product.
 >

Why does the LICENSE file need to have a copy of all the other licenses?
 These are contained in the lib/ directory like many other ASF projects.




See the last paragraph of:

http://www.apache.org/dev/apply-license.html#new

  
"or at least put a pointer in the LICENSE file to the third-party 
license" - which we in the NOTICE file.


There is not a legal requirement here that it must be in the LICENSE 
file itself - if so, please point me to the place in the license. This 
is page is to provide "guidance" (see the first sentence), not be the 
ultimate authority on what exactly is legally permissible for distributions.


If you look at many other ASF projects in the incubator and outside, 
you'll see that this is not an enforced policy - this is simply telling 
developers one way to get started here.


Dan

--
Dan Diephouse
MuleSource
http://mulesource.com | http://netzooid.com 



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

License files - separate or one file [was Re: [VOTE] Approve the release of Apache Abdera 0.4.0-incubating (updated)]

[Dan Diephouse]

sebb wrote:

On 31/03/2008, Dan Diephouse <[EMAIL PROTECTED]> wrote:
  

 >>> -1: The LICENSE files need to either contain copies of the 3rd party
 >>>
 >>  > licenses, or they need to have a reference to the 3rd party licences.
 >>  > Equally, there is no need for the lib directory to contain copies of
 >>  > the AL for every ASF product.
 >>  >
 >>
 >> Why does the LICENSE file need to have a copy of all the other licenses?
 >>  These are contained in the lib/ directory like many other ASF projects.
 >>
 >>
 >
 > See the last paragraph of:
 >
 > http://www.apache.org/dev/apply-license.html#new
 >
 >

"or at least put a pointer in the LICENSE file to the third-party
 license" - which we in the NOTICE file.




But they need to go in the LICENSE file, see:

http://www.apache.org/dev/apply-license.html#new
  

Did you not read the next paragraph?

 There is not a legal requirement here that it must be in the LICENSE
 file itself - if so, please point me to the place in the license. This
 is page is to provide "guidance" (see the first sentence), not be the
 ultimate authority on what exactly is legally permissible for distributions.

  If you look at many other ASF projects in the incubator and outside,
 you'll see that this is not an enforced policy - this is simply telling
 developers one way to get started here.


Can other people please chime in here?

I have never ever seen this enforced and I do not believe its a 
requirement. Just to summarize - do we need to 1) include all the 
licenses for all our dependencies in a single libary or can we 2) have 
our top LICENSE file which is ASL and then have individual LICENSE files 
for each library in the lib/ directory.


I think not allowing the second would be a HUGE mistake. It makes it 
much clearer which license applies to which file.


Dan

--
Dan Diephouse
MuleSource
http://mulesource.com | http://netzooid.com 



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

Re: License files - separate or one file [was Re: [VOTE] Approve the release of Apache Abdera 0.4.0-incubating (updated)]

[Dan Diephouse]

Dan Diephouse wrote:

sebb wrote:

On 31/03/2008, Dan Diephouse <[EMAIL PROTECTED]> wrote:
 
 >>> -1: The LICENSE files need to either contain copies of the 3rd 
party

 >>>
 >>  > licenses, or they need to have a reference to the 3rd party 
licences.
 >>  > Equally, there is no need for the lib directory to contain 
copies of

 >>  > the AL for every ASF product.
 >>  >
 >>
 >> Why does the LICENSE file need to have a copy of all the other 
licenses?
 >>  These are contained in the lib/ directory like many other ASF 
projects.

 >>
 >>
 >
 > See the last paragraph of:
 >
 > http://www.apache.org/dev/apply-license.html#new
 >
 >

"or at least put a pointer in the LICENSE file to the third-party
 license" - which we in the NOTICE file.




But they need to go in the LICENSE file, see:

http://www.apache.org/dev/apply-license.html#new
  

Did you not read the next paragraph?

 There is not a legal requirement here that it must be in the LICENSE
 file itself - if so, please point me to the place in the license. This
 is page is to provide "guidance" (see the first sentence), not be the
 ultimate authority on what exactly is legally permissible for 
distributions.


  If you look at many other ASF projects in the incubator and outside,
 you'll see that this is not an enforced policy - this is simply 
telling

 developers one way to get started here.


Can other people please chime in here?

I have never ever seen this enforced and I do not believe its a 
requirement. Just to summarize - do we need to 1) include all the 
licenses for all our dependencies in a single libary or can we 2) have 
our top LICENSE file which is ASL and then have individual LICENSE 
files for each library in the lib/ directory.


I think not allowing the second would be a HUGE mistake. It makes it 
much clearer which license applies to which file.


Dan


I misspoke. Here's what I meant to ask:

Do we need to 1) include all the licenses for all our dependencies in a 
single LICENSE file or can we 2) have our top LICENSE file which is ASL 
and then have individual LICENSE files for each library in the lib/ 
directory.


Dan

--
Dan Diephouse
MuleSource
http://mulesource.com | http://netzooid.com 



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

Re: License files - separate or one file [was Re: [VOTE] Approve the release of Apache Abdera 0.4.0-incubating (updated)]

[Dan Diephouse]

Kevan Miller wrote:


On Apr 2, 2008, at 1:43 PM, Dan Diephouse wrote:


Dan Diephouse wrote:

sebb wrote:

On 31/03/2008, Dan Diephouse <[EMAIL PROTECTED]> wrote:

>>> -1: The LICENSE files need to either contain copies of the 3rd 
party

>>>
>>  > licenses, or they need to have a reference to the 3rd party 
licences.
>>  > Equally, there is no need for the lib directory to contain 
copies of

>>  > the AL for every ASF product.
>>  >
>>
>> Why does the LICENSE file need to have a copy of all the other 
licenses?
>>  These are contained in the lib/ directory like many other ASF 
projects.

>>
>>
>
> See the last paragraph of:
>
> http://www.apache.org/dev/apply-license.html#new
>
>

"or at least put a pointer in the LICENSE file to the third-party
license" - which we in the NOTICE file.




But they need to go in the LICENSE file, see:

http://www.apache.org/dev/apply-license.html#new


Did you not read the next paragraph?

There is not a legal requirement here that it must be in the LICENSE
file itself - if so, please point me to the place in the license. 
This

is page is to provide "guidance" (see the first sentence), not be the
ultimate authority on what exactly is legally permissible for 
distributions.


 If you look at many other ASF projects in the incubator and outside,
you'll see that this is not an enforced policy - this is simply 
telling

developers one way to get started here.


Can other people please chime in here?

I have never ever seen this enforced and I do not believe its a 
requirement. Just to summarize - do we need to 1) include all the 
licenses for all our dependencies in a single libary or can we 2) 
have our top LICENSE file which is ASL and then have individual 
LICENSE files for each library in the lib/ directory.


I think not allowing the second would be a HUGE mistake. It makes it 
much clearer which license applies to which file.


Dan


I misspoke. Here's what I meant to ask:

Do we need to 1) include all the licenses for all our dependencies in 
a single LICENSE file or can we 2) have our top LICENSE file which is 
ASL and then have individual LICENSE files for each library in the 
lib/ directory.


I'm not aware of a requirement for having only 1 LICENSE file. In 
fact, the document says you don't have to append 3rd-party licenses to 
the LICENSE file. It does say you should put a pointer to the license 
files. So, IMO, 2) is fine. Other Apache projects do this also.


I do think LICENSE information in jar files should be complete (i.e. 
jar files shouldn't reference information that would only be found in 
a full binary distribution). It looks like your jars are ok, in that 
respect.


On the other hand, I believe there must be only one NOTICE file. I see 
multiple NOTICE files in your jars. I haven't downloaded the full 
distribution given the number of changes which seem to be occurring... 
Hard to keep track.
Each jar has a NOTICE file in META-INF/NOTICE. The source and binary 
distributions each have a NOTICE file in /.


Where are the multiple NOTICE files?

Dan

--
Dan Diephouse
MuleSource
http://mulesource.com | http://netzooid.com 



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

Re: License files - separate or one file

[Dan Diephouse]

Can someone clarify the below for us on [EMAIL PROTECTED]

sebb wrote:

On 02/04/2008, Robert Burrell Donkin <[EMAIL PROTECTED]> wrote:
  

On Wed, Apr 2, 2008 at 8:59 PM, sebb <[EMAIL PROTECTED]> wrote:
 > On 02/04/2008, Kevan Miller <[EMAIL PROTECTED]> wrote:
 >  >  On Apr 2, 2008, at 1:43 PM, Dan Diephouse wrote:





 >  > > I misspoke. Here's what I meant to ask:
 >  > >
 >  > > Do we need to 1) include all the licenses for all our dependencies in a
 >  > single LICENSE file or can we 2) have our top LICENSE file which is ASL 
and
 >  > then have individual LICENSE files for each library in the lib/ directory.
 >  > >
 >  >
 >  >  I'm not aware of a requirement for having only 1 LICENSE file. In fact, 
the
 >  > document says you don't have to append 3rd-party licenses to the LICENSE
 >  > file. It does say you should put a pointer to the license files. So, IMO, 
2)
 >  > is fine. Other Apache projects do this also.
 >
 >  2) is fine so long as the main LICENSE jar tells users where to find
 >  the other license - i.e. it  has pointers to the other licenses.


AIUI this is not policy




My understanding differs, so I think this needs to be resolved and
formally documented.

  



--
Dan Diephouse
MuleSource
http://mulesource.com | http://netzooid.com 



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

Re: [VOTE] Release Abdera 0.4.0-incubating Take 7

[Dan Diephouse]

sebb wrote:

On 07/04/2008, sebb <[EMAIL PROTECTED]> wrote:
  

On 07/04/2008, James M Snell <[EMAIL PROTECTED]> wrote:
 > Ok, we've updated the release candidate... please review
 >
 >  Take 7 of the vote to release Apache Abdera 0.4.0-incubating. The
 >  following things have changed:
 >  - All necessary files now include ASL headers
 >  - LICENSE file now includes pointers to non-ASL licenses and Mark
 >  Pilgrim's license
 >  - NOTICE files in the jars are much cleaner thanks to the new
 >  maven-remote-resource plugin.
 >  - Information about a jar's dependencies and their licenses are now
 >  included in META-INF/DEPENDENCIES instead of the NOTICE file.
 >  - The NOTICE file in the distributions contains all the stuff not in
 >  lib/*-LICENSE.txt and provides a pointer to the lib directory for the
 >  additional stuff.
 >  - Everything is signed


But where can I find the key?


 >  Binary distributions:
 >
 > 
http://people.apache.org/~dandiep/abdera-take7/org/apache/abdera/apache-abdera/0.4.0-incubating/apache-abdera-0.4.0-incubating.zip
 > 
http://people.apache.org/~dandiep/abdera-take7/org/apache/abdera/apache-abdera/0.4.0-incubating/apache-abdera-0.4.0-incubating.tar.gz
 >
 >  Source distributions:
 >
 > 
http://people.apache.org/~dandiep/abdera-take7/org/apache/abdera/apache-abdera/0.4.0-incubating/apache-abdera-0.4.0-incubating-src.zip
 > 
http://people.apache.org/~dandiep/abdera-take7/org/apache/abdera/apache-abdera/0.4.0-incubating/apache-abdera-0.4.0-incubating-src.tar.gz
 >



Some of the MD5 digest files are missing.

  

Fixed.

 >  Maven Repository:
 > http://people.apache.org/~dandiep/abdera-take7/
 >


And where is the SVN tag please?



Same place as always - 
http://svn.apache.org/repos/asf/incubator/abdera/java/tags/abdera-0.4.0-incubating/



--
Dan Diephouse
MuleSource
http://mulesource.com | http://netzooid.com 



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

Re: [VOTE] Release Abdera 0.4.0-incubating Take 7

[Dan Diephouse]

sebb wrote:

What about
  apache-abdera-0.4.0-incubating.pom?
Does that not need an MD5?

  

Fixed.

It would be helpful if the Java requirements were documented in some
obvious places such as in BUILDING and on the overview, building and
download sections of the website.

Two of the tests fail on IBM Java 6:
java version "1.6.0"
Java(TM) SE Runtime Environment (build pwi3260-20071123_01)
IBM J9 VM (build 2.4, J2RE 1.6.0 IBM J9 2.4 Windows XP x86-32
jvmwi3260-20071121_15015 (JIT enabled)

---
Test set: org.apache.abdera.test.parser.stax.FOMTest
---
  
Thanks, but I believe tests only pass on Java 5 at the moment due to 
various JDK changes on Java6. Our build server verifies this and none of 
our releases have ever been published without running the full test suite.


Dan

--
Dan Diephouse
MuleSource
http://mulesource.com | http://netzooid.com 



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

[RESULTS] Re: [VOTE] Release Abdera 0.4.0-incubating Take 7

[Dan Diephouse]

With 4 binding +1s (dims, Matthieu Riou, Garrett Rooney, Paul Fremantle) 
and 4 non binding +1s (me, James Snell, Luciando Resende, Ugo Cei), the 
vote passes!


Thanks for participating and helping give Abdera a big step forward! 
I'll be pushing out the releases and we'll send an announcement soon.


Dan

James M Snell wrote:

Ok, we've updated the release candidate... please review

Take 7 of the vote to release Apache Abdera 0.4.0-incubating. The
following things have changed:
- All necessary files now include ASL headers
- LICENSE file now includes pointers to non-ASL licenses and Mark
Pilgrim's license
- NOTICE files in the jars are much cleaner thanks to the new
maven-remote-resource plugin.
- Information about a jar's dependencies and their licenses are now
included in META-INF/DEPENDENCIES instead of the NOTICE file.
- The NOTICE file in the distributions contains all the stuff not in
lib/*-LICENSE.txt and provides a pointer to the lib directory for the
additional stuff.
- Everything is signed

Binary distributions:

http://people.apache.org/~dandiep/abdera-take7/org/apache/abdera/apache-abdera/0.4.0-incubating/apache-abdera-0.4.0-incubating.zip 

http://people.apache.org/~dandiep/abdera-take7/org/apache/abdera/apache-abdera/0.4.0-incubating/apache-abdera-0.4.0-incubating.tar.gz 



Source distributions:

http://people.apache.org/~dandiep/abdera-take7/org/apache/abdera/apache-abdera/0.4.0-incubating/apache-abdera-0.4.0-incubating-src.zip 

http://people.apache.org/~dandiep/abdera-take7/org/apache/abdera/apache-abdera/0.4.0-incubating/apache-abdera-0.4.0-incubating-src.tar.gz 



Maven Repository: http://people.apache.org/~dandiep/abdera-take7/

- The Abdera folks


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




--
Dan Diephouse
MuleSource
http://mulesource.com | http://netzooid.com 



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

Publishing Releases for Mirrors

[Dan Diephouse]

How do we get "abdera" to show up in here: 
http://www.apache.org/dist/incubator/ ? It seems 
/www/archive.apache.org/dist/incubator/* maps to these directories, but 
not all of them show up.


I copied the abdera release to 
/www/archive.apache.org/dist/incubator/abdera/0.4.0-incubating before I 
read the notice on that above page as it seemed the place it should go. 
Hopefully this isn't flagrantly wrong and it is just some config setting 
to make the abdera release show up and be mirrored?


I poked around on the incubator website, but didn't find correct docs - 
did I miss something?


Dan

--
Dan Diephouse
MuleSource
http://mulesource.com | http://netzooid.com 



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

Re: Publishing Releases for Mirrors

[Dan Diephouse]

Thanks Dan! So obvious in retrospect :-) I did a locate for where the 
cxf binaries where and I must have missed that location.


Dan

Daniel Kulp wrote:

On Thursday 10 April 2008, Dan Diephouse wrote:
  

How do we get "abdera" to show up in here:
http://www.apache.org/dist/incubator/ ?



You have to put them there.

  
It seems 
/www/archive.apache.org/dist/incubator/* maps to these directories,

but not all of them show up.



It's the other way around.   Stuff you put in 
/www/www.apache.org/dist/incubator

will get synced to:
/www/archive.apache.org/dist/incubator

Dan


  

I copied the abdera release to
/www/archive.apache.org/dist/incubator/abdera/0.4.0-incubating before
I read the notice on that above page as it seemed the place it should
go. Hopefully this isn't flagrantly wrong and it is just some config
setting to make the abdera release show up and be mirrored?

I poked around on the incubator website, but didn't find correct docs
- did I miss something?

Dan





  



--
Dan Diephouse
MuleSource
http://mulesource.com | http://netzooid.com 



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

Re: [VOTE] [POLICY] Allow extra release distribution channels like the central Maven repository

[Dan Diephouse]

+1 (non-binding)

The current policy is silly.

On Wed, Sep 10, 2008 at 8:34 AM, Jukka Zitting <[EMAIL PROTECTED]>wrote:

> Hi,
>
> We've had a number of long discussions about the incubating projects
> using the central Maven repository to distribute their releases. The
> current policy is that incubating releases should not go to there. The
> related discussion threads have died with no consensus but the issue
> still exists and affects many podlings. I would like to finally
> resolve the issue one way or another by calling the Incubator PMC to
> vote on the matter.
>
> In INCUBATOR-82 I have prepared a patch (also attached below) that
> changes the policy document to explicitly _allow_ extra distribution
> channels like the central Maven repository for incubating releases.
> Note that the proposed patch allows any such channels instead of
> focusing just on the Maven repository. Also, any releases must still
> be approved, comply with the disclaimer and naming rules, and be
> primarily distributed through the official
> http://www.apache.org/dist/incubator/ channel.
>
> Please vote on accepting or rejecting this policy change! This
> majority vote is open for a week and only votes from the Incubator PMC
> members are binding.
>
> [ ] +1 Yes, allow extra release distribution channels like the central
> Maven repository
> [ ] -1 No, keep the current policy
>
> My vote is +1
>
> BR,
>
> Jukka Zitting
>
> Patch from https://issues.apache.org/jira/browse/INCUBATOR-82:
>
> Index: site-author/incubation/Incubation_Policy.xml
> ===
> --- site-author/incubation/Incubation_Policy.xml(revision 692094)
> +++ site-author/incubation/Incubation_Policy.xml(working copy)
> @@ -489,6 +489,8 @@
> 
>  Releases for podling MUST be distributed through
>  http://www.apache.org/dist/incubator/podling.
> +In addition, the Podling MAY choose to distribute approved releases
> through
> +other channels like the central Maven repository.
> 
>   
>   
>
> ---------
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
>


-- 
Dan Diephouse
http://netzooid.com/blog

Re: [VOTE] Incubator PMC to approve 3.0-M1 release of ServiceMix

[Dan Diephouse]

I am really confused by the reaction to this. I don't see any reason to 
be puzzled or upset.  I don't want to make this a bigger issue than it 
is, but:


1. The project is incubating and this is the first time its done an 
Apache release. There are a lot of check boxes that need to be checked 
to make Apache happy. Overlooking a NOTICE file that almost no one looks 
at doesn't seem like that big of a jump to me. With an M1 release, I 
think everyone was a bit more worried whether the damn thing worked at 
all. As we move toward a .0 release things will certainly get more 
cleaned up.


2. Incubating release don't need to conform to Apache policy as far as I 
understand it. Only to whats outlined in the release section [1]. Thats 
why Roller can release with LGPL dependencies. So in this light, the 
NOTICE file shouldn't be a hold up, no? Only -incubator instead of 
-incubating can.


And, at the risk of being hypocrytical here, can we keep commentary to a 
minimum? -1, +1, suggestions, and informing that requirements aren't met 
is great, but there doesn't seem to be a need to stir things up with how 
you feel a particular project is doing its job.


Regards,

- Dan

1. http://incubator.apache.org/incubation/Incubation_Policy.html#Releases

Leo Simons wrote:

On Wed, Apr 19, 2006 at 10:59:30PM -0400, Noel J. Bergman wrote:
  

-1

Bill Stoddard is correct in his understanding of
http://incubator.apache.org/incubation/Incubation_Policy.html#Releases.  The
fact that other people have voted +1 without verifying that the release
adheres to Incubator policy is a bit disturbing, but that's why we have
multiple sets of eyes on these things.



More than a bit, if you ask me. People even asking for a vote for a release
without a NOTICE file is like, seriously messed up. What is going on around
here lately?

LSD, puzzled(tm)

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

  



--
Dan Diephouse
Envoi Solutions
http://envoisolutions.com
http://netzooid.com/blog


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

Re: [PROPOSAL] CeltiXfire Project

[Dan Diephouse]

Apache projects as well like Woden, Neethi and JaxMe. 


== Avoiding the Warning Signs ==

=== Orphaned products ===
CeltiXfire is a merging of two successful open source projects, ObjectWeb Celtix and Codehaus Xfire. Both have active communities and developers. CeltiXfire provides support for some important specifications to Java community, we expect that this project will continue to grow and develop within its own community, and be embraced by many other open source projects as well. 


=== Inexperience with open source ===
The authors of the existing code have extensive experience with open source already.  The initial list of committers includes 9 Apache Committers.  They are involved in: 
* Apache Continuum 
* Apache Geronimo 
* Apache ServiceMix 
* Apache Tuscany 
* Apache Yoko 


=== Homogeneous developers ===
The project's initial committers include individuals that are employed by a diverse set of companies, including Envoi Solutions, IONA, LogicBlaze, BEA and Red Hat.  About 2/3 of the initial committers are employed by IONA.  Additionally the project has several committers whose work is not funded by any particular employer.  


=== Reliance on Salaried Developers ===
Many of the developers are salaried, but they are spread out over several organizations. Several other developers are contributing to this project without any connection to an employer. 


=== No ties to other Apache products ===
Both ObjectWeb Celtix and Codehaus Xfire currently use many Apache projects. These have 
been outlined in the "alignment" section.

=== A fascination with the Apache brand ===
While we expect the Apache brand may help attract more contributors, our interests in starting this project is based on the factors mentioned in the Rationale section.  However, we will be sensitive to inadvertent abuse of the Apache brand and will work with the Incubator PMC and the PRC to ensure the brand policies are respected.  


=== Scope of Subprojects ===
No subprojects proposed.

== Initial Source ==
The Celtix codebase is owned by IONA. It is currently available under both EPL 
and LGPL licenses (http://celtix.objectweb.org). The applicable code will be 
relicensed under the Apache License 2.0. The Codehaus Xfire codebase is owned 
by Envoi Solutions LLC and is available under an MIT license 
(http://xfire.codehaus.org). The applicable code will be relicensed under the 
Apache Software License 2.0. The dependencies all have Apache compatible 
licenses. These include BSD, CDDL, CPL, MPL and MIT licensed dependencies.

== ASF Resources to be Created ==
* Mailing lists 
  * cxf-dev 
  * cxf-user 
  * cxf-commits 
  * cxf-ppmc 
* SVN Repository https://svn.apache.org/repos/asf/incubator/cxf 
* JIRA CeltiXfire (CeltiXfire) 
* Official Build Systems 


== Initial Committers ==
* Adi Sakala  
* Dan Diephouse 
* Guillaume Nodet 
* James Strachan 
* David Blevins  
* Peter Royal  
* Daniel Kulp 
* Balaji Ravi 
* Conrad O'Dea
* Hani Suileman 
* Mika Goekel  
* Adam Kramer 
* Tomek Sztelak
* Stuart Edmondston 
* Bozhong Lin 
* Jervis Liu 
* Julian Squires  
* James Mao  
* Jim Ma
* Freeman Fang 
* Tom Li  
* Willem Jiang 
* Andrea Smyth  
* Eoghan Glynn 
* Debbie Moynihan
* Ajay Paibir 
* Ulhas Bhole 
* Sean O'Callaghan  
* Peter Jones  
* Eric Johnson 
* Brian Zotter

* Mark Little

== Sponsor ==
We kindly request the Incubator PMC to accept sponsorship for this proposal. 


== Champion ==
Jason Van Zyl
 
== Mentors ==
* Jason Van Zyl  
* Jim Jagielski   
* James Strachan 


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

 




--
Dan Diephouse
(616) 971-2053
Envoi Solutions LLC
http://netzooid.com



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

Re: [PROPOSAL] CeltiXfire Project

[Dan Diephouse]

Please, Hani has been a great contributor to the XFire project:

http://fisheye.codehaus.org/changelog/~author=hani/xfire/

Not only has he contributed code, he has written documentation and 
helped users out on the mailing list/irc. While you may not like what  
he says on his blog, anyone that has worked with him on a project will 
vouch for his extensive expertise and ability to work in a team.


I could go on, but I don't think this discussion will benefit from it.

- Dan

Sanjiva Weerawarana wrote:


On Tue, 2006-06-20 at 13:52 -0400, Sakala, Adinarayana wrote:
 


== Initial Committers ==
   


...
 

* Hani Suileman 
   



Wow. Interesting. Never imagined Hani'd come our way. See for example
his latest masterpiece from
http://www.jroller.com/page/fate/?anchor=defecating_on_a_jdk:

"In a rather perplexing move, it's announced that the Java 6 JDK will
include Derby, the turdy little unwanted IBM poop plopped onto Apache
(about par for the course, since large swathes of Apache seem to exit
solely as an IBM marketing tool.)"

And also from
http://www.jroller.com/page/fate/?anchor=javaone_bea_keynote:

"Someone must have given him the wrong suppository to make him say such
horrible things, come on, of all people, surely he'd know that Apache
does NOT have 'cool software'?"

And also from (my personal favorite of course)
http://www.jroller.com/page/fate/?anchor=axis2_why_bother:

"Swing development requires people with at least a double digit IQ,
which (with maybe two exceptions) nobody at the Java side of Apache has
managed to evolve to."

and

"As much as I hate Apache, one thing one could always count on is their
moralistic holier than thou good behaviour."



Is Hani seriously going to participate in an Apache meritocracy or is
this some kind of joke?

Sanjiva.


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

 




--
Dan Diephouse
(616) 971-2053
Envoi Solutions LLC
http://netzooid.com


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

Re: [PROPOSAL] CeltiXfire Project

[Dan Diephouse]

= Community ==
The CeltiXfire Community will bring together two already successful 
communities - Xfire and Celtix. Both projects have active users and 
contributors on the mailing lists.


== Core Developers ==
The CeltiXfire project's initial committers include a diverse set of 
individuals. Some of the individuals are employed by Envoi Solutions, 
IONA, BEA, LogicBlaze and Red Hat, and some are not funded by any 
particular employer.


== Alignment ==
CeltiXfire currently uses and integrates with many Apache projects 
but does not have hard dependencies on these (in alphabetical order):

 * ActiveMQ is used as the default JMS implementation.
 * Continuum: Apache Continuum currently uses XFire for its SOAP 
integration.
 * Harmony: Harmony is implementing Java 5.0 and requires support for 
many of the JSR that CeltiXfire will provide.

 * Jakarta Commons HttpClient can be used for the HTTP client transport.
 * Geronimo: Celtix already provides Geronimo integration. CeltiXfire 
will continue this effort and will be made available so that Geronimo 
could use CeltiXfire as its JAX-WS implementation for JEE.
 * ServiceMix: Codehaus XFire is currently used within ServiceMix to 
provide web service integration. Celtix provides its own JBI 
integration for ServiceMix as well, although JBI is an option and not 
a requirement for Celtix implementation.
 * Maven 2: Celtix and Xfire already provide Maven 2 plug-ins for 
invoking the Celtix and Xfire tooling.

 * Tuscany: Celtix is already integrated with Tuscany.
 * WSS4J: CeltiXfire uses Apache WSS4J for WS-Security support.
 * XMLBeans is currently used as one of the data-binding options for 
CeltiXfire.
 * XmlSchema: CeltiXfire uses XmlSchema for many schema related 
functions internally.
 * Yoko: Celtix is already integrated with Yoko to provide support 
for exposing CORBA services as web services.


We are currently evaluating the use of other Apache projects as well 
like Woden, Neethi and JaxMe.


== Avoiding the Warning Signs ==

=== Orphaned products ===
CeltiXfire is a merging of two successful open source projects, 
ObjectWeb Celtix and Codehaus Xfire. Both have active communities and 
developers. CeltiXfire provides support for some important 
specifications to Java community, we expect that this project will 
continue to grow and develop within its own community, and be 
embraced by many other open source projects as well.


=== Inexperience with open source ===
The authors of the existing code have extensive experience with open 
source already.  The initial list of committers includes 9 Apache 
Committers.  They are involved in:

 * Apache Continuum
 * Apache Geronimo
 * Apache ServiceMix
 * Apache Tuscany
 * Apache Yoko

=== Homogeneous developers ===
The project's initial committers include individuals that are 
employed by a diverse set of companies, including Envoi Solutions, 
IONA, LogicBlaze, BEA and Red Hat.  About 2/3 of the initial 
committers are employed by IONA.  Additionally the project has 
several committers whose work is not funded by any particular employer.


=== Reliance on Salaried Developers ===
Many of the developers are salaried, but they are spread out over 
several organizations. Several other developers are contributing to 
this project without any connection to an employer.


=== No ties to other Apache products ===
Both ObjectWeb Celtix and Codehaus Xfire currently use many Apache 
projects. These have been outlined in the "alignment" section.


=== A fascination with the Apache brand ===
While we expect the Apache brand may help attract more contributors, 
our interests in starting this project is based on the factors 
mentioned in the Rationale section.  However, we will be sensitive to 
inadvertent abuse of the Apache brand and will work with the 
Incubator PMC and the PRC to ensure the brand policies are respected.


=== Scope of Subprojects ===
No subprojects proposed.

== Initial Source ==
The Celtix codebase is owned by IONA. It is currently available under 
both EPL and LGPL licenses (http://celtix.objectweb.org). The 
applicable code will be relicensed under the Apache License 2.0. The 
Codehaus Xfire codebase is owned by Envoi Solutions LLC and is 
available under an MIT license (http://xfire.codehaus.org). The 
applicable code will be relicensed under the Apache Software License 
2.0. The dependencies all have Apache compatible licenses. These 
include BSD, CDDL, CPL, MPL and MIT licensed dependencies.


== ASF Resources to be Created ==
 * Mailing lists
   * cxf-dev
   * cxf-user
   * cxf-commits
   * cxf-ppmc
 * SVN Repository https://svn.apache.org/repos/asf/incubator/cxf
 * JIRA CeltiXfire (CeltiXfire)
 * Official Build Systems

== Initial Committers ==
 * Adi Sakala
 * Dan Diephouse
 * Guillaume Nodet
 * James Strachan
 * David Blevins
 * Peter Royal
 * Daniel Kulp
 * Balaji Ravi
 * Conrad O'Dea
 * Hani Suileman
 * Mika Goekel
 * Adam Kramer
 * Tomek Sztelak
 * Stuart Edmondston

Re: [PROPOSAL] CeltiXfire Project

[Dan Diephouse]

Justin Erenkrantz wrote:

On 6/21/06, Yoav Shapira <[EMAIL PROTECTED]> wrote:

> Do you think its useful to have individual employer?
> Obviously if anyone wants more detailed info I am happy to provide 
that.


I do think it's useful.  If it's a pain to update the proposal to
reflect these individual associations, I apologize.  If others don't
think it's useful, they can chime in ;)


Yes, it's our policy to disclose employment information for Incubator
project committers so that the Incubator PMC can make an accurate
assessment about the composition of the community - especially when
the proposal says that: "About 2/3 of the initial committers are
employed by IONA."

In order to graduate, we require:

http://incubator.apache.org/incubation/Incubation_Policy.html#Minimum+Exit+Requirements 



---
The project is not highly dependent on any single contributor (there's
at least 3 legally independent committers and there is no single
company or entity that is vital to the success of the project)
---

HTH.  -- justin


I added the name of each individual's employer where appropriate and 
also which project they're associated with, if any:


http://wiki.apache.org/incubator/CeltiXfireProposal

Thanks Justin and Yoav.

- Dan

--
Dan Diephouse
Envoi Solutions
http://envoisolutions.com
http://netzooid.com/blog


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

Re: [PROPOSAL] CeltiXfire Project

[Dan Diephouse]

Justin Erenkrantz wrote:

On 6/21/06, Mika Göckel <[EMAIL PROTECTED]> wrote:

Hey!

It has been chosen from some (weird) alternatives in a discussion
between (some of) the listed intial committers.
 From my point of (not native speaker's) view, it has karma, it's
expressive and not technical (I personally don't like too descriptive
names or even acronyms).
My opinion is, that the name will stay -- do you think it'll need 
another?


It depends upon whether Celtix and XFire are completely shuttered down
in favor of the new Apache projects - or will they continue on in some
form?  Mainly that all project resources, lists, websites, etc. are
transitioned over.  If they will be continued, then yes, this project
should get a different name as to avoid confusion.

For an example, compare SpamAssassin with Felix.  For SpamAssassin,
everything got transitioned over ultimately.  But, for Felix, the
ObjectWeb resources are still (somewhat) maintained.  -- justin
Currently the plan is to leave both the old websites & docs will at the 
old locations. And XFire will be making release until Celtixfire 
releases a .0 release. I think Celtix will probably make some 1.x or 
1.0.x releases as well.


Is this official policy? Or do we just need to come to some consensus as 
to whether or not this will be confusing for our users?


- Dan

--
Dan Diephouse
Envoi Solutions
http://envoisolutions.com
http://netzooid.com/blog


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

Re: [PROPOSAL] CeltiXfire Project

[Dan Diephouse]

Thomas Dudziak wrote:

(Btw, I don't know whether it's him anyway, because the name is
spelled differently.)
It was meant to be Hani Suleiman. I spelled his name wrong on the 
proposal and corrected it in the wiki immediately proceeding our submission.


- Dan

--
Dan Diephouse
Envoi Solutions
http://envoisolutions.com
http://netzooid.com/blog


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

Re: [PROPOSAL] CeltiXfire Project

[Dan Diephouse]

Sanjiva Weerawarana wrote:

I thought XFire does all these specs too
(http://xfire.codehaus.org/Stack+Comparison; except for obviously
JAX-WSA as that's not even done yet). So what part of Celtix (other than
the name) is in Celtixfire in that case?

  
Celtix has JAX-WS nearly fully done (hard to tell when the TCK isn't 
available yet), where as XFire only has about 50% done.  Additionally 
Celtix has things like WS-RM, better JMX Integration, a better JMS 
transport, etc.



However, I'm not certain Iona folks look at it as just an impl of these
specs- at least that's not the impression I've gotten so far. Adi or any
of the Iona folks can you indicate what exactly Celtixfire is from your
point of view? Celtix is still marketed as an ESB and James' picture
doesn't quite fit. From http://celtix.objectweb.org/: "Celtix 1.0
provides users with a feature-rich, open source ESB runtime that can
support any organization’s adoption of Service Oriented Architecture
(SOA) in the enterprise."
I don't presume to speak for IONA, but after chatting with them a fair 
amount I wouldn't let their marketing team influence your opinion of 
what the project is about.


- Dan

--
Dan Diephouse
Envoi Solutions
http://envoisolutions.com
http://netzooid.com/blog


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

Re: mentoring celtixfire

[Dan Diephouse]

peter royal wrote:

i'm volunteering to help mentor celtixfire, i've added myself to the  
list in the wiki.

-pete


Excellent, thanks for volunteering! Cheers,
- Dan

--
Dan Diephouse
(616) 971-2053
Envoi Solutions LLC
http://netzooid.com


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

Re: [PROPOSAL] CeltiXfire Project

[Dan Diephouse]

Hi Jim,
Even once we're in the incubator the XFire project will still have to do 
releases. We have a 1.2 release in progress and will be doing bug fix 
releases as well.  Additionally, I would imagine IONA might want to 
issue a bug fix release at some point for Celtix. I can't really comment 
on them though.


- Dan

Jim Jagielski wrote:


We've handled these types of things before, for example
with SpamAssassin and Cayenne, when external codebases
were being folded into the incubator. What they've done
is mention on the old sites that the projects are
now ASF Incubator projects, etc... The intent is that
until the code has been relicensed to the AL 2.0, we
cannot host it here, but as soon as that happens, the
old sites no longer host the current codebases, just
the old ones.

At no time should Celtix and XFire continue parallel
development with what is in the Incubator after the
podling has started.

On Jun 30, 2006, at 8:01 AM, Paul Fremantle wrote:


Robert +1

I think also, given that I understand that the Celtix and XFire
projects will remain alive outside, at least for the initial future,
that it would help reduce confusion to have a separate and distinct
name for the Apache project.

Paul

On 6/30/06, robert burrell donkin <[EMAIL PROTECTED]>  
wrote:



On 6/21/06, Justin Erenkrantz <[EMAIL PROTECTED]> wrote:
>
> On 6/21/06, Dan Diephouse <[EMAIL PROTECTED]> wrote:
> > Currently the plan is to leave both the old websites & docs  
will at the

> > old locations. And XFire will be making release until Celtixfire
> > releases a .0 release. I think Celtix will probably make some  
1.x or

> > 1.0.x releases as well.
>
> Given that, I think it's probably prudent to consider  alternative 
names.



+1

> Is this official policy? Or do we just need to come to some  
consensus as

> > to whether or not this will be confusing for our users?
>
> Our naming policy is to strive very hard not to conflict with any
> other projects.  If those projects are going to continue  
independently

> of CeltiXfire, then I'd view that as a conflict we should avoid.


i wonder as well whether iona may need to consider whether they  really
understand the implications of choosing this name for the apache  
project.
the ASF would own the Apache CeltiXFire trademark and the  community 
is very

sensitive to issues around usage especially with regard to marketing.

our model is different from objectweb and it is likely that the  
existing
approach that iona takes when marketing celtix would need to be  
changed.
apache is really centered on individuals. corporations of all  kinds 
as well
as many individuals find space to coorporate by this focus. this  
corporation
transparency implies neutrality. AIUI this is very different to  the 
approach

taken at (for example) objectweb.

in addition, it is possible that iona may wish to maintain  separate 
patched
versions of the apache codebase. this may cause difficulties if  
iona needed

to promote these products using an apache trademark.

quite a lot of energy would be required for iona to maintain  marketing
material making extensive use of a possible Apache CeltiXFire  
trademark. a
growing number of projects are also known to the outside by  
marketing names
(for example apache derby). this allows a much greater degree of  
freedom as

well as building separate value for their corporation in their brand.

this may help to explain the trend towards unique but non- 
descriptive names

for projects.

- robert





--
Paul Fremantle
VP/Technology, WSO2 and OASIS WS-RX TC Co-chair

http://bloglines.com/blog/paulfremantle
[EMAIL PROTECTED]

"Oxygenating the Web Service Platform", www.wso2.com

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




--
Dan Diephouse
(616) 971-2053
Envoi Solutions LLC
http://netzooid.com


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

Re: [PROPOSAL] CeltiXfire Project

[Dan Diephouse]

+1 - The XFire community will definitely still need the ability to make 
releases after we graduate. As you said, there are big incompatabile 
changes (I think of this as like a 2.0)  and its a merge, so we can't 
leave existing users in the dust.

- Dan

Guillaume Nodet wrote:


Could you please explain the rational behind that ?
When merging two existing code bases, the two community will
certainly focus on the merge, but existing users should not be
left without any support.  Even when the podling start
release something, there are big changes that the new project
will be incompatible with the old donations.
This of course leads to the need for bug fix releases on the old
projects.
On another point, the old code bases are open source and when
licensed under ASL, you have no way to control who use
those codebases.
Merging two projects give a third project, not something that is
backward compatible with the old codebases...

Cheers,
Guillaume Nodet

Jim Jagielski wrote:


Yes, up until the podling can make releases, the old
"external" projects still can do releases. However,
it's expected that once the podling starts releases,
that the 2 external ones shut down.

On Jun 30, 2006, at 9:30 AM, Dan Diephouse wrote:


Hi Jim,
Even once we're in the incubator the XFire project will still have  
to do releases. We have a 1.2 release in progress and will be doing  
bug fix releases as well.  Additionally, I would imagine IONA might  
want to issue a bug fix release at some point for Celtix. I can't  
really comment on them though.


- Dan

Jim Jagielski wrote:


We've handled these types of things before, for example
with SpamAssassin and Cayenne, when external codebases
were being folded into the incubator. What they've done
is mention on the old sites that the projects are
now ASF Incubator projects, etc... The intent is that
until the code has been relicensed to the AL 2.0, we
cannot host it here, but as soon as that happens, the
old sites no longer host the current codebases, just
the old ones.

At no time should Celtix and XFire continue parallel
development with what is in the Incubator after the
podling has started.

On Jun 30, 2006, at 8:01 AM, Paul Fremantle wrote:


Robert +1

I think also, given that I understand that the Celtix and XFire
projects will remain alive outside, at least for the initial future,
that it would help reduce confusion to have a separate and distinct
name for the Apache project.

Paul

On 6/30/06, robert burrell donkin  
<[EMAIL PROTECTED]>  wrote:



On 6/21/06, Justin Erenkrantz <[EMAIL PROTECTED]> wrote:
>
> On 6/21/06, Dan Diephouse <[EMAIL PROTECTED]> wrote:
> > Currently the plan is to leave both the old websites & docs   
will at the
> > old locations. And XFire will be making release until  
Celtixfire
> > releases a .0 release. I think Celtix will probably make  
some  1.x or

> > 1.0.x releases as well.
>
> Given that, I think it's probably prudent to consider   
alternative names.



+1

> Is this official policy? Or do we just need to come to some   
consensus as

> > to whether or not this will be confusing for our users?
>
> Our naming policy is to strive very hard not to conflict with any
> other projects.  If those projects are going to continue   
independently

> of CeltiXfire, then I'd view that as a conflict we should avoid.


i wonder as well whether iona may need to consider whether they   
really
understand the implications of choosing this name for the  
apache  project.
the ASF would own the Apache CeltiXFire trademark and the   
community is very
sensitive to issues around usage especially with regard to  
marketing.


our model is different from objectweb and it is likely that the   
existing
approach that iona takes when marketing celtix would need to be   
changed.
apache is really centered on individuals. corporations of all   
kinds as well
as many individuals find space to coorporate by this focus.  
this  corporation
transparency implies neutrality. AIUI this is very different to   
the approach

taken at (for example) objectweb.

in addition, it is possible that iona may wish to maintain   
separate patched
versions of the apache codebase. this may cause difficulties if   
iona needed

to promote these products using an apache trademark.

quite a lot of energy would be required for iona to maintain   
marketing
material making extensive use of a possible Apache CeltiXFire   
trademark. a
growing number of projects are also known to the outside by   
marketing names
(for example apache derby). this allows a much greater degree  
of  freedom as
well as building separate value for their corporation in their  
brand.


this may help to explain the trend towards unique but non-  
descriptive names

for projects.

- robert





--
Paul Fremantle
VP/Technology, WSO2 and OASIS W

Re: [VOTE] [UPDATE] CeltiXfire Project Proposal

[Dan Diephouse]

Sanjiva Weerawarana wrote:

On Tue, 2006-07-18 at 21:38 -0400, Noel J. Bergman wrote:
  

Jason,

I am +1 for the project, overall.

I do suggest that we start out with the PPMC of you and the other Mentors,
have you bring Dan and other appropriate people onto the PMC as your first
order of business, and them go about selecting Committers.  From what I
recall at ApacheCon, there was some uncertaintly about the current roster,
so let's allow the PPMC to review and address as appropriate.

As was discussed at ApacheCon EU, I hope that the project will continue
efforts to collaborate with the rest of the Web Services community at the
ASF, because I hate to see wasted, redundant, effort when collaboration is
possible.  And it certainly appears from discussion that they are willing to
explore any number of options.

So give it your best effort, and good luck.  :-)



+1 Noel. I'd like to join the PPMC too as an interested party observer.
I will poke my nose in as a mentor when possible but don't have the
cycles to commit to it.

Hi Sanjiva,

I'm confused, you're saying you don't have the time to commit to it, but 
you want to be one? Mentors have some very concrete responsibilities:


http://incubator.apache.org/incubation/Roles_and_Responsibilities.html#Mentor

While I value your feedback and input, if you don't have enough time, I 
don't understand why you should be a mentor. We have 4 mentors already, 
and from a logistical standpoint I find it hard to keep up with. Each 
mentor tends to have a different opinion or different input.  While more 
input can be great, it can easily get to the point of overload and 
impedes Getting Stuff Done. :-)


- Dan

--
Dan Diephouse
Envoi Solutions
http://envoisolutions.com
http://netzooid.com/blog


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

Re: [VOTE] [UPDATE] CeltiXfire Project Proposal

[Dan Diephouse]

William A. Rowe, Jr. wrote:

Noel J. Bergman wrote:

Dan Diephouse wrote:


We have 4 mentors already,
and from a logistical standpoint I find it hard to keep up with. Each
mentor tends to have a different opinion or different input.  While 
more

input can be great, it can easily get to the point of overload and
impedes Getting Stuff Done. :-)


As for your legitimate concern, if you do find that there are discordant
views coming to CeltixFire from the PMC, please first discuss it 
within the
project, and if that doesn't help to resolve it, inform the Incubator 
PMC so

that we can address the problem.


I was gonna say ... when we do things right, all of your mentors, one 
of them
or 5 of them all speak with one voice.  When that doesn't happen 
confront them
(politely) with the discrepancy.  90+% of the time, you probably will 
discover

they were saying the same thing, different ways, same net result.
Just to be clear, I'm talking about things like "How should we explain X 
on our proposal." There is a lot of the process which is not black and 
white, but more opinion based.


Cheers,

- Dan

--
Dan Diephouse
Envoi Solutions
http://envoisolutions.com
http://netzooid.com/blog


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

Re: [VOTE] [UPDATE] CeltiXfire Project Proposal

[Dan Diephouse]

Sanjiva Weerawarana wrote:

On Wed, 2006-07-19 at 21:28 -0400, Dan Diephouse wrote:
  

+1 Noel. I'd like to join the PPMC too as an interested party observer.
I will poke my nose in as a mentor when possible but don't have the
cycles to commit to it.
  

Hi Sanjiva,

I'm confused, you're saying you don't have the time to commit to it, but 
you want to be one? Mentors have some very concrete responsibilities:



You misunderstood as I wasn't clear: I used "mentor" in the English
sense and not in the "Mentor" role sense. You know, like give some
suggestions and maybe even unsolicited advice here and there. I've done
that to various projects .. whether I'm a Mentor or not. No one is
required to take such advice seriously.

  

That makes more sense now.
While I value your feedback and input, if you don't have enough time, I 
don't understand why you should be a mentor. We have 4 mentors already, 
and from a logistical standpoint I find it hard to keep up with. Each 
mentor tends to have a different opinion or different input.  While more 
input can be great, it can easily get to the point of overload and 
impedes Getting Stuff Done. :-)



The Getting Stuff Done part in the project is restricted to the
technical part - mentoring is not about getting stuff done. I know a
thing or two about the technical area Dan and I darned well will have
input on it. Do you see that as a problem too? 
  
As I said in the previous message, I value your input. My comment about 
the mentors and lots of opinions was more in reference to non technical 
things, like the art of writing an Apache Incubator proposal.

Mentors are not there to give input on technical stuff. They are around
to ensure that the project behaves and acts as an ASF project (over
time)- if you are saying that you don't want any pontificating advice
from me on how to run the project, that's totally fine. I have no desire
to poke my nose in if its not welcome .. what I said in my email is that
I don't have the time to take the "Mentor" role but that I will mentor
where I see something not quite koshure but if that's a problem/concern
all is ok fine with me.
  
I hope you will poke your nose in, just as I read the axis list and try 
to poke my nose in there.


Cheers,
- Dan

--
Dan Diephouse
Envoi Solutions
http://envoisolutions.com
http://netzooid.com/blog


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

Re: [VOTE] [UPDATE] CeltiXfire Project Proposal

[Dan Diephouse]

Why is there a difference? I am not an Axis committer. Just because I've 
become a ws-commons doesn't mean I have a responsibility to participate 
in Axis, Tuscany, or any number of other projects. If so, I would feel 
especially bad for the Jakarta folks. Furthermore, I started 
participating on the lists before I became a ws-commons committer.

- Dan

Davanum Srinivas wrote:

There's a slight difference Dan. As you are a WS committer, you have a
right and responsibility to poke your nose and you do have the karma
to work on / fix anything you feel like in various ws projects. I hope
you appreciate the difference :)

-- dims

On 7/21/06, Dan Diephouse <[EMAIL PROTECTED]> wrote:

Sanjiva Weerawarana wrote:
> On Wed, 2006-07-19 at 21:28 -0400, Dan Diephouse wrote:
I hope you will poke your nose in, just as I read the axis list and try
to poke my nose in there.

Cheers,
- Dan

--
Dan Diephouse
Envoi Solutions
http://envoisolutions.com
http://netzooid.com/blog


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








--
Dan Diephouse
Envoi Solutions
http://envoisolutions.com
http://netzooid.com/blog


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

Adding projects to report scheduel? [was Re: REMINDER: AUGUST REPORTS ARE ***DUE***]

[Dan Diephouse]

I just took the liberty of adding CeltiXfire to the 
Jan/April/July/October schedule. I don't think there is policy for this 
so I just went and did it :-) Let me know if this wasn't appropriate, 
but otherwise we will just plan on reporting then.

- Dan

Noel J. Bergman wrote:


The page has been sitting waiting for content:

 http://wiki.apache.org/incubator/August2006

Reports are due every month folks.  I should not have to constantly nag you
to get them in.

--- Noel



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

 




--
Dan Diephouse
(616) 971-2053
Envoi Solutions LLC
http://netzooid.com


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

Re: Setting up a Maven 2 repo Was: Maven 2 repo for incubating project releases?

[Dan Diephouse]

Yeah, I find this a bit confusing too. The ibiblio repository 
distribution policy is unrelated to Apache's. No one is making any 
claims on ibiblio about  the licensing (other than its freely 
distributable)/community/etc - I mean, come on, there are sourceforge 
binaries on there! :-)


Also, Guillaume makes a good point, anybody create upload requests for 
ibiblio. Why couldn't I go make an upload request for any of the 
incubating projects? You don't have to be a project coordinator to get 
jars uploaded. It only needs to be a freely distributable binary.


I'm +1 to creating the repositories and its a very necessary first step, 
but I think things should go further.


- Dan

Guillaume Nodet wrote:
What is the real purpose of such a repository if it is not synced to 
ibiblio ?

What if a user of an incubating project create an upload request ?
There's no reason why Apache internal policies would affect such a 
request.

AFAIK, Ibiblio repository is not owned by the ASF ...

Jason van Zyl wrote:

+1

On 14 Aug 06, at 5:03 PM 14 Aug 06, Henri Yandell wrote:


On 8/7/06, Henri Yandell <[EMAIL PROTECTED]> wrote:


> people.apache.org/repo/m1-incubating-repository
> people.apache.org/repo/m2-incubating-repository

Noel, shall I go ahead and create the above? They get my +1 from a
repository@ point of view.


Pinging on this to make sure the Incubator is happy with the idea
before I set it up.

Hen

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




Jason van Zyl
[EMAIL PROTECTED]




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




--
Dan Diephouse
Envoi Solutions
http://envoisolutions.com
http://netzooid.com/blog


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

Re: [policy] incubating projects and maven repositories v1.0

[Dan Diephouse]

Jason van Zyl wrote:

Hi,

It looks like people objected to creating another mailing list for 
policy so I just used [policy] as Robert did in a previous message.


Henri has setup Maven repositories for the incubator and there is a 
document which is an attempt to describe the current setup here:


http://www.apache.org/dev/repository-faq.html

I think that everyone agrees that a separate repository for incubating 
projects is a good idea as


1) you can clearly see what incubator artifacts have been created
2) we can perform analysis and create reports for incubator artifacts 
easily (using Archiva, the maven repository manager)
3) separating the administration duties of the incubator repository is 
a good idea I think. This might involve a different instance of 
Archiva and/or different people looking after the respective repositories


I haven't looked at all the projects using Maven in the incubator but 
cxf, the one I'm most involved with, looks like its settling on 
versions like:


2.0-incubator-SNAPSHOT

So the repository is clearly separated, and from a dependency element 
in a Maven POM you can clearly see it's an incubator version.


There was discussion that incubator repository would not be sync'd to 
the central repository but I don't really see much point in this. A 
few folks with incubating projects have voiced concerns that they 
don't want to see their projects be taken out of circulation in the 
central repository because they are incubating. If each and every 
incubating project has a version for each artifact like that above 
then it will be fairly clear that it's from the incubator. Moreso then 
if you just had a repository definition pointing at the incubator 
repository.


Also someone may make an repository request to place an incubator 
artifact in the central repository and at this point a policy mandated 
here would conflict with someone's right to redistribute artifacts 
created in the incubator. I don't really want to get into the business 
of policing repository requests. I think it is in the best interests 
of the  incubating projects to have the incubator repository sync'd to 
Maven's central repository. The source of artifacts for incubating 
projects is clear from the version so I don't think there will be any 
confusion by consumers of these artifacts and as such I don't really 
see any downside to allowing the sync to Maven's central repository.


Thoughts?

Jason van Zyl
[EMAIL PROTECTED]


+1.

- Dan

--
Dan Diephouse
Envoi Solutions
http://envoisolutions.com
http://netzooid.com/blog


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

Re: [policy] incubating projects and maven repositories v1.0

[Dan Diephouse]

Niclas Hedhman wrote:

On Monday 28 August 2006 11:31, Jason van Zyl wrote:
  
Could that report be made part of the release:prepare and the  
release manager

had to explicitly approve it??
  
How are we supposed to enforce that? And what if they are not using  
Maven? Say using either the Maven Ant Tasks, or Ivy, or just an http  
get to get artifacts from a repository.



We are probably misunderstanding each other...
The question that came up was about transitive dependencies, which the user do 
not necessarily check for, and could end up being dependent on incubating 
projects against his/her will. Something that can't happen for snapshots 
(unless you bypass Maven's intended behaviours) 

You said, that one can check the full set of dependencies from a report 
generated by Maven2.


I said, if that report could be output during the release:prepare phase, and 
that if the release:prepare phase would require the release manager to 
approve the use of that dependency tree, then we put the responsibility in 
the hands of the Maven2 user.


You then start talking about 'enforcement'... And I am lost. Enforcing what? 
If the report can be generated, then either your statement above isn't valid, 
or the report is not capable of reporting the dependencies, in which case the 
original statement is not accurate.


I suspect that you are trying to find problems with non-Maven systems, but 
that can always happen and not the issue at hand. BuildSystemAbc could pull 
down all kinds of stuff for the users, including snapshots, pirated software 
and virii. IMHO, Maven repositories exist mainly to support Maven and 
Maven-compatible(!) build systems.


Your suggestions in the original mail is very good, and *I* don't have any 
opinion about whether a separate Incubating repository is needed or not. Both 
arguments for and against sound reasonable.
  
I don't really think that this is going to help anything. The user is 
always in control.  The responsibility has never left their hands. Lets 
step away from the incubator a sec and take GPL jars for instance - if 
there is a transitive dependency on GPL jars, the user is completely 
responsible for that. Why would it be any different for an incubator JAR?


- Dan

--
Dan Diephouse
Envoi Solutions
http://envoisolutions.com
http://netzooid.com/blog


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

Re: [policy] incubating projects and maven repositories v1.0

[Dan Diephouse]

Why?

Davanum Srinivas wrote:

If it comes to a VOTE, i'd vote -1 on automatic syncing of incubator
artifacts to maven central repo.

-- dims

On 8/30/06, Dan Diephouse <[EMAIL PROTECTED]> wrote:

Jason van Zyl wrote:
> Hi,
>
> It looks like people objected to creating another mailing list for
> policy so I just used [policy] as Robert did in a previous message.
>
> Henri has setup Maven repositories for the incubator and there is a
> document which is an attempt to describe the current setup here:
>
> http://www.apache.org/dev/repository-faq.html
>
> I think that everyone agrees that a separate repository for incubating
> projects is a good idea as
>
> 1) you can clearly see what incubator artifacts have been created
> 2) we can perform analysis and create reports for incubator artifacts
> easily (using Archiva, the maven repository manager)
> 3) separating the administration duties of the incubator repository is
> a good idea I think. This might involve a different instance of
> Archiva and/or different people looking after the respective 
repositories

>
> I haven't looked at all the projects using Maven in the incubator but
> cxf, the one I'm most involved with, looks like its settling on
> versions like:
>
> 2.0-incubator-SNAPSHOT
>
> So the repository is clearly separated, and from a dependency element
> in a Maven POM you can clearly see it's an incubator version.
>
> There was discussion that incubator repository would not be sync'd to
> the central repository but I don't really see much point in this. A
> few folks with incubating projects have voiced concerns that they
> don't want to see their projects be taken out of circulation in the
> central repository because they are incubating. If each and every
> incubating project has a version for each artifact like that above
> then it will be fairly clear that it's from the incubator. Moreso then
> if you just had a repository definition pointing at the incubator
> repository.
>
> Also someone may make an repository request to place an incubator
> artifact in the central repository and at this point a policy mandated
> here would conflict with someone's right to redistribute artifacts
> created in the incubator. I don't really want to get into the business
> of policing repository requests. I think it is in the best interests
> of the  incubating projects to have the incubator repository sync'd to
> Maven's central repository. The source of artifacts for incubating
> projects is clear from the version so I don't think there will be any
> confusion by consumers of these artifacts and as such I don't really
> see any downside to allowing the sync to Maven's central repository.
>
> Thoughts?
>
> Jason van Zyl
> [EMAIL PROTECTED]

+1.

- Dan

--
Dan Diephouse
Envoi Solutions
http://envoisolutions.com
http://netzooid.com/blog


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








--
Dan Diephouse
Envoi Solutions
http://envoisolutions.com
http://netzooid.com/blog


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

Re: [policy] incubating projects and maven repositories v1.0

[Dan Diephouse]

Justin Erenkrantz wrote:

On 8/30/06, Davanum Srinivas <[EMAIL PROTECTED]> wrote:

If it comes to a VOTE, i'd vote -1 on automatic syncing of incubator
artifacts to maven central repo.


I would -1 it as well.

The idea behind a separate repository was to make it very explicit to
the user that they are fetching stuff from the Incubator.  This
strikes me as an end-run around that policy...  -- justin

Well it can be run around right now too. I as a user of an incubating 
project can request that a jar be uploaded to ibiblio. The incubator and 
ibiblio policies are distinct. Unless the incubator can enforce policy 
on the Ibiblio/Maven project for them to police the artifacts, they can 
currently be redistributed on Ibiblio, it is just an extra pain for me 
as a user.


- Dan

--
Dan Diephouse
Envoi Solutions
http://envoisolutions.com
http://netzooid.com/blog


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

Re: [policy] incubating projects and maven repositories v1.0

[Dan Diephouse]

Yes, and I feel that Jason is addressing the issues brought up 
previously. As Jason stated, and I reiterated in my message to Justin, 
the incubator policy doesn't really affect the ibiblio distribution 
policy, so I see those as in conflict right now. So I want to know on 
what grounds the incubator can prevent me from requesting that some 
incubating jars from being uploaded to ibiblio.


- Dan

Davanum Srinivas wrote:

I guess, you need to read more emails on this list :) For example see [1]

thanks,
dims

[1] 
http://marc.theaimsgroup.com/?l=incubator-general&m=115440663222532&w=2



On 8/30/06, Dan Diephouse <[EMAIL PROTECTED]> wrote:

Why?

Davanum Srinivas wrote:
> If it comes to a VOTE, i'd vote -1 on automatic syncing of incubator
> artifacts to maven central repo.
>
> -- dims
>
> On 8/30/06, Dan Diephouse <[EMAIL PROTECTED]> wrote:
>> Jason van Zyl wrote:
>> > Hi,
>> >
>> > It looks like people objected to creating another mailing list for
>> > policy so I just used [policy] as Robert did in a previous message.
>> >
>> > Henri has setup Maven repositories for the incubator and there is a
>> > document which is an attempt to describe the current setup here:
>> >
>> > http://www.apache.org/dev/repository-faq.html
>> >
>> > I think that everyone agrees that a separate repository for 
incubating

>> > projects is a good idea as
>> >
>> > 1) you can clearly see what incubator artifacts have been created
>> > 2) we can perform analysis and create reports for incubator 
artifacts

>> > easily (using Archiva, the maven repository manager)
>> > 3) separating the administration duties of the incubator 
repository is

>> > a good idea I think. This might involve a different instance of
>> > Archiva and/or different people looking after the respective
>> repositories
>> >
>> > I haven't looked at all the projects using Maven in the 
incubator but

>> > cxf, the one I'm most involved with, looks like its settling on
>> > versions like:
>> >
>> > 2.0-incubator-SNAPSHOT
>> >
>> > So the repository is clearly separated, and from a dependency 
element

>> > in a Maven POM you can clearly see it's an incubator version.
>> >
>> > There was discussion that incubator repository would not be 
sync'd to

>> > the central repository but I don't really see much point in this. A
>> > few folks with incubating projects have voiced concerns that they
>> > don't want to see their projects be taken out of circulation in the
>> > central repository because they are incubating. If each and every
>> > incubating project has a version for each artifact like that above
>> > then it will be fairly clear that it's from the incubator. 
Moreso then

>> > if you just had a repository definition pointing at the incubator
>> > repository.
>> >
>> > Also someone may make an repository request to place an incubator
>> > artifact in the central repository and at this point a policy 
mandated

>> > here would conflict with someone's right to redistribute artifacts
>> > created in the incubator. I don't really want to get into the 
business
>> > of policing repository requests. I think it is in the best 
interests
>> > of the  incubating projects to have the incubator repository 
sync'd to

>> > Maven's central repository. The source of artifacts for incubating
>> > projects is clear from the version so I don't think there will 
be any
>> > confusion by consumers of these artifacts and as such I don't 
really
>> > see any downside to allowing the sync to Maven's central 
repository.

>> >
>> > Thoughts?
>> >
>> > Jason van Zyl
>> > [EMAIL PROTECTED]
>>
>> +1.
>>
>> - Dan
>>
>> --
>> Dan Diephouse
>> Envoi Solutions
>> http://envoisolutions.com
>> http://netzooid.com/blog
>>
>>
>> -
>> To unsubscribe, e-mail: [EMAIL PROTECTED]
>> For additional commands, e-mail: [EMAIL PROTECTED]
>>
>>
>
>


--
Dan Diephouse
Envoi Solutions
http://envoisolutions.com
http://netzooid.com/blog


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








--
Dan Diephouse
Envoi Solutions
http://envoisolutions.com
http://netzooid.com/blog


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

Re: [policy] incubating projects and maven repositories v1.0

[Dan Diephouse]

Justin Erenkrantz wrote:

On 8/30/06, Dan Diephouse <[EMAIL PROTECTED]> wrote:

Well it can be run around right now too. I as a user of an incubating
project can request that a jar be uploaded to ibiblio. The incubator and
ibiblio policies are distinct. Unless the incubator can enforce policy
on the Ibiblio/Maven project for them to police the artifacts, they can
currently be redistributed on Ibiblio, it is just an extra pain for me
as a user.


As I understand it, the ibiblio repository is under the de facto
control of the Maven PMC.  So, if the policy was that only project
owners can upload the JARs, that would be respected.  -- justin
I don't believe thats the current policy. Some projects don't care about 
maven, so users need to take things into their own hands.


- Dan

--
Dan Diephouse
Envoi Solutions
http://envoisolutions.com
http://netzooid.com/blog


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

Re: Incubator Lightning Talks at ApacheCon US?

[Dan Diephouse]

Justin Erenkrantz wrote:


On 9/6/06, Coach Wei <[EMAIL PROTECTED]> wrote:


This is a great idea.

I'd be interested in talking about XAP after having enough beer.



Thanks everyone.  To help track this, I created:

http://wiki.apache.org/incubator/ApacheConFastTrack

I seeded that list with people who've replied so far.  Other folks
should feel free to add your podlings and topics there.

Thanks!  -- justin


Very cool. Just added CeltiXfire & myself.

How about allowing lighting talks about the incubator & incubation in 
general? That could be a rousing get together :-)


- Dan

--
Dan Diephouse
(616) 971-2053
Envoi Solutions LLC
http://netzooid.com


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

Re: [doc] call for feedback for http://incubator.apache.org/guides/proposal.html

[Dan Diephouse]

This is very good Robert. Comments inline:

robert burrell donkin wrote:


http://incubator.apache.org/guides/proposal.html is currently a
draft document. i think that it's strong enough to push towards
promoting it (and putting it in the indexes).

feedback would be very much appreciated. as always, if anyone can see
any improvements please post a patch to this list, open a JIRA or (if
you have karma) dive in.

but in particular please reply with feedback about:

1 presentation (is the way the content presented easily digested and
understandable?)


Yup.



2 commentary (is the commentary on the template generally too long,
too short or just about right?)


Seems just right to me.


3 examples (would more examples and/or long examples improve the
document or (conversely) are the examples too verbose at present?)


The examples are very helpful. Definitely not too verbose!


4 style changes (blue for notes)


The styling makes it very clear whats an example and whats not. I like it.

Cheers,
- Dan

--
Dan Diephouse
(616) 971-2053
Envoi Solutions LLC
http://netzooid.com


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

PPMCs [was Re: what are required for contributing to release management]

[Dan Diephouse]

robert burrell donkin wrote:

thinking about whether there's a need to wait to release until the
PPMC is fully formed and representation of the podling committers.

PPMCs are typically filled up relatively late in the process - towards
graduation. (whether this is a good idea, i'm not sure.) if there are
just mentors on the PPMC then i see no benefit in waiting until the
PPMC is composed of a representation cross-section of committers
before creating a release.

- robert 

Hiya,

Pardon my ignorance here, but can you elaborate or point me to docs on 
how exactly the PMCs are formed? I know that the mentors from a project 
are on it, but as for the rest of the committers I have heard 
conflicting things. I have heard that you need to be voted on and I have 
also heard that the all of initial committers ends up on the PPMC. 
Obviously it can't be both and I can't find any real docs on it 
(http://incubator.apache.org/guides/ppmc.html is silent) either.


Cheers,
- Dan

--
Dan Diephouse
Envoi Solutions
http://envoisolutions.com
http://netzooid.com/blog


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

Re: PPMCs [was Re: what are required for contributing to release management]

[Dan Diephouse]

Garrett Rooney wrote:

On 9/28/06, Dan Diephouse <[EMAIL PROTECTED]> wrote:

robert burrell donkin wrote:
> thinking about whether there's a need to wait to release until the
> PPMC is fully formed and representation of the podling committers.
>
> PPMCs are typically filled up relatively late in the process - towards
> graduation. (whether this is a good idea, i'm not sure.) if there are
> just mentors on the PPMC then i see no benefit in waiting until the
> PPMC is composed of a representation cross-section of committers
> before creating a release.
>
> - robert
Hiya,

Pardon my ignorance here, but can you elaborate or point me to docs on
how exactly the PMCs are formed? I know that the mentors from a project
are on it, but as for the rest of the committers I have heard
conflicting things. I have heard that you need to be voted on and I have
also heard that the all of initial committers ends up on the PPMC.
Obviously it can't be both and I can't find any real docs on it
(http://incubator.apache.org/guides/ppmc.html is silent) either.


Well, PMCs are formed by the board when a project moves to top level
status.

Sorry for the confusion - I meant to say PPMC, not PMC in my message.

PPMCs are formed for an incubating project, and exactly how
that works tends to differ a bit between projects.  Some mentors start
off with just the mentors on the PPMC, and then invite project members
as time goes on (or that's the impression I've gotten).  Others just
start with the whole group of committers plus the mentors on the PPMC
(that's what we did with Abdera).

Well that explains my utter confusion. Thanks for the clarification. So 
this is up to the mentors to decide then?


- Dan

--
Dan Diephouse
Envoi Solutions
http://envoisolutions.com
http://netzooid.com/blog


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

Re: Problem with commit rights on Celtixfire

[Dan Diephouse]

Hi Jim,

Can you please explain what the criteria was for removing people from 
the comitter list? Can you also detail who was removed? Can you also 
explain why this hasn't been communicated to everyone on the dev list so 
far? And why I have only heard about the final decision third hand from 
this email and an offhand mention in Bo's email? I am OK with the PMC's 
authority as thats what I signed up for at Apache, but I feel that if 
they make such an important decision as this they should at least 
communicate the above.


- Dan

Jim Jagielski wrote:


Without discussing anything regarding the initial list
and who should or should not have been on it, it needs
to be reminded that the bar to committership for Incubator
podlings is necessarily a bit lower than for real
PMCs. After all, one thing the podling must work on is
increasing the community.

I would recommend that anyone who does not have
commit privs but feel they should, to send Email to
the dev list with url pointers to patches, etc
which serve to indicate the work they've done.

As for any "internal" discussions which may or may not
have been going on, let me also state that it is
really against the ASF to make any sort of development
decisions behind closed door, but that occasionally
PMCs do need to talk privately within themselves,
and any leaking of that information is considered
a VERY bad thing to do.

On Sep 29, 2006, at 5:06 AM, Mark Little wrote:

Redhat were one of the supporters of the Celtixfire incubator  
project and discussed with the proposers to add Kevin Conner and  
myself to the list of initial commiters. As part of this, our names  
were included in the proposal. Both Kevin and I are working on  
Redhat related projects and see a lot of potential collaboration  
possibilities with Celtixfire.


At the formation of the project all members of the group were asked  
to submit signed ICLAs, which we did via fax and snail-mail.  
However, due to a problem with the fax, after 4 weeks they hadn't  
turned up and we re-submitted. This time, at the start of  September, 
the ICLAs were acknowledged and we were told our  commiter status was 
in the works. However, despite several follow  up emails, commiter 
status was not given and no answer for the  delay provided.


Yesterday we learnt that there has been some internal decision to  
limit the number of commiters and not take into account the listed  
individuals on the initial commiters list. Is this normal  procedure? 
Have we been waiting 2 months based on false  assumptions? We 
believed that, as supporters of the submission, we  had already gone 
through the process of arguing who should, or  should not, be an 
initial commiter, so to be presented with a  different result (and 
one which appears to have been conducted  behind closed doors) is 
frustrating.


Clearly this is not a case of "piling on", as joining the project  
was discussed with the project submitters prior to the formation of  
the group. Something seems wrong here; if there was no intention of  
adding us (and perhaps others we don't know about) as initial  
commiters, why did the project submitter include us? On what basis  
where these accounts not set up? Is random denial of initial  
commiters typical?


Thanks,

Mark.

--

Director of Standards, Development Manager, JBoss (a Division of  
Redhat).




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




--
Dan Diephouse
(616) 971-2053
Envoi Solutions LLC
http://netzooid.com


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

Re: PPMCs [was Re: what are required for contributing to release management]

[Dan Diephouse]

Hi Jim,

Jim Jagielski wrote:



On Sep 30, 2006, at 11:51 AM, Jason van Zyl wrote:



On 28 Sep 06, at 12:59 PM 28 Sep 06, Garrett Rooney wrote:



Well, PMCs are formed by the board when a project moves to top level
status.  PPMCs are formed for an incubating project, and exactly how
that works tends to differ a bit between projects.  Some mentors  start
off with just the mentors on the PPMC, and then invite project  members
as time goes on (or that's the impression I've gotten).  Others just
start with the whole group of committers plus the mentors on the PPMC
(that's what we did with Abdera).



I think starting with the mentors is the wisest choice as at that  
point any committers can be brought aboard if deemed fit. So that  
can support both models as all committers can be brought aboard if  
it fits, or over time if more suitable. I was also confused about  
this as I heard one thing from Noel and one thing from Jim, but the  
mentors deciding seems sensible as projects can be dealt with on a  
case by case basis. I don't believe committers should automatically  
be made (P)PMC members as to me it's a different level of  
understanding and commitment.




http://incubator.apache.org/guides/ppmc.html


I assume you're referring to this sentence:

"Initially, it is composed of the Podling's mentors and initial committers."

I have also found some threads which indicate that all committers should 
be added [1][2]. I want to know here - who is wrong? The documentation? 
Or the previous incubated projects who didn't add all the initial 
committers? There is also the following sentence which adds some doubt 
that the above is the official policy:


"The PPMC is directly responsible for the oversight of the podling and 
it also decides who to add as a PPMC member."


While this could be referrering to post PPMC formation, it isn't clear.  
I will happily make a patch for the documentation to make things more 
clear if there is consensus.



I am pretty philosophically against making every committer PPMC members. 
Apache is meritocracy based and IMO it makes much more sense to start 
with the mentors on the PPMC and have committers voted on based on their 
leadership. There may be many people on the incubation proposal or who 
have committed code to a project in the past, but an additional level of 
leadership is needed [3]. Not everyone may have the necessary leadership 
skills, and to presuppose they do because they have contributed good 
code, is IMO, a mistake.



Cheerz,
- Dan

1. 
http://mail-archives.apache.org/mod_mbox/incubator-general/200312.mbox/[EMAIL PROTECTED]
2. 
http://mail-archives.apache.org/mod_mbox/incubator-general/200603.mbox/[EMAIL PROTECTED]
3. See Project Management Committee section here 
http://www.apache.org/foundation/how-it-works.html#structure


--
Dan Diephouse
(616) 971-2053
Envoi Solutions LLC
http://netzooid.com


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

Re: Policy on Initial Committership

[Dan Diephouse]

Justin Erenkrantz wrote:


On 10/1/06, Noel J. Bergman <[EMAIL PROTECTED]> wrote:



I disagree.  You're conflating process with application of process, and
then
stating as assured a case when your fellow PMC Members would act in a
manner
you find offensive.

Why would the PMC not elect "the people who contributed it further
access"?




We've seen an example of this with Celtixfire.  So far, we're waiting 
for an

explanation (as those discussions did not occur in a place where the
Incubator PMC could provide any oversight), but the aggrieved parties
believe they have been barred access to a project they felt they 
contributed

to.

So, I don't believe this situation isn't a hypothetical at all.  -- 
justin


It seems to me that this is the reverse actually - committers were 
approved, and then the PMC revoked their rights. However, this is just 
inference on my part so far.


- Dan

--
Dan Diephouse
(616) 971-2053
Envoi Solutions LLC
http://netzooid.com


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

Re: PPMCs [was Re: what are required for contributing to release management]

[Dan Diephouse]

Noel J. Bergman wrote:


Justin Erenkrantz wrote:
 


Noel J. Bergman <[EMAIL PROTECTED]> wrote:
   


I am pretty philosophically against making every committer PPMC
 


members.
   


I don't agree at all.  If they contribute code, they merit a say in
   


the
 


direction of the project.
   


Are you reading Dan's statement as independent or dependent upon time?
 


I
 


read it as an objection to mandated concurrency.  Over time, your view
should be the dominant one, as each Committer becomes a (P)PMC member.
 


as for the one line that you retained: I view Dan's perspective as
being independent of time - that is, committers should never equal
the PMC - I view that as extremely unhealthy.
   



If I had read it as you do, I would agree with you.  I read it as suggestive
of a process over time, and that at any snapshot in time, the body of
Committers might not be entirely present in the PPMC.
 

I did in fact mean it as dependent on time. And specifically I meant at 
the beginning of incubation. I don't think every committer should be on 
the PPMC from the outset. Every committer may be on the PPMC at 
graduation, and this is encouraged, but only after they are explicitly 
voted on by the existing PPMC members. Now the PPMC may just chose to 
vote on specific individuals or everyone at once, its up to them. I 
would however encourage only voting people in after they an appropriate 
level of committment and involvement with the project.


- Dan

--
Dan Diephouse
(616) 971-2053
Envoi Solutions LLC
http://netzooid.com


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

Re: PPMCs [was Re: what are required for contributing to release management]

[Dan Diephouse]

Dan Diephouse wrote:


Noel J. Bergman wrote:


Justin Erenkrantz wrote:
 


Noel J. Bergman <[EMAIL PROTECTED]> wrote:
  


I am pretty philosophically against making every committer PPMC



members.
  



I don't agree at all.  If they contribute code, they merit a say in
  



the
 


direction of the project.
  


Are you reading Dan's statement as independent or dependent upon time?




I
 


read it as an objection to mandated concurrency.  Over time, your view
should be the dominant one, as each Committer becomes a (P)PMC member.



as for the one line that you retained: I view Dan's perspective as
being independent of time - that is, committers should never equal
the PMC - I view that as extremely unhealthy.
  



If I had read it as you do, I would agree with you.  I read it as 
suggestive

of a process over time, and that at any snapshot in time, the body of
Committers might not be entirely present in the PPMC.
 

I did in fact mean it as dependent on time. And specifically I meant 
at the beginning of incubation. I don't think every committer should 
be on the PPMC from the outset. Every committer may be on the PPMC at 
graduation, and this is encouraged, but only after they are explicitly 
voted on by the existing PPMC members. Now the PPMC may just chose to 
vote on specific individuals or everyone at once, its up to them. I 
would however encourage only voting people in after they an 
appropriate level of committment and involvement with the project.


One reason I feel this way is that I think protect's Apache's interests. 
Lets say that hypothetically, more people are put on a proposal than 
should be. If the PPMC members are elected after showing their 
committment to the long term health of the project, as opposed to all 
committers being added at the outset of the project, I believe this 
gives a better chance for correction. If I end up on the CXF (P)PMC I 
have every intention of starting a vote which removes any committers who 
have not contributed anything during incubation or significantly in the 
past.  I hope I don't have to do that, but it doesn't seem fair that 
they would graduate as part of the project and have as much say as those 
who have shown their committment. If someone wants to get involved 
later, they can always contribute and get voted back in. I think this 
gives people a slightly lower barrier to get involved, which seems 
befitting to incubation and starting of a project, but also provides 
corrective measures in case there are problems.


Cheers,
- Dan

--
Dan Diephouse
(616) 971-2053
Envoi Solutions LLC
http://netzooid.com


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

Re: Policy on Initial Committership

[Dan Diephouse]

Justin Erenkrantz wrote:


On 10/8/06, Jim Jagielski <[EMAIL PROTECTED]> wrote:



However, in that case I would really like to see it that
if committers from other ASF projects read the proposal
and have a sincere interest in helping, that they be
included in the initial list, since I think it helps
bootstrap the community process right off the bat.




Noel and I were chatting about this last night, and my position is 
that I'm
okay with 'piling on' by ASF folks *if* the podling community is happy 
with
that.  If the podling folks do not want them on the initial list and 
desire
that they earn their commit bits through actual participation, I'm 
okay with

that too.

Noel's said that being the arbitrator of who is on the list should be the
role of the Champion and I think that's probably as good as we're 
going to
get.  But, by the time the Incubator PMC votes on a proposal, that 
list must

be set (i.e. no deletions after the vote concludes).  -- justin


+1 - I like your explanation & reasoning.

- Dan

--
Dan Diephouse
(616) 971-2053
Envoi Solutions LLC
http://netzooid.com


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

Re: [VOTE] Release ServiceMix 3.0.1

[Dan Diephouse]

robert burrell donkin wrote:


On 11/20/06, Dan Diephouse <[EMAIL PROTECTED]> wrote:


Since these are generated files, must they have license headers?



no

however, i think that running preprocessors against the source in the
repository that strips license headers *is* an issue for me. IMO
source distributions should be simple exports of the repository.

I'm not sure its a preprocessor per se, I'd call it a transformer... but 
I guess thats semantics. :-) For those who aren't aware, what happens in 
this process is the SNAPSHOT pom is fed in, the version is changed, the 
necessary module dependency versions are changed, and the SVN location 
is updated.



anyone from maven around to explain the reasons behind this behaviour?


I chatted with Brett about it a few days ago, and he said the problem is 
a bug in JDOM. Sometimes it preserves the bits before the root element 
and sometimes it doesn't. It has to do with whitespace AFAIK.


- Dan

--
Dan Diephouse
(616) 971-2053
Envoi Solutions LLC
http://netzooid.com


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

Release notes... [was Re: [VOTE] Release ServiceMix 3.0.1]

[Dan Diephouse]

On 11/20/06, robert burrell donkin <[EMAIL PROTECTED]> wrote:



i strongly recommend adding RELEASE_NOTES. these are an important form
of guerrilla advertising. yes, tools like maven can generate lots of
documentation about the release but this doesn't replace a
RELEASE_NOTES explaining the project, inviting people to get involved
and inducating where other information can be found.



In XFire we made our release notes our download page. This allowed us to
inform the users, welcome them into the project, and provide up to date
errata whenever they went to download. In the days of maven, a lot of people
don't even download a distribution any more: in the month of October roughly
60% of the XFire users downloaded the binary distribution and 40% downloaded
via Maven. If you factor in the amount of people that actually read the
release notes, I think we are now in a situation where we have much less
than half reading them (maybe less than 10%). Making the release notes the
download page makes sure 100% of the people see it. Sticking it in the
distribution also has other issues, namely people don't maintain the release
notes and they can not be updated with errata after the release.

So I think that having a release notes in the distribution is overrated and
using the website can be a better approach.

- Dan

*

--
Dan Diephouse
Envoi Solutions
http://envoisolutions.com | http://netzooid.com/blog

Re: [VOTE] Release ServiceMix 3.0.1

[Dan Diephouse]

Since these are generated files, must they have license headers? We had 
a recent discussion on this on the legal-discuss list. To quote Roy: [1]



We don't require headers on generated files because they are a pain
in the butt to generate.  Headers are not required to preserve  
copyright,

so there is no "legal" reason to provide them at all.  The reason we do
provide them is to inform the users that we have given them permission
to do Apache Licensed things with the code that copyright would  
(normally)

prevent them from doing.  In other words, the header is just us being
nice to our users (and hopefully reducing future FAQs).


Regards,
- Dan

1. 
http://mail-archives.apache.org/mod_mbox/www-legal-discuss/200611.mbox/[EMAIL PROTECTED]

Guillaume Nodet wrote:


They were in svn before the release has been performed by
the maven plugin.They still are present in the branch that
was used to release this version.  Unfortunately, it seems
to be a maven bug :(

Cheers,
Guillaume Nodet


robert burrell donkin wrote:
 


On 11/17/06, Guillaume Nodet <[EMAIL PROTECTED]> wrote:
   


The ServiceMix community voted on and has approved to release ServiceMix
3.0.1-incubating.
We would now like to request the permission of the Incubator PMC to
publish the release.
 


running RAT, there seem to be a *lot* of poms without license header.
any reason why they are missing?

- robert

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

 




--
Dan Diephouse
(616) 971-2053
Envoi Solutions LLC
http://netzooid.com


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

[VOTE] Apache CXF 2.0-M1 Release

[Dan Diephouse]

The Apache CXF team has cut a candidate release and published builds here:

Binaries and Source Distributions:
http://people.apache.org/~blin/incubator-cxf-2.0-M1/<http://people.apache.org/%7Eblin/incubator-cxf-2.0-M1/>
Maven Repository:
http://people.apache.org/~blin/incubator-cxf-2.0-M1/repository/org/apache/cxf
Release notes: 
http://cwiki.apache.org/confluence/display/CXF/Apache+CXF+2.0-M1+Incubating+Release+Notes


The release notes may continue to involve during the vote if we find further
errata. The final release notes will be part of our static HTML site at
http://cwiki.apache.org/CXF/ once we finalize the release. Also, there are
release notes in the docs/ directory.

We ask that you please vote to approve this release binary:

[ ] +1 Release the binary as Apache CXF 2.0-M1
[ ] -1 Veto the release (please provide specific comments)

Thanks!

- The CXF team

--
Dan Diephouse
Envoi Solutions
http://envoisolutions.com | http://netzooid.com/blog

Re: Notification of a(nother) release vote for Tuscany

[Dan Diephouse]

Hi Jeremy,
I'm not 100% sure of your goal of this message, but it seems to imply that
you're planning on holding another vote on the incubator list once its done.
Not sure if you know this or not - but I was informed at ApacheCon, that you
don't really need to hold multiple votes (i.e. one for the project and one
on [EMAIL PROTECTED]). You can just CC both lists at once and have one vote.
This reduces the time necessary to get the vote done and resolve issues -
which is in everyone's best interests I think. Hopefully I haven't
misunderstood something here, but if so, ignore this... :-)

Good luck on the release!
Regards,
- Dan

On 11/21/06, Jeremy Boynes <[EMAIL PROTECTED]> wrote:


I have recently started a vote on tuscany-dev to approve the content
of our incubator-M2 release for Java SCA. This note is to inform the
IPMC of this vote and to invite any interested members to review the
content.

http://mail-archives.apache.org/mod_mbox/ws-tuscany-dev/200611.mbox/%
[EMAIL PROTECTED]

Thanks
--
Jeremy

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





--
Dan Diephouse
Envoi Solutions
http://envoisolutions.com | http://netzooid.com/blog

Re: Notification of a(nother) release vote for Tuscany

[Dan Diephouse]

Ah, it is all making sense to me now. Thanks for the clarification as I
learn the incubator ways! :-)

- Dan

On 11/22/06, Luciano Resende <[EMAIL PROTECTED]> wrote:


Yes Jeremy, this is my understanding as well...
If we get the three IPMC +1 votes on Tuscany devlist, we could do
something
simmilar to this thread :
http://www.mail-archive.com/general%40incubator.apache.org/msg11681.html

--
Luciano Resende
http://people.apache.org/~lresende

On 11/21/06, Jeremy Boynes <[EMAIL PROTECTED]> wrote:
>
> Rather than cross post which might get confusing if people replied to
> different lists, the intention here was to notify the IPMC that we
> were having a vote in Tuscany and to ask for their input (and
> hopefully votes) there. If we got three IPMC +1's on the project list
> I would think that was binding.
>
> --
> Jeremy
>
> On Nov 21, 2006, at 9:55 PM, Dan Diephouse wrote:
>
> > Hi Jeremy,
> > I'm not 100% sure of your goal of this message, but it seems to
> > imply that
> > you're planning on holding another vote on the incubator list once
> > its done.
> > Not sure if you know this or not - but I was informed at ApacheCon,
> > that you
> > don't really need to hold multiple votes (i.e. one for the project
> > and one
> > on [EMAIL PROTECTED]). You can just CC both lists at once and have
> > one vote.
> > This reduces the time necessary to get the vote done and resolve
> > issues -
> > which is in everyone's best interests I think. Hopefully I haven't
> > misunderstood something here, but if so, ignore this... :-)
> >
> > Good luck on the release!
> > Regards,
> > - Dan
> >
> > On 11/21/06, Jeremy Boynes <[EMAIL PROTECTED]> wrote:
> >>
> >> I have recently started a vote on tuscany-dev to approve the content
> >> of our incubator-M2 release for Java SCA. This note is to inform the
> >> IPMC of this vote and to invite any interested members to review the
> >> content.
> >>
> >> http://mail-archives.apache.org/mod_mbox/ws-tuscany-dev/200611.mbox/%
> >> [EMAIL PROTECTED]
> >>
> >> Thanks
> >> --
> >> Jeremy
> >>
> >> -
> >> To unsubscribe, e-mail: [EMAIL PROTECTED]
> >> For additional commands, e-mail: [EMAIL PROTECTED]
> >>
> >>
> >
> >
> > --
> > Dan Diephouse
> > Envoi Solutions
> > http://envoisolutions.com | http://netzooid.com/blog
>
>
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
>





--
Dan Diephouse
Envoi Solutions
http://envoisolutions.com | http://netzooid.com/blog

Re: [VOTE] Apache CXF 2.0-M1 Release

[Dan Diephouse]

Arggh... *mutters very bad things about standards organizations*.

Looking into this deeper, and the only file that I can find that is
associated with the WS-I organization is this one:

http://fisheye3.cenqua.com/browse/celtixfire/trunk/distribution/src/main/release/samples/mtom/wsdl/wsi-swa.xsd?r=450119


To me the amount of creativity in this file is dubious, but it does clearly
state that "Use of this WS-I Material i
governed by the WS-I Test License and other licenses."

We'll go through and recheck things to make sure they're valid. We caught
some stuff the first time through, but not all of it it seems.

Thanks Robert,
- Dan

On 11/23/06, robert burrell donkin <[EMAIL PROTECTED]> wrote:


On 11/22/06, Dan Diephouse <[EMAIL PROTECTED]> wrote:



> We ask that you please vote to approve this release binary:
>
> [ ] +1 Release the binary as Apache CXF 2.0-M1
> [ ] -1 Veto the release (please provide specific comments)

-1

*** IMPORTANT ***

my reading of 
http://svn.apache.org/repos/asf/incubator/cxf/tags/2.0-incubator-M1/distribution/src/main/release/licenses/wsi.html

is that it *EXPLICITLY PREVENTS DISTRIBUTION*. if this is the case we
need to remove all material in subversion under that license *RIGHT
NOW*

we've usually been able to work around mistakes like the past but the
right thing to do is to stop distributing now and then work out what
to do later.

- robert

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





--
Dan Diephouse
Envoi Solutions
http://envoisolutions.com | http://netzooid.com/blog

Re: [VOTE] Apache CXF 2.0-M1 Release

[Dan Diephouse]

I've taken immediate action to remove these files from SVN. I'm curious to
know if any other Apache projects depend on this wsi-swa.xsd file as I don't
think its possible to use the JAXB 2.0 soap with attachments support without
referencing this file. I know the JAXWS-RI itself redistributes it, which
may have thrown us off.

Are there any WS-I experts around that can shed light on this? It is hard to
conform to the basic profile if you can't use their schemas in
projects/products - which kind of defeats the point.

I will start a thread sometime soon on legal-discuss on how to best deal
with this.

- Dan

On 11/23/06, Dan Diephouse <[EMAIL PROTECTED]> wrote:


Arggh... *mutters very bad things about standards organizations*.

Looking into this deeper, and the only file that I can find that is
associated with the WS-I organization is this one:

http://fisheye3.cenqua.com/browse/celtixfire/trunk/distribution/src/main/release/samples/mtom/wsdl/wsi-swa.xsd?r=450119


To me the amount of creativity in this file is dubious, but it does
clearly state that "Use of this WS-I Material i
governed by the WS-I Test License and other licenses."

We'll go through and recheck things to make sure they're valid. We caught
some stuff the first time through, but not all of it it seems.

Thanks Robert,
- Dan

On 11/23/06, robert burrell donkin < [EMAIL PROTECTED]> wrote:
>
> On 11/22/06, Dan Diephouse < [EMAIL PROTECTED]> wrote:
>
> 
>
> > We ask that you please vote to approve this release binary:
> >
> > [ ] +1 Release the binary as Apache CXF 2.0-M1
> > [ ] -1 Veto the release (please provide specific comments)
>
> -1
>
> *** IMPORTANT ***
>
> my reading of 
http://svn.apache.org/repos/asf/incubator/cxf/tags/2.0-incubator-M1/distribution/src/main/release/licenses/wsi.html
>
> is that it *EXPLICITLY PREVENTS DISTRIBUTION*. if this is the case we
> need to remove all material in subversion under that license *RIGHT
> NOW*
>
> we've usually been able to work around mistakes like the past but the
> right thing to do is to stop distributing now and then work out what
> to do later.
>
> - robert
>
> -----
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
>


--
Dan Diephouse
Envoi Solutions
http://envoisolutions.com | http://netzooid.com/blog





--
Dan Diephouse
Envoi Solutions
http://envoisolutions.com | http://netzooid.com/blog

Re: [VOTE] Apache CXF 2.0-M1 Release

[Dan Diephouse]

Hi Again,
I did it a bit of poking around and it seems that no one else is using the
wsi-swa.xsd which is good. There are however two files in Axis1 C though
that are under the WS-I test license:

http://svn.apache.org/viewvc/webservices/axis/trunk/c/tests/auto_build/wsi/analyzerConfig.xml?view=log
http://svn.apache.org/viewvc/webservices/axis/trunk/c/tests/auto_build/wsi/monitorConfig.xml?view=log

I'm not sure if these files are being distributed or not. Maybe the Axis
team can comment?

- Dan

On 11/23/06, Dan Diephouse <[EMAIL PROTECTED]> wrote:


I've taken immediate action to remove these files from SVN. I'm curious to
know if any other Apache projects depend on this wsi-swa.xsd file as I
don't think its possible to use the JAXB 2.0 soap with attachments support
without referencing this file. I know the JAXWS-RI itself redistributes it,
which may have thrown us off.

Are there any WS-I experts around that can shed light on this? It is hard
to conform to the basic profile if you can't use their schemas in
projects/products - which kind of defeats the point.

I will start a thread sometime soon on legal-discuss on how to best deal
with this.

- Dan

On 11/23/06, Dan Diephouse <[EMAIL PROTECTED]> wrote:
>
> Arggh... *mutters very bad things about standards organizations*.
>
> Looking into this deeper, and the only file that I can find that is
> associated with the WS-I organization is this one:
>
> 
http://fisheye3.cenqua.com/browse/celtixfire/trunk/distribution/src/main/release/samples/mtom/wsdl/wsi-swa.xsd?r=450119
>
>
> To me the amount of creativity in this file is dubious, but it does
> clearly state that "Use of this WS-I Material i
> governed by the WS-I Test License and other licenses."
>
> We'll go through and recheck things to make sure they're valid. We
> caught some stuff the first time through, but not all of it it seems.
>
> Thanks Robert,
> - Dan
>
> On 11/23/06, robert burrell donkin < [EMAIL PROTECTED]>
> wrote:
> >
> > On 11/22/06, Dan Diephouse < [EMAIL PROTECTED]> wrote:
> >
> > 
> >
> > > We ask that you please vote to approve this release binary:
> > >
> > > [ ] +1 Release the binary as Apache CXF 2.0-M1
> > > [ ] -1 Veto the release (please provide specific comments)
> >
> > -1
> >
> > *** IMPORTANT ***
> >
> > my reading of 
http://svn.apache.org/repos/asf/incubator/cxf/tags/2.0-incubator-M1/distribution/src/main/release/licenses/wsi.html
> >
> > is that it *EXPLICITLY PREVENTS DISTRIBUTION*. if this is the case we
> > need to remove all material in subversion under that license *RIGHT
> > NOW*
> >
> > we've usually been able to work around mistakes like the past but the
> > right thing to do is to stop distributing now and then work out what
> > to do later.
> >
> > - robert
> >
> > -----
> > To unsubscribe, e-mail: [EMAIL PROTECTED]
> > For additional commands, e-mail: [EMAIL PROTECTED]
> >
> >
>
>
> --
> Dan Diephouse
> Envoi Solutions
> http://envoisolutions.com | http://netzooid.com/blog
>



--
Dan Diephouse
Envoi Solutions
http://envoisolutions.com | http://netzooid.com/blog





--
Dan Diephouse
Envoi Solutions
http://envoisolutions.com | http://netzooid.com/blog

Re: [VOTE] Apache CXF 2.0-M1 Release

[Dan Diephouse]

Well, we'd like to have it as part of our build as it seems necessary to
test JAXB 2 + soap with attachments*. We've included it as a URL instead of
a local file now, but that breaks offline builds - which we've worked hard
to avoid so far.

Regards,

- Dan

* I'm going to confirm that though. It'll be interesting to see what the TCK
includes :-)

On 11/24/06, Davanum Srinivas <[EMAIL PROTECTED]> wrote:


Robert,

Users can download that xsd and use it themselves. We don't have to
ship it in the box:)

-- dims

On 11/24/06, robert burrell donkin <[EMAIL PROTECTED]> wrote:
> On 11/24/06, Dan Diephouse <[EMAIL PROTECTED]> wrote:
> > I've taken immediate action to remove these files from SVN.
>
> thanks :-)
>
> > I'm curious to
> > know if any other Apache projects depend on this wsi-swa.xsd file as I
don't
> > think its possible to use the JAXB 2.0 soap with attachments support
without
> > referencing this file. I know the JAXWS-RI itself redistributes it,
which
> > may have thrown us off.
>
> yeh - that's understandable
>
> far too often, web standards are a real PITA legally speaking
>
> > Are there any WS-I experts around that can shed light on this?
>
> or (alternatively) ws standards process experts
>
> dims? sanjiva?
>
> > It is hard to
> > conform to the basic profile if you can't use their schemas in
> > projects/products - which kind of defeats the point.
>
> +1
>
> this point needs to make frequently and strongly to standards
> organisations. it may be worth trying to open a dialog (again?)
>
> may need to do a clean room implementation (if that's allowed by the
> specification)
>
> > I will start a thread sometime soon on legal-discuss on how to best
deal
> > with this.
>
> +1
>
> - robert
>
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
>


--
Davanum Srinivas : http://www.wso2.net (Oxygen for Web Service Developers)

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





--
Dan Diephouse
Envoi Solutions
http://envoisolutions.com | http://netzooid.com/blog

[VOTE] Apache CXF 2.0-M1 Incubating Release

[Dan Diephouse]

The Apache CXF team has cut another candidate release which fixes the
previous licensing issues. Builds have been published here:

Binaries and Source Distributions:
http://people.apache.org/~blin/incubator-cxf-2.0-M1/
Maven Repository:
http://people.apache.org/~blin/incubator-cxf-2.0-M1/repository/org/apache/cxf
Release notes: 
http://cwiki.apache.org/confluence/display/CXF/Apache+CXF+2.0-M1+Incubating+Release+Notes


We ask that you please vote to approve this release:

[ ] +1 Release the binary as Apache CXF 2.0-M1
[ ] -1 Veto the release (please provide specific comments)

Thanks!

- The CXF team

Re: [VOTE] Apache CXF 2.0-M1 Incubating Release

[Dan Diephouse]

Is this a show stopper and a -1? Can we fix this as part of our next
milestone?

On 11/30/06, Jim Jagielski <[EMAIL PROTECTED]> wrote:



On Nov 29, 2006, at 11:50 AM, Dan Diephouse wrote:

> The Apache CXF team has cut another candidate release which fixes the
> previous licensing issues. Builds have been published here:
>
> Binaries and Source Distributions:
> http://people.apache.org/~blin/incubator-cxf-2.0-M1/ people.apache.org/%7Eblin/incubator-cxf-2.0-M1/>
> Maven Repository:
> http://people.apache.org/~blin/incubator-cxf-2.0-M1/repository/org/
> apache/cxf<http://people.apache.org/%7Eblin/incubator-cxf-2.0-M1/
> repository/org/apache/cxf>
> Release notes: http://cwiki.apache.org/confluence/display/CXF/Apache
> +CXF+2.0-M1+Incubating+Release+Notes
>
>

The release_notes.txt in the docs folder
of the release build refer to Apache CXF and not Apache
Incubator CXF. This should be fixed :)

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





--
Dan Diephouse
Envoi Solutions
http://envoisolutions.com | http://netzooid.com/blog

[VOTE] Apache Incubator CXF 2.0-M1 Release (RC 3)

[Dan Diephouse]

The Apache CXF team has cut another candidate release which fixes the
previous branding issues. As no one else seems to have found any other
issues, we've cut a new build and published it here:

Binaries and Source Distributions:
http://people.apache.org/~blin/incubator-cxf-2.0-M1-v2/
Maven Repository:
http://people.apache.org/~blin/incubator-cxf-2.0-M1-v2/repository/org/apache/cxf/
Release notes: 
http://cwiki.apache.org/confluence/display/CXF/Apache+CXF+2.0-M1+Incubating+Release+Notes


(NOTE: we just started labelling the different releases as v1/v2/etc. While
this is our 3rd attempt, the above says v2 as we just started counting in
the directory name...)

We ask that you please vote to approve this release:

[ ] +1 Release the binary as Apache Incubator CXF 2.0-M1
[ ] -1 Veto the release (please provide specific comments)

Thanks for everyone who has helped so far with the previous release
candidates and this one!

- The CXF team

Re: Add UIMA to reporting schedule [was: December 2006 Incubator Reports]

[Dan Diephouse]

Just add yourself to the monthly schedule on the wiki and then you'll be
scheduled (pick any group you like) :-)

http://wiki.apache.org/incubator/ReportingSchedule

Also, new incubator projects must report every month for the first three
months. After that then the reporting schedule kicks in for you.

- Dan

On 12/7/06, Thilo Goetz <[EMAIL PROTECTED]> wrote:


Noel J. Bergman wrote:
> Henri's
> https://svn.apache.org/repos/private/committers/board/incubator-info.txt
> shows the list of projects needing to report, plus any that have been
newly
> accepted.

UIMA reported in November for the first time.  We are currently listed
as "Needs to be added to the monthly schedule".  Who can do that, is
there anything we can do to make this happen?

We're happy to report each month until further notice, but don't want to
flood the board with unwanted reports either ;-)

I believe Wicket is in the same boat, they have also reported before and
have not been added to the 3 month reporting schedule.

--Thilo

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





--
Dan Diephouse
Envoi Solutions
http://envoisolutions.com | http://netzooid.com/blog

Re: [VOTE] Apache Incubator CXF 2.0-M1 Release (RC 3)

[Dan Diephouse]

Hi Robert,

- questions -



http://people.apache.org/~blin/incubator-cxf-2.0-M1-v2/repository/org/apache/cxf/cxf-api/2.0-incubator-M1/cxf-api-2.0-incubator-M1-javadoc.jar
is missing license, disclaimer and notice files. it cannot therefore
be distributed. planning to distribute this jar from a repository? (if
yes then IMHO the release needs recutting, if no it's fine)



I could be wrong here, but after a quick investigation, it appears we hit a
limitation/bug of Maven's javadoc plugin. All the others turned out fine,
but for API we tweaked some of the javadoc parameters it looks like, so
maybe this affected things.

As opposed to cutting a new release completely, can we choose one/any of the
follow options and get your +1?
1. Not distribute the javadoc jar
2. Recut just that jar after figuring out how to make Maven comply to our
wishes
3. Update the JAR by hand to include the appropate licenses

- notes, comments and suggestions (not requirements) -


MANIFEST's are a little empty. sun recommends quite a list in one
place or another (Extension-Name, Specification-Title,
Specification-Vendor, Specification-Version, Implementation-Vendor-Id,
Implementation-Title, Implementation-Vendor, Implementation-Version).
AIUI maven will generate these if asked.



http://issues.apache.org/jira/browse/CXF-298

once cxf graduates, remember that all artifacts need to be prefixed with

apache



As in apache-cxf-api-2.0.jar?

the source contains some xml specifications that are licensed under

non-open source licenses (copy and distribution only). it is proposed
(http://www.apache.org/legal/3party.html) that this is against policy.
there is still time to join in the discussions (on legal-discuss)
before this policy is adopted.



OK, we've already brought up these licenses on the legal list, but haven't
heard anything back yet.

- Dan


--
Dan Diephouse
Envoi Solutions
http://envoisolutions.com | http://netzooid.com/blog

Deploying Incubator Maven Artifacts [was Re: [VOTE] Apache Incubator CXF 2.0-M1 Release (RC 3)]

[Dan Diephouse]

On 12/7/06, Daniel Kulp <[EMAIL PROTECTED]> wrote:


I would say for now we just remove that jar if it's needed.  However, how
did
the servicemix and other projects votes pass if it's a requirement?  Is
this
another "new requirement in the middle of a vote" thing?



*wonders the same thing*

Additionally, I just realized there are some projects too that have been
publishing Maven builds that haven't been approved. Most recently Abdera did
this [1][2]. They voted for the release of their binaries, but not their
maven artifacts which they created/deployed post vote as I understand it
(sorry to cause trouble Abdera folks, I was the one pushing for those builds
too!).

- Dan

1.
http://mail-archives.apache.org/mod_mbox/incubator-general/200612.mbox/[EMAIL 
PROTECTED]
2.
http://mail-archives.apache.org/mod_mbox/incubator-abdera-dev/200612.mbox/[EMAIL
 PROTECTED]

--
Dan Diephouse
Envoi Solutions
http://envoisolutions.com | http://netzooid.com/blog

Re: [VOTE] Apache Incubator CXF 2.0-M1 Release (RC 3)

[Dan Diephouse]

On 12/7/06, robert burrell donkin <[EMAIL PROTECTED]> wrote:


On 12/7/06, Dan Diephouse <[EMAIL PROTECTED]> wrote:
> As opposed to cutting a new release completely, can we choose one/any of
the
> follow options and get your +1?
> 1. Not distribute the javadoc jar
> 2. Recut just that jar after figuring out how to make Maven comply to
our
> wishes
> 3. Update the JAR by hand to include the appropate licenses

any of these sound fine



Alright, then I think we should just not distribute the javadoc jars for
now. Given that its in Bo's directory, I can't delete them and he's
undoubtedly asleep for a few more hours :-).

If we decide we need to distribute them we can create a separate VOTE for
the javadoc jars. Otherwise we'll just fix them our next release when
hopefully the maven plugin will be working...

With that caveat can we get an official +1? ;-)

- Dan

--
Dan Diephouse
Envoi Solutions
http://envoisolutions.com | http://netzooid.com/blog

Re: Deploying Incubator Maven Artifacts [was Re: [VOTE] Apache Incubator CXF 2.0-M1 Release (RC 3)]

[Dan Diephouse]

I must be missing something. If they aren't voted on, how do you know
if they're valid and meet release requirements?

On 12/7/06, Roy T. Fielding <[EMAIL PROTECTED]> wrote:

On Dec 7, 2006, at 3:00 PM, Dan Diephouse wrote:

> On 12/7/06, Daniel Kulp <[EMAIL PROTECTED]> wrote:
>
>> I would say for now we just remove that jar if it's needed.
>> However, how
>> did
>> the servicemix and other projects votes pass if it's a
>> requirement?  Is
>> this
>> another "new requirement in the middle of a vote" thing?
>>
>>
> *wonders the same thing*
>
> Additionally, I just realized there are some projects too that have
> been
> publishing Maven builds that haven't been approved. Most recently
> Abdera did
> this [1][2]. They voted for the release of their binaries, but not
> their
> maven artifacts which they created/deployed post vote as I
> understand it
> (sorry to cause trouble Abdera folks, I was the one pushing for
> those builds
> too!).

FYI, traditionally, all release votes are for the source code package
and
only that package.  Once the source code version is set in stone,
binaries
and assorted other release artifacts can be generated by individual
committers without a vote if the group trusts them to do so and they
have a signed key.  Some groups might require a vote on binaries as
well,
but the ASF only requires a vote on the source.

Roy

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





--
Dan Diephouse
Envoi Solutions
http://envoisolutions.com | http://netzooid.com/blog

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

Re: [VOTE] Apache Incubator CXF 2.0-M1 Release (RC 4)

[Dan Diephouse]

+1

On 12/13/06, Daniel Kulp <[EMAIL PROTECTED]> wrote:



Based on conversations with various people, the Apache CXF Team decided to
change the release notes in RC3 to add a disclaimer about the level of
support for the JAX-WS API's since no TCK tests have been run.   The ONLY
change made to the branch was the release_notes.txt file.   However, that
required rebuilding new distributions, thus a new vote is required.

Binaries and Source Distributions:
http://people.apache.org/~blin/incubator-cxf-2.0-M1-v4/
Maven Repository:

http://people.apache.org/~blin/incubator-cxf-2.0-M1-v4/repository/org/apache/cxf/
Wiki Copy of Release notes:

http://cwiki.apache.org/confluence/display/CXF/Apache+CXF+2.0-M1+Incubating+Release+Notes


We ask that you please vote to approve this release:
[ ] +1 Release the binary as Apache Incubator CXF 2.0-M1
[ ] -1 Issue detected (please provide details)


Thanks for everyone who has helped so far with the previous release
candidates and this one!

- The CXF team


--
J. Daniel Kulp
Principal Engineer
IONA
P: 781-902-8727C: 508-380-7194
[EMAIL PROTECTED]

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





--
Dan Diephouse
Envoi Solutions
http://envoisolutions.com | http://netzooid.com/blog

Re: [VOTE] Apache Incubator CXF 2.0-M1 Release (RC 4)

[Dan Diephouse]

Thanks Paul. IIRC I believe Roy said if you changed the source distribution
(which this does do), you need a new vote. Regards,
- Dan

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


Dan

I'm not sure you need to have a complete new vote... anyway thanks
very much for fixing this.

You now have my +1.

Paul

On 12/13/06, Liu, Jervis <[EMAIL PROTECTED]> wrote:
> +1 again.
>
> Jervis
>
> > -Original Message-
> > From: Daniel Kulp [mailto:[EMAIL PROTECTED]
> > Sent: Wednesday, December 13, 2006 12:08 PM
> > To: cxf-dev@incubator.apache.org
> > Cc: general@incubator.apache.org
> > Subject: [VOTE] Apache Incubator CXF 2.0-M1 Release (RC 4)
> >
> >
> >
> > Based on conversations with various people, the Apache CXF
> > Team decided to
> > change the release notes in RC3 to add a disclaimer about the
> > level of
> > support for the JAX-WS API's since no TCK tests have been
> > run.   The ONLY
> > change made to the branch was the release_notes.txt file.
> > However, that
> > required rebuilding new distributions, thus a new vote is required.
> >
> > Binaries and Source Distributions:
> > http://people.apache.org/~blin/incubator-cxf-2.0-M1-v4/
> > Maven Repository:
> > http://people.apache.org/~blin/incubator-cxf-2.0-M1-v4/reposit
> ory/org/apache/cxf/
> Wiki Copy of Release notes:
>
http://cwiki.apache.org/confluence/display/CXF/Apache+CXF+2.0-M1+Incubating+Release+Notes
>
>
> We ask that you please vote to approve this release:
> [ ] +1 Release the binary as Apache Incubator CXF 2.0-M1
> [ ] -1 Issue detected (please provide details)
>
>
> Thanks for everyone who has helped so far with the previous release
> candidates and this one!
>
> - The CXF team
>
>
> --
> J. Daniel Kulp
> Principal Engineer
> IONA
> P: 781-902-8727C: 508-380-7194
> [EMAIL PROTECTED]
>
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
>


--
Paul Fremantle
VP/Technology, WSO2 and OASIS WS-RX TC Co-chair

http://bloglines.com/blog/paulfremantle
[EMAIL PROTECTED]

"Oxygenating the Web Service Platform", www.wso2.com

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





--
Dan Diephouse
Envoi Solutions
http://envoisolutions.com | http://netzooid.com/blog

[announce] Apache Incubator CXF 2.0-M1 Release

[Dan Diephouse]

The Apache Incubator CXF team is proud to announce the availability of
the 2.0-M1 release! Release notes and download information can be
found here:

http://cwiki.apache.org/CXF/apache-cxf-20-m1-incubating-release-notes.html

Apache Incubator CXF is an open source service development framework.
This release contains the following features:

* JAX-WS frontend - (NOTE: Apache CXF uses/implements the JAX-WS API's
but makes no representation that this release is JAX-WS compliant).
* Java2WSDL and WSDL2Java tools
* SOAP 1.1 & 1.2, XML and RESTful HTTP bindings support
* JAXB 2.0 databinding support
* JSON support
* WS-Addressing support
* MTOM support
* HTTP, Servlet, JMS and Local Transports
* Simple POJO service frontend
* Javascript frontend
* JBI Service Engine. CXF services can be deployed into any JBI
compliant container (ServiceMix or OpenESB)
* JCA 1.0 support, J2EE application can integrate with legacy
application through JCA 1.0 support in CXF
* Spring Support

If you have feedback, questions or would like to get involved in the
CXF project please join the mailing lists and let us know your
thoughts.

The Apache Incubator CXF Team
http://cwiki.apache.org/CXF/

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

Re: JAX-WS TCK and CXF 2.0 release

[Dan Diephouse]

legal-discuss: Any chance someone could comment on this that has access to
the TCK license?

Many thanks,

- Dan

On 3/13/07, Noel J. Bergman <[EMAIL PROTECTED]> wrote:


Bozhong Lin wrote:

> we would like to cut 2.0 release sooner without fully passing
> JAX-WS TCK, and plan to push JAX-WS TCK test into 2.1 release
> plan. Of course, in CXF 2.0 release note, we will explicitly
> mention that Apache CXF does NOT claim any JAX-WS compliant
> yet, like what we did with CXF 2.0 M1 release.

> Is this plan OK to incubator PPMC from legal standpoint?

From a legal standpoint, it should probably be run through legal.  I
haven't
seen the TCK license for JAX-WS TCK, but does it contain language that
prohibits use of the package namespace until the TCK is passed?

--- Noel



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





--
Dan Diephouse
Envoi Solutions
http://envoisolutions.com | http://netzooid.com/blog

Re: Killing the incubator m2 repository

[Dan Diephouse]

On 3/15/07, Davanum Srinivas <[EMAIL PROTECTED]> wrote:


"It's even knowing that you need to add another repo,"

[DIMS] This is by design.



As everyone else is saying, its a silly design. The version/artifactId
clearly as "incubator" in it. People know they're using an incubating
project.

" it's pinging that repo every time you build looking for every other

artifact"

[DIMS] Please file a maven2 bug report for this.



NOT a bug. You can't just assume that because the jar wasn't there the last
time, it won't be there again. You also can't make any assumptions that one
repo mirrors another. There is NO way around this.

"it's not having any alternative when the people.apache.org is

inaccessible (and this happens a lot)."

[DIMS] Please raise this as an infrastructure issue. Here am assuming
you are talking about snapshots. That problem will exist no matter
what since no one with the right head will publish snapshots to the
central repo.



Not really. In CXF we don't depend on any SNAPSHOTS and most people in
general tend to shy away from them.

+1 to getting rid of the m2 incubator repository. Its well intentioned, but
ultimately a silly idea.

- Dan

--
Dan Diephouse
Envoi Solutions
http://envoisolutions.com | http://netzooid.com/blog

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

[Dan Diephouse]

(non-binding)

ONE: Should Incubator tarballs go in the normal place (and thus mirrors).


[X] +1
[ ] -1

TWO: Should there be an Incubator maven repository.

[ ] +1
[X] -1




--
Dan Diephouse
Envoi Solutions
http://envoisolutions.com | http://netzooid.com/blog

[announce] Apache CXF 2.0-incubator-RC Release

[Dan Diephouse]

The Apache CXF team is proud to announce the availability of the
2.0-incubator-RC release! Release notes and download information can
be found here:

Apache CXF is a Java open source service development framework. This
release contains the following features:

* JAX-WS frontend - Apache CXF uses/implements the JAX-WS API's but
makes no representation that this release is JAX-WS compliant.
* Java2WSDL and WSDL2Java tools and Maven plugin
* SOAP 1.1 & 1.2, XML and RESTful HTTP bindings
* JAXB 2.0 Databinding support
* WSDL 1.1 support
* WS-Addressing, WS-ReliableMessaging, WS-Security, and WS-Policy support
* MTOM attachment support
* HTTP, Servlet, JMS and Local Transports
* Simple POJO service frontend
* Javascript frontend
* JBI Service Engine. CXF services can be deployed into any JBI
compliant container (ServiceMix or OpenESB)
* JCA 1.0 support, J2EE application can integrate with legacy
application through JCA 1.0 support in CXF
* Spring Support
* JSON support with Jettison
* Many other bug fixes and feature enhancements

For more information see:
* Website: http://incubator.apache.org/cxf/
* Release Notes:
http://incubator.apache.org/cxf/apache-cxf-20-rc-incubating-release-notes.html
* Mailing lists: http://incubator.apache.org/cxf/mailing-lists.html

If you have feedback, questions or would like to get involved in the
CXF project please join the mailing lists and let us know your
thoughts.

The Apache Incubator CXF Team
http://incubator.apache.org/cxf/

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

Re: PPMC guidance on new committers

[Dan Diephouse]

e PPMC.

o The podling's developer list, with notice posted to the Incubator
general list. The notice is a separate email forwarding the vote
email with a cover statement that this vote is underway on the
podling's developer list. This is a good approach if you are sure of
getting the required three +1 votes from incubator PMC members. It is
embarrassing to have a public vote fail or take a very long time
because not enough incubator PMC members vote and have to be
solicited to vote for a committer.
Only votes cast by Incubator PMC members are binding. If the vote is
positive (three or more binding +1 votes and no binding -1 votes),
the proposer offers committership to the nominee. If the nominee
accepts the responsibility of a committer for the project, the
nominee formally becomes an Apache committer. The proposer then asks
an Incubator PMC member to follow the documented procedures to
complete the process.

If the nominee is already an Apache committer on another project, the
proposer asks the incubator PMC chair to update the authorization
file to include the nominee as a committer on the podling. If the
nominee is not already an Apache committer, the incubator PMC member
CC's both the Incubator PMC and the PPMC when sending the necessary e-
mails to root. Normally, the incubator PMC member is a Mentor on the
podling's PPMC but due to unavailability, the proposer can ask any
incubator PMC member.

The proposer then directs the new committer to the Apache developer's
pages, to the Apache Incubator site, and to the Incubator Committers
Guide for important additional information.

Craig


On May 30, 2007, at 3:37 PM, Jean T. Anderson wrote:

> Craig L Russell wrote:
>> Hi Jean,
>>
>> On May 30, 2007, at 8:11 AM, Jean T. Anderson wrote:
>>
>>> Craig L Russell wrote:
>>>
>>>> Hi Carl,
>>>>
>>>> On May 30, 2007, at 6:14 AM, Carl Trieloff wrote:
>>>>
>>>>> One more question on this topic as I have also seen differing
>>>>> views
>>>>> from different members of the Incubator PMC on:  "Who can and
>>>>> who  can
>>>>> not send the account setup mail to root?"
>>>>>
>>>>> Given each new committer vote will have 3 PMC votes, why does a
>>>>> mentor have to send the account setup to root? Why can't the
>>>>> mail  to
>>>>> root just contain a link to the vote result with 3 PMC
>>>>> members   on it
>>>>> from the general list?
>>>>
>>>> This is a question that I believe only infrastructure can
>>>> answer. The
>>>> issue is that right now, "root" has to respond only to emails
>>>> from  PMC
>>>> chairs, and it's easy to verify that it's really the PMC chair
>>>> sending
>>>> the request.
>>>
>>> In the general PMC case, "root" responds to requests from PMC
>>> members:
>>> "The project PMC needs to send an email to root at apache.org
>>> requesting
>>> a new account to be created" [1]. It says "project PMC" not
>>> "project PMC
>>> chair".
>>
>> Thanks for the correction. I need to remind myself to read the entire
>> documentation every time, and not rely on memory. ;-)
>
> I don't know of anyone who has committed all apache docs to memory
> -- I
> sure haven't. :-)  The only reason I'm attentive to this detail is
> as a
> pmc chair myself I don't want account requests to be held up just
> because I don't happen to be around.
>
>>> But I think the issue is that PPMCs aren't real PMCs,
>>
>> Right.
>>
>>> so for the
>>> Incubator the request should come from a mentor.
>>
>> I'd prefer to say that the request must come from an incubator pmc
>> member.
>
> yes; I think what matters to root is that the request is made from
> somebody formally on the PMC, which makes this somebody easily
> verified
> by checking
> https://svn.apache.org/repos/private/committers/board/committee-
> info.txt
> . Just like most of us haven't committed all apache docs to memory,
> root
> won't have committed the list of who is on which PMC to memory. We
> want
> to make it easy for root to process that account request.
>
>  -jean
>
>
>> But then the ppmc member who is managing the new committer
>> process should ask an incubator pmc member to make the root request,
>> and that incubator pmc member would naturally but not necessarily be
>> one of the podling's mentors.
>>
>> Craig
>
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>

Craig Russell
Architect, Sun Java Enterprise System http://java.sun.com/products/jdo
408 276-5638 mailto:[EMAIL PROTECTED]
P.S. A good JDO? O, Gasp!






--
Dan Diephouse
Envoi Solutions
http://envoisolutions.com | http://netzooid.com/blog

[vote] Christopher Moesel as committer on CXF

[Dan Diephouse]

Hiya,
We started this vote (and a second one for Jeff Genender which I will
forward in a moment) a while back on CXF-dev, and we've been unable to gain
the necessary number of IPMC votes necessary to close the votes. Right now
we have 15 +1s from the various CXF committers and no votes from IPMC
members.  I'm forwarding it here in hopes that we can change that :-)

If you could please take a moment to review this and hopefully add your +1,
I know the CXF community as well as Chris and Jeff would both appreciate it.


Thanks,
- Dan

-- Forwarded message ------
From: Dan Diephouse <[EMAIL PROTECTED]>
Date: May 17, 2007 11:14 AM
Subject: [vote] Christopher Moesel as committer
To: [EMAIL PROTECTED]

I would like to nominate Christopher Moesel to be a committer on CXF. He's
been contributing both on the mailing list and with patches - including
fixes for MTOM, MTOM Policy support, and a Maven Java2WSDL plugin.

Here's my +1.

Cheers,
- Dan

--
Dan Diephouse
Envoi Solutions
http://envoisolutions.com | http://netzooid.com/blog

--
Dan Diephouse
Envoi Solutions
http://envoisolutions.com | http://netzooid.com/blog

[vote] Jeff Genender as a Committer on CXF

[Dan Diephouse]

Hiya,
We started this vote (and another one for Christopher Moesel which I just
sent to [EMAIL PROTECTED]) a while back on CXF-dev, and we've been unable to
gain the necessary number of IPMC votes necessary to close the votes. Right
now we have 15 +1s from the various CXF committers and no votes from IPMC
members.  I'm forwarding it here in hopes that we can change that :-)

If you could please take a moment to review this and hopefully add your +1,
I know the CXF community as well as Jeff would appreciate it.

Thanks,
- Dan

On 5/17/07, Dan Diephouse <[EMAIL PROTECTED]> wrote:


I would like to nominate Jeff Genender to be a committer on CXF. He's been
contributing a steady stream of patches for a while now which has been
helping us progress with the TCK compliance and Geronimo integration.

Here's my +1.

Cheers,
- Dan

--
Dan Diephouse
Envoi Solutions
http://envoisolutions.com | http://netzooid.com/blog





--
Dan Diephouse
Envoi Solutions
http://envoisolutions.com | http://netzooid.com/blog

[result] [vote] Christopher Moesel as committer on CXF

[Dan Diephouse]

I'm going to go ahead and close this vote now (its been several weeks).
We've got 6 IPMC +1s now and 15 +1s from CXF commiters. I'll be taking
appropriate actions so a mentor can email root and get the accounts set up.
Thanks!
- Dan

On 6/11/07, Jim Jagielski <[EMAIL PROTECTED]> wrote:



On Jun 8, 2007, at 3:25 PM, Dan Diephouse wrote:

> Hiya,
> We started this vote (and a second one for Jeff Genender which I will
> forward in a moment) a while back on CXF-dev, and we've been unable
> to gain
> the necessary number of IPMC votes necessary to close the votes.
> Right now
> we have 15 +1s from the various CXF committers and no votes from IPMC
> members.  I'm forwarding it here in hopes that we can change that :-)
>
> If you could please take a moment to review this and hopefully add
> your +1,
> I know the CXF community as well as Chris and Jeff would both
> appreciate it.
>
>

+1 (as IPMC member and CXF Mentor)


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





--
Dan Diephouse
Envoi Solutions
http://envoisolutions.com | http://netzooid.com/blog

Re: CXF committer votes

[Dan Diephouse]

Busy like everyone else I guess :-)

On 6/8/07, Noel J. Bergman <[EMAIL PROTECTED]> wrote:


> we have 15 +1s from the various CXF committers and no votes from IPMC
> members.

None?  Where are your Mentors?

--- Noel


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





--
Dan Diephouse
Envoi Solutions
http://envoisolutions.com | http://netzooid.com/blog

[result] [vote] Jeff Genender as a Committer on CXF

[Dan Diephouse]

I'm going to go ahead and close this vote now (its been several weeks).
We've got 6 IPMC +1s now and 15 +1s from CXF commiters. I'll be taking
appropriate actions so a mentor can email root and get the accounts set up.
Thanks!
- Dan

On 6/11/07, Jim Jagielski <[EMAIL PROTECTED]> wrote:



On Jun 8, 2007, at 3:27 PM, Dan Diephouse wrote:

> Hiya,
> We started this vote (and another one for Christopher Moesel which
> I just
> sent to [EMAIL PROTECTED]) a while back on CXF-dev, and we've been
> unable to
> gain the necessary number of IPMC votes necessary to close the
> votes. Right
> now we have 15 +1s from the various CXF committers and no votes
> from IPMC
> members.  I'm forwarding it here in hopes that we can change that :-)
>
> If you could please take a moment to review this and hopefully add
> your +1,
> I know the CXF community as well as Jeff would appreciate it.
>
> Thanks,
> - Dan
>

+1 (as IPMC member and CXF Mentor)


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





--
Dan Diephouse
Envoi Solutions
http://envoisolutions.com | http://netzooid.com/blog

[VOTE] Approve release CXF 2.0.2-incubator

[Dan Diephouse]

We held a vote on cxf-dev to release a new version of CXF. This version 
includes mosltly bug fixes since the 2.0.1 release. For a full list of 
the issues, see:


https://issues.apache.org/jira/secure/ReleaseNote.jspa?version=12312672&styleName=Html&projectId=12310511&Create=Create

The vote thread is at: 
http://www.nabble.com/-VOTE--Release-CXF-2.0.2-incubator-tf4403518.html


In summary, we have 11 +1 votes,  no 0 or -1 votes.  One of these is an 
IPMC vote from Jeff Genender.


The staging area is at:
http://people.apache.org/~dkulp/stage_cxf/2.0.2-incubator-take1/

The distributions are in the "dist" directory.
The "m2_repo" directory contains the stuff that will by pushed
to the m2-incubating-repository.

This release is tagged at: 
http://svn.apache.org/repos/asf/incubator/cxf/tags/cxf-2.0.2-incubator/


We and our users appreciate you taking the time to look over this release!

- Dan

--
Dan Diephouse
MuleSource
http://mulesource.com | http://netzooid.com/blog

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

Re: [VOTE] Approve release CXF 2.0.2-incubator

[Dan Diephouse]

java/org/apache/cxf/tools/java2wsdl/processor/internal/jaxws/expected/expected_holder.wsdl
tools/javato/ws/src/test/java/org/apache/cxf/tools/java2wsdl/processor/internal/jaxws/expected/expected_rpclist_no_sei.wsdl
tools/javato/ws/src/test/java/org/apache/cxf/tools/java2wsdl/processor/internal/jaxws/expected/rpc_greeter.wsdl
tools/javato/ws/src/test/java/org/apache/cxf/tools/java2wsdl/processor/internal/jaxws/expected/stock_noanno_rpc.wsdl
tools/jdee/src/main/java/org/apache/cxf/maven_plugin/jdee/prj.vm
tools/wsdlto/core/src/main/java/org/apache/cxf/tools/wsdlto/namespace2package.cfg
tools/wsdlto/core/src/main/java/org/apache/cxf/tools/wsdlto/wsdltojavaexclude.cfg
tools/wsdlto/frontend/jaxws/src/main/java/org/apache/cxf/tools/wsdlto/frontend/jaxws/validator/Messages.properties
tools/wsdlto/test/src/test/resources/META-INF/services/com.sun.tools.xjc.Plugin

Cheers,
Matthieu

On 9/11/07, Dan Diephouse <[EMAIL PROTECTED]> wrote:

We held a vote on cxf-dev to release a new version of CXF. This version
includes mosltly bug fixes since the 2.0.1 release. For a full list of
the issues, see:


https://issues.apache.org/jira/secure/ReleaseNote.jspa?version=12312672&styleName=Html&projectId=12310511&Create=Create

The vote thread is at:
http://www.nabble.com/-VOTE--Release-CXF-2.0.2-incubator-tf4403518.html

In summary, we have 11 +1 votes,  no 0 or -1 votes.  One of these is an
IPMC vote from Jeff Genender.

The staging area is at:
http://people.apache.org/~dkulp/stage_cxf/2.0.2-incubator-take1/

The distributions are in the "dist" directory.
The "m2_repo" directory contains the stuff that will by pushed
to the m2-incubating-repository.

This release is tagged at:
http://svn.apache.org/repos/asf/incubator/cxf/tags/cxf-2.0.2-incubator/

We and our users appreciate you taking the time to look over this release!

- Dan

--
Dan Diephouse
MuleSource
http://mulesource.com | http://netzooid.com/blog

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







--
Dan Diephouse
MuleSource
http://mulesource.com | http://netzooid.com/blog

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

Re: AJAX Toolkit Framework Proposal

[Dan Diephouse]

Sylvain Wallez wrote:
- why incubate an Ajax library that none of the current ASF projects 
uses nor plans to use, unless I missed something?


It is a valid question, but it is also valid to point out that the 
ASF has projects as diverse as TCL and SpamAssassin.


The situation is very different here: several projects are integrating 
Ajax features and incidentally found that they were considering the 
same framework for that purpoe. Whereas none of the ASF projects was 
already envisioning close integration with a spam filter when 
SpamAssassin came to Apache.


That could even end up with the funny (ahem) situation where Apache 
has an Ajax framework that isn't used by its Ajax-enabled server-side 
frameworks. Doesn't it sound weird?


I don't think this is weird at all. This may be off topic (or missing 
the point), but why do the ASF projects have to be one coherent product 
suite? Do they have to all tie together?  Sure tie-ins are great, but 
not everything needs to be related or play nice together. We have plenty 
of examples of competing projects (see struts, beehive, turbine, 
tapestry, etc).


I think Sam summed it up great when he said:

What is more important is considerations that the code be licensed 
with the Apache Software License (not dual licensed, like Dojo), that 
the committer bases be diverse, and operate in an open and 
collaborative model.

I think this is right on with the ASF philosophy [1]:

"""
While there is not an official list, these six principles have been 
cited as the core beliefs of philosophy behind the foundation, which is 
normally referred to as "The Apache Way":


   * collaborative software development
   * commercial-friendly standard license
   * consistently high quality software
   * respectful, honest, technical-based interaction
   * faithful implementation of standards
   * security as a mandatory feature

""""
I think there is a space for any and all projects that meet the above 
criteria.


Cheers,
- Dan

1. http://www.apache.org/foundation/how-it-works.html#management

--
Dan Diephouse
Envoi Solutions LLC
http://netzooid.com


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

Re: Incubating java projects

[Dan Diephouse]

Davanum Srinivas wrote:

James,

Incubation process is not set in stone. Just last week, we voted on
standardizing the mailing list names. So it is a mix of good
judgement, experience, consensus and rules. If you insist we can put
start a VOTE on [EMAIL PROTECTED] I think you are part of that as well.

I did bring up issues on the [EMAIL PROTECTED] mailing lists and we
resolved it. As to "related-ness". I'd even be ok with ActiveMQ as a
TLP or ServiceMix as a TLP. But it does not seem right to be part of
Geronimo as a sub project. I'd prefer ServiceMix folks to work more
closely with WS folks or even move to WS-land. But that's another
story. FYI, am and Guillaume Nodet did work during the hackathon on
some stuff. But i'd like to see more closer cooperation. Especially
for items that you need and those that affect Geronimo like JAX-WS
2.0/JAXB. It's not like we want all ws stuff to be in ws pmc. JSR 181
in Beehive and WSRP4J in portals are good examples of sister projects
that still work closely with Axis dev folks.

Also, what does "community" means? does it mean existing folks who are
working on the projects already at codehaus? Especially when Syanpse
and Axis are mentioned in the proposal and we don't see anyone show up
on the dev mailing lists, it's just fishy to say the least. FYI, this
is not the first time i had to do this. I did this with beehive too.
See my post in Oct 2004 articulating the same concerns with beehive.
  
First, I don't know what you are expecting regarding Syanpse and Axis. 
Synapse hasn't even done a milestone yet so there isn't much to 
integrate with JBI. Axis 2 has done mile stones but enough people are 
using it yet for the SM team to spend their time on it. And I think if 
you'll look closely it is already possible to work with Axis 1.x 
services in SM.


Second, I don't think you can expect SM to come to you and flop a bunch 
of code out there which makes the integration perfect. I originally came 
to the ServiceMix guys with XFire integration and thats how it got 
integrated. That in turn got me involved with ServiceMix and Guillaume 
in turn has helped XFire a little. Its reciprocal.


Also, I hope you aren't implying that ServiceMix has created an 
exclusive community of Codehaus people. I have seen the ServiceMix team 
be more than helpful to myself and to others who joined in both in and 
outside the Codehaus/Apache communitys. In fact, they MUST. ServiceMix's 
job is to not play favorites and integrate with everyone. Why must 
ServiceMix work extra close with the WS PMC? I'm sure when people start 
needing integration with WS-* projects that will happen. Thats how open 
source works right?


Cheers,

- Dan


--
Dan Diephouse
Envoi Solutions LLC
http://netzooid.com


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

Re: ajax proposal?

[Dan Diephouse]

Martin Cooper wrote:

On 1/4/06, Sanjiva Weerawarana <[EMAIL PROTECTED]> wrote:
  

So .. amidst all of our soul searching .. what'd we decide to do with
the Ajax proposal from IBM et al.?? Did I miss the vote and decision??




I don't believe there is a sponsoring PMC at this point.

Personally, I would prefer that the ASF not accept _any_ AJAX framework at
this point in time. The area is relatively new and in a great deal of flux
right now, and "crowning" one of them with the ASF brand will create a de
facto standard instead of letting the market decide, whether we like it or
not.

I realise that the Incubator doesn't work that way, though, and that plenty
of people don't seem to care / mind that we'd create a (premature, IMHO) de
facto standard, but I can always hope. ;-)
  
I am confused - why can't there be multiple ajax projects at somepoint? 
As the perlers say, "there is more than one way to do things." See my 
note in a previous thread about multiple web app frameworks, etc, etc[1].


- Dan

1. 
http://mail-archives.apache.org/mod_mbox/incubator-general/200512.mbox/[EMAIL PROTECTED]



--
Martin Cooper


Sanjiva.
  

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





  



--
Dan Diephouse
Envoi Solutions LLC
http://netzooid.com


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