Re: Feedback on updated NOTICE and LICENSE files (was: [VOTE] Release Kafka 0.7.0-incubating)
On Thu, Dec 1, 2011 at 10:04 PM, Jun Rao jun...@gmail.com wrote: Does Apache has tools (like rat) to extract all the needed license? Digging out the license manually is both labour intensive and error prone. The rat community has started working on whisker[1] (and some other tools) but we really need more volunteers to step forward and start contributing to the development. Some other tools have also been seeded recently (eye and tentacles) but we need volunteers to step forward to document and polish them for a wider audience. Robert [1] http://svn.apache.org/repos/asf/incubator/rat/whisker/trunk - 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)
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. 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
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: Feedback on updated NOTICE and LICENSE files (was: [VOTE] Release Kafka 0.7.0-incubating)
On Fri, Dec 2, 2011 at 10:55 AM, sebb seb...@gmail.com wrote: 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. +1 Tracking licensing for applications composed from hundreds of components is non-trivial, and - without build support - is a *lot* of work. This is just one key service provided by a healthy downstream ecosystem. But unless consumers can download and get started, this ecosystem may be slow to grow. The approach - inspired by Lean and Continuous Delivery - we're trying over the James and Whisker is to extend the release pipeline. Separate concerns about the official release of source and components from those about assembling an official application from those component an the other dependencies required. Release first the source and components, and then work on an application release from those components. Robert - 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
When are board reports due?
Marvin says... supply board reports 2 weeks before the above date (Wed, Dec 7th). The December report[1] says... reports are due here by the first day of the month 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). 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? 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
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 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 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
Re: Change in Due Dates for Board reports
Hi Andrew, On Wed, Nov 30, 2011 at 6:14 PM, Andrew Savory asav...@apache.org wrote: ...We need to update http://apache.org/foundation/board/reporting and http://community.apache.org/boardreport.html to reflect this change and to be consistent with each other. The pages currently disagree on when reporting should happen:... I have removed the details of the reporting schedule in both (revisions 799610 and 799612), to avoid duplicated information. -Bertrand - 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 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 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 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. 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. Thanks for your help! Billie - 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
[PROPOSAL] Apache Bloodhound
Hello Incubator! WANdisco would like to propose the inclusion of a new project, Apache Bloodhound, to the Incubator. The proposal has been posted to the wiki[1], and is also included below. We've privately discussed this project with a number of individuals, but would now like to get the discussion rolling here. Bloodhound is new effort, based on Trac[2], to provide issue tracking and collaboration tools for developers. We realize the proposal is a work-in-progress, and as such look forward to feedback and discussion. We hope to attract mentors and other interested parties through the incubation proposal process, and further diversify the community as we move through incubation. In particular, this project is an opportunity to build a new community around the codebase, and we look forward to doing so at the ASF. -Hyrum [1] http://wiki.apache.org/incubator/BloodhoundProposal [2] http://trac.edgewall.org/ = Bloodhound - Collaborative development tools based on Trac = == Abstract == Bloodhound will be a software development collaboration tool, including issue tracking, wiki and repository browsing. Essentially an improved distribution of the well-known Trac project, Bloodhound will include the common and useful plugins to enable a more complete distribution than a typical Trac installation. == Proposal == Bloodhound will be a software development collaboration tool, based on the existing Trac project, which will include a repository browser, wiki, and defect tracker. In addition to the standard Trac installation, Bloodhound will incorporate a number of popular modules into the core distribution, and include additional improvements developed (as [[http://trac-hacks.org/|plugins]]) outside the Trac project. == Background == The [[http://trac.edgewall.org/|Trac project]] is a BSD-licensed collaboration tool used to assist in software development. It has a wide user base, a pluggable infrastructure, and is generally considered stable. By it's own recognition, however, the development community surrounding Trac has largely dissipated, with little mailing list traffic, and very few commits to the source code repository (see [2]). Private efforts to engage the existing developers in implementing features have been negatively received. At the same time, other individuals and companies, such as [[http://www.wandisco.com|WANdisco]], have expressed interest in helping continue to develop Trac. These entities would prefer this effort to be at a vendor-neutral location, with the clear process for intellectual property management that comes from the Foundation. As such, the Apache Software Foundation feels like the best fit for this new project based on Trac. == Rationale == As discussed earlier, the current Trac development community is small and reluctant to accept outside contributions. Given the Foundation’s reputation for building and maintaining communities, we feel a new project, based on Trac but incubated under the Apache umbrella, would help re-build the developer community, jump started by developer time donated by WANdisco. Additionally, as a developer tool, Bloodhound is a good fit with other, similarly-focused developer tools at the ASF. Private discussions have shown there is some interest by third-parties to release internal improvements to Trac, and Bloodhound gives them an additional venue to do so. == Initial Goals == The initial goals for Bloodhound primarily revolve around migrating the existing code base and integrating external features to make the project easy to deploy. Additional ideas will of course follow, but the following goals are sufficiently difficult to be considered early milestones. Some of the initial goals include: * Migrate the existing BSD-licensed Trac code base to the ASF. * Attract developer and user interest in the new Bloodhound project. * Incorporate externally developed features into the core Bloodhound project. * Package the most popular plugins into the core project, so installations and administration of Bloodhound becomes dead simple. = Current Status = == Meritocracy == Although initially corporate-sponsored, any interested developers would be granted commit access. Even developers employed by the sponsoring companies would be required to demonstrate competency to gain commit privileges. Individuals with corporate affiliations would understandably be known within the community, but would not have bearing on the granting of commit privileges. == Community == One of the primary purposes of this proposal is to develop a strong developer community around the Trac code base. The current developers and supporting institution have moved on to other things, and this has caused stagnation in the existing community. We want to use the experience of the Incubator PMC, and the incubation process, to reboot the developer community, while at the same time incorporating oft-requested features into the existing product. Building
Re: [PROPOSAL] Apache Bloodhound
so this is basically Trac ++ and a fork of Trac ? Or is it a completely rewritten new approach? just curious :) LieGrue, strub - Original Message - From: Hyrum K Wright hyrum.wri...@wandisco.com To: general@incubator.apache.org Cc: Ian Wild ian.w...@wandisco.com; Greg Stein gst...@gmail.com Sent: Friday, December 2, 2011 4:53 PM Subject: [PROPOSAL] Apache Bloodhound Hello Incubator! WANdisco would like to propose the inclusion of a new project, Apache Bloodhound, to the Incubator. The proposal has been posted to the wiki[1], and is also included below. We've privately discussed this project with a number of individuals, but would now like to get the discussion rolling here. Bloodhound is new effort, based on Trac[2], to provide issue tracking and collaboration tools for developers. We realize the proposal is a work-in-progress, and as such look forward to feedback and discussion. We hope to attract mentors and other interested parties through the incubation proposal process, and further diversify the community as we move through incubation. In particular, this project is an opportunity to build a new community around the codebase, and we look forward to doing so at the ASF. -Hyrum [1] http://wiki.apache.org/incubator/BloodhoundProposal [2] http://trac.edgewall.org/ = Bloodhound - Collaborative development tools based on Trac = == Abstract == Bloodhound will be a software development collaboration tool, including issue tracking, wiki and repository browsing. Essentially an improved distribution of the well-known Trac project, Bloodhound will include the common and useful plugins to enable a more complete distribution than a typical Trac installation. == Proposal == Bloodhound will be a software development collaboration tool, based on the existing Trac project, which will include a repository browser, wiki, and defect tracker. In addition to the standard Trac installation, Bloodhound will incorporate a number of popular modules into the core distribution, and include additional improvements developed (as [[http://trac-hacks.org/|plugins]]) outside the Trac project. == Background == The [[http://trac.edgewall.org/|Trac project]] is a BSD-licensed collaboration tool used to assist in software development. It has a wide user base, a pluggable infrastructure, and is generally considered stable. By it's own recognition, however, the development community surrounding Trac has largely dissipated, with little mailing list traffic, and very few commits to the source code repository (see [2]). Private efforts to engage the existing developers in implementing features have been negatively received. At the same time, other individuals and companies, such as [[http://www.wandisco.com|WANdisco]], have expressed interest in helping continue to develop Trac. These entities would prefer this effort to be at a vendor-neutral location, with the clear process for intellectual property management that comes from the Foundation. As such, the Apache Software Foundation feels like the best fit for this new project based on Trac. == Rationale == As discussed earlier, the current Trac development community is small and reluctant to accept outside contributions. Given the Foundation’s reputation for building and maintaining communities, we feel a new project, based on Trac but incubated under the Apache umbrella, would help re-build the developer community, jump started by developer time donated by WANdisco. Additionally, as a developer tool, Bloodhound is a good fit with other, similarly-focused developer tools at the ASF. Private discussions have shown there is some interest by third-parties to release internal improvements to Trac, and Bloodhound gives them an additional venue to do so. == Initial Goals == The initial goals for Bloodhound primarily revolve around migrating the existing code base and integrating external features to make the project easy to deploy. Additional ideas will of course follow, but the following goals are sufficiently difficult to be considered early milestones. Some of the initial goals include: * Migrate the existing BSD-licensed Trac code base to the ASF. * Attract developer and user interest in the new Bloodhound project. * Incorporate externally developed features into the core Bloodhound project. * Package the most popular plugins into the core project, so installations and administration of Bloodhound becomes dead simple. = Current Status = == Meritocracy == Although initially corporate-sponsored, any interested developers would be granted commit access. Even developers employed by the sponsoring companies would be required to demonstrate competency to gain commit privileges. Individuals with corporate affiliations would understandably be known within the community, but would not have bearing on the granting of commit privileges. ==
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: [PROPOSAL] Apache Bloodhound
On Fri, Dec 2, 2011 at 10:14 AM, Mark Struberg strub...@yahoo.de wrote: so this is basically Trac ++ and a fork of Trac ? Pretty much. It's Trac plus a number of commonly used plugins plus additional functionality. There's been some discussion about this with the principles on the Trac project, as well as on trac-dev, and so far there hasn't been any discord. Or is it a completely rewritten new approach? Bloodhound may eventually diverge from Trac, but that's up to the communities involved. -Hyrum - Original Message - From: Hyrum K Wright hyrum.wri...@wandisco.com To: general@incubator.apache.org Cc: Ian Wild ian.w...@wandisco.com; Greg Stein gst...@gmail.com Sent: Friday, December 2, 2011 4:53 PM Subject: [PROPOSAL] Apache Bloodhound Hello Incubator! WANdisco would like to propose the inclusion of a new project, Apache Bloodhound, to the Incubator. The proposal has been posted to the wiki[1], and is also included below. We've privately discussed this project with a number of individuals, but would now like to get the discussion rolling here. Bloodhound is new effort, based on Trac[2], to provide issue tracking and collaboration tools for developers. We realize the proposal is a work-in-progress, and as such look forward to feedback and discussion. We hope to attract mentors and other interested parties through the incubation proposal process, and further diversify the community as we move through incubation. In particular, this project is an opportunity to build a new community around the codebase, and we look forward to doing so at the ASF. -Hyrum [1] http://wiki.apache.org/incubator/BloodhoundProposal [2] http://trac.edgewall.org/ = Bloodhound - Collaborative development tools based on Trac = == Abstract == Bloodhound will be a software development collaboration tool, including issue tracking, wiki and repository browsing. Essentially an improved distribution of the well-known Trac project, Bloodhound will include the common and useful plugins to enable a more complete distribution than a typical Trac installation. == Proposal == Bloodhound will be a software development collaboration tool, based on the existing Trac project, which will include a repository browser, wiki, and defect tracker. In addition to the standard Trac installation, Bloodhound will incorporate a number of popular modules into the core distribution, and include additional improvements developed (as [[http://trac-hacks.org/|plugins]]) outside the Trac project. == Background == The [[http://trac.edgewall.org/|Trac project]] is a BSD-licensed collaboration tool used to assist in software development. It has a wide user base, a pluggable infrastructure, and is generally considered stable. By it's own recognition, however, the development community surrounding Trac has largely dissipated, with little mailing list traffic, and very few commits to the source code repository (see [2]). Private efforts to engage the existing developers in implementing features have been negatively received. At the same time, other individuals and companies, such as [[http://www.wandisco.com|WANdisco]], have expressed interest in helping continue to develop Trac. These entities would prefer this effort to be at a vendor-neutral location, with the clear process for intellectual property management that comes from the Foundation. As such, the Apache Software Foundation feels like the best fit for this new project based on Trac. == Rationale == As discussed earlier, the current Trac development community is small and reluctant to accept outside contributions. Given the Foundation’s reputation for building and maintaining communities, we feel a new project, based on Trac but incubated under the Apache umbrella, would help re-build the developer community, jump started by developer time donated by WANdisco. Additionally, as a developer tool, Bloodhound is a good fit with other, similarly-focused developer tools at the ASF. Private discussions have shown there is some interest by third-parties to release internal improvements to Trac, and Bloodhound gives them an additional venue to do so. == Initial Goals == The initial goals for Bloodhound primarily revolve around migrating the existing code base and integrating external features to make the project easy to deploy. Additional ideas will of course follow, but the following goals are sufficiently difficult to be considered early milestones. Some of the initial goals include: * Migrate the existing BSD-licensed Trac code base to the ASF. * Attract developer and user interest in the new Bloodhound project. * Incorporate externally developed features into the core Bloodhound project. * Package the most popular plugins into the core project, so installations and administration of Bloodhound becomes dead simple. = Current Status = == Meritocracy == Although initially
DeltaSpike proposal
I was a committer at Seam 3 and I'd like to join forces in DeltaSpike project. p.s.: Struberg instructed me to send an email to general@incubator.apache.org, Am I doing it right? Best Regards, José Rodolfo Freitas
[PROPOSAL] Apache DeltaSpike - CDI-Extensions
Hi, I would be glad to be part of Apache DeltaSpike. I have already written some useful CDI-Extensions for my company open knowledge GmbH and I think we would contribute them to that project. Cheers, Arne
Re: Apache DeltaSpike commiter agreement.
Hi José! No worries, we don't yet have our mailing lists - this will all come after the VOTE to accept Deltaspike as incubation. I know, you (me too) are all eager to finally start hacking, but there is still a week to hold your feet still ;) After all the mailing list is setup, we'll ping you (or just ask then). txs 4 the patience and LieGrue, strub From: José Rodolfo Freitas joserodolfo.frei...@gmail.com To: general@incubator.apache.org Cc: secret...@apache.org; deltaspike-priv...@incubator.apache.org; priv...@incubator.apache.org Sent: Friday, December 2, 2011 7:01 PM Subject: Re: Apache DeltaSpike commiter agreement. I sent an email earlier to general@incubator.apache.org asking to join DeltaSpike project as a committer. But I guess that I should have mentioned that I already signed the ICLA and it's in the ASF records. Best regards, José Rodolfo Freitas On Fri, Dec 2, 2011 at 12:46 PM, Sam Ruby ru...@intertwingly.net wrote: Dear José Rodolfo Freitas, This message acknowledges receipt of your ICLA, which has been filed in the Apache Software Foundation records. If you have been voted in as a committer, please advise the project PMC that your ICLA has been filed. Warm Regards, -- Sam Ruby Assistant Secretary, Apache Software Foundation - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
[RESULT][IP CLEARANCE] Apache Geronimo 2.2 Dependency Upgrades
Our 72 hour window has passed. So, I'm calling this IP CLEARANCE complete. Thanks! --kevan On Nov 29, 2011, at 5:09 AM, Robert Burrell Donkin wrote: On Mon, Nov 28, 2011 at 11:56 PM, Kevan Miller kevan.mil...@gmail.com wrote: The Apache Geronimo project has received a contribution which updates a number of Geronimo dependencies and associated code updates. The code contributions have been attached to https://issues.apache.org/jira/browse/GERONIMO-6217 I've committed the IP Clearance form to the Incubator website -- http://incubator.apache.org/ip-clearance/geronimo-dependency-upgrades.html The Geronimo community has passed a vote to accept the contribution -- http://mail-archives.apache.org/mod_mbox/geronimo-dev/20.mbox/%3c1bc3ab3f-2b25-4ce4-ba7b-5c8b4764e...@gmail.com%3e This stage of the IP clearance process is a 72-hour lazy consensus. Barring a -1, the ip clearance for this contribution will pass in 72 hours. Yes :-) this process is by lazy consensus. If anyone sees a problem, please post a -1 to this thread to force a formal review and VOTE. Kevan will close this thread by posting a RESULT mail no earlier than Friday, December 2, 2011 at 12:00:00 UTC [1] (by my reckoning). If you can spare a few cycles, please take a look before then. Robert [1] http://www.timeanddate.com/worldclock/fixedtime.html?iso=20111202T12 - 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: Feedback on updated NOTICE and LICENSE files (was: [VOTE] Release Kafka 0.7.0-incubating)
On Dec 2, 2011, at 3:51 PM, Jakob Homan wrote: So I hope it's clear why it's frustrating to have this rule suddenly pop up when it's apparently not enforced in the majority of cases (and then to be asked to go and open JIRAs for each of these projects on top of it). This requirement is fairly well documented, IMO. The incubator's release documentation is here -- http://incubator.apache.org/guides/releasemanagement.html The LICENSE and NOTICE file requirements are documented here -- http://incubator.apache.org/guides/releasemanagement.html#best-practice-license. I don't think this should come as a big surprise... OK. Some of that wording is too weak, IMO. All the licenses on all the files to be included within a package should be included in the LICENSE document. The should be is probably referring to a single LICENSE file as opposed to multiple license files in a license/ directory. I do understand that this is a frustrating process. You have code that's ready and want to release it. Many projects going through the incubator have gone through this same pain. However, it is important, IMO. I spend a fair amount of time on the Geronimo project. We have a lot of dependencies… http://svn.apache.org/repos/asf/geronimo/server/trunk/LICENSE We document source and binary licenses in a single LICENSE/NOTICE file. I have seen projects maintain separate LICENSE/NOTICE files for their source and binary distributions. To be honest, I'm not sure what form is preferred. I'd be happy to see either… --kevan - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: [PROPOSAL] Apache Bloodhound
SO, IIUIC, the first step is to import TRAC, and we will have primarily a BSD codebase as the main body of code? Does this mean that all BSD notices in source files must live in ASF repository for all eternity, assuming that we are allowed to sublicense into ALv2 (which I think is no problem)? And what about the lack of patent license that we offer downstream, but have not received from upstream? Cheers Niclas On Sat, Dec 3, 2011 at 12:14 AM, Mark Struberg strub...@yahoo.de wrote: so this is basically Trac ++ and a fork of Trac ? Or is it a completely rewritten new approach? just curious :) LieGrue, strub - Original Message - From: Hyrum K Wright hyrum.wri...@wandisco.com To: general@incubator.apache.org Cc: Ian Wild ian.w...@wandisco.com; Greg Stein gst...@gmail.com Sent: Friday, December 2, 2011 4:53 PM Subject: [PROPOSAL] Apache Bloodhound Hello Incubator! WANdisco would like to propose the inclusion of a new project, Apache Bloodhound, to the Incubator. The proposal has been posted to the wiki[1], and is also included below. We've privately discussed this project with a number of individuals, but would now like to get the discussion rolling here. Bloodhound is new effort, based on Trac[2], to provide issue tracking and collaboration tools for developers. We realize the proposal is a work-in-progress, and as such look forward to feedback and discussion. We hope to attract mentors and other interested parties through the incubation proposal process, and further diversify the community as we move through incubation. In particular, this project is an opportunity to build a new community around the codebase, and we look forward to doing so at the ASF. -Hyrum [1] http://wiki.apache.org/incubator/BloodhoundProposal [2] http://trac.edgewall.org/ = Bloodhound - Collaborative development tools based on Trac = == Abstract == Bloodhound will be a software development collaboration tool, including issue tracking, wiki and repository browsing. Essentially an improved distribution of the well-known Trac project, Bloodhound will include the common and useful plugins to enable a more complete distribution than a typical Trac installation. == Proposal == Bloodhound will be a software development collaboration tool, based on the existing Trac project, which will include a repository browser, wiki, and defect tracker. In addition to the standard Trac installation, Bloodhound will incorporate a number of popular modules into the core distribution, and include additional improvements developed (as [[http://trac-hacks.org/|plugins]]) outside the Trac project. == Background == The [[http://trac.edgewall.org/|Trac project]] is a BSD-licensed collaboration tool used to assist in software development. It has a wide user base, a pluggable infrastructure, and is generally considered stable. By it's own recognition, however, the development community surrounding Trac has largely dissipated, with little mailing list traffic, and very few commits to the source code repository (see [2]). Private efforts to engage the existing developers in implementing features have been negatively received. At the same time, other individuals and companies, such as [[http://www.wandisco.com|WANdisco]], have expressed interest in helping continue to develop Trac. These entities would prefer this effort to be at a vendor-neutral location, with the clear process for intellectual property management that comes from the Foundation. As such, the Apache Software Foundation feels like the best fit for this new project based on Trac. == Rationale == As discussed earlier, the current Trac development community is small and reluctant to accept outside contributions. Given the Foundation’s reputation for building and maintaining communities, we feel a new project, based on Trac but incubated under the Apache umbrella, would help re-build the developer community, jump started by developer time donated by WANdisco. Additionally, as a developer tool, Bloodhound is a good fit with other, similarly-focused developer tools at the ASF. Private discussions have shown there is some interest by third-parties to release internal improvements to Trac, and Bloodhound gives them an additional venue to do so. == Initial Goals == The initial goals for Bloodhound primarily revolve around migrating the existing code base and integrating external features to make the project easy to deploy. Additional ideas will of course follow, but the following goals are sufficiently difficult to be considered early milestones. Some of the initial goals include: * Migrate the existing BSD-licensed Trac code base to the ASF. * Attract developer and user interest in the new Bloodhound project. * Incorporate externally developed features into the core Bloodhound project. * Package the most popular plugins into the core project, so installations and administration
