Re: [VOTE] Release for Bigtop version 0.3.0-incubating
On 03/20/2012 11:35 AM, Roman Shaposhnik wrote: This is the third incubator release for Apache Bigtop, version 0.3.0-incubating. It fixes the following issues: https://issues.apache.org/jira/secure/ReleaseNote.jspa?version=12317841projectId=12311420 The delta between RC0 and RC1 includes fixes for the following issues: BIGTOP-446. Typo in hadoop module for puppet BIGTOP-459. remove references to cloudera from the packaging files BIGTOP-443. deb/oozie/oozie-client.postinst installs an alternative for a path that isn't there BIGTOP-382. hadoop-conf-pseudo packages contains subversion metada BIGTOP-457. Bigtop 0.3.0: Hadoop namenode doesnt start after installing the deb package *** Please download, test, and vote by Mon, March 26 Note that we are voting on the source (tag): release-0.3.0-incubating-RC1 Source tarball, checksums, signature: http://people.apache.org/~rvs/bigtop-0.3.0-incubating-RC1/ The tag to be voted on: https://svn.apache.org/repos/asf/incubator/bigtop/tags/release-0.3.0-incubating-RC1/ Bigtop's KEYS file, containing the PGP keys used to sign the release: http://svn.apache.org/repos/asf/incubator/bigtop/dist/KEYS Please also make sure to try installing our convenience binary distribution artifacts. We are publishing the Bigtop 0.3.0 incubating distributions for the following Linux platforms: Ubuntu 10.04, CentOS 5, CentOS 6, Fedora 15, Fedora 16, SLES 11. The easies way to install Bigtop distribution on your favorite Linux OS is to pick one of the attached files, and place it (as root) in the following folder: * Ubuntu -- /etc/apt/sources.list.d/ * CentOS5, CentOS6, Fedora 15, Fedora 16 -- /etc/yum.repos.d/ * SLES 11 -- /etc/zypp/repos.d/ After that you can follow the installation instructions from over here (DO NOT FORGET TO SKIP STEPS #1 and #2): https://cwiki.apache.org/confluence/display/BIGTOP/How+to+install+Hadoop+distribution+from+Bigtop Thanks! Bigtop 0.3.0 release manager, Roman Shaposhnik +1 LGTM. Note, I also tested upgrading from 0.2.0 to 0.3.0 on SLES11SP1 and it went smoothly with no errors or issues. Thanks, Peter - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: [VOTE] Release ManifoldCF 0.5-incubating, RC0
On Mar 27, 2012, at 2:15 AM, sebb wrote: On 26 March 2012 16:20, Roy T. Fielding field...@gbiv.com wrote: On Mar 26, 2012, at 4:41 PM, Karl Wright wrote: On Mon, Mar 26, 2012 at 10:24 AM, sebb seb...@gmail.com wrote: On 26 March 2012 02:38, Shinichiro Abe shinichiro.ab...@gmail.com wrote: Hello Incubator IPMC, Please vote on whether or not to release ManifoldCF 0.5-incubating, RC0. This RC has passed our podling vote and awaits your inspection. You can find the artifact at http://people.apache.org/~shinichiro/apache-manifoldcf-0.5-incubating-RC0/, or in svn at https://svn.apache.org/repos/asf/incubator/lcf/tags/release-0.5-incubating-RC0/. The NOTICE file says: Apache ManifoldCF Copyright 2010-2011 The Apache Software Foundation The LICENSE file includes references to lots of jars that are dual licensed under CDDL v1.0 and GPL v2. However, there is no indication which license has been chosen by the project. I think this is a blocker. A project does not choose a license. The license is provided by the copyright owner. We do not change that license, nor do we reduce the number of the available licenses to choose from, for downstream recipients. Therefore, it doesn't make any sense to indicate which one is chosen. In any case, the indicated artifacts are only included in binary packages. We don't release binaries, so none of these licenses belong in our source product's LICENSE file. We need to be clear that the source code package does not include these dependencies. They only exist in binary distributions. That's not the case with this product at present; all the jars are actually in SVN and they are also in the source and binary archives. Do I really need to explain what source code means? http://www.apache.org/dev/release.html#what All releases are in the form of the source materials needed to make changes to the software being released. Apache releases open source and ONLY open source. Our releases are absolutely forbidden to contain anything other than the open source code that is in our vcs-of-record, meaning code that is in the form most likely to be edited by recipients for the sake of modifying the product, and in some specific cases the generated (and open) source code of build scripts. Binary distributions and binary/jar dependencies MUST be separate packages that are not voted on by the PMC during the release vote, because they are not part of our product and are not released by the ASF. No PMC has been granted the authority to publish binary releases on behalf of the ASF. It would be contrary to the mission of the foundation. They may distribute binary build packages of existing source releases, but these are not ASF releases -- they are just builds provided by the project for user convenience. Likewise for jar files of dependencies -- they are NOT our product and they MUST NOT be present in the source code package that is voted on for release. If podlings get this wrong, fix them. If TLPs get this wrong, fix them. No project should ever leave incubator before this is drilled into their collective skull: The ASF produces open source software! If any ASF member is aware of an Apache release package that is not 100% open source code, you are hereby instructed to DELETE it from our servers. Nobody, not even me, has the right to place a compiled class in one of our packages and call that a source release. Is that clear? Roy - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Binary dependencies in source releases (Was: [VOTE] Release ManifoldCF 0.5-incubating, RC0)
Hi, [dropped infra@, I believe most interested people are already on general@] Let's decouple this thread from the specific issue of the ManifoldCF release. There's a long tradition of Apache releases like the ones ManifoldCF is producing, so turning this suddenly into a blocker is IMHO bad business, especially since no legal issues are involved (this is about Apache policy). If we do come to the consensus that releases like this are contrary to Apache policy, then affected projects should be given a reasonable amount of time to adapt. Also, let's make a clear distinction between binary distributions (i.e. the packages that result from building one of our source releases) and binary dependencies (i.e. binary distributions of upstream projects). AFAICT there's clear consensus that binary distributions are *not* official Apache releases, and we've been pretty consistent about that so far. However, the word on binary dependencies is much less clear. There's explicit Apache policy (category B, etc.) that talks about binary dependencies and plenty of Apache releases contain them. This is clearly not an area where we have consensus. On Tue, Mar 27, 2012 at 11:50 AM, Roy T. Fielding field...@gbiv.com wrote: Likewise for jar files of dependencies -- they are NOT our product and they MUST NOT be present in the source code package that is voted on for release. Citation needed. Note that the source materials reference you mentioned earlier is vague. It covers stuff like configure scripts in httpd releases, test files, and indeed (as far as it so far has been interpreted) binary dependencies of upstream open source projects. I'm fine if this point needs to be clarified and some current practice terminated, but let's follow standard process to do so. If any ASF member is aware of an Apache release package that is not 100% open source code, you are hereby instructed to DELETE it from our servers. What hat are you holding here? Which packages explicitly are you referring to? BR, Jukka Zitting - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: Binary dependencies in source releases (Was: [VOTE] Release ManifoldCF 0.5-incubating, RC0)
On Mar 27, 2012, at 12:57 PM, Jukka Zitting wrote: Hi, [dropped infra@, I believe most interested people are already on general@] Let's decouple this thread from the specific issue of the ManifoldCF release. There's a long tradition of Apache releases like the ones ManifoldCF is producing, so turning this suddenly into a blocker is IMHO bad business, especially since no legal issues are involved (this is about Apache policy). If we do come to the consensus that releases like this are contrary to Apache policy, then affected projects should be given a reasonable amount of time to adapt. I don't see where you get the idea that there is a long tradition of including binary artifacts within the source package releases at Apache. There may be specific groups who are apparently lacking the appropriate clue and stubbornly refuse to read the messages I have sent multiple times to this mailing list, legal-discuss, and members, but there is no question whatsoever that a source package cannot include binaries. It would not be a source package otherwise. http://incubator.apache.org/guides/releasemanagement.html This issue is not open for discussion. It is is a mandate from the certificate of this foundation -- our agreement with the State of Delaware that I signed as incorporator. It is fundamental to our status as an IRS 501(c)3 charity. It is the key charter delegated by the board as part of every TLP resolution: charged with the creation and maintenance of open-source software ... for distribution at no charge to the public. Class files are not open source. Jar files filled with class files are not open source. The fact that they are derived from open source is applicable only to what we allow projects to be dependent upon, not what we vote on as a release package. Release votes are on verified open source artifacts. Binary packages are separate from source packages. One cannot vote to approve a release containing a mix of source and binary code because the binary is not open source and cannot be verified to be safe for release (even if it was derived from open source). I thought that was frigging obvious. Why do I need to write documentation to explain something that is fundamental to the open source definition? Also, let's make a clear distinction between binary distributions (i.e. the packages that result from building one of our source releases) and binary dependencies (i.e. binary distributions of upstream projects). AFAICT there's clear consensus that binary distributions are *not* official Apache releases, and we've been pretty consistent about that so far. However, the word on binary dependencies is much less clear. There's explicit Apache policy (category B, etc.) that talks about binary dependencies and plenty of Apache releases contain them. This is clearly not an area where we have consensus. Please point those packages out to me and I will ask Joe to give me root access again so that I can go through and personally delete them from our dist directories. Seriously. I am so tired of having to send these emails, write the documentation, and then watch Java projects to do the wrong things again and again. It is time for the sledgehammer. The Category B is about products in general, not just source packages. Yes, that documentation sucks. Yes, I said so at the time. No, it is NOT an approved policy document of the ASF. The categories are about software licensing of the product as a whole, including hard dependencies and built packages, not whether something is included in a source code package. On Tue, Mar 27, 2012 at 11:50 AM, Roy T. Fielding field...@gbiv.com wrote: Likewise for jar files of dependencies -- they are NOT our product and they MUST NOT be present in the source code package that is voted on for release. Citation needed. Note that the source materials reference you mentioned earlier is vague. It covers stuff like configure scripts in httpd releases, test files, and indeed (as far as it so far has been interpreted) binary dependencies of upstream open source projects. I'm fine if this point needs to be clarified and some current practice terminated, but let's follow standard process to do so. It isn't even remotely vague. Source has only one definition. And it isn't just that document: http://incubator.apache.org/guides/releasemanagement.html#best-practice If any ASF member is aware of an Apache release package that is not 100% open source code, you are hereby instructed to DELETE it from our servers. What hat are you holding here? Which packages explicitly are you referring to? My hat. I'll make it a board directive at the next meeting, if you like. If I had known of any such packages, I would have deleted them already. Don't you remember the similar conversation we had about Jackrabbit releases? The only jar files we should have in subversion are the non-product trees -- the places where we store build tools, the artifacts
Re: Request for an early review of an potential Apache OpenOffice release
2012/3/26 Jürgen Schmidt jogischm...@googlemail.com: I created and used an ant script (main/solenv/bin/srcrelease.xml) to create the src release files as part of the normal build if required. I decided to use ant because it allows me some flexibility... Our trunk contains 4 directories where trunk/ext_sources shouldn't be included in a src release because it contains external library packages for convenient purposes only. We have to patch some external libs for example where an upstreaming is not possible or where the versions we use are too old. That is something we would like to improve in the future and over time. But they will be downloaded on demand. OK, I think that sounds right. trunk/main trunk/ext_libraries trunk/ext_sources trunk/extras That means I include main, ext_libraries and extras only. ext_libraries is a new module where we started to collect build projects for external libs in our own office specific build env etc. Main purpose is to have a cleaner separation over time. trunk/main/NOTICE and trunk/main/LICENSE and trunk/main/README are moved in the destination root directory of our src release to simply have it in the root as expected. We kept trunk clean so far or better we don't put any files in trunk directly and used main as the main source directory. extras contains translation files only to keep them somewhat separated as well. I had a brief glance at srcrelease.xml, and between that and your description of how the system has been set up, I'm content that you understand the requirements and are making a good-faith effort to uphold them. Canonical ASF source releases are supposed to be assembled using a repeatable build process. I think it is very repeatable and the script used is part of the source as well. Excellent. see my description above, anybody can build the src release no local setup necessary. It is more or less a pure svn dump. Right -- just with a few files moved around and a bunch filtered out. We run RAT on our build bots (at least on one) and use the exclude list that you can find in trunk/main/rat-excludes You can find the nightly output under http://ci.apache.org/projects/openoffice/rat-output.html Right now we have still 1471 files with unknown license but they are more or less all part of the SGA or should be. We are working right now on these files and analyze if it's possible to include a license header or not. OR put in in the exclude file with a proper comment to document everything. Nice workflow, +1. I had a look at the rat-excludes file. The individual files which are listed and documented in the lower half -- that all looks great. The top half, though, has an awful lot of wildcards: **/*.add **/*.all **/*.am **/*.applications **/*.attr **/*.btm **/*.cgm **/*.chd **/*.cl **/*.cls **/*.cmn **/*.common **/*.component **/*.components [...] # binary media formats **/*.bmp **/*.emf **/*.eps **/*.gif **/*.giff **/*.icns **/*.ico **/*.img **/*.jpeg **/*.jpg **/*.mov [...] # binary document formats **/*.doc **/*.docx **/*.odb **/*.odf **/*.odg **/*.odl [...] I understand that a lot of those filetypes can't have embedded licenses. Ideally, each such file would be listed together with a comment explaining its licensing situation. Less desirable but still acceptable to list wildcards within directories, explaining where e.g. all the images in this/folder/full/of/*.jpeg files came from. Having wildcards which exclude a file type for the whole source tree, though, weakens the RAT check, both now and in the future. Are you confident that all the files which match those wildcards were part of the Oracle SGA or are otherwise properly licensed for ASF usage? Thanks, Marvin Humphrey - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: Binary dependencies in source releases (Was: [VOTE] Release ManifoldCF 0.5-incubating, RC0)
On Tue, Mar 27, 2012 at 12:57 PM, Jukka Zitting jukka.zitt...@gmail.com wrote: Let's decouple this thread from the specific issue of the ManifoldCF release. There's a long tradition of Apache releases like the ones ManifoldCF is producing, so turning this suddenly into a blocker is IMHO bad business, especially since no legal issues are involved (this is about Apache policy). If we do come to the consensus that releases like this are contrary to Apache policy, *jaw drops*. Huh? But, but, but. But! It's called open *source*. I am honestly just really surprised that this can even come up as a discussion topic. It's such a core concept that source releases are, well, *source* releases, everything is built on top of it. It's not a policy thing, it's a definition thing. The one case I can imagine that might be sort-of ok is if you ship a release with an ant-based build that includes a custom task, and in the source release of your entire project you *also* include a binary version of the custom task, so lazy people (or those without a working bash, or whatever) can avoid running your bootstrap script. (and simlarly, s/ant/maven/, s/task/plugin/, etc). But there's obviously better ways to do that stuff (target that compiles task, taskdef for task in next target, that kind of thing). then affected projects should be given a reasonable amount of time to adapt. Uhm. Normally I'd want to take a similar approach. But. But. But! Open *source*. It's so fundamental to what we do. This seems exactly the reason why we have incubation disclaimers: so we make clear to our downstream users we might be making some mistakes like this, and so that we can then be agile in fixing it. Whoops, made a mistake folks, no downloads here, stand by while the podling makes a new release I'd think that when we find a problem like this after a release is published, we (we as in the PMC, this is not a task to shove onto infra!) should immediately explain the problem and then immediately yank any existing incubation releases that have an issue here. No grace period, no voting, no discussion. Just fix it. That said, I'm not aware of us actually having such a release out there? How to deal with this stuff for TLPs that got it wrong, well, I guess that's a conversation for (a) different mailing list(s). g'night Leo, still trying to pick his jaw up from the floor - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Request for Comments - Apache Jena proposed graduation resolution
Hi All At the recommendation of our mentors the Apache Jena incubator polling is currently working towards graduation. We recently passed a community vote to proceed with graduation and held a PPMC vote to select our chairman upon graduation. We have also been discussing our board resolution between ourselves and we'd now like to request feedback from the IPMC to refine this resolution as necessary prior to submitting it for a formal IPMC vote in the next week or so: 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 accessing, storing, querying, publishing and reasoning with semantic web data while adhering to relevant W3C and community standards. NOW, THEREFORE, BE IT RESOLVED, that a Project Management Committee (PMC), to be known as the Apache Jena Project, be and hereby is established pursuant to Bylaws of the Foundation; and be it further RESOLVED, that the Apache Jena Project be and hereby is responsible for the creation and maintenance of software related to accessing, storing, querying, publishing and reasoning with semantic web data while adhering to relevant W3C and community standards; and be it further RESOLVED, that the office of Vice President, Apache Jena 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 Jena Project, and to have primary responsibility for management of the projects within the scope of responsibility of the Apache Jena 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 Jena Project: * Andy Seaborne (andy) * Benson Marguilies (bimargulies) * Chris Dollin (chrisdollin) * Damian Steer (damian) * Dave Reynolds (der) * Ian Dickinson (ijd) * Paolo Castagna (castagna) * Rob Vesse (rvesse) * Stephen Allen (sallen) NOW, THEREFORE, BE IT FURTHER RESOLVED, that Andy Seaborne be appointed to the office of Vice President, Apache Jena, 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 Jena 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 Jena Project; and be it further RESOLVED, that the Apache Jena Project be and hereby is tasked with the migration and rationalization of the Apache Incubator Jena podling; and be it further RESOLVED, that all responsibilities pertaining to the Apache Incubator Jena podling encumbered upon the Apache Incubator Project are hereafter discharged. The proposed PMC is composed of all current members plus one of our mentors (Benson Marguilies) who has graciously agreed to remain on the project for the time being. We look forward to receiving your comments On behalf of the Apache Jena PPMC, Rob Vesse - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
