Re: CMS! Re: buildbot success in ASF Buildbot on incubator-site-staging
On 1 March 2012 20:44, Joe Schaefer joe_schae...@yahoo.com wrote: +1, thanks sebb! [Top -posting?] From: sebb seb...@gmail.com To: general@incubator.apache.org; Joe Schaefer joe_schae...@yahoo.com Sent: Thursday, March 1, 2012 3:42 PM Subject: Re: CMS! Re: buildbot success in ASF Buildbot on incubator-site-staging On 1 March 2012 14:39, Joe Schaefer joe_schae...@yahoo.com wrote: OK http://incubator.staging.apache.org/ is up. All we need to do at this point is migrate site-author/ to content/ and flip on svnpubsub for production. Any takers? OK, I'm happy to do the SVN and build.xml changes. Just to confirm what needs to be done: - rename site-author/ as content/ - fix up build.xml (and any other scripts that use site-author) - (test and) commit the changes Is that correct? I've done a search for site-author and it appears in the build and clutch scripts, as well in various documentation files. I suspect that many of the docn files will need more updating than just replacing site-author by content. I propose to leave the site-author references in files that need more than a simple replacement. This is because it will be easy to find the string site-author. - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
[SITE] site-author renamed to content
In preparation for moving the Incubator site to svnpubsub, the SVN source for the site, i.e. site-author/, has been renamed to content/ The site Ant build and clutch still work as before. - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: [ATTN] Incubator releases distribution area reminder!
On 27 February 2012 03:01, Daniel Shahaf d...@daniel.shahaf.name wrote: sebb wrote on Mon, Feb 27, 2012 at 02:17:15 +: On 26 February 2012 18:39, Daniel Shahaf d...@daniel.shahaf.name wrote: Andy Seaborne wrote on Sun, Feb 26, 2012 at 17:37:49 +: 3/ [[ Often symbolic links are created from the root of the project distribution directory to the latest version of each release. This allows scripts or users to easily locate the latest release. AIUI, this is a bad idea, because: - the links are frequently not updated - they don't work for mirrors, which means the mirrors space usage increases - when the file is downloaded using the link, the file name does not include the version information Users will normally get the latest release from the download page, so the only possible use is for scripts. ]] is at odds with http://www.apache.org/dev/mirror-step-by-step.html [[ 9. Do not use symbolic links in mirrored directories! ]] although that does say Note: This file contains out-of-date information. That refers to the suggestion to ssh www. But yeah, I can assure you that until a few weeks ago no one (PMC or podling) used symlinks in that matter, and even today there exists only one such link in the entire dist/ tree. Huh? The use of symlinks under /www/www.apache.org/dist is unfortunately still quite common. pwd dist : pwd /www/www.apache.org/dist pwd dist : find . -type l -name *current*.asc -ls | wc -l 77 deltacloud/stable is only symlink that cron complain about. (Feel free to compare it between archive and dist.) It's on root@'s todo list, somewhere, to make those complaints stop. deltacloud/stable is a softlink to a directory; there are several other such links, e.g. zookeeper/current zookeeper/stable I've no idea why deltacloud is the only such one that cron does not like. But this is straying away from the question about the use of symlinks. Why does the incubator document disagee with the dev/ document? Are symlinks disallowed/deprecated/allowed? Or perhaps only some types of links are allowed - e.g. README.html, KEYS, i.e. files that are not release-specific. The policy ought to be determined and documented properly, including the assumptions/reasoning behind the policy. - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: [VOTE] Release jena-tdb-0.9.0-incubating (RC-4)
On 26 February 2012 15:41, Andy Seaborne a...@apache.org wrote: sebb, What I'm trying to get to at the moment is something that enables a release of TDB and we can apply to next module. jena is a number of modules, we have released 3 (5 actually - 2 are the parent POM and the distribution maker for the core) already; TDB is the sixth, and there are 3 more in the pipeline. People have been asking for more packaging forms - WAR file for the server functionality, OSGi for Jena as a whole, which seems to be a non-trivial exercise. One of the ones to come is not a simple jar build - it's a server that can used as a jar, as a combined dependencies jar or run from the command line. I'm trying to understand the constraints required so that will be smooth(er). We are discussing rebuilding our build strategy but doing so, and to get it working reliably and stably will take time. We chose to release with what we have, and not let reworking the build system become critical path for graduation. The apache-jena-tdb... is then merely being a renamed file for browsing apache-jena-tdb-0.9.0-incubating-distribution.zip (c.f. Ant which has renamed items in it dist/ant) I referred to Ant specifically because the incubator documentation for podling releases picks ant and httpd out as examples to look at. ant has top level items for easy discovery which are renamed duplicates of things in binaries/ `-- source-release `-- jena-tdb-0.9.0-incubating What's the point of the subdirectory? because there are other modules with their own source-release artifact. The TDB release items will be merged into the existing directory. So why don't you do the same for the download directory? We had been following a layout like CXF where source-release and binaries are in the same directory. Given that is where a the maven-driven process puts them, someone taking the source releease doing mvn package is going to look in target/ and expect created items to be there. That was the RC-2 proposal for dist for TDB. If, as seems necessary, we have to adopt a different layout, we'll reorganise the existing release items into the same structure. Would a structure: dist |-- binaries | `-- jena-tdb-0.9.0-incubating | |-- jena-tdb-0.9.0-incubating-distribution.tar.gz | |-- jena-tdb-0.9.0-incubating-distribution.zip | |-- jena-tdb-0.9.0-incubating-javadoc.jar | |-- jena-tdb-0.9.0-incubating-sources.jar | |-- jena-tdb-0.9.0-incubating.jar The jars are not generally needed for dist/ |-- download | |-- apache-jena-tdb-0.9.0-incubating-distribution.tar.gz | |-- apache-jena-tdb-0.9.0-incubating-distribution.zip Are these the same as the distribution archives above? `-- source-release `-- jena-tdb-0.9.0-incubating What's the point of the subdirectory? |-- jena-tdb-0.9.0-incubating-source-release.zip Name does not agree with binary archives + the .asc, .md5 .sha1 files be acceptable? Or with download/ removed its files at the top level? I still find it very confusing. e.g. where is the source file for jena-tdb-0.9.0-incubating-distribution.tar.gz? Sorry, that was a mistake - I meant where is the source for the dowload file apache-jena-tdb-0.9.0-incubating-distribution.tar.gz jena-tdb-0.9.0-incubating-source-release.zip Not only is the name different, but also the archive type is different. That is very confusing. Given the way maven classifiers work, it is a reasonable expectation of the user to find the various classifier artifacts in target/ after mvn package Yes, but what has Maven to do with the self-contained release archives? Why is there a download directory and a binaries directory? Like ant, I pulled out the items which are download-unpack-go. The dist areas serves several audiences - for (new) users, not necessarily experienced maven users, we have the Jena website (we use Apache CMS to produce the website, not maven by the way) simply point to download/ (mirrored). Ditto URLs handled out on the web as being the place to go to download Jena. There should be no need to have Maven jars in the dist/ structure. I think this is just confusing to end-users. I don't mind if it's download/ or (like ant) at the top level. What I care about is that it is: - more difficult to find the source than some of the binaries, because of the extra directory level. - not at all clear how to find the source for some of the binaries, as it is at a different level and with a different name. - binaries are available as tar.gz and zip, but source only as zip Andy Mocked up at: http://people.apache.org/~andy/dist-tdb-proto/ See my mockups at: http://people.apache.org/~sebb/dist-tdb-proto/ one - parallel binaries/ and source/ two - single directory named after the release. The latter is likely to be easier to manage when moving to svnpubsub. $ ls -1R ./one: KEYS binaries
Re: [VOTE] RAT Ready To Graduate As Apache Creadur Top Level Project
On 26 February 2012 16:03, Robert Burrell Donkin rdon...@apache.org wrote: The graduation guide[1] recommends that the Rat community demonstrates it's willingness to govern itself through a free VOTE before asking the IPMC to approve graduation. So, here it is :-) See [2] for a draft of the charter, excluding the list of initial committers. Unless anyone jumps into this thread, I'll assume that the current list of committers would be fine. Please read, review and jump in - but this is a vote on the principle of graduating now. This VOTE is open to all, and I'll tally this no early than Wednesday, 29 Feb 2012 17:00 UTC. Robert --8--- [X] +1 the RAT community feels ready to graduate as Apache Creadur [ ] +0 [ ] -0 [ ] -1 Do not graduate RAT at this time --- [1] http://incubator.apache.org/guides/graduation.html#toplevel [2] Suggested Draft Charter: 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 Management Committee charged with the creation and maintenance of open-source software related to the comprehension and auditing of software distributions for distribution at no charge to the public. NOW, THEREFORE, BE IT RESOLVED, that a Project Management Committee (PMC), to be known as the Apache Creadur Project, be and hereby is established pursuant to Bylaws of the Foundation; and be it further RESOLVED, that the Apache Creadur Project be and hereby is responsible for the creation and maintenance of open-source software related to the comprehension and auditing of software distributions for distribution at no charge to the public RESOLVED, that the office of Vice President, Apache Creadur 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 Creadur Project, and to have primary responsibility for management of the projects within the scope of responsibility of the Apache Creadur Project; 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 Creadur Project: ... NOW, THEREFORE, BE IT FURTHER RESOLVED, that Robert Burrell Donkin be appointed to the office of Vice President, Apache Creadur, 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 initial Apache Creadur PMC be and hereby is tasked with the creation of a set of bylaws intended to encourage open development and increased participation in the Apache Creadur Project; and be it further RESOLVED, that the Apache Creadur Project be and hereby is tasked with the migration and rationalization of the Apache Incubator RAT podling; and be it further RESOLVED, that all responsibilities pertaining to the Apache Incubator RAT podling encumbered upon the Apache Incubator Project are hereafter discharged. - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: [ATTN] Incubator releases distribution area reminder!
On 26 February 2012 18:39, Daniel Shahaf d...@daniel.shahaf.name wrote: Andy Seaborne wrote on Sun, Feb 26, 2012 at 17:37:49 +: 3/ [[ Often symbolic links are created from the root of the project distribution directory to the latest version of each release. This allows scripts or users to easily locate the latest release. AIUI, this is a bad idea, because: - the links are frequently not updated - they don't work for mirrors, which means the mirrors space usage increases - when the file is downloaded using the link, the file name does not include the version information Users will normally get the latest release from the download page, so the only possible use is for scripts. ]] is at odds with http://www.apache.org/dev/mirror-step-by-step.html [[ 9. Do not use symbolic links in mirrored directories! ]] although that does say Note: This file contains out-of-date information. That refers to the suggestion to ssh www. But yeah, I can assure you that until a few weeks ago no one (PMC or podling) used symlinks in that matter, and even today there exists only one such link in the entire dist/ tree. Huh? The use of symlinks under /www/www.apache.org/dist is unfortunately still quite common. pwd dist : pwd /www/www.apache.org/dist pwd dist : find . -type l -name *current*.asc -ls | wc -l 77 - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: [VOTE] Release jena-tdb-0.9.0-incubating (RC-4)
On 24 February 2012 12:11, Andy Seaborne a...@apache.org wrote: We distribute through maven but also many of our users are not experienced developers but students, including ones new to java. To make it as easy as possible for this category of user, we ship a distribution which is the collection of jars needed for use without a maven/ivy infrastructure. That's fine, so long as the NL files agree with the contents. They should do. This is created in the maven target/ area - and it is then renamed into the dist/ area as apache-jena* by the distribution build script. Maven forces the name to be jena-tdb- on staging whatever assembly root name is given. Again that's OK, but the layout of the dist area - and the naming convention - is very confusing. There is no direct correspondance between the binary and source archives. It should be immediately obvious how to find the source and corresponding binary, but that's not the case at present. The directory structures align: /download/jena-tdb-0.9.0-incubating /source-release/jena-tdb-0.9.0-incubating I see the following files (amongst others) in the RC area http://people.apache.org/~andy/dist-jena-tdb-0.9.0-incubating-RC-4/ KEYS download/apache-jena-tdb-0.9.0-incubating.zip download//jena-tdb-0.9.0-incubating/jena-tdb-0.9.0-incubating.jar source-release/jena-tdb-0.9.0-incubating/jena-tdb-0.9.0-incubating-source-release.zip Note that the source release is in source-release/jena-tdb-0.9.0-incubating/ whereas the corresponding binary release is in download/ i.e. different depths - and they have different names. [I'm discounting the jar, since that is Maven-specific and is not needed on the dist/ mirror site.] but since this isn't /binaries and /sources we'll build about RC - we'll be back in a week to 10 day I hope. Does not have to be binaries and source (sic), so long as the source and binary archives are directly related. They have different names at present, which makes it difficult to tie them together. Also, the convention is to have the source and binary archives: - in the same directory, or - in parallel directories (binaries/source) In the case of OS-specific binaries, these could be in folders such as binaries/plan9 binaries/windows etc. In such cases, the binary archives would be one level lower than the source archive, but that is easy to follow. The scripts can all have AL headers; there are some XML files as well that could have them. I will put either short or full AL headers on the scripts. find . -name \*xml | xargs grep -L Licensed to the Apache Software Foundation | xargs wc -l 39 ./testing/Deployment/pom.xml 8 ./src/main/java/com/hp/hpl/jena/tdb/tdb-properties.xml 8 ./src/main/resources/org/apache/jena/tdb/tdb-properties.xml 55 total and tdb-properies.xml has 2 Java properties. Andy There is one Java file that has no AL header. 12 are NOTICE/LICENSE/DEPENDENCIES etc. These are OK and then there setting and eclipse files that you have commented on before. (aside: we tried autogenerating Eclipse files following previous comments but encountered problems with eclipse:eclipse which we are investigating) No need to autogenerate; just don't store them with the default names or paths. Perhaps store them under a resources/eclipse directory. Andy - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: [VOTE] Release jena-tdb-0.9.0-incubating (RC-4)
On 23 February 2012 15:50, Andy Seaborne a...@apache.org wrote: The Jena PPMC has voted to release Apache Jena TDB 0.9.0-incubating and we would now be grateful if members of IPMC would review and vote for this release. == Major changes since RC-2 + Distribution has it's own content for NOTICE/LICENSE files which rolls up information for the redistributed binaries. + jar file META-INF/NOTICE says Apache Jena - module TDB at the top. + source-release.zip does not contain a trunk/ copy. + New dist/ layout The existing released files will need to moved to this layout. The KEYS file is copied into the proposed dist/ area for clarity. == Project vote Result: http://mail-archives.apache.org/mod_mbox/incubator-jena-dev/201202.mbox/%3C4F4614CB.9010802%40apache.org%3E including 1 IPMC vote (Benson Margulies) Call for VOTE: http://mail-archives.apache.org/mod_mbox/incubator-jena-dev/201202.mbox/%3C4F40CE69.2080402%40apache.org%3E The following was noted in the jena-dev RC-4 vote: * The license information for Plugged-In software is in the distribution LICENSE file twice. == Staging repository https://repository.apache.org/content/repositories/orgapachejena-001/ This contains zip and tar.gz binary and source archives, which should be deleted as they are not useful to Maven. Direct link to TDB area in staging: http://s.apache.org/vcp == Proposed dist/ area: The following will be added to the existing distribution area: http://people.apache.org/~andy/dist-jena-tdb-0.9.0-incubating-RC-4/ Where is the source that corresponds to: download/apache-jena-tdb-0.9.0-incubating.zip It's not easy to find. And the reverse is just as hard. will be added to: http://www.apache.org/dist/incubator/jena/ Note: we will reorganise the current dist/ area to fit into this style of layout. Both those layouts are difficult to follow; it's not immediately obvious how to find the source for some of the binaries. This is partly because of the directory structure and partly because the source archive has a different naming convention from the binary archive. Some archives are prefixed apache-jena and some just jena. As already explained, the source and binary archives for each component should be at the same level. Either together in a directory, or in parallel source and binary directories. The latter is especially useful when there are OS-specific binaries. I would not expect to find any jars in the dist area, only zip and tar.gz, and if the binary archive has zip and tar.gz formats, so should the source archive. The dist area should also not contain maven-only POMs etc; these should be in the source archive only. == Keys https://svn.apache.org/repos/asf/incubator/jena/dist/KEYS == SVN tag The module is currently tagged with the version and -RC-4. If voted on successfully, the tag will be changed (svn mv) to the same but minus the RC labelling. https://svn.apache.org/repos/asf/incubator/jena/Jena2/TDB/tags/jena-tdb-0.9.0-incubating-RC-4/ There are a lot of source files without AL headers. These need to be fixed. Please vote on this release: [ ] +1 Approve the release of Apache Jena, module TDB 0.9.0-incubating [ ] -1 Don't release, because ... This vote will be open until: Sunday 26/February 23:59 UTC (72 hours from the same hour tonight). Andy - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: [VOTE] Release jena-tdb-0.9.0-incubating (RC-4)
On 23 February 2012 18:58, Mattmann, Chris A (388J) chris.a.mattm...@jpl.nasa.gov wrote: On Feb 23, 2012, at 11:32 AM, sebb wrote: On 23 February 2012 15:50, Andy Seaborne a...@apache.org wrote: The Jena PPMC has voted to release Apache Jena TDB 0.9.0-incubating and we would now be grateful if members of IPMC would review and vote for this release. == Major changes since RC-2 + Distribution has it's own content for NOTICE/LICENSE files which rolls up information for the redistributed binaries. + jar file META-INF/NOTICE says Apache Jena - module TDB at the top. + source-release.zip does not contain a trunk/ copy. + New dist/ layout The existing released files will need to moved to this layout. The KEYS file is copied into the proposed dist/ area for clarity. == Project vote Result: http://mail-archives.apache.org/mod_mbox/incubator-jena-dev/201202.mbox/%3C4F4614CB.9010802%40apache.org%3E including 1 IPMC vote (Benson Margulies) Call for VOTE: http://mail-archives.apache.org/mod_mbox/incubator-jena-dev/201202.mbox/%3C4F40CE69.2080402%40apache.org%3E The following was noted in the jena-dev RC-4 vote: * The license information for Plugged-In software is in the distribution LICENSE file twice. == Staging repository https://repository.apache.org/content/repositories/orgapachejena-001/ This contains zip and tar.gz binary and source archives, which should be deleted as they are not useful to Maven. On the contrary, they are plenty useful to Maven. They are used by its assembly plugin to allow for transitive dependencies and the ability to unpackage those distros as needed. Huh? Are you sure? Cheers, Chris ++ Chris Mattmann, Ph.D. Senior Computer Scientist NASA Jet Propulsion Laboratory Pasadena, CA 91109 USA Office: 171-266B, Mailstop: 171-246 Email: chris.a.mattm...@nasa.gov WWW: http://sunset.usc.edu/~mattmann/ ++ Adjunct Assistant Professor, Computer Science Department University of Southern California, Los Angeles, CA 90089 USA ++ - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: [VOTE] Release jena-tdb-0.9.0-incubating (RC-4)
On 23 February 2012 20:11, Damian Steer pl...@mac.com wrote: On 23 Feb 2012, at 18:32, sebb wrote: == Proposed dist/ area: The following will be added to the existing distribution area: http://people.apache.org/~andy/dist-jena-tdb-0.9.0-incubating-RC-4/ Where is the source that corresponds to: download/apache-jena-tdb-0.9.0-incubating.zip It's not easy to find. And the reverse is just as hard. I see only one file under source, and it seems to build everything found under dist. https://svn.apache.org/repos/asf/incubator/jena/Jena2/TDB/tags/jena-tdb-0.9.0-incubating-RC-4/ There are a lot of source files without AL headers. These need to be fixed. jena-tdb-0.9.0-incubating-RC-4 pldms$ ack -v -l 'Licensed to the Apache Software Foundation' . ... src-dev/dev/LongTermIssues.java ... Only one source file is missing this (plus a number of configuration files and shell scripts). Am I missing something obvious? (a: probably) All of those should have AL headers. Damian - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: [VOTE] Release jena-tdb-0.9.0-incubating (RC-4)
On 23 February 2012 19:42, Mattmann, Chris A (388J) chris.a.mattm...@jpl.nasa.gov wrote: Hi Sebb, On Feb 23, 2012, at 12:13 PM, sebb wrote: On the contrary, they are plenty useful to Maven. They are used by its assembly plugin to allow for transitive dependencies and the ability to unpackage those distros as needed. Huh? Are you sure? Yep, I'm not an expert, but we push tar.gz and .zip distributions in OODT, and then we have specialized assembly.xml descriptors in downstream OODT components that depend on the tarballs, and Maven will go and get them remotely. Paul Ramirez knows a ton about this in OODT: I've mainly just been a watcher of his Maven magic :) But, I do know they are useful, at least to us in OODT, and wanted to mention it. Sounds like that is specific to the way OODT does its resolution. Cheers, Chris ++ Chris Mattmann, Ph.D. Senior Computer Scientist NASA Jet Propulsion Laboratory Pasadena, CA 91109 USA Office: 171-266B, Mailstop: 171-246 Email: chris.a.mattm...@nasa.gov WWW: http://sunset.usc.edu/~mattmann/ ++ Adjunct Assistant Professor, Computer Science Department University of Southern California, Los Angeles, CA 90089 USA ++ - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: [VOTE] Release jena-tdb-0.9.0-incubating (RC-4)
On 23 February 2012 20:44, Andy Seaborne a...@apache.org wrote:
On 23/02/12 18:32, sebb wrote:
Hi sebb,
Thanks for the review,
== Staging repository
https://repository.apache.org/content/repositories/orgapachejena-001/
This contains zip and tar.gz binary and source archives, which should
be deleted as they are not useful to Maven.
There are two addition classifiers used: source-release and distribution.
To take the file jena-tdb-0.9.0-incubating-source-release.zip specifically,
this gets there because
mvn release:perform -Papache-release
puts it there. This seems to be the practice elsewhere as well:
e.g.
https://repository.apache.org/content/repositories/releases/org/apache/sling/org.apache.sling.engine/2.2.4/
For distribution:
We distribute through maven but also many of our users are not experienced
developers but students, including ones new to java.
To make it as easy as possible for this category of user, we ship a
distribution which is the collection of jars needed for use without a
maven/ivy infrastructure.
That's fine, so long as the NL files agree with the contents.
This is created in the maven target/ area - and it is then renamed into the
dist/ area as apache-jena* by the distribution build script. Maven forces
the name to be jena-tdb- on staging whatever assembly root name is
given.
Again that's OK, but the layout of the dist area - and the naming
convention - is very confusing.
There is no direct correspondance between the binary and source archives.
It should be immediately obvious how to find the source and
corresponding binary, but that's not the case at present.
== SVN tag
The module is currently tagged with the version and -RC-4. If voted
on
successfully, the tag will be changed (svn mv) to the same but minus
the
RC labelling.
https://svn.apache.org/repos/asf/incubator/jena/Jena2/TDB/tags/jena-tdb-0.9.0-incubating-RC-4/
There are a lot of source files without AL headers.
These need to be fixed.
Could you say which ones you mean?
Following the recent discussion on this (LEGAL-124), I thought the
conclusion was it wasn't necessary on short files with little or no
creativity or value.
The files in testing/ are short test files - we do put the ASF header on the
manifests.
e.g:
https://svn.apache.org/repos/asf/incubator/jena/Jena2/TDB/tags/jena-tdb-0.9.0-incubating-RC-4/testing/Pattern/pattern-1.rq
PREFIX : http://example/OTHER
SELECT *
{
:NoSuchNode ?p ?z .
?x ?p ?z
}
I found
A total of 118 files that do not contain th line
Licensed to the Apache Software Foundation (ASF) under
67 under testing/
25 are scripts
The scripts can all have AL headers; there are some XML files as well
that could have them.
There is one Java file that has no AL header.
12 are NOTICE/LICENSE/DEPENDENCIES etc.
These are OK
and then there setting and eclipse files that you have commented on before.
(aside: we tried autogenerating Eclipse files following previous comments
but encountered problems with eclipse:eclipse which we are investigating)
No need to autogenerate; just don't store them with the default names or paths.
Perhaps store them under a resources/eclipse directory.
Andy
-
To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
For additional commands, e-mail: general-h...@incubator.apache.org
-
To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
For additional commands, e-mail: general-h...@incubator.apache.org
Re: [VOTE] Release jena-tdb-0.9.0-incubating (RC-4)
On 23 February 2012 21:21, Mattmann, Chris A (388J) chris.a.mattm...@jpl.nasa.gov wrote: Hi Sebb, On Feb 23, 2012, at 1:15 PM, sebb wrote: Yep, I'm not an expert, but we push tar.gz and .zip distributions in OODT, and then we have specialized assembly.xml descriptors in downstream OODT components that depend on the tarballs, and Maven will go and get them remotely. Paul Ramirez knows a ton about this in OODT: I've mainly just been a watcher of his Maven magic :) But, I do know they are useful, at least to us in OODT, and wanted to mention it. Sounds like that is specific to the way OODT does its resolution. Well not really. It's the Maven assembly plugin and specific to it. I'm suprised that Maven - which normally handles dependency resolution very well - should rely on components packaging their dependencies for downstream components. It should be able to resolve the dependencies from the pom, and then fetch them directly from the repo, rather than having to unpack an archive. But this is getting seriously OT for this thread. Cheers, Chris ++ Chris Mattmann, Ph.D. Senior Computer Scientist NASA Jet Propulsion Laboratory Pasadena, CA 91109 USA Office: 171-266B, Mailstop: 171-246 Email: chris.a.mattm...@nasa.gov WWW: http://sunset.usc.edu/~mattmann/ ++ Adjunct Assistant Professor, Computer Science Department University of Southern California, Los Angeles, CA 90089 USA ++ - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: Incubator site modifcations question
On 21 February 2012 09:31, Emmanuel Lécharny elecha...@gmail.com wrote: Hi guys, yesterday I tried to update the incubator web site to reflect the renaming of the deft project to AWF. To some extent, it was successful : http://incubator.apache.org/projects/ points to AWF However, the main site at http://incubator.apache.org/ still refers to Deft. I committed site-publish and the modifed file, is there something else I have to update ? Yes, you have to login to minotaur and run: cd /www/incubator.apache.org svn update [This will not be necessary once svnpubsub is in place] Thanks ! -- Regards, Cordialement, Emmanuel Lécharny www.iktek.com - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
[Site] Migration to svnpubsub / CMS
I think the site source files and build.xml are now in good shape. The Ant build file can recreate the full output directory tree in any required directory: ant [-Ddocs.dest=target-dir] [default is site-publish] The source tree can also be overridden by using a command of the form: ant -Ddocs.src=content [although it might be best to change the default eventually] Is there anything else that needs to be done in order to fit in with the requirements of CMS? Do we need to rename site-author/ as content/ ? Or can CMS be told where to fetch the sources? I don't see the point of renaming site-author at present; if it has to be done it should be done as part of the switchover. - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: svn commit: r1244915 - /incubator/public/trunk/site-publish/.htaccess
On 21 February 2012 03:15, sebb seb...@gmail.com wrote: On 16 February 2012 10:12, franci...@apache.org wrote: Author: francisdb Date: Thu Feb 16 10:12:31 2012 New Revision: 1244915 URL: http://svn.apache.org/viewvc?rev=1244915view=rev Log: added redirect for empire-db Modified: incubator/public/trunk/site-publish/.htaccess That won't last - you need to update the source file in site-author and regenerate. PING - the last site rebuild overwrote your change. Modified: incubator/public/trunk/site-publish/.htaccess URL: http://svn.apache.org/viewvc/incubator/public/trunk/site-publish/.htaccess?rev=1244915r1=1244914r2=1244915view=diff == --- incubator/public/trunk/site-publish/.htaccess (original) +++ incubator/public/trunk/site-publish/.htaccess Thu Feb 16 10:12:31 2012 @@ -16,6 +16,7 @@ RedirectMatch Permanent ^/deltacloud(.*) RedirectMatch Permanent ^/derby(.*) http://db.apache.org/derby$1 RedirectMatch Permanent ^/directory(.*) http://directory.apache.org$1 RedirectMatch Permanent ^/esme(.*) http://esme.apache.org$1 +RedirectMatch Permanent ^/empire-db(.*) http://empire-db.apache.org$1 RedirectMatch Permanent ^/felix(.*) http://felix.apache.org$1 RedirectMatch Permanent ^/ftpserver(.*) http://mina.apache.org/ftpserver$1 RedirectMatch Permanent ^/geronimo(.*) http://geronimo.apache.org$1 - To unsubscribe, e-mail: cvs-unsubscr...@incubator.apache.org For additional commands, e-mail: cvs-h...@incubator.apache.org - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
[jira] [Commented] (INCUBATOR-120) Are the following files still needed in site-publish?
[ https://issues.apache.org/jira/browse/INCUBATOR-120?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13212303#comment-13212303 ] Sebb commented on INCUBATOR-120: altrmi files dropped as per INCUBATOR-118 Are the following files still needed in site-publish? - Key: INCUBATOR-120 URL: https://issues.apache.org/jira/browse/INCUBATOR-120 Project: Incubator Issue Type: Bug Components: site Reporter: Sebb Priority: Blocker [This is listed as a blocker because it's not possible to move to svnpubsub/CMS until resolved.] The following files in site-publish have no sources in site-author: The entire tree under: site-publish/projects/altrmi/ Looks like it should be deleted, as the project has gone away. Also the following individual files have no means to recreate them: ! 1243649 site-publish\projects\geronimo\status.html ! 1243649 site-publish\projects\geronimo\status.pdf ! 1243649 site-publish\projects\lcf.html ! 1243649 site-publish\projects\geronimo-proposal.html ! 1243649 site-publish\projects\ruper.html -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
[jira] [Resolved] (INCUBATOR-118) Are the altrmi files still needed? If so, should they be moved elsewhere?
[ https://issues.apache.org/jira/browse/INCUBATOR-118?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sebb resolved INCUBATOR-118. Resolution: Fixed Removed altrmi files Are the altrmi files still needed? If so, should they be moved elsewhere? - Key: INCUBATOR-118 URL: https://issues.apache.org/jira/browse/INCUBATOR-118 Project: Incubator Issue Type: Bug Components: site Reporter: Sebb There is a large directory tree in the Incubator-public SVN containing the site for the podling AltRMI which is no longer with the ASF. See http://svn.apache.org/repos/asf/incubator/public/trunk/site-publish/projects/altrmi and http://incubator.apache.org/projects/altrmi/ Seems to me the only AltRMI file we should keep is the podling status, i.e. http://incubator.apache.org/projects/altrmi.html However, if the files are still to be kept, do they really belong on the Incubator public website? Would it not be more appropriate to store them elsewhere and make them read-only? -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: migrating the main site to the CMS- a simple approach
On 15 February 2012 15:44, Jukka Zitting jukka.zitt...@gmail.com wrote: Hi, On Wed, Feb 15, 2012 at 1:59 AM, sebb seb...@gmail.com wrote: The first thing to do is to decide if the following directory tree can be junked: site-publish/projects/altrmi/ I suspect it can, as altrmi has moved elsewhere, but I just want to check it's not being kept for historical reasons. +1 to removing. We still have the content archived in svn history. Done The other files currently only in site-publish are: ! 1243649 site-publish\projects\geronimo\status.html ! 1243649 site-publish\projects\geronimo\status.pdf Remove. Geronimo status is at /projects/geronimo.html. Done ! 1243649 site-publish\projects\lcf.html Remove. LCF renamed itself to ManifoldCF, and its status is now at /projects/manifoldcf.html. Done ! 1243649 site-publish\projects\geronimo-proposal.html Keep. It should be linked to from the proposal list on the Incubator wiki, or perhaps migrated entirely into the wiki (or at least to a better place in site-author). Not sure why that file was flagged as a problem by my testing - there is a source file for it under site-author. ! 1243649 site-publish\projects\ruper.html Remove. AFAICT, Ruper renamed itself to Depot, and its status is now at /projects/depot.html. Done. BR, Jukka Zitting - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
[jira] [Resolved] (INCUBATOR-120) Are the following files still needed in site-publish?
[ https://issues.apache.org/jira/browse/INCUBATOR-120?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sebb resolved INCUBATOR-120. Resolution: Fixed Are the following files still needed in site-publish? - Key: INCUBATOR-120 URL: https://issues.apache.org/jira/browse/INCUBATOR-120 Project: Incubator Issue Type: Bug Components: site Reporter: Sebb Priority: Blocker [This is listed as a blocker because it's not possible to move to svnpubsub/CMS until resolved.] The following files in site-publish have no sources in site-author: The entire tree under: site-publish/projects/altrmi/ Looks like it should be deleted, as the project has gone away. Also the following individual files have no means to recreate them: ! 1243649 site-publish\projects\geronimo\status.html ! 1243649 site-publish\projects\geronimo\status.pdf ! 1243649 site-publish\projects\lcf.html ! 1243649 site-publish\projects\geronimo-proposal.html ! 1243649 site-publish\projects\ruper.html -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
[jira] [Commented] (INCUBATOR-120) Are the following files still needed in site-publish?
[ https://issues.apache.org/jira/browse/INCUBATOR-120?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13212311#comment-13212311 ] Sebb commented on INCUBATOR-120: site-publish\projects\geronimo-proposal.html does have a source file at site-author\projects\geronimo-proposal.xml and is to be kept. Other files deleted as per http://mail-archives.apache.org/mod_mbox/incubator-general/201202.mbox/%3CCAOFYJNYOhw61D9brp3Oozj6M9b2hektDMJKsPu28yJWw47QJqw%40mail.gmail.com%3E Are the following files still needed in site-publish? - Key: INCUBATOR-120 URL: https://issues.apache.org/jira/browse/INCUBATOR-120 Project: Incubator Issue Type: Bug Components: site Reporter: Sebb Priority: Blocker [This is listed as a blocker because it's not possible to move to svnpubsub/CMS until resolved.] The following files in site-publish have no sources in site-author: The entire tree under: site-publish/projects/altrmi/ Looks like it should be deleted, as the project has gone away. Also the following individual files have no means to recreate them: ! 1243649 site-publish\projects\geronimo\status.html ! 1243649 site-publish\projects\geronimo\status.pdf ! 1243649 site-publish\projects\lcf.html ! 1243649 site-publish\projects\geronimo-proposal.html ! 1243649 site-publish\projects\ruper.html -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: [VOTE] Release Apache Hama 0.4-incubating RC6
On 20 February 2012 13:54, Edward J. Yoon edwardy...@apache.org wrote: Hi, I've create RC6 for the Apache Hama 0.4-incubating release. This fixes the license header issue and adds rat-plugin. Signing KEYS: http://svn.apache.org/repos/asf/incubator/hama/trunk/src/site/resources/files/KEYS Artifacts: http://people.apache.org/~edwardyoon/dist/0.4-RC6/ There are no hashes (MD5 or SHA1). AIUI these are required. No need to respin the release, but please create the hashes. Tag: http://svn.apache.org/repos/asf/incubator/hama/tags/0.4-RC6/ NOTICE.txt: http://svn.apache.org/repos/asf/incubator/hama/tags/0.4-RC6/NOTICE.txt LICENSE.txt: http://svn.apache.org/repos/asf/incubator/hama/tags/0.4-RC6/LICENSE.txt Staging website: http://people.apache.org/~edwardyoon/site/ You can run the mvn apache-rat:check command to check for license headers. I tested this RC6 builds, single mode, and distributed mode on my 16 nodes cluster and 5 VMs with EC2. Please retry, check signatures, licenses, and vote! I hope this will be a final, and +1. Thanks. -- Best Regards, Edward J. Yoon @eddieyoon - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
[jira] [Resolved] (INCUBATOR-119) site-publish/ip-clearance/lucene-kuromoji.html does not seem to build correctly
[ https://issues.apache.org/jira/browse/INCUBATOR-119?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sebb resolved INCUBATOR-119. Resolution: Fixed Caused by the fixEOL step; fixed by adding encoding=UTF-8 site-publish/ip-clearance/lucene-kuromoji.html does not seem to build correctly --- Key: INCUBATOR-119 URL: https://issues.apache.org/jira/browse/INCUBATOR-119 Project: Incubator Issue Type: Bug Components: site Environment: WinXP/SP3 Apache Ant(TM) version 1.8.2 compiled on December 20 2010 Reporter: Sebb Priority: Minor If I delete the file site-publish/ip-clearance/lucene-kuromoji.html and rebuild the site, the generated file has differences from the original. Looks like there might be an encoding issue to sort out. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: svn commit: r1244240 - /incubator/public/trunk/build_cms.sh
On 15 February 2012 13:15, Joe Schaefer joe_schae...@yahoo.com wrote: - Original Message - From: sebb seb...@gmail.com To: Joe Schaefer joe_schae...@yahoo.com Cc: general@incubator.apache.org general@incubator.apache.org Sent: Wednesday, February 15, 2012 5:59 AM Subject: Re: svn commit: r1244240 - /incubator/public/trunk/build_cms.sh On 15 February 2012 02:18, Joe Schaefer joe_schae...@yahoo.com wrote: - Original Message - From: sebb seb...@gmail.com To: Joe Schaefer joe_schae...@yahoo.com Cc: general@incubator.apache.org general@incubator.apache.org Sent: Tuesday, February 14, 2012 9:11 PM Subject: Re: svn commit: r1244240 - /incubator/public/trunk/build_cms.sh On 15 February 2012 01:49, Joe Schaefer joe_schae...@yahoo.com wrote: - Original Message - From: sebb seb...@gmail.com To: general@incubator.apache.org; Joe Schaefer joe_schae...@yahoo.com Cc: Sent: Tuesday, February 14, 2012 8:40 PM Subject: Re: svn commit: r1244240 - /incubator/public/trunk/build_cms.sh On 15 February 2012 01:30, Joe Schaefer joe_schae...@yahoo.com wrote: The documentation is in the caller script sebb. Yes, but how can one find the calling script from the build script? If you have problems with the level of detail provided in the script comments, please feel free to add your own commentary. BTW, if the script is run at the moment, it will cause problems. Well with svn 1.7 those problems have been outlined elsethread. Hopefully we will have those resolved by the time the cms host is upgraded. I meant that until snvpubsub is implemented, running the script will cause problems, as it starts by deleting part of the workspace I've just realised that it may also cause problems for the Ant build, as I don't think that expects to create any missing directories. The script should probably just delete files. I sure hope not. There is no good reason to expose this level of site structure micromangement to build system users. If ant doesn't know how to recreate the site starting from an empty site-publish dir, let's move the conversation to dev@ant to try and fix ant. It's the build script that will need fixing (if necessary), not Ant itself. It may be OK already; it may not. It only takes about a minute to test this sebb, could you please look into this? All you have to do to restore your working copy is to nuke the publish-site tree again post-build and run svn up, even with svn 1.6, so really it's no big deal to try it out and see. Seems to be OK. Can also use docs.dest to redirect the output: ant -Ddocs.dest=target - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: svn commit: r1244915 - /incubator/public/trunk/site-publish/.htaccess
On 16 February 2012 10:12, franci...@apache.org wrote: Author: francisdb Date: Thu Feb 16 10:12:31 2012 New Revision: 1244915 URL: http://svn.apache.org/viewvc?rev=1244915view=rev Log: added redirect for empire-db Modified: incubator/public/trunk/site-publish/.htaccess That won't last - you need to update the source file in site-author and regenerate. Modified: incubator/public/trunk/site-publish/.htaccess URL: http://svn.apache.org/viewvc/incubator/public/trunk/site-publish/.htaccess?rev=1244915r1=1244914r2=1244915view=diff == --- incubator/public/trunk/site-publish/.htaccess (original) +++ incubator/public/trunk/site-publish/.htaccess Thu Feb 16 10:12:31 2012 @@ -16,6 +16,7 @@ RedirectMatch Permanent ^/deltacloud(.*) RedirectMatch Permanent ^/derby(.*) http://db.apache.org/derby$1 RedirectMatch Permanent ^/directory(.*) http://directory.apache.org$1 RedirectMatch Permanent ^/esme(.*) http://esme.apache.org$1 +RedirectMatch Permanent ^/empire-db(.*) http://empire-db.apache.org$1 RedirectMatch Permanent ^/felix(.*) http://felix.apache.org$1 RedirectMatch Permanent ^/ftpserver(.*) http://mina.apache.org/ftpserver$1 RedirectMatch Permanent ^/geronimo(.*) http://geronimo.apache.org$1 - To unsubscribe, e-mail: cvs-unsubscr...@incubator.apache.org For additional commands, e-mail: cvs-h...@incubator.apache.org - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: migrating the main site to the CMS- a simple approach
On 21 February 2012 02:31, sebb seb...@gmail.com wrote: On 15 February 2012 15:44, Jukka Zitting jukka.zitt...@gmail.com wrote: Hi, On Wed, Feb 15, 2012 at 1:59 AM, sebb seb...@gmail.com wrote: The first thing to do is to decide if the following directory tree can be junked: site-publish/projects/altrmi/ I suspect it can, as altrmi has moved elsewhere, but I just want to check it's not being kept for historical reasons. +1 to removing. We still have the content archived in svn history. Done The other files currently only in site-publish are: ! 1243649 site-publish\projects\geronimo\status.html ! 1243649 site-publish\projects\geronimo\status.pdf Remove. Geronimo status is at /projects/geronimo.html. Done ! 1243649 site-publish\projects\lcf.html Remove. LCF renamed itself to ManifoldCF, and its status is now at /projects/manifoldcf.html. Done ! 1243649 site-publish\projects\geronimo-proposal.html Keep. It should be linked to from the proposal list on the Incubator wiki, or perhaps migrated entirely into the wiki (or at least to a better place in site-author). Not sure why that file was flagged as a problem by my testing - there is a source file for it under site-author. Discovered the problem. There are two such html files, but only one source: site-author\projects\geronimo\geronimo-proposal.xml site-publish\projects\geronimo-proposal.html site-publish\projects\geronimo\geronimo-proposal.html It looks like the middle file was created a long time ago, and then the xml file was moved. So I will delete the middle file. ! 1243649 site-publish\projects\ruper.html Remove. AFAICT, Ruper renamed itself to Depot, and its status is now at /projects/depot.html. Done. BR, Jukka Zitting - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: svn commit: r1291363 - /incubator/public/trunk/site-author/projects/isis.xml
On 20 February 2012 16:52, danhayw...@apache.org wrote: Author: danhaywood Date: Mon Feb 20 16:52:18 2012 New Revision: 1291363 URL: http://svn.apache.org/viewvc?rev=1291363view=rev Log: Updating Isis project summary after 0.2.0-incubating release Modified: incubator/public/trunk/site-author/projects/isis.xml Next time please regenerate the site and commit the updated html version of the file. Modified: incubator/public/trunk/site-author/projects/isis.xml URL: http://svn.apache.org/viewvc/incubator/public/trunk/site-author/projects/isis.xml?rev=1291363r1=1291362r2=1291363view=diff == --- incubator/public/trunk/site-author/projects/isis.xml [utf-8] (original) +++ incubator/public/trunk/site-author/projects/isis.xml [utf-8] Mon Feb 20 16:52:18 2012 @@ -26,9 +26,9 @@ titleNews/title ul - li2010-09-07 Isis has been accepted to enter incubation/li - + li2012-02-20 Released version 0.2.0-incubating/li li2011-07-14 Released version 0.1.2-incubating/li + li2010-09-07 Isis has been accepted to enter incubation/li /ul /section @@ -274,20 +274,20 @@ ul li - a href=http://wiki.apache.org/incubator/October2010#Isis;October - 2010/a + a + href=http://wiki.apache.org/incubator/December2011#Isis;December + 2011/a /li li a - href=http://wiki.apache.org/incubator/November2010#Isis;November - 2010/a + href=http://wiki.apache.org/incubator/September2011#Isis;September + 2011/a /li li - a - href=http://wiki.apache.org/incubator/December2010#Isis;December - 2010/a + a href=http://wiki.apache.org/incubator/June2011#Isis;June + 2011/a /li li @@ -296,20 +296,20 @@ /li li - a href=http://wiki.apache.org/incubator/June2011#Isis;June - 2011/a + a + href=http://wiki.apache.org/incubator/December2010#Isis;December + 2010/a /li li a - href=http://wiki.apache.org/incubator/September2011#Isis;September - 2011/a + href=http://wiki.apache.org/incubator/November2010#Isis;November + 2010/a /li li - a - href=http://wiki.apache.org/incubator/December2011#Isis;December - 2011/a + a href=http://wiki.apache.org/incubator/October2010#Isis;October + 2010/a /li /ul /section - To unsubscribe, e-mail: cvs-unsubscr...@incubator.apache.org For additional commands, e-mail: cvs-h...@incubator.apache.org - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: svn commit: r1291238 - in /incubator/public/trunk/site-publish: index.html projects/awf.html projects/index.html
On 20 February 2012 13:07, elecha...@apache.org wrote: Author: elecharny Date: Mon Feb 20 13:07:13 2012 New Revision: 1291238 URL: http://svn.apache.org/viewvc?rev=1291238view=rev Log: Updated the site to reflect the deft-awf renaming Added: incubator/public/trunk/site-publish/projects/awf.html Next time, please set eol-style:native on new files. Modified: incubator/public/trunk/site-publish/index.html incubator/public/trunk/site-publish/projects/index.html - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
[jira] [Created] (INCUBATOR-119) site-publish/ip-clearance/lucene-kuromoji.html does not seem to build correctly
site-publish/ip-clearance/lucene-kuromoji.html does not seem to build correctly --- Key: INCUBATOR-119 URL: https://issues.apache.org/jira/browse/INCUBATOR-119 Project: Incubator Issue Type: Bug Components: site Environment: WinXP/SP3 Apache Ant(TM) version 1.8.2 compiled on December 20 2010 Reporter: Sebb Priority: Minor If I delete the file site-publish/ip-clearance/lucene-kuromoji.html and rebuild the site, the generated file has differences from the original. Looks like there might be an encoding issue to sort out. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: svn commit: r1244240 - /incubator/public/trunk/build_cms.sh
On 15 February 2012 02:18, Joe Schaefer joe_schae...@yahoo.com wrote: - Original Message - From: sebb seb...@gmail.com To: Joe Schaefer joe_schae...@yahoo.com Cc: general@incubator.apache.org general@incubator.apache.org Sent: Tuesday, February 14, 2012 9:11 PM Subject: Re: svn commit: r1244240 - /incubator/public/trunk/build_cms.sh On 15 February 2012 01:49, Joe Schaefer joe_schae...@yahoo.com wrote: - Original Message - From: sebb seb...@gmail.com To: general@incubator.apache.org; Joe Schaefer joe_schae...@yahoo.com Cc: Sent: Tuesday, February 14, 2012 8:40 PM Subject: Re: svn commit: r1244240 - /incubator/public/trunk/build_cms.sh On 15 February 2012 01:30, Joe Schaefer joe_schae...@yahoo.com wrote: The documentation is in the caller script sebb. Yes, but how can one find the calling script from the build script? If you have problems with the level of detail provided in the script comments, please feel free to add your own commentary. BTW, if the script is run at the moment, it will cause problems. Well with svn 1.7 those problems have been outlined elsethread. Hopefully we will have those resolved by the time the cms host is upgraded. I meant that until snvpubsub is implemented, running the script will cause problems, as it starts by deleting part of the workspace I've just realised that it may also cause problems for the Ant build, as I don't think that expects to create any missing directories. The script should probably just delete files. I sure hope not. There is no good reason to expose this level of site structure micromangement to build system users. If ant doesn't know how to recreate the site starting from an empty site-publish dir, let's move the conversation to dev@ant to try and fix ant. It's the build script that will need fixing (if necessary), not Ant itself. It may be OK already; it may not. - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
[jira] [Created] (INCUBATOR-120) Are the following files still needed in site-publish?
Are the following files still needed in site-publish? - Key: INCUBATOR-120 URL: https://issues.apache.org/jira/browse/INCUBATOR-120 Project: Incubator Issue Type: Bug Components: site Reporter: Sebb Priority: Blocker [This is listed as a blocker because it's not possible to move to svnpubsub/CMS until resolved.] The following files in site-publish have no sources in site-author: The entire tree under: site-publish/projects/altrmi/ Looks like it should be deleted, as the project has gone away. Also the following individual files have no means to recreate them: ! 1243649 site-publish\projects\geronimo\status.html ! 1243649 site-publish\projects\geronimo\status.pdf ! 1243649 site-publish\projects\lcf.html ! 1243649 site-publish\projects\geronimo-proposal.html ! 1243649 site-publish\projects\ruper.html -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: [RESULT][VOTE] Release Sqoop version 1.4.1-incubating
On 15 February 2012 07:42, Roman Shaposhnik r...@apache.org wrote: Hi! On Tue, Feb 14, 2012 at 11:31 PM, Jarek Jarcec Cecho jar...@apache.org wrote: Hi Roman, we're definitely open to embrace any Apache policy for naming files. Can you point me to some written docs? AFAIK, it would be fair to say that Apache, in general, is all about source releases. The binary artifacts are simply convenience artifacts and thus it makes sense that the default tarballs are source tarballs. I'm not sure I can quote chapter and verse, my experience comes from doing Apache Bigtop Project which is an integration point between at least a dozen different Apache projects. When I pulled your RC into Bigtop the other day it was the only project that I had to modify my scripts for. Everything else follows the most default naming convention. There are certainly other naming conventions in common usage. AIUI, by default Maven appends -bin and -src to archives (not jars). However projects may drop the -bin and keep the -src (e.g. Commons) Also Tomcat (though that does not use Maven to build). Have a look at some of the other projects under the dist/ tree. There is a different naming convention for the jars which are intended for upload to Maven repositories. In that case, the binary jar cannot have a suffix; -source and -javadoc are used for the obvious purposes. Hope this helps. Thanks, Roman. - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: migrating the main site to the CMS- a simple approach
On 14 February 2012 16:21, Joe Schaefer joe_schae...@yahoo.com wrote: So I realize that I don't have enough time myself to convert the incubator site's content to markdown even tho there are scripts to automate that process. Instead let me offer a different idea- to keep the existing build system but superimpose the CMS on top of it. To facilitate this, all that needs to happen is for someone to find a generic way of invoking anakia so it satisfies the command-line interface of https://svn.apache.org/repos/infra/websites/cms/build/build_external.pl (ie builds sources from ./content/ into a specified target dir). That's not actually sufficient to build the main Incubator site, because it does not take the Clutch updates into account. However, I guess Clutch could be run separately to update the source files, and then trigger a site rebuild. By generic, I mean a suitable command-line invocation for the build_external.pl script for the anakia type (basically supplying the right @system_args in the script) so that pretty much any site currently using anakia will be able to do the same thing. Hopefully the challenge to produce such @system_args is within the means of this community ;-)- it amounts to 1 line of perl at this point. - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: migrating the main site to the CMS- a simple approach
On 14 February 2012 17:08, Joe Schaefer joe_schae...@yahoo.com wrote: - Original Message - From: Joe Schaefer joe_schae...@yahoo.com To: general@incubator.apache.org general@incubator.apache.org Cc: Sent: Tuesday, February 14, 2012 12:04 PM Subject: Re: migrating the main site to the CMS- a simple approach From: sebb seb...@gmail.com To: general@incubator.apache.org Sent: Tuesday, February 14, 2012 11:57 AM Subject: Re: migrating the main site to the CMS- a simple approach On 14 February 2012 16:21, Joe Schaefer joe_schae...@yahoo.com wrote: So I realize that I don't have enough time myself to convert the incubator site's content to markdown even tho there are scripts to automate that process. Instead let me offer a different idea- to keep the existing build system but superimpose the CMS on top of it. To facilitate this, all that needs to happen is for someone to find a generic way of invoking anakia so it satisfies the command-line interface of https://svn.apache.org/repos/infra/websites/cms/build/build_external.pl (ie builds sources from ./content/ into a specified target dir). That's not actually sufficient to build the main Incubator site, because it does not take the Clutch updates into account. However, I guess Clutch could be run separately to update the source files, and then trigger a site rebuild. Alternately, if the clutch builds simply modify source content, Yes, that's all it does. that aspect can be performed manually and the build system will generate that content from the changes to the source content. All someone would have to do in addition to what they already already do now is publish the changes to the live site. However, the site build does a lot more than just run Anakia. It also runs XSLT and texen; each is run several times with different data. There are some other stages as well. This is all done by Ant, using the build.xml from the top-level directory. I suspect this is also true of a lot of other sites which use Anakia. Ideally the Clutch updates can be considered as dynamic content for the CMS, so we can simply schedule clutch builds on a periodic basis. That is done separately from the generic process of doing anakia builds. By generic, I mean a suitable command-line invocation for the build_external.pl script for the anakia type (basically supplying the right @system_args in the script) so that pretty much any site currently using anakia will be able to do the same thing. Hopefully the challenge to produce such @system_args is within the means of this community ;-)- it amounts to 1 line of perl at this point. - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: migrating the main site to the CMS- a simple approach
On 14 February 2012 18:09, Joe Schaefer joe_schae...@yahoo.com wrote: - Original Message - From: sebb seb...@gmail.com To: general@incubator.apache.org; Joe Schaefer joe_schae...@yahoo.com Cc: Sent: Tuesday, February 14, 2012 1:04 PM Subject: Re: migrating the main site to the CMS- a simple approach On 14 February 2012 17:08, Joe Schaefer joe_schae...@yahoo.com wrote: - Original Message - From: Joe Schaefer joe_schae...@yahoo.com To: general@incubator.apache.org general@incubator.apache.org Cc: Sent: Tuesday, February 14, 2012 12:04 PM Subject: Re: migrating the main site to the CMS- a simple approach From: sebb seb...@gmail.com To: general@incubator.apache.org Sent: Tuesday, February 14, 2012 11:57 AM Subject: Re: migrating the main site to the CMS- a simple approach On 14 February 2012 16:21, Joe Schaefer joe_schae...@yahoo.com wrote: So I realize that I don't have enough time myself to convert the incubator site's content to markdown even tho there are scripts to automate that process. Instead let me offer a different idea- to keep the existing build system but superimpose the CMS on top of it. To facilitate this, all that needs to happen is for someone to find a generic way of invoking anakia so it satisfies the command-line interface of https://svn.apache.org/repos/infra/websites/cms/build/build_external.pl (ie builds sources from ./content/ into a specified target dir). That's not actually sufficient to build the main Incubator site, because it does not take the Clutch updates into account. However, I guess Clutch could be run separately to update the source files, and then trigger a site rebuild. Alternately, if the clutch builds simply modify source content, Yes, that's all it does. that aspect can be performed manually and the build system will generate that content from the changes to the source content. All someone would have to do in addition to what they already already do now is publish the changes to the live site. However, the site build does a lot more than just run Anakia. It also runs XSLT and texen; each is run several times with different data. There are some other stages as well. This is all done by Ant, using the build.xml from the top-level directory. I suspect this is also true of a lot of other sites which use Anakia. Well whatever- we can change the build type from anakia to ant. That's no big deal. All we need at this point for CMS support is: 1) to change the name of the directory holding the site sources to content, The sources are held under: https://svn.apache.org/repos/asf/incubator/public/trunk/site-author However, there are support files in other directories, in particular the lib/ directory. 2) to figure out what command-line arguments to pass to ant or to build.sh or whatever to tell it to build to a specified target directory also named content but with a different base directory. The output currently goes to https://svn.apache.org/repos/asf/incubator/public/trunk/site-publish. I think most files under site-publish are derived from site-author; however there are probably some that are only in site-publish. For example, .htaccess seems to be only in site-publish. Probably the first task is to ensure that all site-publish files are derivable from site-author. Can then rename the input directory, and fix up the build file. Changing the output directory would be a bit more involved as it is used for the workspace on minotaur. Would it be possible to switch to the eventual svnpubsub target without actually switching to CMS yet? Could then switch the workspace on minotaur to use the new content output directory. Once that's working, then CMS could be plugged in. - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: migrating the main site to the CMS- a simple approach
On 14 February 2012 22:47, Joe Schaefer joe_schae...@yahoo.com wrote: - Original Message - From: Joe Schaefer joe_schae...@yahoo.com To: sebb seb...@gmail.com; general@incubator.apache.org general@incubator.apache.org Cc: Sent: Tuesday, February 14, 2012 1:47 PM Subject: Re: migrating the main site to the CMS- a simple approach - Original Message - From: sebb seb...@gmail.com To: general@incubator.apache.org; Joe Schaefer joe_schae...@yahoo.com Cc: Sent: Tuesday, February 14, 2012 1:36 PM Subject: Re: migrating the main site to the CMS- a simple approach On 14 February 2012 18:09, Joe Schaefer joe_schae...@yahoo.com wrote: - Original Message - From: sebb seb...@gmail.com To: general@incubator.apache.org; Joe Schaefer joe_schae...@yahoo.com Cc: Sent: Tuesday, February 14, 2012 1:04 PM Subject: Re: migrating the main site to the CMS- a simple approach On 14 February 2012 17:08, Joe Schaefer joe_schae...@yahoo.com wrote: - Original Message - From: Joe Schaefer joe_schae...@yahoo.com To: general@incubator.apache.org general@incubator.apache.org Cc: Sent: Tuesday, February 14, 2012 12:04 PM Subject: Re: migrating the main site to the CMS- a simple approach From: sebb seb...@gmail.com To: general@incubator.apache.org Sent: Tuesday, February 14, 2012 11:57 AM Subject: Re: migrating the main site to the CMS- a simple approach On 14 February 2012 16:21, Joe Schaefer joe_schae...@yahoo.com wrote: So I realize that I don't have enough time myself to convert the incubator site's content to markdown even tho there are scripts to automate that process. Instead let me offer a different idea- to keep the existing build system but superimpose the CMS on top of it. To facilitate this, all that needs to happen is for someone to find a generic way of invoking anakia so it satisfies the command-line interface of https://svn.apache.org/repos/infra/websites/cms/build/build_external.pl (ie builds sources from ./content/ into a specified target dir). That's not actually sufficient to build the main Incubator site, because it does not take the Clutch updates into account. However, I guess Clutch could be run separately to update the source files, and then trigger a site rebuild. Alternately, if the clutch builds simply modify source content, Yes, that's all it does. that aspect can be performed manually and the build system will generate that content from the changes to the source content. All someone would have to do in addition to what they already already do now is publish the changes to the live site. However, the site build does a lot more than just run Anakia. It also runs XSLT and texen; each is run several times with different data. There are some other stages as well. This is all done by Ant, using the build.xml from the top-level directory. I suspect this is also true of a lot of other sites which use Anakia. Well whatever- we can change the build type from anakia to ant. That's no big deal. All we need at this point for CMS support is: 1) to change the name of the directory holding the site sources to content, The sources are held under: https://svn.apache.org/repos/asf/incubator/public/trunk/site-author So rename site-author to content. That'd be step 1 precisely. However, there are support files in other directories, in particular the lib/ directory. That has no material impact on what I'm proposing: just leave those where they are. 2) to figure out what command-line arguments to pass to ant or to build.sh or whatever to tell it to build to a specified target directory also named content but with a different base directory. The output currently goes to https://svn.apache.org/repos/asf/incubator/public/trunk/site-publish. I think most files under site-publish are derived from site-author; however there are probably some that are only in site-publish. For example, .htaccess seems to be only in site-publish. Well that would need to go into the content dir and ant would need to copy it over to the target content dir. Probably the first task is to ensure that all site-publish files are derivable from site-author. Yes. Can then rename the input directory, and fix up the build file. Changing the output directory would be a bit more involved as it is used for the workspace on minotaur. Well can't we make this configurable? I mean cmon it's 2012, surely we can pass some argument to build.sh that tells it to use a different directory other than site-publish. Would it be possible to switch to the eventual svnpubsub target without actually switching to CMS yet? Could then switch the workspace
Re: svn commit: r1244240 - /incubator/public/trunk/build_cms.sh
On 14 February 2012 22:19, j...@apache.org wrote: Author: joes Date: Tue Feb 14 22:19:04 2012 New Revision: 1244240 URL: http://svn.apache.org/viewvc?rev=1244240view=rev Log: support CMS builds. All that's left to do is to rename site-author/ content/ and to ensure all the content in site-publish originates from content/. Added: incubator/public/trunk/build_cms.sh (with props) Added: incubator/public/trunk/build_cms.sh URL: http://svn.apache.org/viewvc/incubator/public/trunk/build_cms.sh?rev=1244240view=auto == --- incubator/public/trunk/build_cms.sh (added) +++ incubator/public/trunk/build_cms.sh Tue Feb 14 22:19:04 2012 @@ -0,0 +1,6 @@ +#!/bin/sh +ant site The current build.xml defaults to docs and does not have a site target. +rv=$? +rsync -a $1/site-publish/ $2/content/ It would help to document the expected parameters. +exit $? + Propchange: incubator/public/trunk/build_cms.sh -- svn:executable = * - To unsubscribe, e-mail: cvs-unsubscr...@incubator.apache.org For additional commands, e-mail: cvs-h...@incubator.apache.org - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: svn commit: r1244240 - /incubator/public/trunk/build_cms.sh
On 15 February 2012 01:30, Joe Schaefer joe_schae...@yahoo.com wrote: The documentation is in the caller script sebb. Yes, but how can one find the calling script from the build script? BTW, if the script is run at the moment, it will cause problems. Will fix the ant invocation. - Original Message - From: sebb seb...@gmail.com To: general@incubator.apache.org Cc: Sent: Tuesday, February 14, 2012 8:28 PM Subject: Re: svn commit: r1244240 - /incubator/public/trunk/build_cms.sh On 14 February 2012 22:19, j...@apache.org wrote: Author: joes Date: Tue Feb 14 22:19:04 2012 New Revision: 1244240 URL: http://svn.apache.org/viewvc?rev=1244240view=rev Log: support CMS builds. All that's left to do is to rename site-author/ content/ and to ensure all the content in site-publish originates from content/. Added: incubator/public/trunk/build_cms.sh (with props) Added: incubator/public/trunk/build_cms.sh URL: http://svn.apache.org/viewvc/incubator/public/trunk/build_cms.sh?rev=1244240view=auto == --- incubator/public/trunk/build_cms.sh (added) +++ incubator/public/trunk/build_cms.sh Tue Feb 14 22:19:04 2012 @@ -0,0 +1,6 @@ +#!/bin/sh +ant site The current build.xml defaults to docs and does not have a site target. +rv=$? +rsync -a $1/site-publish/ $2/content/ It would help to document the expected parameters. +exit $? + Propchange: incubator/public/trunk/build_cms.sh -- svn:executable = * - To unsubscribe, e-mail: cvs-unsubscr...@incubator.apache.org For additional commands, e-mail: cvs-h...@incubator.apache.org - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: svn commit: r1244240 - /incubator/public/trunk/build_cms.sh
On 15 February 2012 01:49, Joe Schaefer joe_schae...@yahoo.com wrote: - Original Message - From: sebb seb...@gmail.com To: general@incubator.apache.org; Joe Schaefer joe_schae...@yahoo.com Cc: Sent: Tuesday, February 14, 2012 8:40 PM Subject: Re: svn commit: r1244240 - /incubator/public/trunk/build_cms.sh On 15 February 2012 01:30, Joe Schaefer joe_schae...@yahoo.com wrote: The documentation is in the caller script sebb. Yes, but how can one find the calling script from the build script? If you have problems with the level of detail provided in the script comments, please feel free to add your own commentary. BTW, if the script is run at the moment, it will cause problems. Well with svn 1.7 those problems have been outlined elsethread. Hopefully we will have those resolved by the time the cms host is upgraded. I meant that until snvpubsub is implemented, running the script will cause problems, as it starts by deleting part of the workspace I've just realised that it may also cause problems for the Ant build, as I don't think that expects to create any missing directories. The script should probably just delete files. Will fix the ant invocation. - Original Message - From: sebb seb...@gmail.com To: general@incubator.apache.org Cc: Sent: Tuesday, February 14, 2012 8:28 PM Subject: Re: svn commit: r1244240 - /incubator/public/trunk/build_cms.sh On 14 February 2012 22:19, j...@apache.org wrote: Author: joes Date: Tue Feb 14 22:19:04 2012 New Revision: 1244240 URL: http://svn.apache.org/viewvc?rev=1244240view=rev Log: support CMS builds. All that's left to do is to rename site-author/ content/ and to ensure all the content in site-publish originates from content/. Added: incubator/public/trunk/build_cms.sh (with props) Added: incubator/public/trunk/build_cms.sh URL: http://svn.apache.org/viewvc/incubator/public/trunk/build_cms.sh?rev=1244240view=auto == --- incubator/public/trunk/build_cms.sh (added) +++ incubator/public/trunk/build_cms.sh Tue Feb 14 22:19:04 2012 @@ -0,0 +1,6 @@ +#!/bin/sh +ant site The current build.xml defaults to docs and does not have a site target. +rv=$? +rsync -a $1/site-publish/ $2/content/ It would help to document the expected parameters. +exit $? + Propchange: incubator/public/trunk/build_cms.sh -- svn:executable = * - To unsubscribe, e-mail: cvs-unsubscr...@incubator.apache.org For additional commands, e-mail: cvs-h...@incubator.apache.org - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: [VOTE] Release Apache Hama 0.4-incubating (RC4)
On 15 February 2012 01:55, Edward J. Yoon edwardy...@apache.org wrote: Dear Incubator PMC members, We'd like to ask your approval to release the Hama RC4 as Apache Hama 0.4.0-incubating. This RC4 has passed the Hama PMC vote as follows (*, ** marks an PMC, IPMC vote) : +1 Thomas Jungblut * +1 Apurv Verma +1 Edward J. Yoon * +1 Suraj Menon +1 Tommaso Teofili ** +1 ChiaHung Lin * http://markmail.org/thread/3estvkfxyrq2mq7j Now we'd need 2 more IPMC +1 to proceed with the release. Artifacts is: http://people.apache.org/~edwardyoon/dist/0.4-RC4/ Signing Keys is available at: http://svn.apache.org/repos/asf/incubator/hama/trunk/src/site/resources/files/KEYS SVN Tag is here: https://svn.apache.org/repos/asf/incubator/hama/tags/0.4-RC4/ Apache Hama Copyright 2008-2011 The Apache Software Foundation Year? And, the staging web site is at: http://people.apache.org/~edwardyoon/site/ [ ] +1 approve [ ] +0 no opinion [ ] -1 disapprove (because why) This vote will remain open for at least 72 hours. Thanks in advance! -- Best Regards, Edward J. Yoon @eddieyoon - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: [VOTE] Release Sqoop version 1.4.1-incubating
On 10 February 2012 19:27, Jarek Jarcec Cecho jar...@apache.org wrote: This is the second incubator release for Apache Sqoop, version 1.4.1-incubating. We already have one IPMC vote on dev list (Oliver Lamy) and we're looking for additional two. *** Please cast your vote by 2012-02-14 *** Dev list vote thread: http://markmail.org/message/alpqeqwliq4xbbcc The list of fixed issues: http://svn.apache.org/repos/asf/incubator/sqoop/branches/branch-1.4.1/CHANGES.txt The tarball (*.tar.gz), signature (*.asc), checksum (*.md5), and test result (log/*.ant_test.log): http://people.apache.org/~jarcec/sqoop-1.4.1-incubating-rc3/ The tag to be voted upon: http://svn.apache.org/repos/asf/incubator/sqoop/tags/release-1.4.1-rc3 NOTICE file is slightly dated: Apache Sqoop Copyright 2011 The Apache Software Foundation The KEYS file: http://www.apache.org/dist/incubator/sqoop/KEYS - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: [VOTE] Release jena-tdb-0.9.0-incubating (RC2)
On 8 February 2012 13:03, Andy Seaborne a...@apache.org wrote: The Jena PPMC has voted to release Apache Jena TDB 0.9.0-incubating and we would now be grateful if members of IPMC would review and vote for this release. == Overview This will be the second incubator release for by Jena; it's the first Apache release for the TDB module. Jena is composed of a number of modules. Historically, they have been released semi-independently, sort of flying in formation. We intend to switch to a more integrated build process and we want to create the time to do that by making this first Apache release of TDB now. Jena TDB is currently delivered as maven artifacts for the jar and also a single distribution file as a zip or tar.gz containing all the jars and their dependencies so users have a download and unpack option. == Project vote Result: http://mail-archives.apache.org/mod_mbox/incubator-jena-dev/201202.mbox/%3C4F324DFA.2050800%40apache.org%3E Call for VOTE: http://mail-archives.apache.org/mod_mbox/incubator-jena-dev/201202.mbox/%3C4F2DA188.6080105%40apache.org%3E == Staging repository https://repository.apache.org/content/repositories/orgapachejena-192/ This contains the source and binary archives, which are not normally released to Maven repos. IMO they should be deleted - they are not usable by Maven. The jars need to contain valid NOTICE files; however the files start as follows: TDB Copyright 2012 The Apache Software Foundation TDB is not valid as the component name on its own; there should not be a leading blank line either. Direct link to TDB area in staging: http://s.apache.org/apache-jena-tdb-0.9.0-incubating-RC-2/ == Proposed dist/ area: The following will be added to the existing distribution area: http://people.apache.org/~andy/dist-tdb-0.9.0-RC2/ There is some confusion over the directory structure and naming here. The top-level dir contains binary zip and tar archives, but no source archive. The subdir jena-tdb-0.9.0-incubating/ contains what appears to the the source archive, but only as a zip. It also contains several jars, which are not generally released to dist/ Also the source zip has a different name prefix from the binary zip There is no source tar.gz file. Normally both binary and source archives are released in the same formats. I would expect to find a directory structure more like dist-tdb-0.9.0-RC2/ dist-tdb-0.9.0-RC2/binaries dist-tdb-0.9.0-RC2/source where the top-level contains the KEYS file, and the sub dirs contain the appropriate archives. Other arrangements are possible, but the source and binary archives should be at the same level. The binary archive contains jars for icu4j and slf4j, but these are not mentioned in the license file. Depending on the license, they may also need to be mentioned in the notice file. will be added to: http://www.apache.org/dist/incubator/jena/ == Keys https://svn.apache.org/repos/asf/incubator/jena/dist/KEYS Should also be in the dist tree as mentioned above. == SVN tag The module is currently tagged with the version and -RC-2. If voted on successfully, the tag will be changed (svn mv) to the same but minus the RC labelling. https://svn.apache.org/repos/asf/incubator/jena/Jena2/TDB/tags/jena-tdb-0.9.0-incubating-RC-2/ There's something wrong with the tag - why does it have a directory called trunk/ ? The source archive also includes the trunk directory tree. Also, best not to include Eclipse files and folders (.classpath, .project, .settings/) in SVN. Unfortunately these are not portable so can cause problems for developers who have a slightly different setup (e.g. different default JVM). If you want to include sample versions, stick them in a subfolder or give them a different name, e.g. eclipse.classpath. [Unlike the other issues, this is not a blocker] Please vote on this release: [ ] +1 Approve the release of Apache Jena, module TDB 0.9.0-incubating [ ] -1 Don't release, because ... The binary NL files need to be sorted out before release. The tag and the packaging also need to be sorted out before release. This vote will be open until: Saturday 11/February 23:59 UTC (72 hours from the same hour tonight). As well as the vote, we'd also appreciate any feedback for improving our release process and project generally. Andy - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: [DISCUSS] Re: [VOTE] Jukka Zitting for IPMC Chair (was Re: NOMINATIONS for Incubator PMC Chair)
On 9 February 2012 16:32, Marcel Offermans marcel.offerm...@luminis.nl wrote: On Feb 9, 2012, at 17:10 PM, Andrus Adamchik wrote: On Feb 9, 2012, at 7:04 PM, Mattmann, Chris A (388J) wrote: Hi Ross, Sorry, I didn't see a mail from Noel, but he's already the chair. If this VOTE isn't successful, then he'll remain the chair. If you want to explicitly call a VOTE for Noel, go ahead, but this is the VOTE I am interested in calling, thanks! Cheers, Chris Well, if there's an election, the fair thing is to include all candidates and see who gets the majority. A vote on just one candidate is odd. I agree with Ross and Andrus that this is a strange way to hold an election, and I would be in favor of doing this in a different way. We could hold separate VOTEs for each remaining candidate, and then vote for the best vote thread? (joke) In case it's not obvious, I agree with Ross, Andrus and Marcel - I think the current VOTE thread is invalid and should be cancelled. Greetings, Marcel - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: [DISCUSS] [VOTE] Jukka Zitting for IPMC Chair (was Re: NOMINATIONS for Incubator PMC Chair)
On 9 February 2012 17:11, Mattmann, Chris A (388J) chris.a.mattm...@jpl.nasa.gov wrote: On Feb 9, 2012, at 9:03 AM, Ate Douma wrote: On 02/09/2012 05:58 PM, Mattmann, Chris A (388J) wrote: On Feb 9, 2012, at 8:49 AM, Jim Jagielski wrote: On Feb 9, 2012, at 11:10 AM, Andrus Adamchik wrote: Well, if there's an election, the fair thing is to include all candidates and see who gets the majority. A vote on just one candidate is odd. Agreed. I suggest that this VOTE be withdrawn, and a true election, with all candidates be done. What's preventing anyone from calling a VOTE on any other candidate? Of which, as I understand it, there are none. Noel is the existing chair. If this VOTE is *not* successful, then he remains the chair. If it is, successful, then the recommendation is to change him out as the chair. Did I miss something by actually trying to make progress here? For one, how or when would you call this vote successful? The same way we could if there were 2 people on the ballot. Max(votes), with the greater number being the winner, no? There is little difference but implementation mechanism for: a. holding a single VOTE thread with 2 candidates b. holding 2 VOTE threads with a candidate each. And then summing the total votes in either case. As long as: - people know that each vote thread is not the only vote thread - the votes are held at the same time so each person can vote for either (or both/neither). Otherwise one or other vote thread may have an unfair advantage. Cheers, Chris ++ Chris Mattmann, Ph.D. Senior Computer Scientist NASA Jet Propulsion Laboratory Pasadena, CA 91109 USA Office: 171-266B, Mailstop: 171-246 Email: chris.a.mattm...@nasa.gov WWW: http://sunset.usc.edu/~mattmann/ ++ Adjunct Assistant Professor, Computer Science Department University of Southern California, Los Angeles, CA 90089 USA ++ - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: Mad signing and checksumming (Was: [VOTE] Release DeltaSpike 0.1-incubating)
On 8 February 2012 10:41, Jukka Zitting jukka.zitt...@gmail.com wrote: Hi, On Wed, Feb 8, 2012 at 3:06 AM, sebb seb...@gmail.com wrote: On 8 February 2012 01:44, Niall Pemberton niall.pember...@gmail.com wrote: A small but annoying nit: you've gone mad signing and creating AFAIK, this is a known bug with Nexus and/or Maven. I know the problem with .asc.md5 and .asc.sha1 [1], but not the one with .asc.asc and .asc.asc.*. Is this a new generic issue, or just something specific to the DeltaSpike build? [1] http://jira.codehaus.org/browse/MDEPLOY-73 See also similar Nexus bug with bundles: https://issues.sonatype.org/browse/NEXUS-4644 BR, Jukka Zitting - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: [VOTE] Release DeltaSpike 0.1-incubating
On 8 February 2012 01:44, Niall Pemberton niall.pember...@gmail.com wrote: RAT report on the source distro looks good. None of the artifacts (zip or jar files) seem to have the incubator disclaimer notice. A small but annoying nit: you've gone mad signing and creating AFAIK, this is a known bug with Nexus and/or Maven. It's possible to delete the spurious sigs and hashes from the closed Nexus staging repo, but it would be very tedious in this case. checksums. Rather than just creating 1 signature file and sha md5 checksums for each file there are additional signatures and checksums for signatures. Take the deltaspike-core-api-0.1-incubating.jar file, for example there are the following 8 files instead of 3: deltaspike-core-api-0.1-incubating.jar.asc deltaspike-core-api-0.1-incubating.jar.asc.asc deltaspike-core-api-0.1-incubating.jar.asc.asc.md5 deltaspike-core-api-0.1-incubating.jar.asc.asc.sha1 deltaspike-core-api-0.1-incubating.jar.asc.md5 deltaspike-core-api-0.1-incubating.jar.asc.sha1 deltaspike-core-api-0.1-incubating.jar.md5 deltaspike-core-api-0.1-incubating.jar.sha1 https://repository.apache.org/content/repositories/orgapachedeltaspike-187/org/apache/deltaspike/core/deltaspike-core-api/0.1-incubating/ Niall On Tue, Feb 7, 2012 at 7:20 PM, Gerhard Petracek gpetra...@apache.org wrote: Hi, This is the first incubator release for Apache DeltaSpike, with the artifacts being versioned as 0.1-incubating. We have received 16 binding +1 votes (including 4 votes of IPMC members) during the release voting on deltaspike-dev. Vote thread: http://s.apache.org/Ta2 Result: http://s.apache.org/8I3 Git release branch: http://s.apache.org/PbX (It will be pushed to our Apache Git repository after this vote passed.) Git release tag: http://s.apache.org/uC (It will be pushed to our Apache Git repository after this vote passed.) Release notes: http://s.apache.org/DeltaSpike_01incubating Release artifacts: http://s.apache.org/5hU PGP release file (key 2FDB81B1): http://s.apache.org/wW This vote is open for 72 hours. [ ] +1 approve [ ] +0 no opinion [ ] -1 disapprove (and reason why) Thanks, Gerhard - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: Licence headers in template files
As I read it, http://www.apache.org/legal/src-headers.html#faq-exceptions only applies to files with no creative content. AFAICT this is not the case here. On 6 February 2012 15:03, Ross Gardler rgard...@opendirective.com wrote: Perfect - thanks Ate On 6 February 2012 14:54, Ate Douma a...@douma.nu wrote: On 02/06/2012 03:30 PM, ant elder wrote: On Mon, Feb 6, 2012 at 2:16 PM, Ate Doumaa...@douma.nu wrote: On 02/06/2012 02:44 PM, ant elder wrote: On Mon, Feb 6, 2012 at 1:37 PM, Franklin, Matthew B. mfrank...@mitre.org wrote: I am sure you know this (especially since you first pointed me at this page), but the release FAQ [1] makes it sound like you need the header, if you assume your templates are source: Which Files Must Contain An ASF License Text? Every source file must contain the appropriate ASF License text. I am no lawyer, so I will defer to someone who has more experience than me to help you determine whether your snippets count as source. I think that is a bug in the Release FAQ. What i've been told in the past but which i can't find links to right now, is that the top level LICENSE file covers everything anyway and the individual license headers aren't strictly necessary especially for source files without significant IP. Really? That then would be quite some 'bug' IMO. I can't recall have heard it said like this before, instead confirmation of the above rule quite often. Exceptions (no headers) only being allowed for sources without real IP value. Ate IMHO if the headers are problematic for Wookie in those files then it would be ok to just not include the header. ...ant I've just asked for clarification about this over at legal - https://issues.apache.org/jira/browse/LEGAL-124 Seems to me this has been asked and answered before: http://www.apache.org/legal/src-headers.html#faq-exceptions ...ant - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org -- Ross Gardler (@rgardler) Programme Leader (Open Development) OpenDirective http://opendirective.com - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: Licence headers in template files
On 6 February 2012 15:29, Ross Gardler rgard...@opendirective.com wrote: On 6 February 2012 15:20, sebb seb...@gmail.com wrote: As I read it, http://www.apache.org/legal/src-headers.html#faq-exceptions only applies to files with no creative content. AFAICT this is not the case here. Can you tell me why you think this is the case? As a reminder, in my original post I said: There is no significant IP in these templates. they are mostly boilerplates that are intended to be replaced by the end user Are IP and creativity the same thing? Seems to me that the templates do contain creative content. Ross On 6 February 2012 15:03, Ross Gardler rgard...@opendirective.com wrote: Perfect - thanks Ate On 6 February 2012 14:54, Ate Douma a...@douma.nu wrote: On 02/06/2012 03:30 PM, ant elder wrote: On Mon, Feb 6, 2012 at 2:16 PM, Ate Doumaa...@douma.nu wrote: On 02/06/2012 02:44 PM, ant elder wrote: On Mon, Feb 6, 2012 at 1:37 PM, Franklin, Matthew B. mfrank...@mitre.org wrote: I am sure you know this (especially since you first pointed me at this page), but the release FAQ [1] makes it sound like you need the header, if you assume your templates are source: Which Files Must Contain An ASF License Text? Every source file must contain the appropriate ASF License text. I am no lawyer, so I will defer to someone who has more experience than me to help you determine whether your snippets count as source. I think that is a bug in the Release FAQ. What i've been told in the past but which i can't find links to right now, is that the top level LICENSE file covers everything anyway and the individual license headers aren't strictly necessary especially for source files without significant IP. Really? That then would be quite some 'bug' IMO. I can't recall have heard it said like this before, instead confirmation of the above rule quite often. Exceptions (no headers) only being allowed for sources without real IP value. Ate IMHO if the headers are problematic for Wookie in those files then it would be ok to just not include the header. ...ant I've just asked for clarification about this over at legal - https://issues.apache.org/jira/browse/LEGAL-124 Seems to me this has been asked and answered before: http://www.apache.org/legal/src-headers.html#faq-exceptions ...ant - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org -- Ross Gardler (@rgardler) Programme Leader (Open Development) OpenDirective http://opendirective.com - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org -- Ross Gardler (@rgardler) Programme Leader (Open Development) OpenDirective http://opendirective.com - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: Licence headers in template files
On 6 February 2012 16:30, ant elder ant.el...@gmail.com wrote: On Mon, Feb 6, 2012 at 2:54 PM, Ate Douma a...@douma.nu wrote: On 02/06/2012 03:30 PM, ant elder wrote: On Mon, Feb 6, 2012 at 2:16 PM, Ate Doumaa...@douma.nu wrote: On 02/06/2012 02:44 PM, ant elder wrote: On Mon, Feb 6, 2012 at 1:37 PM, Franklin, Matthew B. mfrank...@mitre.org wrote: I am sure you know this (especially since you first pointed me at this page), but the release FAQ [1] makes it sound like you need the header, if you assume your templates are source: Which Files Must Contain An ASF License Text? Every source file must contain the appropriate ASF License text. I am no lawyer, so I will defer to someone who has more experience than me to help you determine whether your snippets count as source. I think that is a bug in the Release FAQ. What i've been told in the past but which i can't find links to right now, is that the top level LICENSE file covers everything anyway and the individual license headers aren't strictly necessary especially for source files without significant IP. Really? That then would be quite some 'bug' IMO. I can't recall have heard it said like this before, instead confirmation of the above rule quite often. Exceptions (no headers) only being allowed for sources without real IP value. Ate IMHO if the headers are problematic for Wookie in those files then it would be ok to just not include the header. ...ant I've just asked for clarification about this over at legal - https://issues.apache.org/jira/browse/LEGAL-124 Seems to me this has been asked and answered before: http://www.apache.org/legal/src-headers.html#faq-exceptions One of the things I've seen come up repeatedly for poddlings is that they should have license headers in doc files like READMEs. It could be argued they have creative content but as one example, the HTTPD doc type files don't have license headers. Perhaps the answer to Why is a licensing header necessary? http://www.apache.org/legal/src-headers.html#faq-whyheader is relevant here. The README file is generally not going to be modified - or seen in isolation - so it's not so necessary for the end user to know its license from the file itself. However, the template files are specifically designed for modification, and are likely to be seen without the LICENSE file, so IMO the enduser should see the AL header as part of the file. Searching in the archives it looks like this type of question comes up quite a lot. One longer thread is this one http://apache.markmail.org/message/5hk2t2vl6jjtsloy which ends with: For now, I'll be happy with some wording in our License Policy document that explicitly permits the PMC to use its judgement as to whether a license header is required in a source artifact. We've seen evidence that the current policy doesn't leave room for such things as test cases that should not have license headers. ...ant - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: Licence headers in template files
On 6 February 2012 19:38, Greg Stein gst...@gmail.com wrote: On Mon, Feb 6, 2012 at 13:18, Ross Gardler rgard...@opendirective.com wrote: Sent from my mobile device, please forgive errors and brevity. On Feb 6, 2012 5:26 PM, Greg Stein gst...@gmail.com wrote: On Feb 6, 2012 11:41 AM, sebb seb...@gmail.com wrote: ... Perhaps the answer to Why is a licensing header necessary? http://www.apache.org/legal/src-headers.html#faq-whyheader is relevant here. The README file is generally not going to be modified - or seen in isolation - so it's not so necessary for the end user to know its license from the file itself. However, the template files are specifically designed for modification, and are likely to be seen without the LICENSE file, so IMO the enduser should see the AL header as part of the file. That would be my thinking, too. Not in this specific case, I think. You keep refining the description :-P The original template files are not modified directly, neither are the output files. Modifications are by token replacement in the simplest form or by creating a completely new template to override the original (at which point the user can define their own licence). Personally, I call that a tool problem. Seems there ought to be some kind of comment directive that won't get included into the output. Put the ALv2 notice in that comment. And you're saying supply a new template, but who knows what people will do? Is there anything that prevents a downstream user from editing these templates before packaging? Probably not. Sure... you'd *like* them to provide a new template as part of Best Practices, but I doubt that is forced. If the user generates their widgets from these templates the files we are talking about will be included in larger files, which do contain license headers. Final outputs will therefore always have an Apache header, there may be user specified headers surrounding their own contributions. Gotcha. Yeah, that would be ugly, and it gets back to having some kind of a don't place this into the output block. The final outputs should never be edited, it's the widget definitions (the tokens referred to above) that get edited. Sure. Elsethread, I think Craig's suggestion is effectively saying if the file is shorter than the text, then we will declaratively state there is no creativity in it. I'm not sure that is proper, but can certainly see the argument. There are probably quite a few Java interface definitions that are shorter than the AL header, but I think they should surely still have the header. Cheers, -g - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: Reviewing a Release
On 4 February 2012 11:55, Mark Struberg strub...@yahoo.de wrote: Hi folks! I've quickly collected a page of things to check before casting your vote for a staged release. https://cwiki.apache.org/confluence/display/DeltaSpike/Reviewing+a+Release This was done from the back of my head, thus I've maybe missed some parts. Just wondered if we don't have such a checklist somewhere for general incubator projects? Feel free to add anything missing or point me to a location where this already got collected. Not entirely sure what this means: if there is a tag in the SCM, does it contain reproduceable sources? I would say instead that: is there an SVN tag which was used to derive the source archive? do all the files in the source archive agree with the files in the SVN tag? [*] This is to ensure that the source archive itself can be re-created. Also that it is built from traceable sources (and does not include file(s) that happen to be on the RMs system). It's a lot easier to trace provenance through SVN history. The podling should ensure that files committed to SVN are checked for compliance with IP and licensing. Provided source archives are only created from SVN then there is no need to separately check each file in each source archive for compliance. [*] Not all SVN files need to be in the source archive, e.g. DOAPs aren't needed in source releases, but all files in the source archive must derive from the SVN tag. txs and LieGrue, strub - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: Fwd: mentoring individuals as well as projects
On 1 February 2012 15:54, Marvin Humphrey mar...@rectangular.com wrote: On Wed, Feb 01, 2012 at 01:54:18PM +, Ross Gardler wrote: My point is that when we help guide individuals who demonstrate a willingness to contribute those individuals often grow in capacity. There was a memorable post on another ASF list a few months ago which compared Apache's decentralized leadership model to that of military organizations and contrasted it with the stiff hierarchical model common in the corporate world. It linked to an article which studied the question of why military service -- particularly service in the crucible of combat -- is exceptionally effective at developing leaders.[1] The article author's answer, in part: Secondly, military leaders tend to hold high levels of responsibility and authority at low levels of our organizations. Top level PMCs at Apache are largely autonomous, but when it comes to binding votes on releases, podlings are wholly dependent on IPMC members whose attentions often wander. AIUI, a Mentor must be an IPMC member, and a podling should have at least 3 mentors, so a podling is not *wholly dependent* on the IPMC. Far from it. It's only when a podlings own mentors are lacking or AWOL that it is necessary to solicit votes from the IPMC at large. Our future PMC members do not hold high levels of responsibility and authority at low levels of our organization -- instead, projects have a boolean graduated/not-graduated property whereby podlings move from having no autonomy and mandatory supervision to having near-total autonomy and scant supervision after graduation. I believe that we would develop better future PMC members if PPMC members were encouraged to earn partial autonomy for their podlings by earning a binding vote for themselves. Serving alongside Mentors encourages podling contributors to think like Mentors, exercising servant leadership and devolving responsibility within their own projects. Not sure how that would work if the podlings mentors are already awol. Presently, we do not often take advantage of this opportunity to expand the capacity of these individuals who demonstrate a willingness to contribute within the crucible of incubation -- to our podlings' detriment and our own. Marvin Humphrey [1] http://blogs.hbr.org/frontline-leadership/2009/02/why-the-military-produces-grea.html - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: Q: including notice for binary release of artifacts that are brought in via Maven?
On 31 January 2012 11:07, Jukka Zitting jukka.zitt...@gmail.com wrote: Hi, On Tue, Jan 31, 2012 at 2:49 AM, Jakob Homan jgho...@gmail.com wrote: Great, thanks. Using this method, I get a file layout similar to: giraph-0.1-SNAPSHOT-bin.tar.gz NOTICE (without appended text for dep1 and dep2) LICENSE (without appended text for dep1 and dep2) bin/ lib/ dep1.jar dep2.jar giraph.jar META-INF/ NOTICE (with appended text for dep1 and dep2) LICENSE (with appended text for dep1 and dep2) This matches with what I see when I checkout the jackrabbit-standalone code and do a package command from maven there. I just want to verify that this will past muster with incubator. This configuration satisfies the requirement for those notices/licenses to be included? The general idea is that the NOTICE/LICENSE pair of an artifact should cover all the bits included inside that artifact. Also the idea is that the NL (and Disclaimer, Readme if any) are at the top-level of the artifact. The only exception to this is that NL files are added to a jar META-INF directory instead (as that is the convention for jars) . Having the files in a standard place is intended to make it easy for the consumer to find the files. The NL files are important for the consumer; they should not have to go looking for them. If giraph.jar doesn't embed dep1 and dep2, then there's no need to mention them in the NOTICE/LICENSE pair of that jar. Instead, since you are including dep1 and dep2 inside giraph-bin.tar.gz, they should be covered by the NOTICE/LICENSE pair of the tarball. If you look inside the jackrabbit-standalone jar, you'll notice that it actually contains all the external components mentioned in the NOTICE/LICENSE files. BR, Jukka Zitting - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: Q: including notice for binary release of artifacts that are brought in via Maven?
On 31 January 2012 18:15, Jakob Homan jgho...@gmail.com wrote: Instead, since you are including dep1 and dep2 inside giraph-bin.tar.gz, they should be covered by the NOTICE/LICENSE pair of the tarball. This is the case for Giraph (and Kafka and other projects that bring in transitive dependencies into the tar.gz via maven), so the jackrabbit approach won't work. Which puts me back at my original question: how to include NL for the binary distribution without having to re-create it on the release branch each time. I'll take a look at Whisker, but for now it seems like one just needs to have a release-specific NL for the binary artifact? Just include the binary NL files somewhere other than the top level in SVN, and copy them to the top-level in the binary artifacts. Perhaps use names like NOTICE_binary/LICENSE_binary to make it obvious. -jg On Tue, Jan 31, 2012 at 6:05 AM, sebb seb...@gmail.com wrote: On 31 January 2012 11:07, Jukka Zitting jukka.zitt...@gmail.com wrote: Hi, On Tue, Jan 31, 2012 at 2:49 AM, Jakob Homan jgho...@gmail.com wrote: Great, thanks. Using this method, I get a file layout similar to: giraph-0.1-SNAPSHOT-bin.tar.gz NOTICE (without appended text for dep1 and dep2) LICENSE (without appended text for dep1 and dep2) bin/ lib/ dep1.jar dep2.jar giraph.jar META-INF/ NOTICE (with appended text for dep1 and dep2) LICENSE (with appended text for dep1 and dep2) This matches with what I see when I checkout the jackrabbit-standalone code and do a package command from maven there. I just want to verify that this will past muster with incubator. This configuration satisfies the requirement for those notices/licenses to be included? The general idea is that the NOTICE/LICENSE pair of an artifact should cover all the bits included inside that artifact. Also the idea is that the NL (and Disclaimer, Readme if any) are at the top-level of the artifact. The only exception to this is that NL files are added to a jar META-INF directory instead (as that is the convention for jars) . Having the files in a standard place is intended to make it easy for the consumer to find the files. The NL files are important for the consumer; they should not have to go looking for them. If giraph.jar doesn't embed dep1 and dep2, then there's no need to mention them in the NOTICE/LICENSE pair of that jar. Instead, since you are including dep1 and dep2 inside giraph-bin.tar.gz, they should be covered by the NOTICE/LICENSE pair of the tarball. If you look inside the jackrabbit-standalone jar, you'll notice that it actually contains all the external components mentioned in the NOTICE/LICENSE files. BR, Jukka Zitting - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: Creation of Gora TLP and discharge of responsibilities on Incubator PMC
On 27 January 2012 18:37, Mattmann, Chris A (388J) chris.a.mattm...@jpl.nasa.gov wrote: Hi Guys, So, the board passed the Gora TLP resolution and now I'm in the process of helping migrate the Gora project to its TLP status. I've created an issue here: https://issues.apache.org/jira/browse/INFRA-4368 To track the tasks. Lewis, as the chair, can you take the in discharging the responsibilities from the Incubator? That would likely involve: 1. Marking the Gora project.xml file as graduated, and updating the necessary Incubator project page for Gora. 2. Updating the Incubator website to show that Gora is now in the graduated projects list. 3. Taking care to clean up current releases of Gora from the Incubator dist area, after making sure that those releases are present on archive.apache.org The other Incubator vets here can help also if I've missed anything. There's a useful checklist here: http://incubator.apache.org/guides/graduation.html#transfer Please remember to delete the old website - i.e. http://incubator.apache.org/gora/ - once it has been migrated. That is often forgotten. Thanks! Cheers, Chris ++ Chris Mattmann, Ph.D. Senior Computer Scientist NASA Jet Propulsion Laboratory Pasadena, CA 91109 USA Office: 171-266B, Mailstop: 171-246 Email: chris.a.mattm...@nasa.gov WWW: http://sunset.usc.edu/~mattmann/ ++ Adjunct Assistant Professor, Computer Science Department University of Southern California, Los Angeles, CA 90089 USA ++ - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: [VOTE Result] Release Apache Lucene.Net 2.9.4g incubating
On 28 January 2012 20:53, Prescott Nasser geobmx...@hotmail.com wrote: This vote passes with the required 3 +1's from Sebb, Ant, and Stefan. Thank you guys for taking the time to review and approve this release, ~Prescott Date: I did not vote +1. I did not vote at all. Fri, 27 Jan 2012 09:19:57 + Subject: Re: [VOTE] Release Apache Lucene.Net 2.9.4g incubating From: ant.el...@gmail.com To: general@incubator.apache.org On Thu, Jan 26, 2012 at 1:29 PM, Stefan Bodewig bode...@apache.org wrote: On 2012-01-23, Prescott Nasser wrote: Lucene.Net 2.9.4g is ready for release. This is very similar to our release at the end of November, however we have used generics where appropriate to give it a better feel for .Net developers. SVN Tag: https://svn.apache.org/repos/asf/incubator/lucene.net/tags/Lucene.Net_2_9_4g_RC1/ Artifacts: http://people.apache.org/~pnasser/Lucene.Net/2.9.4g-incubating-RC1/ Repeating my vote from the dev list +1 With Benson's vote we have two IPMC +1s and still need a third one. Stefan +1 ...ant - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: [VOTE] Release Apache Lucene.Net 2.9.4g incubating
On 23 January 2012 06:20, Prescott Nasser geobmx...@hotmail.com wrote: Hi all, Lucene.Net 2.9.4g is ready for release. This is very similar to our release at the end of November, however we have used generics where appropriate to give it a better feel for .Net developers. SVN Tag: https://svn.apache.org/repos/asf/incubator/lucene.net/tags/Lucene.Net_2_9_4g_RC1/ Various stemmers are mentioned in the LICENSE file; their license appears to require a notice in the NOTICE file. The DISCLAIMER text file has excessively long lines in it. Artifacts: http://people.apache.org/~pnasser/Lucene.Net/2.9.4g-incubating-RC1/ The vote is open for 72 hours, or until we get the needed number of votes. [ ] +1 Release this package as Apache Lucene.Net 2.9.4g-incubating [ ] -1 Do not release this package because... Thank you for your time reviewing this release, ~Prescott - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: [VOTE] Release Apache Rave 0.7-incubating
On 23 January 2012 15:17, Franklin, Matthew B. mfrank...@mitre.org wrote: This is the sixth incubator release for Apache Rave, with the artifacts being versioned as 0.7-incubating. We are requesting a lazy consensus vote, as we have already received 3 binding IPMC +1 votes during the release voting on rave-dev - VOTE: http://s.apache.org/xqH RESULT: http://s.apache.org/rg Release notes: http://svn.apache.org/repos/asf/incubator/rave/tags/0.7-incubating/CHANGELOG SVN source tag (r1227377): https://svn.apache.org/repos/asf/incubator/rave/tags/0.7-incubating/ NOTICE file says: Apache Rave Copyright 2011 The Apache Software Foundation Is this still correct? Maven staging repo: https://repository.apache.org/content/repositories/orgapacherave-015/ Source release: https://repository.apache.org/content/repositories/orgapacherave-015/org/apache/rave/rave-project/0.7-incubating/rave-project-0.7-incubating-source-release.zip Binary releases http://people.apache.org/builds/incubator/rave/0.7-incubating/apache-rave-0.7-incubating-bin.tar.gz http://people.apache.org/builds/incubator/rave/0.7-incubating/apache-rave-0.7-incubating-bin.zip PGP release keys: https://svn.apache.org/repos/asf/incubator/rave/KEYS Lazy consensus, vote open for 72 hours. [ ] +1 approve [ ] +0 no opinion [ ] -1 disapprove (and reason why) - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Recent committers added to podlings were not added to incubator group
Entries in podling bloodhound not in incubator group: gmj,hwright Entries in podling giraph not in incubator group: ssc Entries in podling gora not in incubator group: ferdy Command to update incubator group: modify_unix_group.pl incubator -add=ferdy,gmj,hwright,ssc Please ensure when adding existing committers to poblings that they are added to the incubator group if necessary. Otherwise they may not have full access to the incubator resources, e.g. they won't be able to update websites. - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: Thoughts about reporting (was: Re: [RT] Community over policy...)
On 17 January 2012 01:06, Leo Simons m...@leosimons.com wrote: On Mon, Jan 16, 2012 at 6:42 PM, Sam Ruby ru...@intertwingly.net wrote: snip/ We may also have semantic gaps. Leo's [RT] may be presuming that a podling's board report[sic] is merely a bureaucratic requirement. snip/ Hmm :-) And so the threads collide... ...I guess I'll allow it. But since we're in my thoughts now, I'll go ahead and say something :-) I would say that you need to provide a quarterly report using this template and add it to that wiki page and then get it signed off by a mentor [1] is a somewhat bureaucratic expression of your community needs to be self-reflective and periodically tell us how things are going, because of [X] and [Y] [1] and that the expression of the latter is perhaps more important than the expression of the former. It's definitely more interesting! And it's more useful. I think a lot of the arguments about rules stem from the fact that the assumptions and reasoning behind the rules is rarely made explicit. This has several consequences: - people don't like the rules because their purpose is not understood - if the rules are unclear (e.g. edge cases), it's not obvious how they need to be interpreted - it's very difficult to adapt the rules if the underlying assumptions change - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: January 2012 Incubator Board Report
On 12 January 2012 06:09, Noel J. Bergman n...@devtech.com wrote: A number of substantive issues came up during the past month. First, and although it was raised on the private list and therefore details won't be part of the public report, we advise the Board that there is substantial discussion regarding changing the Incubator VP, which has been held for almost 8 years by the current VP. Second, there is a dispute, both in the abstract and concretely, regarding whether or not the ASF, via the Incubator, may play host to a community that has forked a compatibly licensed codebase. Roy suggested that, in the specific case: The VOTE was based on misleading information. The Incubator PMC should declare it void and request a new proposal. The existing Bloodhound podling should be placed on hold until this is sorted out. Greg has said, more recently, that the Bloodhound and Trac communities already have a new non-fork plan and are executing on that now, on the bloodhound-dev mailing list. If that comes to pass, perhaps no further attention from the PMC and Board will be required on this issue. If not, we'll have to revisit the specific case. However, Bill Rowe has requested that the Incubator PMC formally put the general matter to the Board: what policy do or should we have regarding a community that wishes to fork a suitably licensed codebase and come to the ASF? If so, what is that policy? Or is that decision still a matter to be determined situationally by the Incubator PMC? For whatever it is worth, the latter is the opinion of the Incubator VP, who recalls that more than one successful ASF project started elsewhere and came to the ASF as a fork, and not without some complaint from members of the outside community (e.g., Apache Felix). Third, there was a lot of discussion surrounding a couple of Incubator issues: 1) podlings being comfortably settled in the Incubator, and not being focused enough on graduation; 2) Mentors being insufficiently active, and thus not providing either proper guidance or oversight. We definitely need to address these issues, promoting both Mentor involvement and graduation from the Incubator. And, finally, Jukka spent time reviewing the status of many of the older podlings, and recommending an action. Perhaps not coincidentally, ACE, Gora and Bean Validation Framework are all in graduation mode. But, meanwhile, Bloodhound (the podling previously mentioned), DeviceMap and Flex have joined. Below are podling reports. Sam Ruby has already reviewed the original list prior to posting, and requested that specific posts not be provided to the Board, as he was unhappy with their status: Kato: has been in limbo for years due to Oracle. The podling needs to decide what to do, or terminate Bloodhound, HISE, JSPWiki and Openmeetings: missing VXQuery: not signed off by a Mentor Although initially requested to be excluded, the Celix and Tashi reports were revised to provide at least some graduation guidance, and so their reports are included, below. - Any23 Any23 is defined as a Java library, a Web service and a set of command line tools to extract and validate structured data in RDF format from a variety of Web documents and markup formats. Any23 is what it is informally named an RDF Distiller. A list of the three most important issues to address in the move towards graduation 1. Port Any23 code to ASF infrastructure and update license headers 2. Develop a strong community with organizational diversity and with strong connections to other relevant ASF communities. 3. At least one Any23 incubating release Any issues that the Incubator PMC (IPMC), Tika PMC, or ASF Board wish/need to be aware of? Yes, all of the code has been ported from Google Code to the ASF. Thanks to Daniel Shahaf and Michele Mostarda for leading the charge here. How has the community developed since the last report? All ASF karma has been granted on the repository, and we've received a few JIRA issues, but not from outside the core set of PPMC members as of yet. The team needs to respond to Paolo Castagna's points regarding RDF frameworks and collaboration, and will hopefully do so this month. How has the project developed since the last report? Any23 was voted into the Incubator by the IPMC on October 1, 2011. We have Jenkins CI builds going thanks to Lewis John McGibbney, code up and running at the ASF thanks to Michele and to Daniel, so we're all set to really get kicking! Celix Celix is an implementation of the OSGi Specification in C. Celix entered incubation on November 2, 2010. Over the last few months lots of work has been put into integrating APR and updating the Celix code base to the proposed code style. This code style has partially been documented on [1]. Also some effort has been put into updating
Re: [VOTE] Release MRUnit version 0.8.0-incubating
On 11 January 2012 18:44, Patrick Hunt phu...@gmail.com wrote: On Wed, Jan 11, 2012 at 10:22 AM, sebb seb...@gmail.com wrote: On 11 January 2012 18:06, Patrick Hunt ph...@apache.org wrote: On Wed, Jan 11, 2012 at 9:59 AM, sebb seb...@gmail.com wrote: On 11 January 2012 17:49, Patrick Hunt ph...@apache.org wrote: In this case the files are exactly the same, there is no difference btw the contents of the two archives (which makes verification simpler). Yes. The source archive(s) should also be checked against the SVN tag. How is this most easily accomplished? Checkout tag from SVN then manually diff against the artifact, or some other way is better/easier? I checkout the SVN tag and explode the archive(s) in the same parent directory, and then use a Gui difference tool (WinDiff) to show the differences. Have to ignore SVN directories and (perhaps) EOL differences. The biggest problems come from different directory layouts in SVN and the archive. Also the SVN $Date variable is locale-dependent so causes spurious differences; don't use it! Patrick - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: [VOTE] Release MRUnit version 0.8.0-incubating
On 12 January 2012 12:08, Marvin Humphrey mar...@rectangular.com wrote: On Thu, Jan 12, 2012 at 11:37:18AM +, sebb wrote: How is this most easily accomplished? Checkout tag from SVN then manually diff against the artifact, or some other way is better/easier? I checkout the SVN tag and explode the archive(s) in the same parent directory, and then use a Gui difference tool (WinDiff) to show the differences. Have to ignore SVN directories and (perhaps) EOL differences. I use svn export to avoid the .svn directories, then diff -ur on the Unix command line, optionally with --strip-trailing-cr when checking .zip archives. I also normally do a check on the SVN tag to verify that that appropriate SVN properties have been set; that does not work on an exported copy. It's easy enough to ignore the SVN directories (especially since the 1.7 change to the working copy format). Marvin Humphrey - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: Checking release archive against VCS tag (was [VOTE] Release MRUnit version 0.8.0-incubating)
On 12 January 2012 12:35, Marvin Humphrey mar...@rectangular.com wrote: On Thu, Jan 12, 2012 at 12:26:49PM +, sebb wrote: On 12 January 2012 12:08, Marvin Humphrey mar...@rectangular.com wrote: On Thu, Jan 12, 2012 at 11:37:18AM +, sebb wrote: How is this most easily accomplished? Checkout tag from SVN then manually diff against the artifact, or some other way is better/easier? I checkout the SVN tag and explode the archive(s) in the same parent directory, and then use a Gui difference tool (WinDiff) to show the differences. Have to ignore SVN directories and (perhaps) EOL differences. I use svn export to avoid the .svn directories, then diff -ur on the Unix command line, optionally with --strip-trailing-cr when checking .zip archives. I also normally do a check on the SVN tag to verify that that appropriate SVN properties have been set; that does not work on an exported copy. It's easy enough to ignore the SVN directories (especially since the 1.7 change to the working copy format). What svn props do you look for? I'm curious if I'm missing anything. There's eol-style of course, but that's per file, so there's no way I'm checking it on a giant source tree. I don't check it manually! And the actual release archive is an svn export Depends on the build process; it may be repacked from a clean checkout of the tag. (all this assumes svn and not git of course), so whatever svn props were there, they're gone now! It seems like svn props are a development issue rather than a release issue, no? Yes, but if the eolstyle is missing or incorrect, it causes problems when developers use OSes with different EOLs. Not only can it make it harder for the developer to use the file, it can also affect the SVN diff messages, showing diffs where there are none. Similarly if binary files don't have the correct mime-type; there have been occasions when PDFs have been treated as text, which causes diff messages to be huge and may cause some mail clients to bork. Besides, I don't actually care about line endings when performing this QC step -- I just want to see that the archive really was exported from the VCS tag. There's no point for my use-case to both checkout the tag and export it; once is enough. Marvin Humphrey - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: [VOTE] Release MRUnit version 0.8.0-incubating
On 11 January 2012 17:49, Patrick Hunt ph...@apache.org wrote: +1 sig/xsum match up, tested clean and RAT reports fine. It's a bit odd to me that there are two source release artifacts here (one archived with tar/gz the other with zip), I've not seen that for other projects. Typically you want to have a single source release artifact. You could then create convenience artifacts off that. Having multiple archive types is very common in other ASF projects. I verified that the contents of the two artifacts are exactly the same, just differing archiving tools. Or possibly also differing in EOL setting, e.g. Windows more commonly has zip support, so source may have EOL=CRLF Un*x systems more commonly support tar/gz, so source may have EOL=LF. Patrick On Mon, Jan 9, 2012 at 3:52 PM, Brock Noland br...@cloudera.com wrote: This is an incubator release for Apache MRUnit, version 0.8.0-incubating. It fixes the following issues: https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12311292version=12316359 *** Please download, test and vote by [3 working days after sending]. Note that we are voting upon the source (tag), binaries are provided for convenience. Source and binary files: http://people.apache.org/~brock/mrunit-0.8.0-incubating-candidate-0 Maven staging repo: https://repository.apache.org/content/repositories/orgapachemrunit-031/ The tag to be voted upon: http://svn.apache.org/repos/asf/incubator/mrunit/tags/release-0.8.0-incubating/ MRUnit's KEYS file containing PGP keys we use to sign the release: http://svn.apache.org/repos/asf/incubator/mrunit/dist/KEYS Note that the Incubator PMC needs to vote upon the release after a successful PPMC vote before any release can be made official. - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: [VOTE] Release MRUnit version 0.8.0-incubating
On 11 January 2012 18:06, Patrick Hunt ph...@apache.org wrote: On Wed, Jan 11, 2012 at 9:59 AM, sebb seb...@gmail.com wrote: On 11 January 2012 17:49, Patrick Hunt ph...@apache.org wrote: +1 sig/xsum match up, tested clean and RAT reports fine. It's a bit odd to me that there are two source release artifacts here (one archived with tar/gz the other with zip), I've not seen that for other projects. Typically you want to have a single source release artifact. You could then create convenience artifacts off that. Having multiple archive types is very common in other ASF projects. Ok, but that means that we need to verify/vote on both, correct? (we yes. can do them together, I'm just saying that it requires more reviewer work than just verifying the single artifact). I verified that the contents of the two artifacts are exactly the same, just differing archiving tools. Or possibly also differing in EOL setting, e.g. Windows more commonly has zip support, so source may have EOL=CRLF Un*x systems more commonly support tar/gz, so source may have EOL=LF. In this case the files are exactly the same, there is no difference btw the contents of the two archives (which makes verification simpler). Yes. The source archive(s) should also be checked against the SVN tag. Patrick - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: Podling rename, vote needed?
On 10 January 2012 10:13, Jukka Zitting jukka.zitt...@gmail.com wrote: Hi, On Tue, Jan 10, 2012 at 3:48 AM, sebb seb...@gmail.com wrote: On a related matter, how is the rename being handled for the various incubator data files, web-pages, mailing lists etc.? We're still working on that, but I suppose we'll be leaving pointers from old callback locations to new cordova ones where appropriate. It may well be that we'll postpone some parts of the name change all the way to graduation, in case we can get there soon enough. At the very least, please update the status page to document the name change. BR, Jukka Zitting - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: [VOTE] Chukwa 0.5.0 Release Candidate 3
On 10 January 2012 06:09, Eric Yang eric...@gmail.com wrote: Hi all, Chukwa 0.5.0 is ready for release. This will be the first incubator release for Chukwa. The source tarball artifact is available at: http://people.apache.org/~eyang/chukwa-0.5.0-rc3/ Documents are available at: http://people.apache.org/~eyang/chukwa-0.5.0-docs/ The SVN tag to be voted upon: https://svn.apache.org/repos/asf/incubator/chukwa/tags/chukwa-0.5.0-rc3/ NL files look OK to me now; thanks for fixing them. Chukwa's KEYS file containing PGP keys we use to sign the release: http://people.apache.org/~eyang/chukwa-0.5.0-rc3/KEYS Please download, evaluate, and vote on general@incubator. The PPMC vote thread is in progress at the same time as general@incubator. Changes since rc2: - Updated LICENSE and NOTICE files to reflect changes base on Sebb's examples. The vote will close at 12:30pm PST on Saturday January 14, 2012. Thanks regards, Eric - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: [VOTE] Release MRUnit version 0.8.0-incubating
On 9 January 2012 23:52, Brock Noland br...@cloudera.com wrote: This is an incubator release for Apache MRUnit, version 0.8.0-incubating. It fixes the following issues: https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12311292version=12316359 *** Please download, test and vote by [3 working days after sending]. Note that we are voting upon the source (tag), binaries are provided for convenience. Source and binary files: http://people.apache.org/~brock/mrunit-0.8.0-incubating-candidate-0 Maven staging repo: https://repository.apache.org/content/repositories/orgapachemrunit-031/ The tag to be voted upon: http://svn.apache.org/repos/asf/incubator/mrunit/tags/release-0.8.0-incubating/ NOTICE says: Copyright 2011 The Apache Software Foundation If you have made any substantial changes this year, surely that ought to be changed? MRUnit's KEYS file containing PGP keys we use to sign the release: http://svn.apache.org/repos/asf/incubator/mrunit/dist/KEYS Note that the Incubator PMC needs to vote upon the release after a successful PPMC vote before any release can be made official. - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: Small but otherwise happy podlings
On 9 January 2012 04:41, Kalle Korhonen kalle.o.korho...@gmail.com wrote: On Sun, Jan 8, 2012 at 10:23 AM, Benson Margulies bimargul...@gmail.com wrote: This has been the subject of prior conversations, but I'm opening a thread in some hope of reaching a definitive resolution. Some of our non-graduating podlings have a common problem. They look good in all ways except growth. This inhibits graduation from 2.5 standpoints: 1) they are dubiously large enough to sustain as a TLP. 2) they don't have much (or any) track record in incorporating new contributors. 2.5) they might not be very diverse. I list this as a .5 because I think that we've established that diversity is a lower priority. There are some possible responses to this situation. a) toss them out of the incubator. b) keep them in the incubator indefinitely. c) graduate them, but with some conditions. Should smaller incubator projects be encouraged to graduate as sub-projects of existing projects or is that not an option anymore? Specifically, I was thinking about Amber, which might just work as a sub-project of Apache Shiro if they are too small to make it on their own. However, we (the Shiro PMC) haven't suggested this to them and they haven't contacted us. Since Jakarta, my understanding is that the incubator would rather see the projects graduating as TLPs, not sub-projects, is that correct? I don't think so. It's just umbrella TLPs are discouraged. If the podling fits well with an existing TLP, and that TLP agrees to take it on, then it can graduate as a sub-project of that TLP. For example, Sanselan graduated into Commons, because it fits well with the Commons scope. Kalle - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: [VOTE] Release Apache Rave 0.6-incubating
On 9 January 2012 13:09, Franklin, Matthew B. mfrank...@mitre.org wrote: Does my answer below suffice? It would be nice to close this vote out one way or another The answer describes what happened. However, it does not fix the problem, which is that the end-user sees a file with conflicting information. Not a blocker, but you may find it takes less time overall to fix the issue before release rather than dealing with user queries afterwards. It may also lessen confidence in the release: if there is such an obvious error, what other errors are lurking? -Original Message- From: Franklin, Matthew B. [mailto:mfrank...@mitre.org] Sent: Tuesday, January 03, 2012 12:19 PM To: general@incubator.apache.org Subject: RE: [VOTE] Release Apache Rave 0.6-incubating -Original Message- From: sebb [mailto:seb...@gmail.com] Sent: Tuesday, January 03, 2012 7:06 AM To: general@incubator.apache.org Subject: Re: [VOTE] Release Apache Rave 0.6-incubating On 28 December 2011 19:15, Franklin, Matthew B. mfrank...@mitre.org wrote: This is the fifth incubator release for Apache Rave, with the artifacts being versioned as 0.6-incubating. We are requesting at least one additional IPMC member vote, as we have received 2 binding IPMC +1 votes during the release voting on rave-dev - VOTE: http://s.apache.org/Czr RESULT: http://s.apache.org/yIQ IPMC member votes from the rave-dev list: Ate Douma: +1 Ross Gardler: +1 Release notes: http://svn.apache.org/repos/asf/incubator/rave/tags/0.6- incubating/CHANGELOG Apparently, I didn't commit back the CHANGELOG for 0.6 . Here is the issue list from JIRA https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12311290 version=12317563 which says: Release Notes - Rave - Version 0.5-INCUBATING So what was changed for 0.6? SVN source tag (r1208867): https://svn.apache.org/repos/asf/incubator/rave/tags/0.6-incubating/ Maven staging repos: https://repository.apache.org/content/repositories/orgapacherave-278/ https://repository.apache.org/content/repositories/orgapacherave-279/ Source release: https://repository.apache.org/content/repositories/orgapacherave- 278/org/apache/rave/rave-project/0.6-incubating/rave-project-0.6- incubating-source-release.zip Binary releases http://people.apache.org/builds/incubator/rave/0.6-incubating/apache- rave-0.6-incubating-bin.tar.gz http://people.apache.org/builds/incubator/rave/0.6-incubating/apache- rave-0.6-incubating-bin.zip PGP release keys: https://svn.apache.org/repos/asf/incubator/rave/KEYS Vote open for 72 hours. [ ] +1 approve [ ] +0 no opinion [ ] -1 disapprove (and reason why) - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: [VOTE] Chukwa 0.5.0 release candidate 2
On 9 January 2012 19:40, Eric Yang eric...@gmail.com wrote: Hi all, Chukwa 0.5.0 is ready for release. This will be the first incubator release for Chukwa. The source tarball artifact is available at: http://people.apache.org/~eyang/chukwa-0.5.0-rc2/ Documents are available at: http://people.apache.org/~eyang/chukwa-0.5.0-docs/ The SVN tag to be voted upon: https://svn.apache.org/repos/asf/incubator/chukwa/tags/chukwa-0.5.0-rc2/ The Script.aculo.us license has the following copyright notice: Copyright (c) 2005-2008 Thomas Fuchs (http://script.aculo.us, http://mir.aculo.us) However, this does not appear in NOTICE.txt. I would expect to see something like the following 2 lines in NOTICE.txt: This product includes Script.aculo.us Copyright (c) 2005-2008 Thomas Fuchs (http://script.aculo.us, http://mir.aculo.us) Similarly for any other included products that have a notice requirement, i.e. This product includes YUI Copyright Yahoo inc, 2009 This product includes IUI Copyright (c) 2007-2009, iUI Project Members etc. for any other included products that have a notice requirement. The entries in the NOTICE file need to be the minimum required. Chukwa's KEYS file containing PGP keys we use to sign the release: http://people.apache.org/~eyang/chukwa-0.5.0-rc2/KEYS Please download, evaluate, and vote on general@incubator. The PPMC vote thread is in progress at the same time as general@incubator. Changes since rc1: - Updated LICENSE and NOTICE files to reflect changes base on ipmc feedback. - Updated Hadoop dependency to Hadoop 1.0.0. The vote will close at 12:30pm PST on Thursday January 12, 2012. Thanks regards, Eric - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: Podling rename, vote needed?
On 10 January 2012 02:29, Jukka Zitting jukka.zitt...@gmail.com wrote: Hi, [to: general@, cc: callback-dev@] As discussed during the Callback proposal phase [1], the podling community wasn't too certain about the Callback name and thus after some discussion they recently voted [2] on adopting the new name Apache Cordova. The vote and its result was mentioned in the December status report [3]. Now the question came up [4] about whether such a rename needs to be explicitly approved by a vote of the IPCM. Personally I don't think one is needed, as the possible need for such a rename was already discussed on general@, and as the community vote itself and the related name selection process was monitored by us mentors. A similar process was followed when the Lucene Connector Framework podling changed it's name to ManifoldCF [5]. Thus we never asked the podling to bring the matter to the IPMC for a formal vote. However, if people feel that an IPMC vote on this is needed, we'll happily comply. On a related matter, how is the rename being handled for the various incubator data files, web-pages, mailing lists etc.? People need to be able to find the podling under its new name, and clutch etc. need to be able to keep track of the podling status. There need to be redirects added for web-pages if/when the old pages are renamed. [1] http://markmail.org/message/i6d2nrwdbqse3rqs [2] http://markmail.org/message/kq3oa7wewl5ltvic [3] http://wiki.apache.org/incubator/December2011 [4] https://issues.apache.org/jira/browse/INFRA-4306?focusedCommentId=13182966page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-13182966 [5] http://wiki.apache.org/incubator/December2010 BR, Jukka Zitting - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: [VOTE] Recommend graduating Apache Bean-Validation (BVAL) as a TLP
On 8 January 2012 21:04, Mark Struberg strub...@yahoo.de wrote: Dear IPMC, dear Community! The Apache Bean-Validation project provides an ALv2 licensed implementation of the JSR-303 Bean Validation Specification and would like to start a VOTE on graduating as a TLP. The podling is in the incubator since 2010 and successfully shipped 3 releases and established an active community. The internal PPMC VOTE has decided with 11 +1 (see [1]) that we would like to propose graduation as a TLP. We also went through the graduation checklist and made sure that we fulfilled all requirements. We would like to thank our Mentors and the board for their continued support and also Roman Stumm and his team for contributing this project to the ASF! We are happy to finally start the VOTE about the recommendation to the board about graduating BVAL to a TLP with the Board Resolution Report attached below. For better readability, the Resolution text is also available in our WIKI [2] Please VOTE on recommending BVAL as a TLP [+1] graduate BVAL as a TLP [+0] don't care [-1] nope, because (fill in) The VOTE is open for 72h. Incubator Page : http://incubator.apache.org/bval Status Page : http://incubator.apache.org/projects/beanvalidation.html thanks, the BVAL PPMC Board Resolution Report -- 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 Management Committee charged with the creation and maintenance of open-source software related to creating an implementation compliant with JSR-303 and a library of pre-developed validators and extensions for distribution at no charge to the public. I'm not sure I follow the sentence after related to. implementation of what? Do the validators and extensions relate to JSR-303? Or are they independent? Is this Java-only software, or could other languages be used? NOW, THEREFORE, BE IT RESOLVED, that a Project Management Committee (PMC), to be known as the Apache Bean Validation Project, be and hereby is established pursuant to Bylaws of the Foundation; and be it further RESOLVED, that the Apache Bean Validation Project be and hereby is responsible for the creation and maintenance of software related to creating an implementation compliant with JSR-303 and a library of pre-developed validators and extensions; and be it further RESOLVED, that the office of Vice President, Apache Bean Validation 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 Bean Validation Project, and to have primary responsibility for management of the projects within the scope of responsibility of the Apache Bean Validation Project; 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 Bean Validation Project: * Albert Lee allee8...@apache.org * Carlos Vara Callau carlosv...@apache.org * David Jencks djen...@apache.org * Donald Woods dwo...@apache.org * Gerhard Petracek gpetra...@apache.org * Jeremy Bauer jrba...@apache.org * Kevan Lee Miller ke...@apache.org * Luciano Resende lrese...@apache.org * Matthias Wessendorf mat...@apache.org * Matthew Jason Benson mben...@apache.org * Mohammad Nour El-Din mn...@apache.org * Niall Pemberton nia...@apache.org * Roman Stumm romanst...@apache.org * Simone Tripodi simonetrip...@apache.org * Mark Struberg strub...@apache.org NOW, THEREFORE, BE IT FURTHER RESOLVED, that Matthew Jason Benson be appointed to the office of Vice President, Apache Bean Validation, 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 initial Apache Bean Validation PMC be and hereby is tasked with the creation of a set of bylaws intended to encourage open development and increased participation in the Apache Bean Validation Project; and be it further RESOLVED, that the Apache Bean Validation Project be and hereby is tasked with the migration and rationalization of the Apache Incubator Bean Validation podling; and be it further RESOLVED, that all responsibilities pertaining to the Apache Incubator Bean Validation podling encumbered upon the Apache Incubator Project are hereafter discharged. [1] http://mail-archives.apache.org/mod_mbox/incubator-bval-dev/20.mbox/%3CCAOvkMoZ6EVNDZ2SNq44L992JTr_oquoJV2Oun-fKhpYX03DPiQ%40mail.gmail.com%3E [2] https://cwiki.apache.org/confluence/display/BeanValidation/Graduation+Proposal - To unsubscribe, e-mail:
Re: [VOTE] Chukwa 0.5.0 release candidate 1
On 6 January 2012 19:21, Eric Yang eric...@gmail.com wrote: Hi all, Chukwa 0.5.0 is ready for release. This will be the first incubator release for Chukwa. The source tarball artifact is available at: http://people.apache.org/~eyang/chukwa-0.5.0-rc1/ Agrees with the SVN tag, which is good. Sig and hash are OK, sig key is published. Documents are available at: http://people.apache.org/~eyang/chukwa-0.5.0-docs/ The SVN tag to be voted upon: https://svn.apache.org/repos/asf/incubator/chukwa/tags/chukwa-0.5.0-rc1/ There are quite a few files without any licenses at all, e.g. conf/aggregator.sql conf/database_create_tables.sql src/main/web/hicc/css/default.css The NOTICE file should only contain *required* notices. In particular, the following paragraph is not required: Chukwa incorporates a number of components, not copyright by the Apache Foundation, and under permissive licenses. The YUI license appears to require a notice, but there is none. There are probably other issues; did not check them all. The LICENSE file contains quite a few non-ASCII characters that don't display properly. There's no point repeating AL 2.0 for the components that use it; just state which components use the AL 2.0. Chukwa's KEYS file containing PGP keys we use to sign the release: http://people.apache.org/~eyang/chukwa-0.5.0-rc0/KEYS Please download, evaluate, and vote on general@incubator. The same artifacts have been tested and voted on chukwa-dev mailing list. The PPMC vote thread is: http://www.mail-archive.com/chukwa-dev@incubator.apache.org/msg00827.html The vote will close at 12:30pm PST on Tuesday January 10, 2012. Thanks regards, Eric - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: [VOTE] Chukwa 0.5.0 release candidate 0
On 3 January 2012 18:41, Eric Yang eric...@gmail.com wrote: Dear IPMC members, Chukwa 0.5.0 is ready for release. The artifacts are available at: http://people.apache.org/~eyang/chukwa-0.5.0-rc0/ Documents are available at: http://people.apache.org/~eyang/chukwa-0.5.0-docs/ The SVN tag to be voted upon: https://svn.apache.org/repos/asf/incubator/chukwa/tags/chukwa-0.5.0-rc0/ The NOTCE and LICENSE files contain several strange characters, which don't render OK. The NOTICE file also seems to contain references which are not required, e.g. The Prototype AJAX library license does not seem to require a notice. The NOTICE file is for *required* notices only. Chukwa's KEYS file containing PGP keys we use to sign the release: http://people.apache.org/~eyang/chukwa-0.5.0-rc0/KEYS Please download, evaluate, and vote on general@incubator. The same artifacts have been tested and voted on chukwa-dev mailing list. The PPMC vote thread is: http://www.mail-archive.com/chukwa-dev@incubator.apache.org/msg00814.html The vote will close at 12:30pm PST on Wednesday January 11, 2012. Thanks regards, Eric - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: Oversight of non-mailinglist-ful podlings
On 4 January 2012 19:45, Greg Stein gst...@gmail.com wrote: On Wed, Jan 4, 2012 at 14:33, Daniel Shahaf d...@daniel.shahaf.name wrote: Someone created https://svn.apache.org/repos/asf/incubator/devicemap/site/trunk/?p=1227271 before the devicemap-commits@ list was created. I expect no list received a commit mail about it. This PMC may want to review its mailer config and/or podling creation policies to ensure that no changes slip unnoticed. Saying once the commits mail flow, check the svn tree to see what it contained prior to the first commit that was emailed about might suffice. Couldn't we just have a default rule for asf/incubator/ go to private@incubator? Once a podling is constructed and configured, then its commit emails would go to the correct place. Seems like a good idea, but why use private@ - commit mails are not normally private are they? Would it not be better to send them to public-comm...@incubator.apache.org or general@incubator? Cheers, -g - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: [VOTE] Release Apache Rave 0.6-incubating
On 28 December 2011 19:15, Franklin, Matthew B. mfrank...@mitre.org wrote: This is the fifth incubator release for Apache Rave, with the artifacts being versioned as 0.6-incubating. We are requesting at least one additional IPMC member vote, as we have received 2 binding IPMC +1 votes during the release voting on rave-dev - VOTE: http://s.apache.org/Czr RESULT: http://s.apache.org/yIQ IPMC member votes from the rave-dev list: Ate Douma: +1 Ross Gardler: +1 Release notes: http://svn.apache.org/repos/asf/incubator/rave/tags/0.6-incubating/CHANGELOG which says: Release Notes - Rave - Version 0.5-INCUBATING So what was changed for 0.6? SVN source tag (r1208867): https://svn.apache.org/repos/asf/incubator/rave/tags/0.6-incubating/ Maven staging repos: https://repository.apache.org/content/repositories/orgapacherave-278/ https://repository.apache.org/content/repositories/orgapacherave-279/ Source release: https://repository.apache.org/content/repositories/orgapacherave-278/org/apache/rave/rave-project/0.6-incubating/rave-project-0.6-incubating-source-release.zip Binary releases http://people.apache.org/builds/incubator/rave/0.6-incubating/apache-rave-0.6-incubating-bin.tar.gz http://people.apache.org/builds/incubator/rave/0.6-incubating/apache-rave-0.6-incubating-bin.zip PGP release keys: https://svn.apache.org/repos/asf/incubator/rave/KEYS Vote open for 72 hours. [ ] +1 approve [ ] +0 no opinion [ ] -1 disapprove (and reason why) - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: [VOTE] Release Kafka 0.7.0-incubating
On 20 December 2011 18:51, Neha Narkhede neha.narkh...@gmail.com wrote: Hi, Kafka community is excited to share that RC 8 for release of Kafka-0.7.0-incubating has been +1'd over at kafka-user@incubator. Please try it out and vote for the Apache Kafka 0.7.0-incubating release. This is the first release of Kafka since we've joined the Apache incubator. Vote thread http://markmail.org/message/ijivestda64txwfi?q=kafka+candidate+8 Release artifacts http://people.apache.org/~nehanarkhede/kafka-0.7.0-incubating-candidate-8/ SVN revision https://svn.apache.org/repos/asf/incubator/kafka/tags/kafka-0.7.0-incubating-candidate-8 LICENSE file refers to SBT, but there is no mention in the NOTICE file. The SBT License says: 2. Redistributions in binary form must reproduce the above copyright notice,... which I read as requiring a mention in the NOTICE file. If SBT is shipped with Kafka, then the NOTICE file needs to be updated to include the relevant notice. If SBT is not included, then the LICENSE file should not include the SBT license. PGP release keys http://svn.apache.org/repos/asf/incubator/kafka/KEYS This vote is open until Friday, Dec 23rd 11 am Thanks for all the feedback until now. -Neha - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: [VOTE] Release Apache ODF Toolkit 0.5-incubating RC5
On 20 December 2011 02:30, Devin Han devin...@apache.org wrote: Thank you for point it out. Just as your comments, I agree to remove JUnit info from NOTICE.txt. But it should be reasonable to keep the statement that we JUnit dependence in LICENSE files. No, not if it is not included in the release artifacts. As our test code locate in the Apache SVN, it should also be a part of our artifacts. Generally developers are expected to already have a copy of JUnit for testing purposes. For Maven projects it is downloaded automatically if necessary, and Ant projects can do the same, e.g. Tomcat uses JUnit but does not bundle it. If JUnit is not included in the release artifacts it must not be mentioned in the NL files. I also see Apache POI keeping JUnit statement in their LICENSE file: https://svn.apache.org/repos/asf/poi/trunk/legal/LICENSE I've not looked at what POI bundles; there are a lot of incorrect NL files around and it may be one of them. 2011/12/16 sebb seb...@gmail.com On 16 December 2011 08:47, Devin Han devin...@apache.org wrote: Hi all, Please vote on releasing the following candidate as Apache ODF Toolkit (incubating) version 0.5. This will be the first incubator release for ODF Toolkit in Apache. This release candidate fixes the following issues found in RC3: (1) Add MD5, SHA1 hashes and GPG signatures for all of artifacts; (2) Fix the broken line endings issue in LICENSE.txt, HEADER.txt, and pom.xml. (3) Remove -rc3 from the name of artifacts. (4) Fix the Java 5 compatibility issue in XLST-Runner and Validator. The candidate for the ODF Toolkit 0.5-incubating release is available at: http://people.apache.org/~devinhan/odftoolkit-release/odftoolkit-0.5-incubating-rc5/ The release candidate is a zip archive of the sources in: https://svn.apache.org/repos/asf/incubator/odf/tags/0.5-incubating-rc5/ The NOTICE LICENSE files say that the product includes JUnit - but I could not find that on a brief check of the artifacts, and it's unusual to include test-only dependencies. If it's not included, it must not be mentioned in NL. The SHA1 checksum of the archive is cbecd91eda074f9c291c00995cfc43dfc0a4a0e2. Keys: http://www.apache.org/dist/incubator/odftoolkit/KEYS Please vote on releasing this package as Apache ODF Toolkit 0.5-incubating. The vote is open for the next 72 hours and passes if a majority of at least three +1 ODF Toolkit PMC votes are cast. [ ] +1 Release this package as Apache ODF Toolkit 0.5-incubating [ ] -1 Do not release this package because... -- -Devin - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org -- -Devin - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: [VOTE] Release Apache ODF Toolkit 0.5-incubating RC5
On 16 December 2011 08:47, Devin Han devin...@apache.org wrote: Hi all, Please vote on releasing the following candidate as Apache ODF Toolkit (incubating) version 0.5. This will be the first incubator release for ODF Toolkit in Apache. This release candidate fixes the following issues found in RC3: (1) Add MD5, SHA1 hashes and GPG signatures for all of artifacts; (2) Fix the broken line endings issue in LICENSE.txt, HEADER.txt, and pom.xml. (3) Remove -rc3 from the name of artifacts. (4) Fix the Java 5 compatibility issue in XLST-Runner and Validator. The candidate for the ODF Toolkit 0.5-incubating release is available at: http://people.apache.org/~devinhan/odftoolkit-release/odftoolkit-0.5-incubating-rc5/ The release candidate is a zip archive of the sources in: https://svn.apache.org/repos/asf/incubator/odf/tags/0.5-incubating-rc5/ The NOTICE LICENSE files say that the product includes JUnit - but I could not find that on a brief check of the artifacts, and it's unusual to include test-only dependencies. If it's not included, it must not be mentioned in NL. The SHA1 checksum of the archive is cbecd91eda074f9c291c00995cfc43dfc0a4a0e2. Keys: http://www.apache.org/dist/incubator/odftoolkit/KEYS Please vote on releasing this package as Apache ODF Toolkit 0.5-incubating. The vote is open for the next 72 hours and passes if a majority of at least three +1 ODF Toolkit PMC votes are cast. [ ] +1 Release this package as Apache ODF Toolkit 0.5-incubating [ ] -1 Do not release this package because... -- -Devin - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: svn commit: r1213736 - in /incubator/public/trunk: site-author/projects/openmeetings.xml site-publish/projects/openmeetings.html
On 13 December 2011 15:27, sebawag...@apache.org wrote:
Author: sebawagner
Date: Tue Dec 13 15:27:36 2011
New Revision: 1213736
URL: http://svn.apache.org/viewvc?rev=1213736view=rev
Log:
Update OpenMeetings committers account names
Modified:
incubator/public/trunk/site-author/projects/openmeetings.xml
incubator/public/trunk/site-publish/projects/openmeetings.html
Modified: incubator/public/trunk/site-author/projects/openmeetings.xml
URL:
http://svn.apache.org/viewvc/incubator/public/trunk/site-author/projects/openmeetings.xml?rev=1213736r1=1213735r2=1213736view=diff
==
--- incubator/public/trunk/site-author/projects/openmeetings.xml [utf-8]
(original)
+++ incubator/public/trunk/site-author/projects/openmeetings.xml [utf-8] Tue
Dec 13 15:27:36 2011
@@ -135,12 +135,12 @@
/tr
tr
td./td
- tdsolomax/td
+ tdsolomax666/td
Why was that entry changed?
AFAICT, there is no such login as solomax666, however there is a
solomax login which is also listed in the iclas file.
tdMaxim Solodovnik/td
/tr
tr
td./td
- td/td
+ tdsxander/td
tdSascha Xander/td
/tr
tr
@@ -150,7 +150,7 @@
/tr
tr
td./td
- td/td
+ tdeschwert/td
tdEugen Schwert/td
/tr
tr
Modified: incubator/public/trunk/site-publish/projects/openmeetings.html
URL:
http://svn.apache.org/viewvc/incubator/public/trunk/site-publish/projects/openmeetings.html?rev=1213736r1=1213735r2=1213736view=diff
==
--- incubator/public/trunk/site-publish/projects/openmeetings.html [utf-8]
(original)
+++ incubator/public/trunk/site-publish/projects/openmeetings.html [utf-8]
Tue Dec 13 15:27:36 2011
@@ -1,534 +1,534 @@
-!DOCTYPE html PUBLIC -//W3C//DTD XHTML 1.0 Transitional//EN
- http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd;
-!--
- Licensed to the Apache Software Foundation (ASF) under one
- or more contributor license agreements. See the NOTICE file
- distributed with this work for additional information
- regarding copyright ownership. The ASF licenses this file
- to you under the Apache License, Version 2.0 (the
- License); you may not use this file except in compliance
- with the License. You may obtain a copy of the License at
-
- http://www.apache.org/licenses/LICENSE-2.0
-
- Unless required by applicable law or agreed to in writing,
- software distributed under the License is distributed on an
- AS IS BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY
- KIND, either express or implied. See the License for the
- specific language governing permissions and limitations
- under the License.
---
-html xmlns=http://www.w3.org/1999/xhtml;
- head
- meta http-equiv=Content-Type content=text/html; charset=utf-8 /
- link rel=stylesheet href=../style/bootstrap-1-3-0-min.css
type=text/css /
- link rel=stylesheet href=../style/style.css type=text/css /
- titleOpenMeetings Incubation Status - Apache Incubator/title
-
- /head
- body
- div class=container
- div class=row
-div class=span12
- a href=http://www.apache.org/;img
src=http://www.apache.org/images/asf_logo_wide.gif; alt=The Apache Software
Foundation border=0//a
-/div
-div class=span4
-a href=http://incubator.apache.org/;img
src=../images/apache-incubator-logo.png alt=Apache Incubator
border=0//a
-/div
-/div
- div class=rowdiv class=span16hr noshade=noshade
size=1//div/div
-
- div class=row
- div class=span4
- form action=http://www.google.com/search; method=get
- input value=incubator.apache.org name=sitesearch type=hidden/
- input size=20 name=q id=query type=text value=search...
- onclick=if(this.value == 'search...') {this.value = ''}/
- input name=Search value=Go type=submit/
- /form
- div class=menuheadera
-href=../projects/index.htmlIncubator Projects/a/div
- menu compact=compact
- /menu
- div class=menuheadera
-href=http://www.apache.org/foundation/glossary.html#Podling;Podlings
(What's that?)/a/div
- menu compact=compact
- lia href=../incubation/Incubation_Policy.htmlHow?
(Policy)/a/li
- lia href=../incubation/Roles_and_Responsibilities.htmlWho?
(Roles)/a/li
- lia href=../incubation/Process_Description.htmlWhen?
(Process)/a/li
- /menu
- div class=menuheadera
-href=../guides/index.htmlEntry Guides/a/div
- menu compact=compact
- lia href=../guides/proposal.htmlProposal Guide/a/li
- /menu
- div class=menuheadera
-href=../guides/index.htmlPodling Guides/a/div
- menu compact=compact
- lia href=../guides/committer.htmlPodling Committers/a/li
-
Re: svn commit: r1213805 - /incubator/public/trunk/site-publish/.htaccess
On 13 December 2011 17:47, lut...@apache.org wrote: Author: lutter Date: Tue Dec 13 17:47:07 2011 New Revision: 1213805 URL: http://svn.apache.org/viewvc?rev=1213805view=rev Log: Redirect Deltacloud to its new post-graduation site I assume you are going remove the /www/incubator.apache.org/deltacloud site as it is now inacessible? Modified: incubator/public/trunk/site-publish/.htaccess Modified: incubator/public/trunk/site-publish/.htaccess URL: http://svn.apache.org/viewvc/incubator/public/trunk/site-publish/.htaccess?rev=1213805r1=1213804r2=1213805view=diff == --- incubator/public/trunk/site-publish/.htaccess (original) +++ incubator/public/trunk/site-publish/.htaccess Tue Dec 13 17:47:07 2011 @@ -11,6 +11,7 @@ RedirectMatch Permanent ^/chemistry(.*) RedirectMatch Permanent ^/click(.*) http://click.apache.org$1 RedirectMatch Permanent ^/couchdb(.*) http://couchdb.apache.org$1 RedirectMatch Permanent ^/cxf(.*) http://cxf.apache.org$1 +RedirectMatch Permanent ^/deltacloud(.*) http://deltacloud.apache.org$1 RedirectMatch Permanent ^/derby(.*) http://db.apache.org/derby$1 RedirectMatch Permanent ^/directory(.*) http://directory.apache.org$1 RedirectMatch Permanent ^/esme(.*) http://esme.apache.org$1 - To unsubscribe, e-mail: cvs-unsubscr...@incubator.apache.org For additional commands, e-mail: cvs-h...@incubator.apache.org - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: svn commit: r1213805 - /incubator/public/trunk/site-publish/.htaccess
On 13 December 2011 23:29, David Lutterkort lut...@redhat.com wrote: On Tue, 2011-12-13 at 15:23 -0800, David Lutterkort wrote: On Tue, 2011-12-13 at 19:19 +, sebb wrote: On 13 December 2011 17:47, lut...@apache.org wrote: Author: lutter Date: Tue Dec 13 17:47:07 2011 New Revision: 1213805 URL: http://svn.apache.org/viewvc?rev=1213805view=rev Log: Redirect Deltacloud to its new post-graduation site I assume you are going remove the /www/incubator.apache.org/deltacloud site as it is now inacessible? Yes, I just wanted to make sure the redirect was properly in place before removing the old content. Actually, http://incubator.apache.org/deltacloud/ still gives me a 200; what else do I need to do to have the redirect pushed out to the servers ? Did you update the website on minotaur by running svn update? David - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: so the deadline for podling reports has passed, now what?
On 9 December 2011 05:45, David Crossley cross...@apache.org wrote: Joe Schaefer wrote: Have we made any actionable plans for dealing with the podling reports this month, or are we content letting the board reject yet another rollup of all the raw reports? You are now :-) Thanks. I would like to see us take some steps to process, comment on, and filter the reports in the time we have between now and Wednesday. Do others agree with this plan? Yes. Lets encourage everyone to be involved in the event, not just leave it to the Incubator PMC. We can gather bits into our report. If everyone in incubation would review it: - see how other projects are overcoming hurdles - perhaps it applies to your project - perhaps your project is missing their report: get it in - comment on other projects problems if you have solutions The IPMC can look for common issues and take forward or address. One general issue is that most of the descriptions use podling names as nouns, rather than as adjectives. -David - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: [DISCUSS][VOTE] Release ace version 0.8.1-incubator subprojects
On 8 December 2011 10:14, Karl Pauls karlpa...@gmail.com wrote: The vote on Release ace version 0.8.1-incubator subprojects has been running for 72h and we didn't see any more votes from IPMC members other than the 4 votes we already have from the vote on the ace dev list. Given that this release was created specifically because some issues with our last release where causing some debate on our should we ask for graduation vote I really would have hoped that we get some feedback on this one -- hence, I'm not saying this is a big factor in the lack of response, but normally votes include all the relevant information in the e-mail. In this case one has to go digging through another e-mail (using an offsite link as well) to find the details. The easier it is made for users, the more likely they are to respond. I'm copying the details below in case that helps anyone else: === After our community graduation vote lead to a lengthy discussion about the 0.8.0-incubator release we did, we decided to roll a new ACE release, based on the original release. In the release we fix the issue that our previous source artifacts did not contain a pom.xml so building them was hard. You can now download a single, or all sources, and build them with a single command. Also, we added an extra artifact that contains the full source code, which is there for convenience in case someone wants to download all the sources and start developing from there. We did that in a way that is somewhat similar to Sling, but instead of using svn:externals we used Maven to generate this artifact (for more see the README.txt inside org.apache.ace.release.full 0.8.1-incubator) -- hence, I would like to call a vote on the following ace 0.8.1-incubator subproject releases: ace-pom 0.8.1-incubator org.apache.ace.client.automation 0.8.1-incubator org.apache.ace.client.repository.api 0.8.1-incubator org.apache.ace.client.repository.helper.base 0.8.1-incubator org.apache.ace.client.repository.helper.bundle 0.8.1-incubator org.apache.ace.client.repository.helper.configuration 0.8.1-incubator org.apache.ace.client.repository.helper.user 0.8.1-incubator org.apache.ace.client.repository.impl 0.8.1-incubator org.apache.ace.client.repository.useradmin 0.8.1-incubator org.apache.ace.configurator 0.8.1-incubator org.apache.ace.configurator.serveruseradmin 0.8.1-incubator org.apache.ace.configurator.useradmin.task 0.8.1-incubator org.apache.ace.consolelogger 0.8.1-incubator org.apache.ace.deployment.api 0.8.1-incubator org.apache.ace.deployment.deploymentadmin 0.8.1-incubator org.apache.ace.deployment.provider.api 0.8.1-incubator org.apache.ace.deployment.provider.base 0.8.1-incubator org.apache.ace.deployment.provider.filebased 0.8.1-incubator org.apache.ace.deployment.provider.repositorybased 0.8.1-incubator org.apache.ace.deployment.servlet 0.8.1-incubator org.apache.ace.deployment.streamgenerator 0.8.1-incubator org.apache.ace.deployment.task 0.8.1-incubator org.apache.ace.discovery.api 0.8.1-incubator org.apache.ace.discovery.property 0.8.1-incubator org.apache.ace.discovery.upnp 0.8.1-incubator org.apache.ace.gateway.log 0.8.1-incubator org.apache.ace.gateway.log.store 0.8.1-incubator org.apache.ace.httplistener 0.8.1-incubator org.apache.ace.identification.api 0.8.1-incubator org.apache.ace.identification.ifconfig 0.8.1-incubator org.apache.ace.identification.property 0.8.1-incubator org.apache.ace.launcher 0.8.1-incubator org.apache.ace.location.upnp 0.8.1-incubator org.apache.ace.log 0.8.1-incubator org.apache.ace.log.listener 0.8.1-incubator org.apache.ace.log.servlet 0.8.1-incubator org.apache.ace.log.task 0.8.1-incubator org.apache.ace.managementagent 0.8.1-incubator org.apache.ace.nodelauncher.amazon 0.8.1-incubator org.apache.ace.nodelauncher.api 0.8.1-incubator org.apache.ace.nodelauncher.ui 0.8.1-incubator org.apache.ace.obr.metadata 0.8.1-incubator org.apache.ace.obr.servlet 0.8.1-incubator org.apache.ace.obr.storage 0.8.1-incubator org.apache.ace.range.api 0.8.1-incubator org.apache.ace.release.full 0.8.1-incubator org.apache.ace.repository.api 0.8.1-incubator org.apache.ace.repository.ext 0.8.1-incubator org.apache.ace.repository.impl 0.8.1-incubator org.apache.ace.repository.servlet 0.8.1-incubator org.apache.ace.repository.task 0.8.1-incubator org.apache.ace.resourceprocessor.useradmin 0.8.1-incubator org.apache.ace.scheduler 0.8.1-incubator org.apache.ace.scheduler.api 0.8.1-incubator org.apache.ace.server.action 0.8.1-incubator org.apache.ace.server.action.popupmessage 0.8.1-incubator org.apache.ace.server.log.store 0.8.1-incubator org.apache.ace.tageditor 0.8.1-incubator org.apache.ace.target.defaults 0.8.1-incubator org.apache.ace.target.devgateway 0.8.1-incubator org.apache.ace.target.devserver 0.8.1-incubator org.apache.ace.util 0.8.1-incubator org.apache.ace.webconsole.plugin 0.8.1-incubator org.apache.ace.webui.vaadin 0.8.1-incubator Staging repositories:
Re: [DISCUSS][VOTE] Release ace version 0.8.1-incubator subprojects
On 8 December 2011 10:39, sebb seb...@gmail.com wrote: On 8 December 2011 10:14, Karl Pauls karlpa...@gmail.com wrote: The vote on Release ace version 0.8.1-incubator subprojects has been running for 72h and we didn't see any more votes from IPMC members other than the 4 votes we already have from the vote on the ace dev list. Given that this release was created specifically because some issues with our last release where causing some debate on our should we ask for graduation vote I really would have hoped that we get some feedback on this one -- hence, I'm not saying this is a big factor in the lack of response, but normally votes include all the relevant information in the e-mail. In this case one has to go digging through another e-mail (using an offsite link as well) to find the details. The easier it is made for users, the more likely they are to respond. I'm copying the details below in case that helps anyone else: === After our community graduation vote lead to a lengthy discussion about the 0.8.0-incubator release we did, we decided to roll a new ACE release, based on the original release. In the release we fix the issue that our previous source artifacts did not contain a pom.xml so building them was hard. You can now download a single, or all sources, and build them with a single command. Also, we added an extra artifact that contains the full source code, which is there for convenience in case someone wants to download all the sources and start developing from there. We did that in a way that is somewhat similar to Sling, but instead of using svn:externals we used Maven to generate this artifact (for more see the README.txt inside org.apache.ace.release.full 0.8.1-incubator) -- hence, I would like to call a vote on the following ace 0.8.1-incubator subproject releases: ace-pom 0.8.1-incubator org.apache.ace.client.automation 0.8.1-incubator org.apache.ace.client.repository.api 0.8.1-incubator org.apache.ace.client.repository.helper.base 0.8.1-incubator org.apache.ace.client.repository.helper.bundle 0.8.1-incubator org.apache.ace.client.repository.helper.configuration 0.8.1-incubator org.apache.ace.client.repository.helper.user 0.8.1-incubator org.apache.ace.client.repository.impl 0.8.1-incubator org.apache.ace.client.repository.useradmin 0.8.1-incubator org.apache.ace.configurator 0.8.1-incubator org.apache.ace.configurator.serveruseradmin 0.8.1-incubator org.apache.ace.configurator.useradmin.task 0.8.1-incubator org.apache.ace.consolelogger 0.8.1-incubator org.apache.ace.deployment.api 0.8.1-incubator org.apache.ace.deployment.deploymentadmin 0.8.1-incubator org.apache.ace.deployment.provider.api 0.8.1-incubator org.apache.ace.deployment.provider.base 0.8.1-incubator org.apache.ace.deployment.provider.filebased 0.8.1-incubator org.apache.ace.deployment.provider.repositorybased 0.8.1-incubator org.apache.ace.deployment.servlet 0.8.1-incubator org.apache.ace.deployment.streamgenerator 0.8.1-incubator org.apache.ace.deployment.task 0.8.1-incubator org.apache.ace.discovery.api 0.8.1-incubator org.apache.ace.discovery.property 0.8.1-incubator org.apache.ace.discovery.upnp 0.8.1-incubator org.apache.ace.gateway.log 0.8.1-incubator org.apache.ace.gateway.log.store 0.8.1-incubator org.apache.ace.httplistener 0.8.1-incubator org.apache.ace.identification.api 0.8.1-incubator org.apache.ace.identification.ifconfig 0.8.1-incubator org.apache.ace.identification.property 0.8.1-incubator org.apache.ace.launcher 0.8.1-incubator org.apache.ace.location.upnp 0.8.1-incubator org.apache.ace.log 0.8.1-incubator org.apache.ace.log.listener 0.8.1-incubator org.apache.ace.log.servlet 0.8.1-incubator org.apache.ace.log.task 0.8.1-incubator org.apache.ace.managementagent 0.8.1-incubator org.apache.ace.nodelauncher.amazon 0.8.1-incubator org.apache.ace.nodelauncher.api 0.8.1-incubator org.apache.ace.nodelauncher.ui 0.8.1-incubator org.apache.ace.obr.metadata 0.8.1-incubator org.apache.ace.obr.servlet 0.8.1-incubator org.apache.ace.obr.storage 0.8.1-incubator org.apache.ace.range.api 0.8.1-incubator org.apache.ace.release.full 0.8.1-incubator org.apache.ace.repository.api 0.8.1-incubator org.apache.ace.repository.ext 0.8.1-incubator org.apache.ace.repository.impl 0.8.1-incubator org.apache.ace.repository.servlet 0.8.1-incubator org.apache.ace.repository.task 0.8.1-incubator org.apache.ace.resourceprocessor.useradmin 0.8.1-incubator org.apache.ace.scheduler 0.8.1-incubator org.apache.ace.scheduler.api 0.8.1-incubator org.apache.ace.server.action 0.8.1-incubator org.apache.ace.server.action.popupmessage 0.8.1-incubator org.apache.ace.server.log.store 0.8.1-incubator org.apache.ace.tageditor 0.8.1-incubator org.apache.ace.target.defaults 0.8.1-incubator org.apache.ace.target.devgateway 0.8.1-incubator org.apache.ace.target.devserver 0.8.1-incubator org.apache.ace.util 0.8.1-incubator
Re: [DISCUSS][VOTE] Release ace version 0.8.1-incubator subprojects
On 8 December 2011 14:30, Karl Pauls karlpa...@gmail.com wrote: On Thu, Dec 8, 2011 at 1:08 PM, sebb seb...@gmail.com wrote: On 8 December 2011 10:39, sebb seb...@gmail.com wrote: On 8 December 2011 10:14, Karl Pauls karlpa...@gmail.com wrote: The vote on Release ace version 0.8.1-incubator subprojects has been running for 72h and we didn't see any more votes from IPMC members other than the 4 votes we already have from the vote on the ace dev list. Given that this release was created specifically because some issues with our last release where causing some debate on our should we ask for graduation vote I really would have hoped that we get some feedback on this one -- hence, I'm not saying this is a big factor in the lack of response, but normally votes include all the relevant information in the e-mail. In this case one has to go digging through another e-mail (using an offsite link as well) to find the details. The easier it is made for users, the more likely they are to respond. I'm copying the details below in case that helps anyone else: === After our community graduation vote lead to a lengthy discussion about the 0.8.0-incubator release we did, we decided to roll a new ACE release, based on the original release. In the release we fix the issue that our previous source artifacts did not contain a pom.xml so building them was hard. You can now download a single, or all sources, and build them with a single command. Also, we added an extra artifact that contains the full source code, which is there for convenience in case someone wants to download all the sources and start developing from there. We did that in a way that is somewhat similar to Sling, but instead of using svn:externals we used Maven to generate this artifact (for more see the README.txt inside org.apache.ace.release.full 0.8.1-incubator) -- hence, I would like to call a vote on the following ace 0.8.1-incubator subproject releases: ace-pom 0.8.1-incubator org.apache.ace.client.automation 0.8.1-incubator org.apache.ace.client.repository.api 0.8.1-incubator org.apache.ace.client.repository.helper.base 0.8.1-incubator org.apache.ace.client.repository.helper.bundle 0.8.1-incubator org.apache.ace.client.repository.helper.configuration 0.8.1-incubator org.apache.ace.client.repository.helper.user 0.8.1-incubator org.apache.ace.client.repository.impl 0.8.1-incubator org.apache.ace.client.repository.useradmin 0.8.1-incubator org.apache.ace.configurator 0.8.1-incubator org.apache.ace.configurator.serveruseradmin 0.8.1-incubator org.apache.ace.configurator.useradmin.task 0.8.1-incubator org.apache.ace.consolelogger 0.8.1-incubator org.apache.ace.deployment.api 0.8.1-incubator org.apache.ace.deployment.deploymentadmin 0.8.1-incubator org.apache.ace.deployment.provider.api 0.8.1-incubator org.apache.ace.deployment.provider.base 0.8.1-incubator org.apache.ace.deployment.provider.filebased 0.8.1-incubator org.apache.ace.deployment.provider.repositorybased 0.8.1-incubator org.apache.ace.deployment.servlet 0.8.1-incubator org.apache.ace.deployment.streamgenerator 0.8.1-incubator org.apache.ace.deployment.task 0.8.1-incubator org.apache.ace.discovery.api 0.8.1-incubator org.apache.ace.discovery.property 0.8.1-incubator org.apache.ace.discovery.upnp 0.8.1-incubator org.apache.ace.gateway.log 0.8.1-incubator org.apache.ace.gateway.log.store 0.8.1-incubator org.apache.ace.httplistener 0.8.1-incubator org.apache.ace.identification.api 0.8.1-incubator org.apache.ace.identification.ifconfig 0.8.1-incubator org.apache.ace.identification.property 0.8.1-incubator org.apache.ace.launcher 0.8.1-incubator org.apache.ace.location.upnp 0.8.1-incubator org.apache.ace.log 0.8.1-incubator org.apache.ace.log.listener 0.8.1-incubator org.apache.ace.log.servlet 0.8.1-incubator org.apache.ace.log.task 0.8.1-incubator org.apache.ace.managementagent 0.8.1-incubator org.apache.ace.nodelauncher.amazon 0.8.1-incubator org.apache.ace.nodelauncher.api 0.8.1-incubator org.apache.ace.nodelauncher.ui 0.8.1-incubator org.apache.ace.obr.metadata 0.8.1-incubator org.apache.ace.obr.servlet 0.8.1-incubator org.apache.ace.obr.storage 0.8.1-incubator org.apache.ace.range.api 0.8.1-incubator org.apache.ace.release.full 0.8.1-incubator org.apache.ace.repository.api 0.8.1-incubator org.apache.ace.repository.ext 0.8.1-incubator org.apache.ace.repository.impl 0.8.1-incubator org.apache.ace.repository.servlet 0.8.1-incubator org.apache.ace.repository.task 0.8.1-incubator org.apache.ace.resourceprocessor.useradmin 0.8.1-incubator org.apache.ace.scheduler 0.8.1-incubator org.apache.ace.scheduler.api 0.8.1-incubator org.apache.ace.server.action 0.8.1-incubator org.apache.ace.server.action.popupmessage 0.8.1-incubator org.apache.ace.server.log.store 0.8.1-incubator org.apache.ace.tageditor 0.8.1-incubator org.apache.ace.target.defaults 0.8.1-incubator
Re: [DISCUSS][VOTE] Release ace version 0.8.1-incubator subprojects
On 8 December 2011 15:28, Karl Pauls karlpa...@gmail.com wrote: On Thu, Dec 8, 2011 at 4:21 PM, sebb seb...@gmail.com wrote: On 8 December 2011 14:30, Karl Pauls karlpa...@gmail.com wrote: On Thu, Dec 8, 2011 at 1:08 PM, sebb seb...@gmail.com wrote: On 8 December 2011 10:39, sebb seb...@gmail.com wrote: On 8 December 2011 10:14, Karl Pauls karlpa...@gmail.com wrote: The vote on Release ace version 0.8.1-incubator subprojects has been running for 72h and we didn't see any more votes from IPMC members other than the 4 votes we already have from the vote on the ace dev list. Given that this release was created specifically because some issues with our last release where causing some debate on our should we ask for graduation vote I really would have hoped that we get some feedback on this one -- hence, I'm not saying this is a big factor in the lack of response, but normally votes include all the relevant information in the e-mail. In this case one has to go digging through another e-mail (using an offsite link as well) to find the details. The easier it is made for users, the more likely they are to respond. I'm copying the details below in case that helps anyone else: === After our community graduation vote lead to a lengthy discussion about the 0.8.0-incubator release we did, we decided to roll a new ACE release, based on the original release. In the release we fix the issue that our previous source artifacts did not contain a pom.xml so building them was hard. You can now download a single, or all sources, and build them with a single command. Also, we added an extra artifact that contains the full source code, which is there for convenience in case someone wants to download all the sources and start developing from there. We did that in a way that is somewhat similar to Sling, but instead of using svn:externals we used Maven to generate this artifact (for more see the README.txt inside org.apache.ace.release.full 0.8.1-incubator) -- hence, I would like to call a vote on the following ace 0.8.1-incubator subproject releases: ace-pom 0.8.1-incubator org.apache.ace.client.automation 0.8.1-incubator org.apache.ace.client.repository.api 0.8.1-incubator org.apache.ace.client.repository.helper.base 0.8.1-incubator org.apache.ace.client.repository.helper.bundle 0.8.1-incubator org.apache.ace.client.repository.helper.configuration 0.8.1-incubator org.apache.ace.client.repository.helper.user 0.8.1-incubator org.apache.ace.client.repository.impl 0.8.1-incubator org.apache.ace.client.repository.useradmin 0.8.1-incubator org.apache.ace.configurator 0.8.1-incubator org.apache.ace.configurator.serveruseradmin 0.8.1-incubator org.apache.ace.configurator.useradmin.task 0.8.1-incubator org.apache.ace.consolelogger 0.8.1-incubator org.apache.ace.deployment.api 0.8.1-incubator org.apache.ace.deployment.deploymentadmin 0.8.1-incubator org.apache.ace.deployment.provider.api 0.8.1-incubator org.apache.ace.deployment.provider.base 0.8.1-incubator org.apache.ace.deployment.provider.filebased 0.8.1-incubator org.apache.ace.deployment.provider.repositorybased 0.8.1-incubator org.apache.ace.deployment.servlet 0.8.1-incubator org.apache.ace.deployment.streamgenerator 0.8.1-incubator org.apache.ace.deployment.task 0.8.1-incubator org.apache.ace.discovery.api 0.8.1-incubator org.apache.ace.discovery.property 0.8.1-incubator org.apache.ace.discovery.upnp 0.8.1-incubator org.apache.ace.gateway.log 0.8.1-incubator org.apache.ace.gateway.log.store 0.8.1-incubator org.apache.ace.httplistener 0.8.1-incubator org.apache.ace.identification.api 0.8.1-incubator org.apache.ace.identification.ifconfig 0.8.1-incubator org.apache.ace.identification.property 0.8.1-incubator org.apache.ace.launcher 0.8.1-incubator org.apache.ace.location.upnp 0.8.1-incubator org.apache.ace.log 0.8.1-incubator org.apache.ace.log.listener 0.8.1-incubator org.apache.ace.log.servlet 0.8.1-incubator org.apache.ace.log.task 0.8.1-incubator org.apache.ace.managementagent 0.8.1-incubator org.apache.ace.nodelauncher.amazon 0.8.1-incubator org.apache.ace.nodelauncher.api 0.8.1-incubator org.apache.ace.nodelauncher.ui 0.8.1-incubator org.apache.ace.obr.metadata 0.8.1-incubator org.apache.ace.obr.servlet 0.8.1-incubator org.apache.ace.obr.storage 0.8.1-incubator org.apache.ace.range.api 0.8.1-incubator org.apache.ace.release.full 0.8.1-incubator org.apache.ace.repository.api 0.8.1-incubator org.apache.ace.repository.ext 0.8.1-incubator org.apache.ace.repository.impl 0.8.1-incubator org.apache.ace.repository.servlet 0.8.1-incubator org.apache.ace.repository.task 0.8.1-incubator org.apache.ace.resourceprocessor.useradmin 0.8.1-incubator org.apache.ace.scheduler 0.8.1-incubator org.apache.ace.scheduler.api 0.8.1-incubator org.apache.ace.server.action 0.8.1-incubator org.apache.ace.server.action.popupmessage 0.8.1-incubator org.apache.ace.server.log.store 0.8.1
Re: [DISCUSS][VOTE] Release ace version 0.8.1-incubator subprojects
On 8 December 2011 16:54, Karl Pauls karlpa...@gmail.com wrote: On Thu, Dec 8, 2011 at 5:17 PM, sebb seb...@gmail.com wrote: On 8 December 2011 15:28, Karl Pauls karlpa...@gmail.com wrote: On Thu, Dec 8, 2011 at 4:21 PM, sebb seb...@gmail.com wrote: On 8 December 2011 14:30, Karl Pauls karlpa...@gmail.com wrote: On Thu, Dec 8, 2011 at 1:08 PM, sebb seb...@gmail.com wrote: On 8 December 2011 10:39, sebb seb...@gmail.com wrote: On 8 December 2011 10:14, Karl Pauls karlpa...@gmail.com wrote: The vote on Release ace version 0.8.1-incubator subprojects has been running for 72h and we didn't see any more votes from IPMC members other than the 4 votes we already have from the vote on the ace dev list. Given that this release was created specifically because some issues with our last release where causing some debate on our should we ask for graduation vote I really would have hoped that we get some feedback on this one -- hence, I'm not saying this is a big factor in the lack of response, but normally votes include all the relevant information in the e-mail. In this case one has to go digging through another e-mail (using an offsite link as well) to find the details. The easier it is made for users, the more likely they are to respond. I'm copying the details below in case that helps anyone else: === After our community graduation vote lead to a lengthy discussion about the 0.8.0-incubator release we did, we decided to roll a new ACE release, based on the original release. In the release we fix the issue that our previous source artifacts did not contain a pom.xml so building them was hard. You can now download a single, or all sources, and build them with a single command. Also, we added an extra artifact that contains the full source code, which is there for convenience in case someone wants to download all the sources and start developing from there. We did that in a way that is somewhat similar to Sling, but instead of using svn:externals we used Maven to generate this artifact (for more see the README.txt inside org.apache.ace.release.full 0.8.1-incubator) -- hence, I would like to call a vote on the following ace 0.8.1-incubator subproject releases: ace-pom 0.8.1-incubator org.apache.ace.client.automation 0.8.1-incubator org.apache.ace.client.repository.api 0.8.1-incubator org.apache.ace.client.repository.helper.base 0.8.1-incubator org.apache.ace.client.repository.helper.bundle 0.8.1-incubator org.apache.ace.client.repository.helper.configuration 0.8.1-incubator org.apache.ace.client.repository.helper.user 0.8.1-incubator org.apache.ace.client.repository.impl 0.8.1-incubator org.apache.ace.client.repository.useradmin 0.8.1-incubator org.apache.ace.configurator 0.8.1-incubator org.apache.ace.configurator.serveruseradmin 0.8.1-incubator org.apache.ace.configurator.useradmin.task 0.8.1-incubator org.apache.ace.consolelogger 0.8.1-incubator org.apache.ace.deployment.api 0.8.1-incubator org.apache.ace.deployment.deploymentadmin 0.8.1-incubator org.apache.ace.deployment.provider.api 0.8.1-incubator org.apache.ace.deployment.provider.base 0.8.1-incubator org.apache.ace.deployment.provider.filebased 0.8.1-incubator org.apache.ace.deployment.provider.repositorybased 0.8.1-incubator org.apache.ace.deployment.servlet 0.8.1-incubator org.apache.ace.deployment.streamgenerator 0.8.1-incubator org.apache.ace.deployment.task 0.8.1-incubator org.apache.ace.discovery.api 0.8.1-incubator org.apache.ace.discovery.property 0.8.1-incubator org.apache.ace.discovery.upnp 0.8.1-incubator org.apache.ace.gateway.log 0.8.1-incubator org.apache.ace.gateway.log.store 0.8.1-incubator org.apache.ace.httplistener 0.8.1-incubator org.apache.ace.identification.api 0.8.1-incubator org.apache.ace.identification.ifconfig 0.8.1-incubator org.apache.ace.identification.property 0.8.1-incubator org.apache.ace.launcher 0.8.1-incubator org.apache.ace.location.upnp 0.8.1-incubator org.apache.ace.log 0.8.1-incubator org.apache.ace.log.listener 0.8.1-incubator org.apache.ace.log.servlet 0.8.1-incubator org.apache.ace.log.task 0.8.1-incubator org.apache.ace.managementagent 0.8.1-incubator org.apache.ace.nodelauncher.amazon 0.8.1-incubator org.apache.ace.nodelauncher.api 0.8.1-incubator org.apache.ace.nodelauncher.ui 0.8.1-incubator org.apache.ace.obr.metadata 0.8.1-incubator org.apache.ace.obr.servlet 0.8.1-incubator org.apache.ace.obr.storage 0.8.1-incubator org.apache.ace.range.api 0.8.1-incubator org.apache.ace.release.full 0.8.1-incubator org.apache.ace.repository.api 0.8.1-incubator org.apache.ace.repository.ext 0.8.1-incubator org.apache.ace.repository.impl 0.8.1-incubator org.apache.ace.repository.servlet 0.8.1-incubator org.apache.ace.repository.task 0.8.1-incubator org.apache.ace.resourceprocessor.useradmin 0.8.1-incubator org.apache.ace.scheduler 0.8.1-incubator org.apache.ace.scheduler.api 0.8.1-incubator
Re: [VOTE] accumulo-1.3.5-incubating RC9
On 4 December 2011 20:18, Eric Newton eric.new...@gmail.com wrote: Please vote on releasing the following candidate as Apache Accumulo (incubating) version 1.3.5. This will be the first incubator release for Accumulo. This release candidate fixes the minor issues found in rc8: * Added the component licenses to the LICENSE file * Fixed the URL for Flot * Added license headers to three files that were missing them * Fixed the system reference to thrift in the pom files * Removed the generated toc file * Specified the font encoding for the user manual * Updated the expected number of files missing licenses * Added LICENSE and other files to the jars I generated the tarballs by exporting https://svn.apache.org/repos/asf/incubator/accumulo/tags/1.3.5rc9 then running tar cvzf to create the src and running ./src/assemble/build.sh to create the dist. Tarballs, checksums, signatures: http://people.apache.org/~ecn/ Did not check these. MD5 sums: 8a30125a83bc5b46146d9b432d15ee8e accumulo-1.3.5-incubating-rc9-dist.tar.gz af273780b7c70e0a18833e29eb73 accumulo-1.3.5-incubating-rc9-src.tar.gz SVN tag: https://svn.apache.org/repos/asf/incubator/accumulo/tags/1.3.5rc9 NOTICE file mentions JLine (BSD license) but LICENSE file does not contain the BSD license as far as I can tell. LICENSE file contains license details for the org.apache.accumulo.core.bloomfilter.* classes, but does not mention them in NOTICE. I think the following wording: - Redistributions of source code must retain the above copyright notice, this list of conditions and the following disclaimer. means that the NOTICE should contain the following text: Copyright (c) 2005, European Commission project OneLab under contract 034819 (http://www.one-lab.org) All rights reserved. Keys: http://www.apache.org/dist/incubator/accumulo/KEYS The vote will be held open for the next 72 hours. Thanks, -Eric - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: [VOTE] Release Apache Accumulo 1.3.5-incubating (rc8)
On 29 November 2011 14:24, Eric Newton eric.new...@gmail.com wrote: This is the first incubator release for Apache Accumulo, with the artifacts versioned as 1.3.5-incubating. VOTE: http://www.mail-archive.com/accumulo-dev@incubator.apache.org/msg00939.html RESULT: http://www.mail-archive.com/accumulo-dev@incubator.apache.org/msg01038.html SVN source tag: http://svn.apache.org/viewvc/incubator/accumulo/tags/1.3.5rc8/ Release artifacts: http://people.apache.org/~ecn -1 The NOTICE file references non-Apache Licenses, but they are not in the LICENSES file. I've not yet done any other checks, but IMO this is a blocker. Vote closes in 72 hours. - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: Feedback on updated NOTICE and LICENSE files (was: [VOTE] Release Kafka 0.7.0-incubating)
On 2 December 2011 09:33, Jukka Zitting jukka.zitt...@gmail.com wrote: Hi, On Fri, Dec 2, 2011 at 3:32 AM, Jakob Homan jgho...@gmail.com wrote: You appear to have generated your list of jars from looking at kafka-0.7.0-incubating.tar.gz, the binary distribution that has been built as a customary courtesy as part of the release attempt. This includes quite a few jars that are not included in the source tree since binary distributions do include transitive dependencies. Are you saying that entries need to be included in NOTICE and LICENSE for jars/dlls that are included in binary releases? Yes, see http://www.apache.org/dev/release.html#distribute-other-artifacts If properly tracking the licenses of all the dependencies included in such a composite artifact is too much effort, you can always *not* publish the artifact. Just leave it up to downstream users to compile it and thus have them take over responsibility of properly managing the licensing status in case they want to redistribute the resulting artifacts. Or publish the binary versions of our source only, and leave it to users to download the dependencies. It's vitally important that the users are made aware of the licensing requirements for everything we publish. A quick check shows that neither Hadoop, nor HBase. nor Whirr (recently with a an incubator release) do not do this. Then these projects have some work to do. Can you file issues with these projects referring the above link and this email thread? BR, Jukka Zitting - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: [VOTE] Release Apache Accumulo 1.3.5-incubating (rc8)
On 2 December 2011 10:50, sebb seb...@gmail.com wrote: On 29 November 2011 14:24, Eric Newton eric.new...@gmail.com wrote: This is the first incubator release for Apache Accumulo, with the artifacts versioned as 1.3.5-incubating. VOTE: http://www.mail-archive.com/accumulo-dev@incubator.apache.org/msg00939.html RESULT: http://www.mail-archive.com/accumulo-dev@incubator.apache.org/msg01038.html SVN source tag: http://svn.apache.org/viewvc/incubator/accumulo/tags/1.3.5rc8/ Release artifacts: http://people.apache.org/~ecn Cannot find KEYS file to verify the sigs. A link to the KEYS file should be provided in the VOTE mail. It's not sufficient that the key be listed on public key servers (which this one is, which is good). The md5 and sha hash files have an unusual format that is unlikely to be recognised by many automated checkers. For example: accumulo-1.3.5-incubating-rc8-dist.tar.gz.md5 contains: target/accumulo-1.3.5-incubating-rc8-dist.tar.gz: B5 66 26 C8 20 3B 3D 2C ED 3F 81 9A 29 0E 28 60 The target/ prefix is spurious, and normally the hash is on the same line, for example: B56626C8203B3D2CED3F819A290E2860 target/accumulo-1.3.5-incubating-rc8-dist.tar.gz However, the source archive does agree with the SVN tag which is good. The dist archive also for some reason includes all the source, which agrees with the SVN tag except for the file src/user_manual/accumulo_user_manual.toc which slightly different from the SVN version. I would not expect the dist archive to duplicate the source; but perhaps there is a good reason. If so, then at least the source part needs to be identical to SVN. Though it looks more like the source was accidentally included, perhaps because source and generated output share the same directory structure? The dist archive includes apidocs and user manual which is good. Also contains various jar files, which is also OK except that the 3rd party jars need to be properly documented in the NOTICE and LICENSE files. Ideally, the jar files created from Accumulo source should contain their own N L files in the META-INF directory. For example, see how the included Apache commons-* jars do it. This becomes essential if the jars are to be released independently, for example to Maven Central. The cloudtrace jar classes have the package name cloudtrace/ I assume this is going to change before graduation? In which case, I think there may be an issue with the Maven pom id. Currently it uses: groupIdorg.apache.accumulo/groupId artifactIdcloudtrace/artifactId If the package name is changed, then one or both of the above need to change as well, otherwise Maven won't be able to resolve dependencies correctly where multiple versions are used (long story). -1 The NOTICE file references non-Apache Licenses, but they are not in the LICENSES file. I've not yet done any other checks, but IMO this is a blocker. Vote closes in 72 hours. - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: [VOTE] Release Apache Accumulo 1.3.5-incubating (rc8)
On 2 December 2011 10:50, sebb seb...@gmail.com wrote: On 29 November 2011 14:24, Eric Newton eric.new...@gmail.com wrote: This is the first incubator release for Apache Accumulo, with the artifacts versioned as 1.3.5-incubating. VOTE: http://www.mail-archive.com/accumulo-dev@incubator.apache.org/msg00939.html RESULT: http://www.mail-archive.com/accumulo-dev@incubator.apache.org/msg01038.html SVN source tag: http://svn.apache.org/viewvc/incubator/accumulo/tags/1.3.5rc8/ Release artifacts: http://people.apache.org/~ecn -1 The NOTICE file references non-Apache Licenses, but they are not in the LICENSES file. I've not yet done any other checks, but IMO this is a blocker. Further investigation: NOTICE mentions Flot (MIT) and JLine (BSD). Both of these licenses are acceptable according to my reading of http://www.apache.org/legal/resolved.html However, the MIT and BSD licenses need to be included in the LICENSE file. Prefix the licence with details of the code to which it applies. For example, see http://svn.apache.org/repos/asf/httpd/httpd/trunk/LICENSE BTW, the Flot URL - (http://http://code.google.com/p/flot/) - is incorrect and must be fixed. [It took me a while to find the Flot code, as it is Javascript, not a jar] Vote closes in 72 hours. - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: When are board reports due?
On 2 December 2011 13:11, Tim Williams william...@gmail.com wrote: Marvin says... supply board reports 2 weeks before the above date (Wed, Dec 7th). That's Incubator Marvin, who requires podlings to provide an extra week's notice The December report[1] says... reports are due here by the first day of the month Not sure about that discrepancy. And the reporting schedule[2] says... should have their reports ready by no later than the second Wednesday of that month (Wed, Dec 14th in this case). The link is missing, but I assume that's Board Marvin who e-mails PMCs. I reckon the board's recent decision of 1 week notice has caused some docs to be out of sync and I've probably missed the discussion. What is the correct due date? AIUI, one week for TLPs including the Incubator to report to the Board. 2 weeks for podlings, to give the Incubator PMC time to review and request updates if necessary. Thanks, --tim [1] - http://wiki.apache.org/incubator/December2011 - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: When are board reports due?
On 2 December 2011 13:38, Tim Williams william...@gmail.com wrote: On Fri, Dec 2, 2011 at 8:33 AM, sebb seb...@gmail.com wrote: On 2 December 2011 13:11, Tim Williams william...@gmail.com wrote: Marvin says... supply board reports 2 weeks before the above date (Wed, Dec 7th). That's Incubator Marvin, who requires podlings to provide an extra week's notice The December report[1] says... reports are due here by the first day of the month Not sure about that discrepancy. And the reporting schedule[2] says... should have their reports ready by no later than the second Wednesday of that month (Wed, Dec 14th in this case). The link is missing, but I assume that's Board Marvin who e-mails PMCs. Ooops... no, that's the ReportSchedule wiki page - I didn't look at board's marvin: http://wiki.apache.org/incubator/ReportingSchedule In which case, IIRC that was also suggested on this list as a podling report deadline, as being easy to remember, and not too late. The November board meeting was a week earlier than usual, which might also have been relevant. Unless someone says otherwise, I'll stick with Incubator's marvin as sebb suggested... Thanks, --tim - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: [VOTE] Release Apache Accumulo 1.3.5-incubating (rc8)
On 2 December 2011 14:12, Billie J Rinaldi billie.j.rina...@ugov.gov wrote: On Friday, December 2, 2011 7:11:36 AM, sebb seb...@gmail.com wrote: Cannot find KEYS file to verify the sigs. It's here: http://www.apache.org/dist/incubator/accumulo/KEYS Thanks, please include the link in future vote mails. The md5 and sha hash files have an unusual format that is unlikely to be recognised by many automated checkers. The sections on checksums in the release FAQ list gpg as an acceptable method of generating those files. If it isn't, perhaps this could be changed in the FAQ? http://www.apache.org/dev/release-signing.html#md5 OK, but that does say filename rather than pathname. The target/ prefix needs to be removed. [I will update the page later.] So please remove the spurious target/ prefixes from the next RC. Though it looks more like the source was accidentally included, perhaps because source and generated output share the same directory structure? The source is intentionally included in the dist. We can fix that .toc file. Most other projects release binary (rather than dist) archives; the binary archive will contain those source files that are used at runtime, but normally files that have been compiled into a jar are omitted. But this is not a blocker. Also contains various jar files, which is also OK except that the 3rd party jars need to be properly documented in the NOTICE and LICENSE files. Ideally, the jar files created from Accumulo source should contain their own N L files in the META-INF directory. For example, see how the included Apache commons-* jars do it. This becomes essential if the jars are to be released independently, for example to Maven Central. We'll look into the notice and license file issues. The cloudtrace jar classes have the package name cloudtrace/ I assume this is going to change before graduation? In which case, I think there may be an issue with the Maven pom id. Currently it uses: groupIdorg.apache.accumulo/groupId artifactIdcloudtrace/artifactId If the package name is changed, then one or both of the above need to change as well, otherwise Maven won't be able to resolve dependencies correctly where multiple versions are used (long story). We'll make sure to change the artifactID when changing the package name. OK; again not a blocker. Thanks for your help! Billie - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: [RFC] Proposed voting description edits
On 1 December 2011 23:24, David Crossley cross...@apache.org wrote: sebb wrote: OK? Wow, thanks for that effort. Please do. Now done. Had to make minor tweaks for readability. If there are any complaints with my changes, please raise ASAP so they can be fixed. - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: Feedback on updated NOTICE and LICENSE files (was: [VOTE] Release Kafka 0.7.0-incubating)
On 1 December 2011 06:16, Dennis E. Hamilton dennis.hamil...@acm.org wrote: I notice that the NOTICE has this incomplete statement: This product includes the scala runtime and compiler (www.scala-lang.org) developed by EPFL, which includes the following license: There is not any following license. Nor should there be in the NOTICE file. I think the SCALA NOTICE should read This product includes the scala runtime and compiler (www.scala-lang.org) Copyright (c) 2002-2010 EPFL, Lausanne, unless otherwise specified. In my reading of it, that is all the license requires. This assumes that the product does indeed *include* the SCALA compiler. Otherwise the references must be removed from NOTICE and LICENSE. I also notice that the LICENSE file has copyright notices. I don't think that's a problem; they are often included in 3rd party licenses. - Dennis -Original Message- From: Neha Narkhede [mailto:neha.narkh...@gmail.com] Sent: Wednesday, November 30, 2011 18:30 To: general@incubator.apache.org Cc: kafka-us...@incubator.apache.org Subject: Feedback on updated NOTICE and LICENSE files (was: [VOTE] Release Kafka 0.7.0-incubating) Hi, The Kafka community is hoping to get some feedback on the updated NOTICE and LICENSE files for Kafka, before we post a new vote for it. http://people.apache.org/~nehanarkhede/NOTICE http://people.apache.org/~nehanarkhede/LICENSE The previous vote thread or release artifacts are here - http://apache.markmail.org/message/hntuhwkbazwlfdoe?q=Kafka+list:org.apache.incubator.general We would appreciate it if you can please take the time to review this now, since we would like to ensure a smoother vote this time around. Thanks, Neha - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
