Re: [VOTE] Approve release Apache UIMA 2.2.1-incubating
William A. Rowe, Jr. wrote: > Marshall Schor wrote: >> We've put the LICENSE, NOTICES, and DISCLAIMERs into the top directory >> of the source (and binary) distribution(s), but didn't realize this also >> needs to be in the top level of the SVN tag, because we didn't know that >> was considered part of the "distribution". >> >> Can you please confirm this is the case? In which case, we'll of course >> comply. > > Your distribution must correspond to subversion, otherwise it's very hard > to track the artifacts in the tarball, where they came from, how they > got there, and if they underwent the proper oversight prior to packaging. > (Yes, we vote on the prepared tarball, but you can see how discrepancies > do create questions.) That's not how I interpret the policy document. It says: "To apply the ALv2 to a new software distribution, include one copy of the license text by copying the file: http://www.apache.org/licenses/LICENSE-2.0.txt into a file called LICENSE in the top directory of your distribution. If the distribution is a jar or tar file, try to add the LICENSE file first in order to place it at the top of the archive." That's what we do. Of course we'll make every effort to make our distribution easy to review. However, it does seem that we're ok wrt current policy, and view this as a suggestion for next time. Ok? --Thilo - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] Approve release Apache UIMA 2.2.1-incubating
sebb wrote: > On 15/12/2007, Jean T. Anderson <[EMAIL PROTECTED]> wrote: >> sebb wrote: >>> [Eventually found the KEYS file in SVN, but it might be helpful to >>> provide a pointer in the vote mails] >>> >>> >> yeah, I went to their website and followed the link from there. > > So did I. > >>> The NOTICE file in uimaj-2.2.1-incubating-bin.zip refers to the >>> contributions from IBM: >>> >>> "Software Grant License Agreement", informally known as the >>> "IBM UIMA License Agreement". >>> >>> however, that license is not in LICENSE, nor is it linked from there. >>> >>> >> this wording was approved in their first release -- iirc there were >> discussions about what specifically to put there [1] and I had a minor >> hand in that since they had borrowed wording from derby [2]. > > I'm not objecting to the wording in the NOTICE file. > However, since it refers to another license, I think that needs to be > present in the LICENSE file: > > http://www.apache.org/dev/release.html#distributing-code-under-several-licenses We are not distributing code under several licenses. The only license applicable to UIMA is the AL. The somewhat cryptic (to a non-lawyer) statement in the NOTICE file was put there on request by the IPMC, we didn't have it there originally. To my way of thinking, what it is supposed to say is that some of the code originated with IBM, but has since been relicensed under the Apache License. This exact version of the NOTICE and LICENSE file has been approved for our previous two releases, so I do hope they are still ok. --Thilo - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] Approve release Apache UIMA 2.2.1-incubating
sebb wrote: > [Eventually found the KEYS file in SVN, but it might be helpful to > provide a pointer in the vote mails] Good point, will do next time. [...] > > There are some problems with the MD5 and SHA1 files. > > For example, uimaj-2.2.1-incubating-bin.tar.bz2.md5: > > > uimaj-2.2.1-incubating-bin.tar.bz2: 53 20 6A FB 75 1F 07 9D BB 12 82 58 D0 7D > CA 4B > > > The hash is spread over two lines and into hex pairs. The normal > format is either: > 53206afb751f079dbb128258d07dca4b > or > 53206afb751f079dbb128258d07dca4b *uimaj-2.2.1-incubating-bin.tar.bz2 > > The SHA1 checksums have the same problem. > > The PGP signatures are OK, however the format of the existing MD5/SHA1 > files means that most (all?) checking programs will have difficulty > verifying the checksums. We generate the checksums with gpg --print-md MD5 [fileName] > [fileName].md5 and gpg --print-md SHA1 [fileName] > [fileName].sha respectively (as described in the release signing FAQ; however, I suggested that text ;-). The advantage of using gpg is that you just need one tool for the various signatures. If there are alternatives, we'll be happy to entertain them (we use maven as our build env). Can you elaborate on what checking programs are commonly used? It was my understanding that the primary signing mechanisms were the PGP signatures, and the checksums were just for quick sanity checks (visual verification, as they are so short). Thanks. --Thilo - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] Approve release Apache UIMA 2.2.1-incubating
On Dec 17, 2007 10:09 AM, Thilo Goetz <[EMAIL PROTECTED]> wrote: > William A. Rowe, Jr. wrote: > > Marshall Schor wrote: > >> We've put the LICENSE, NOTICES, and DISCLAIMERs into the top directory > >> of the source (and binary) distribution(s), but didn't realize this also > >> needs to be in the top level of the SVN tag > > Your distribution must correspond to subversion, otherwise it's very hard > > to track the artifacts in the tarball,... > That's not how I interpret the policy document You might be right about the letter of the policy document, but all kinds of alarms go off in my brain when I see a distribution tarball that doesn't match the SVN tag that it's built from. Automated reproducible builds (including building distribution archives) are IMHO a must in our way of working. -Bertrand - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] Approve release Apache UIMA 2.2.1-incubating
Bertrand Delacretaz wrote: > On Dec 17, 2007 10:09 AM, Thilo Goetz <[EMAIL PROTECTED]> wrote: >> William A. Rowe, Jr. wrote: >>> Marshall Schor wrote: We've put the LICENSE, NOTICES, and DISCLAIMERs into the top directory of the source (and binary) distribution(s), but didn't realize this also needs to be in the top level of the SVN tag > >>> Your distribution must correspond to subversion, otherwise it's very hard >>> to track the artifacts in the tarball,... > >> That's not how I interpret the policy document > > You might be right about the letter of the policy document, but all > kinds of alarms go off in my brain when I see a distribution tarball > that doesn't match the SVN tag that it's built from. > > Automated reproducible builds (including building distribution > archives) are IMHO a must in our way of working. Absolutely. Our build is completely automated and reproducible, including generating the distribution. Here's (a slightly simplified version of) our build script: svn checkout $tag cd $leveldir/uimaj mvn -Duima.build.date="`date`" install cd .. cd uimaj-distr mvn assembly:assembly This does everything from svn extract to building the release artifacts (except the signing, that requires some manual intervention because of the release manager's key phrase). I don't think it gets much simpler than that. However, I don't think that addresses your concerns. AIUI, you would like our repository to look exactly like the source distribution. Well, it almost is, except for the files in the top level directory. Those get copied there when we build the distribution. Why? I guess we thought it's cleaner that way, and complies with maven's notion of organizing things. For example, the NOTICE file lives in uimaj-distr/src/main/readme. It's still there in the source distribution, but it's also at the top level. Now if we absolutely must, we can change that. I do admit that I don't quite understand the reason, though, and like it better the way it is ;-) --Thilo - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] Approve release Apache UIMA 2.2.1-incubating
On Dec 17, 2007 11:08 AM, Thilo Goetz <[EMAIL PROTECTED]> wrote: > > Bertrand Delacretaz wrote: > > ...Automated reproducible builds (including building distribution > > archives) are IMHO a must in our way of working. > > Absolutely. Our build is completely automated and reproducible, > including generating the distribution. Here's (a slightly simplified > version of) our build script:... Ok sorry then, I misunderstood. I thought Marshall was saying that you added the LICENSE/NOTICE files manually to the distribution archive (please bear with me, it's Monday morning here ;-) > ...However, I don't think that addresses your concerns. > AIUI, you would like our repository to look exactly like > the source distribution. Well, it almost is, except for > the files in the top level directory That's ok with me, as the automated build recreates the same distribution archive if run from the specified SVN tag. -Bertrand - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] Approve release Apache UIMA 2.2.1-incubating
On 17/12/2007, Thilo Goetz <[EMAIL PROTECTED]> wrote: > sebb wrote: > > On 15/12/2007, Jean T. Anderson <[EMAIL PROTECTED]> wrote: > >> sebb wrote: > >>> [Eventually found the KEYS file in SVN, but it might be helpful to > >>> provide a pointer in the vote mails] > >>> > >>> > >> yeah, I went to their website and followed the link from there. > > > > So did I. > > > >>> The NOTICE file in uimaj-2.2.1-incubating-bin.zip refers to the > >>> contributions from IBM: > >>> > >>> "Software Grant License Agreement", informally known as the > >>> "IBM UIMA License Agreement". > >>> > >>> however, that license is not in LICENSE, nor is it linked from there. > >>> > >>> > >> this wording was approved in their first release -- iirc there were > >> discussions about what specifically to put there [1] and I had a minor > >> hand in that since they had borrowed wording from derby [2]. > > > > I'm not objecting to the wording in the NOTICE file. > > However, since it refers to another license, I think that needs to be > > present in the LICENSE file: > > > > http://www.apache.org/dev/release.html#distributing-code-under-several-licenses > > We are not distributing code under several licenses. > The only license applicable to UIMA is the AL. The > somewhat cryptic (to a non-lawyer) statement in the > NOTICE file was put there on request by the IPMC, we > didn't have it there originally. To my way of thinking, > what it is supposed to say is that some of the code > originated with IBM, but has since been relicensed > under the Apache License. Sorry, I misread the paragraph originally - I somehow managed to overlook the phrase "to the Apache Software Foundation" and thought it referred to a standard 3rd party attribution notice. Apologies for the noise on this matter. > This exact version of the NOTICE and LICENSE file has > been approved for our previous two releases, so I do > hope they are still ok. Yes, it's my "brian" that needs adjusting in this case... > --Thilo > > > - > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] Approve release Apache UIMA 2.2.1-incubating
On 17/12/2007, Thilo Goetz <[EMAIL PROTECTED]> wrote: > sebb wrote: > > [Eventually found the KEYS file in SVN, but it might be helpful to > > provide a pointer in the vote mails] > > Good point, will do next time. > > [...] > > > > There are some problems with the MD5 and SHA1 files. > > > > For example, uimaj-2.2.1-incubating-bin.tar.bz2.md5: > > > > > > uimaj-2.2.1-incubating-bin.tar.bz2: 53 20 6A FB 75 1F 07 9D BB 12 82 58 D0 > > 7D > > CA 4B > > > > > > The hash is spread over two lines and into hex pairs. The normal > > format is either: > > 53206afb751f079dbb128258d07dca4b > > or > > 53206afb751f079dbb128258d07dca4b *uimaj-2.2.1-incubating-bin.tar.bz2 > > > > The SHA1 checksums have the same problem. > > > > The PGP signatures are OK, however the format of the existing MD5/SHA1 > > files means that most (all?) checking programs will have difficulty > > verifying the checksums. > > We generate the checksums with > > gpg --print-md MD5 [fileName] > [fileName].md5 > > and > > gpg --print-md SHA1 [fileName] > [fileName].sha > > respectively (as described in the release signing FAQ; however, > I suggested that text ;-). The advantage of using gpg is that > you just need one tool for the various signatures. If there > are alternatives, we'll be happy to entertain them (we use maven > as our build env). Maven can generate the MD5 and SHA1 checksums itself; no need for a separate tool. I'm not familiar with Maven, so I don't know the commands off-hand, but I can probably find them. > Can you elaborate on what checking programs are commonly used? The programs for checking MD5s are referenced from a lot of download pages, for example: http://xerces.apache.org/xerces-c/download.cgi and http://myfaces.apache.org/download.html All of these expect checksums which are a single string of hex digits. > It was my understanding that the primary signing mechanisms were > the PGP signatures, and the checksums were just for quick sanity > checks (visual verification, as they are so short). Thanks. Yes, PGP sigs are the primary signing mechanisms. MD5 and SHA1 are not as secure. However they are still useful, particularly for checking that the files have been downloaded successfully. To that end, having a format that can be automatically checked is essential. > --Thilo > > > - > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] Move Project Yoko to Apache Geronimo and Apache CXF
On Dec 12, 2007, at 5:28 AM, Niclas Hedhman wrote: On Tuesday 11 December 2007 11:26, Matt Hogstrom wrote: [x] +1 Approve the below proposal and code migration to Apache Geronimo and CXF respectively +1 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] Approve release Apache UIMA 2.2.1-incubating
sebb wrote: [...] > Maven can generate the MD5 and SHA1 checksums itself; no need for a > separate tool. > > I'm not familiar with Maven, so I don't know the commands off-hand, > but I can probably find them. Maybe it can, but I was unable to figure out how. We need to create checksums for the artifacts that fall out of the assembly step, and I don't think maven supports creating those. However, Ant can create checksums in the expected format. So we can call an Ant task from Maven to do this. For the purposes of this vote, would it be ok to just modify the existing .md5 and .sha1 files? I would prefer not having to create another release candidate just for that purpose. --Thilo - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Account Request - Mark Combellack - Tuscany (incubating)
Dear root, Please create an id for Mark Combellack on the Tuscany project under Incubation. Preferred userid:mcombellack Full name: Mark Combellack Forwarding email address:[EMAIL PROTECTED] Requested Karma for: ws-tuscany ICLA is on file. Votes: tuscany-private, Oct 29, Message-ID: < [EMAIL PROTECTED]> incubator-private, Nov 1, Message-ID: < [EMAIL PROTECTED]> Many thanks, ...ant
Re: [VOTE] Move Project Yoko to Apache Geronimo and Apache CXF
My +1 ... sorry On Dec 17, 2007, at 8:36 AM, Jim Jagielski wrote: On Dec 12, 2007, at 5:28 AM, Niclas Hedhman wrote: On Tuesday 11 December 2007 11:26, Matt Hogstrom wrote: [x] +1 Approve the below proposal and code migration to Apache Geronimo and CXF respectively +1 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[RESULT] Move Project Yoko to Apache Geronimo and Apache CXF - Approved 8 +1 votes
There have been sufficient +1 votes with no dissenting votes. There was discussion about IP clearance which we'll make sure is covered in the process of relocating the code. Thanks for the votes and comments. On Dec 10, 2007, at 10:26 PM, Matt Hogstrom wrote: Below is a proposal that was discussed and brought forward by the Yoko Community. In a nutshell the proposal is to create a Yoko sub- project of Apache Geronimo for the Core ORB and to move the bindings to CXF. Please read the proposal below for all the detail. This proposal was brought forward to the Apache Geronimo and Apache CXF communities. Both communities have voted to accept this proposal. Vote results from Apache Geronimo were 20 +1 votes and no 0 or -1 votes. 17 were binding from the Geronimo PMC. CXF Results on the CF Dev list were 13 +1 votes and 1 0 vote I am now bringing this to the Incubator for final approval so that the code can be moved from Incubator to the respective receiving projects. This proposal was previously sent to the IPMC for comment while the respective communities discussed and voted. During that time there has been no comments that indicated there was an issue so I bring this vote back to the Incubator for finalization: [ ] +1 Approve the below proposal and code migration to Apache Geronimo and CXF respectively [ ] 0 No opinion [ ] -1 Do not approve of the move (please provide rationale If someone wants to comment on this thread please use the Alternate [DISCUSS] thread and not the vote thread. This vote will conclude on Dec 14th at 0900 ET. Original Proposal The members of project yoko have been considering the future of Yoko as a project. There have been several milestones delivered and the project is used by other ASF projects. The project is not as active as other ASF projects and it makes sense to move the code from Yoko to other projects. The Yoko team has the following proposal for your consideration. Proposed Code Donation from Project Yoko to Apache CXF and Apache Geronimo The Yoko community has been successful in delivering several milestones of the ORB implementation while in the Apache Incubator. These milestones are used by other Apache projects (namely Geronimo and Harmony) to support their releases. The WebServices bindings are dependent on CXF. The Yoko community has decided that the Yoko project does not have quite the momentum to carry itself as an independent project but has sufficient value for other projects for them to consider receiving the code and committers for that code-base as sub-projects. Since the code under consideration is used by Apache Geronimo, Apache CXF and Apache Harmony the movement of the code should continue to allow for independent releases so the code can be easily shared with other dependent projects. The proposed division is: yoko-spec-corba - this is the org.omg interface classes. rmi-spec - this is the javax.rmi spec implementation core - This is the actual ORB implementation. rmi-impl - This is the implementation of the RMIIIOP support. These modules are also used by Harmony. In addition to the code we propose that the following committers in Apache Yoko be accepted as committers in Apache Geronimo given their demonstration of delivering code, creating releases and functioning as a community. Those noted with asterisks are already Geronimo committers. Continued involvement with the core: Rick McGuire * David Jencks * Alan Cabrera * Lars Kuhne Alexey Petrenko Darren Middleman The remainder of the modules in Yoko are part of the webservices support and are independent of the underlying ORB implementation. api -- interface classes used for the web services support. bindings -- code to implement the CORBA-Web services bindings. tools -- tools for generation WSDL and IDL for the bindings maven-plugin -- some maven plugins that can use the tools for generating binding-related build artifacts. None of the maven-plugin code is used by the ORB. There is also a distribution directory with some sample applications. One set of samples demonstrates using the core ORB, the other set is for WebServices. We recommend that the distribution directory should move to Apache CXF as the webservices examples use the orb samples to bind them as web services. Since Apache Geronimo's only use of CORBA is for exporting EJBs, these samples are not particularly valuable for Geronimo. The Yoko community did not have any committers that expressed an interest in continuing work on these bindings. As such, only the code would be moving to apache CXF. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] Approve release Apache UIMA 2.2.1-incubating
On Dec 17, 2007, at 4:09 AM, Thilo Goetz wrote: William A. Rowe, Jr. wrote: Marshall Schor wrote: We've put the LICENSE, NOTICES, and DISCLAIMERs into the top directory of the source (and binary) distribution(s), but didn't realize this also needs to be in the top level of the SVN tag, because we didn't know that was considered part of the "distribution". Can you please confirm this is the case? In which case, we'll of course comply. Your distribution must correspond to subversion, otherwise it's very hard to track the artifacts in the tarball, where they came from, how they got there, and if they underwent the proper oversight prior to packaging. (Yes, we vote on the prepared tarball, but you can see how discrepancies do create questions.) That's not how I interpret the policy document. It says: "To apply the ALv2 to a new software distribution, include one copy of the license text by copying the file: http://www.apache.org/licenses/LICENSE-2.0.txt into a file called LICENSE in the top directory of your distribution. If the distribution is a jar or tar file, try to add the LICENSE file first in order to place it at the top of the archive." That's what we do. Of course we'll make every effort to make our distribution easy to review. However, it does seem that we're ok wrt current policy, and view this as a suggestion for next time. Ok? Your interpretation works if your subversion repository is not a "distribution". IMO, it is and should contain appropriate license/ notice/disclaimer. --kevan
December 2007 Incubator Board Report
Shindig, a "SocialContainer" is entering Incubation. PDFBox and Bennu (based on the old m0n0wall project) have been proposed to the Incubator. RAT is in the Incubator, and will need to start reporting. Woden has graduated to the WS Project. FTPServer is in the process of moving to MINA. Yoko (CORBA ORB) is being split up, with parts going to Geronimo and CXF. UIMA, QPid, CXF did releases. A number of new committers and PMC members added. Community diversity is an area that was discussed, especially with Tuscany failing to graduate over concerns related to community diversity. === Buildr === Description - Buildr is a build system for Java applications written in Ruby. Date of Entry - Nov. 2007 Community - The buildr community is transitioning from its older infrastructure to the Apache one. The code has been imported and committers work on the Apache SVN now. The migration of users from buildr-talk at google groups to buildr-user is also happening progressively. Development --- Mostly bug fixes and small improvements. There's also work on JRuby support for which patches are submitted regularly from (for now) external contributors. Issues before graduation First we need to fix the IP issues surrounding the Ruby license and our Ruby licensed dependencies before any release can be made. A thread has been started on [EMAIL PROTECTED] and another one is still running on [EMAIL PROTECTED] but we've had few answers so far. We'll probably send a proposition and see if that's acceptable. === OpenEJB === OpenEJB is an open source, modular, configurable, and extendable EJB Container System and EJB Server. Incubating since: 2006-07-10 We received some very excellent feedback we are all really proud of from a new face in the community. OpenEJB has always prided itself for being the kinder, gentler side of open source and it's really good to know this is coming through. http://mail-archives.apache.org/mod_mbox/incubator-openejb-dev/200701.mbox/% [EMAIL PROTECTED] Recent New Contributors: Karan Malhi and Raj Saini contributed their first patches. === River === River is aimed at the development and advancement of the Jini technology core infrastructure. Jini technology is a service oriented architecture that defines a programming model which both exploits and extends Java technology to enable the construction of secure, distributed systems which are adaptive to change. The crypto issue mentioned in last report seems to be resolved without doing anything special as it seems to be not necessary based on the (limited) feedback in the legal mailing list. The River community decided to start with a CTR policy although we urge people to consult others before actually committing for all but the trivial cases. We decided we want to use Hudson as our continuous integration engine, but we have to wait a while for a server becomes available to deploy it on, hopefully somewhere in December/January. Work on the first release moved steady as a glacier (global warming seems to have no effect here :-) ) and didn't require much participation of committers due to the set goals. Currently there is no outstanding work for that first release. We are picking and scheduling fixes and features for the next release and are discussing a branching strategy for SVN before we can finally release the trunk to a stampede of hungry people that will crash into the codebase to make it better. Incubating since: December 2006 === Imperius === Imperius has been incubating since November 2007. Imperius is a rule-based infrastructure management tool Infrastructure has been partly set up. Mailing lists for dev, commits, private, and user are operational. The repository has been set up. Community Two of the original committers have had accounts created. We are waiting for the arrival of ICLAs for the others. === JSPWiki === JSPWiki has been incubating since September 2007. JSPWiki is a JSP-based wiki program. The final JSPWiki LGPL release has been postponed due to a large number of security vulnerabilities that were disclosed to us right before the release, so unfortunately that has also delayed the move of the codebase under ASF's infrastructure. The JSPWiki user community is in the process of transition from outside Apache. There are close to 100 subscribers to the user list. The developer list has meanwhile continued growing, and new people have come forward with patches and expressions of interest on working on the code. === Sanselan === Sanselan has been in incubation since September 2007. Sanselan is a pure-java image library for reading and writing a variety of image formats. The community is still small, with a few more members now compared to the beginning. The code base has been imported and the package names have been changed to org.apache.sanselan. A release is being prepared. ---
Re: [VOTE] Approve release Apache UIMA 2.2.1-incubating
Kevan Miller wrote: > > On Dec 17, 2007, at 4:09 AM, Thilo Goetz wrote: > >> William A. Rowe, Jr. wrote: >>> Marshall Schor wrote: We've put the LICENSE, NOTICES, and DISCLAIMERs into the top directory of the source (and binary) distribution(s), but didn't realize this also needs to be in the top level of the SVN tag, because we didn't know that was considered part of the "distribution". Can you please confirm this is the case? In which case, we'll of course comply. >>> >>> Your distribution must correspond to subversion, otherwise it's very >>> hard >>> to track the artifacts in the tarball, where they came from, how they >>> got there, and if they underwent the proper oversight prior to >>> packaging. >>> (Yes, we vote on the prepared tarball, but you can see how discrepancies >>> do create questions.) >> >> That's not how I interpret the policy document. It says: >> >> "To apply the ALv2 to a new software distribution, include one copy of >> the license text by copying >> the file: >> >> http://www.apache.org/licenses/LICENSE-2.0.txt >> >> into a file called LICENSE in the top directory of your distribution. >> If the distribution is a jar >> or tar file, try to add the LICENSE file first in order to place it at >> the top of the archive." >> >> That's what we do. Of course we'll make every effort to make >> our distribution easy to review. However, it does seem that >> we're ok wrt current policy, and view this as a suggestion >> for next time. Ok? > > Your interpretation works if your subversion repository is not a > "distribution". IMO, it is and should contain appropriate > license/notice/disclaimer. If that is the consensus opinion here, that's what we'll do. But please put yourself in our shoes. We can only go by the information that is available to us. If this is a rule, it would be great if it could be written down so the next incubator project doesn't have to go through this. I'd be happy to help with the docs. Out of curiosity, I started going through the Apache SVN repo to see what Apache projects complied with this requirement. I stopped after C because I'd already found 4 that didn't comply: Avalon, Cayenne, Cocoon and Commons. Compliant were Activemq, Ant, APR and Beehive. --Thilo - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] Approve release Apache UIMA 2.2.1-incubating
Though I don't necessarily agree with Kevan, the best projects to look at are recently graduated projects as those have been scrutinized by the IPMC, and have been held against the same (though possibly changing) standards as you. For instance you could take a look at Wicket, OpenJPA, ServiceMix, Ode, Roller and Felix. Martijn On Dec 17, 2007 6:44 PM, Thilo Goetz <[EMAIL PROTECTED]> wrote: > Kevan Miller wrote: > > > > On Dec 17, 2007, at 4:09 AM, Thilo Goetz wrote: > > > >> William A. Rowe, Jr. wrote: > >>> Marshall Schor wrote: > We've put the LICENSE, NOTICES, and DISCLAIMERs into the top > directory > of the source (and binary) distribution(s), but didn't realize this > also > needs to be in the top level of the SVN tag, because we didn't know > that > was considered part of the "distribution". > > Can you please confirm this is the case? In which case, we'll of > course > comply. > >>> > >>> Your distribution must correspond to subversion, otherwise it's very > >>> hard > >>> to track the artifacts in the tarball, where they came from, how they > >>> got there, and if they underwent the proper oversight prior to > >>> packaging. > >>> (Yes, we vote on the prepared tarball, but you can see how > discrepancies > >>> do create questions.) > >> > >> That's not how I interpret the policy document. It says: > >> > >> "To apply the ALv2 to a new software distribution, include one copy of > >> the license text by copying > >> the file: > >> > >> http://www.apache.org/licenses/LICENSE-2.0.txt > >> > >> into a file called LICENSE in the top directory of your distribution. > >> If the distribution is a jar > >> or tar file, try to add the LICENSE file first in order to place it at > >> the top of the archive." > >> > >> That's what we do. Of course we'll make every effort to make > >> our distribution easy to review. However, it does seem that > >> we're ok wrt current policy, and view this as a suggestion > >> for next time. Ok? > > > > Your interpretation works if your subversion repository is not a > > "distribution". IMO, it is and should contain appropriate > > license/notice/disclaimer. > > If that is the consensus opinion here, that's what we'll > do. But please put yourself in our shoes. We can only go > by the information that is available to us. If this is a > rule, it would be great if it could be written down so the > next incubator project doesn't have to go through this. I'd > be happy to help with the docs. > > Out of curiosity, I started going through the Apache SVN repo > to see what Apache projects complied with this requirement. I > stopped after C because I'd already found 4 that didn't > comply: Avalon, Cayenne, Cocoon and Commons. Compliant > were Activemq, Ant, APR and Beehive. > > --Thilo > > > - > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > -- Buy Wicket in Action: http://manning.com/dashorst Apache Wicket 1.3.0-rc2 is released Get it now: http://www.apache.org/dyn/closer.cgi/wicket/1.3.0-rc1/
Re: [VOTE] Approve release Apache UIMA 2.2.1-incubating
On 17/12/2007, Thilo Goetz <[EMAIL PROTECTED]> wrote: > Kevan Miller wrote: > > > > On Dec 17, 2007, at 4:09 AM, Thilo Goetz wrote: > > > >> William A. Rowe, Jr. wrote: > >>> Marshall Schor wrote: > We've put the LICENSE, NOTICES, and DISCLAIMERs into the top directory > of the source (and binary) distribution(s), but didn't realize this > also > needs to be in the top level of the SVN tag, because we didn't know > that > was considered part of the "distribution". > > Can you please confirm this is the case? In which case, we'll of > course > comply. > >>> > >>> Your distribution must correspond to subversion, otherwise it's very > >>> hard > >>> to track the artifacts in the tarball, where they came from, how they > >>> got there, and if they underwent the proper oversight prior to > >>> packaging. > >>> (Yes, we vote on the prepared tarball, but you can see how discrepancies > >>> do create questions.) > >> > >> That's not how I interpret the policy document. It says: > >> > >> "To apply the ALv2 to a new software distribution, include one copy of > >> the license text by copying > >> the file: > >> > >> http://www.apache.org/licenses/LICENSE-2.0.txt > >> > >> into a file called LICENSE in the top directory of your distribution. > >> If the distribution is a jar > >> or tar file, try to add the LICENSE file first in order to place it at > >> the top of the archive." > >> > >> That's what we do. Of course we'll make every effort to make > >> our distribution easy to review. However, it does seem that > >> we're ok wrt current policy, and view this as a suggestion > >> for next time. Ok? > > > > Your interpretation works if your subversion repository is not a > > "distribution". IMO, it is and should contain appropriate > > license/notice/disclaimer. > > If that is the consensus opinion here, that's what we'll > do. But please put yourself in our shoes. We can only go > by the information that is available to us. If this is a > rule, it would be great if it could be written down so the > next incubator project doesn't have to go through this. I'd > be happy to help with the docs. > > Out of curiosity, I started going through the Apache SVN repo > to see what Apache projects complied with this requirement. I > stopped after C because I'd already found 4 that didn't > comply: Avalon, Cayenne, Cocoon and Commons. Avalon is defunct, so does not count. Commons looks OK to me; there are N&L files in http://svn.apache.org/repos/asf/commons/proper/attributes/trunk/ http://svn.apache.org/repos/asf/commons/proper/commons-build/trunk/ and http://svn.apache.org/repos/asf/commons/proper/vfs/trunk/ to take a few at random The top-level directory: http://svn.apache.org/repos/asf/commons/ is not a project - see the README for details. I agree that Cayenne and Cocoon are "non-compliant". > Compliant > were Activemq, Ant, APR and Beehive. > > --Thilo > > > - > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] Approve release Apache UIMA 2.2.1-incubating
On Dec 17, 2007 5:49 PM, Kevan Miller <[EMAIL PROTECTED]> wrote: > > Your interpretation works if your subversion repository is not a > "distribution". IMO, it is and should contain appropriate license/ > notice/disclaimer. > I don't agree with this standpoint as for instance the LICENSE and DISCLAIMER docs can be automatically included into the correct distribution location from officially released bundles. This makes much more sense as it keeps the definition of those documents in one place. This process is repeatable using maven. IMO SVN does not have to mirror an unzipped release (there is no policy directing that, or if there is, please provide a link), as long as it is reproducible from the release tag. Martijn -- Buy Wicket in Action: http://manning.com/dashorst Apache Wicket 1.3.0-rc2 is released Get it now: http://www.apache.org/dyn/closer.cgi/wicket/1.3.0-rc1/
Re: [VOTE] Approve release Apache UIMA 2.2.1-incubating
On 17/12/2007, Martijn Dashorst <[EMAIL PROTECTED]> wrote: > On Dec 17, 2007 5:49 PM, Kevan Miller <[EMAIL PROTECTED]> wrote: > > > > Your interpretation works if your subversion repository is not a > > "distribution". IMO, it is and should contain appropriate license/ > > notice/disclaimer. > > I agree with Kevan. > I don't agree with this standpoint as for instance the LICENSE and > DISCLAIMER docs can be automatically included into the correct distribution > location from officially released bundles. This makes much more sense as it > keeps the definition of those documents in one place. This process is > repeatable using maven. > IMO SVN does not have to mirror an unzipped release (there is no policy > directing that, or if there is, please provide a link), as long as it is > reproducible from the release tag. > I have asked about this on the legal discuss list. Regardless of the outcome, I think that there are problems with generating the NOTICE and LICENSE files automatically. Unless the project is pure ASF, there are additional items that may need to be added to the N & L files. In any case, I think it's important that these files are carefully considered to ensure that the required entries are present. This is difficult if not impossible if the contents of the N & L files are automatically generated. The N & L files are unlikely to change frequently, so it really does not save much work (if any) to create them by hand. Having them in the top-level SVN directory seems sensible to me. > Martijn > > -- > Buy Wicket in Action: http://manning.com/dashorst > Apache Wicket 1.3.0-rc2 is released > Get it now: http://www.apache.org/dyn/closer.cgi/wicket/1.3.0-rc1/ > - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] Approve release Apache UIMA 2.2.1-incubating
sebb wrote: > On 17/12/2007, Martijn Dashorst <[EMAIL PROTECTED]> wrote: > >> On Dec 17, 2007 5:49 PM, Kevan Miller <[EMAIL PROTECTED]> wrote: >> >>> Your interpretation works if your subversion repository is not a >>> "distribution". IMO, it is and should contain appropriate license/ >>> notice/disclaimer. >>> >>> > > I agree with Kevan. > > >> I don't agree with this standpoint as for instance the LICENSE and >> DISCLAIMER docs can be automatically included into the correct distribution >> location from officially released bundles. This makes much more sense as it >> keeps the definition of those documents in one place. This process is >> repeatable using maven. >> IMO SVN does not have to mirror an unzipped release (there is no policy >> directing that, or if there is, please provide a link), as long as it is >> reproducible from the release tag. >> >> > > I have asked about this on the legal discuss list. > > Regardless of the outcome, I think that there are problems with > generating the NOTICE and LICENSE files automatically. Unless the > project is pure ASF, there are additional items that may need to be > added to the N & L files. In any case, I think it's important that > these files are carefully considered to ensure that the required > entries are present. This is difficult if not impossible if the > contents of the N & L files are automatically generated. > Just to be clear, in the case of UIMA, these files are *not* being generated (that is, their contents are not being generated) automatically. The only thing that is happening is that our automated build process for building the binary and source distributions from our SVN has a step which copies these files from where they reside in our SVN to the top level, as required in the distribution. > The N & L files are unlikely to change frequently, so it really does > not save much work (if any) to create them by hand. Having them in the > top-level SVN directory seems sensible to me. > The tools we use for development (Eclipse, mainly) like to have files in projects; we have adopted an organization where our SVN follows this convention. So, for us, it is more convenient to have these files in SVN inside one of our Eclipse projects, where we can then use the standard tooling for maintaining them. -Marshall > >> Martijn >> >> -- >> Buy Wicket in Action: http://manning.com/dashorst >> Apache Wicket 1.3.0-rc2 is released >> Get it now: http://www.apache.org/dyn/closer.cgi/wicket/1.3.0-rc1/ >> >> > > - > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > > > - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] Approve release Apache UIMA 2.2.1-incubating
On Dec 17, 2007 10:17 PM, sebb <[EMAIL PROTECTED]> wrote: > Regardless of the outcome, I think that there are problems with > generating the NOTICE and LICENSE files automatically. Unless the > project is pure ASF, there are additional items that may need to be > added to the N & L files. In any case, I think it's important that > these files are carefully considered to ensure that the required > entries are present. This is difficult if not impossible if the > contents of the N & L files are automatically generated. Generating those files based on some knowledge of the project is something that SHOULD be allowed. For instance, the Wicket project generates the root NOTICE file from sub projects' notice files inside the source tree. This generated file is distributed inside our tar balls and zip files. The same strategy can be applied to the license file. The reason being that dependencies are typically managed at a local level in a multi-module project. Administering the NOTICE and LICENSE files locally is more convenient and less likely to get out of date than putting everything in a central file by hand. (As an aside, Wicket does store the generated files in a separate release branch in the svn repo, but not in the root of trunk). The question is not about wether generating these files is good or not. It is whether svn MUST mirror the released artifact. In my opinion that is not the case: building the distribution should be reproducible based on the release tag. How projects implement that is their prerogative. As incubator we don't have to prescribe these minutiae, but provide oversight on actual distributed artifacts. These are the zips and tarballs our podlings provide. IMO dictating a release procedure is stepping across the boundaries of what a podling/project can evolve themselves. The N & L files are unlikely to change frequently, so it really does > not save much work (if any) to create them by hand. Having them in the > top-level SVN directory seems sensible to me. But sensible does not policy make: I find it sensible to use maven for building a release, but I wouldn't turn that into policy. Martijn -- Buy Wicket in Action: http://manning.com/dashorst Apache Wicket 1.3.0-rc2 is released Get it now: http://www.apache.org/dyn/closer.cgi/wicket/1.3.0-rc1/
Re: [VOTE] Move Project Yoko to Apache Geronimo and Apache CXF
Ant pinged me and gently reminded me there had been no response to his comment. My apologies for closing the vote before clearing this up. On Dec 13, 2007, at 3:42 AM, ant elder wrote: The proposal mentions continuing to allow for independent releases of the Yoko code that gets moved to Geronimo so is this going to be a new sub-project of Geronimo and if so then shouldn't this just be a simple graduation as a sub-project vote? ...ant I had sent a note to the Incubator PMC about the plan and hadn't received this as an option. I spect this is basically what we're doing except the code is going to two different places. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[RESULT][VOTE] Graduate FtpServer
On Wednesday 12 December 2007 18:53, Niclas Hedhman wrote: > Gang, > As the Mentor, I hereby call for a vote to graduate the FtpServer project. > > The MINA PMC has accepted FtpServer to become a subproject in the MINA > project. This vote has now run more than 72 hours, no negative votes, no abstains and 4 positive votes. I hereby declare FtpServer finally graduated from Incubator. I will proceed with updating the status file, and work with the MINA PMC and the FtpServer community to execute the move. Cheers -- Niclas Hedhman, Software Developer I live here; http://tinyurl.com/2qq9er I work here; http://tinyurl.com/2ymelc I relax here; http://tinyurl.com/2cgsug - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
