Re: Websites of retired podlings (was Re: Retired podlings with RW SVN access)
Another option which might be cleaner and less burdensome to administer would be to create a boilerplate Retired Podling static html page which would replace the website for any podling which does not graduate. This page would give a brief explanation of the project's history and status and point at any remaining resources, such as read-only SVN if the podling completed a successful code grant. If there is interest in that idea, I volunteer to help create the template for the Retired Podling page. I like that idea. But we should the folder i.a.o/retiredpodling not simply have a httpd redirect rule pointing to the incubator status page? The state of the podling is reflected there very well and there is even a chance to send a personal message Christian I have two objectives with this proposal. The first is practical: we should aid users who may come looking for a project to learn what happened to it with minimal effort. The other goal is to help podlings retire with dignity. Every software project has a life cycle, there are many reasons why a podling might not make it to graduation, and a lot may have been accomplished during an attempt at incubation. I think our default policy should be to recognize and celebrate the contributions that a podling's volunteers made while it was active. Marvin Humphrey - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org -- http://www.grobmeier.de - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: Websites of retired podlings (was Re: Retired podlings with RW SVN access)
On Sun, Aug 21, 2011 at 4:06 AM, Marvin Humphrey mar...@rectangular.com wrote: On Sat, Aug 20, 2011 at 05:25:00PM -0400, Benson Margulies wrote: On Sat, Aug 20, 2011 at 02:59:33PM +0300, Daniel Shahaf wrote: Gavin McDonald wrote on Sat, Aug 20, 2011 at 16:35:47 +1000: The retirement guide [1] makes no mention of removing podling websites but I think they should all be removed at retirement, thoughts? This doesn't need to be on private@... Good catch, Daniel. My preference would be to avoid erasing podling web presences on retirement, If an RO svn is retained, some sort of web presence explaining it makes sense to me. But I agree that a pseudo-active-project web site is not the right sort of web presence. Yes, I also agree that a site which misleads visitors into thinking that a retired podling is active is not desirable. When a top-level project enters the Attic, its website gets updated to reflect the fact that it has been retired. For instance, all of Hivemind's web pages have a big red banner alerting visitors to the project's status: http://hivemind.apache.org/ http://hivemind.apache.org/download.html Provided that someone is willing to do that work, that there is zero ongoing maintenance burden, and that there are no practical or legal difficulties, I think something similar would also be OK for a retired podling -- however, that's not necessarily my preferred approach. Another option which might be cleaner and less burdensome to administer would be to create a boilerplate Retired Podling static html page which would replace the website for any podling which does not graduate. This page would give a brief explanation of the project's history and status and point at any remaining resources, such as read-only SVN if the podling completed a successful code grant. If there is interest in that idea, I volunteer to help create the template for the Retired Podling page. +1 I have two objectives with this proposal. The first is practical: we should aid users who may come looking for a project to learn what happened to it with minimal effort. The other goal is to help podlings retire with dignity. Every software project has a life cycle, there are many reasons why a podling might not make it to graduation, and a lot may have been accomplished during an attempt at incubation. I think our default policy should be to recognize and celebrate the contributions that a podling's volunteers made while it was active. Marvin Humphrey - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org -- Thanks - Mohammad Nour Life is like riding a bicycle. To keep your balance you must keep moving - Albert Einstein - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: [PROPOSAL] HMS Project for the Apache Incubator
+1 Very good idea and perfectly fits with Hadoop ecosystem. On Sat, Aug 20, 2011 at 2:31 AM, Eric Yang ey...@hortonworks.com wrote: Greetings All, We would like to propose HMS Project for inclusion in ASF Incubator as a new podling. HMS is monitoring, administration and lifecycle management project for Apache Hadoop clusters. The complete proposal can be found at: http://wiki.apache.org/incubator/HMSProposal The initial contents of this proposal are also pasted below for convenience. Thanks and Regards, Eric = HMS Proposal = == Abstract == HMS is monitoring, administration and lifecycle management project for Apache Hadoop clusters. == Proposal == HMS will simplify the process of deployment, configuration, management and monitoring of the collection of Hadoop services and applications that compose a Hadoop cluster. The collection of services (Hadoop Stack) will include at least HDFS, !MapReduce, HBase, Hive, HCatalog, Pig and Zookeeper. HMS will be easily configurable to add additional services and applications to the stack. Our plan is to support the Hadoop stack as a unit of deployment and configuration where only certain pre-tested versions of software components are supported to be part of Hadoop stack. Administrators can always enable/disable the individual software components from the Hadoop stack per their deployment needs. The main use cases that HMS is trying to address are the following: * Hadoop stack deployment and upgrades * Hadoop services configuration management * Administration of Hadoop services * Includes starting and stopping services * Hadoop system maintenance tasks, such as fsck, format, re-balance, and compaction * User access quota management on Hadoop clusters * Easily check and be alerted to failures in Hadoop servers * Automated discovery of new machines that become available * Expanding and contracting Hadoop clusters * Automatic resynchronization to ‘desired’ state (of Hadoop stack) to handle faulty nodes * Handle node burn-ins (stress test nodes using Hadoop before deploying them for production use) * Simple monitoring and management UI * Dynamic configuration - Hadoop configuration deduced from machine attributes (e.g., RAM, CPU, Disk) * Operational HBase-based (inspired by OpenTSDB) monitoring for Hadoop clusters * Make it possible for administrators to deploy other Hadoop related services and client applications HMS is targeted to administrators responsible for managing Hadoop clusters. HMS leverages existing data center management and monitoring infrastructure - Nagios, LDAP, Kerberos, etc. All HMS functionality and data will be accessible via RESTFUL APIs and command line tools to facilitate its integration with existing data center management suites. For the bare metal provisioning, the cluster admins continue to use their existing infrastructure. Provisioning a machine from scratch is not in the scope of the current roadmap. == Background == Hadoop’s ecosystem includes many projects (HDFS, !MapReduce, Pig, HBase, etc.). In many cases, users and operators typically want to deploy a combination of some projects as a stack. It takes a significant amount of time to get a properly configured Hadoop cluster up and running. HMS has been designed to solve that problem. HMS automates the whole process of deploying a stack. HMS is being developed by developers employed with Yahoo!, Hortonworks and IBM. Such a tool would have a large number of users and increase the adoption of Apache Hadoop’s ecosystem. We are therefore proposing to make HMS Apache open source. == Rationale == Hadoop clusters are complicated and difficult to deploy and manage. The HMS project aims to improve the usability of Apache Hadoop. Doing so will demoncratize Apache Hadoop, growing its community and increasing the places Hadoop can be used and the problems it can solve. By developing HMS in Apache we hope to gather a diverse community of contributors, helping to make sure that HMS is deployable in as many different situations as possible. members of the Hadoop development community will be able to influence HMS’s roadmap, and contribute to it. We believe having HMS as part of the Apache Hadoop ecosystem will be a great benefit to all of Hadoop's users. == Current Status == Prototype available, developed by the list of initial committers. === Meritocracy === Our intent with this incubator proposal is to start building a diverse developer community around HMS following the Apache meritocracy model. We have wanted to make the project open source and encourage contributors from multiple organizations from the start. We plan to provide plenty of support to new developers and to quickly recruit those who make solid contributions to committer status. === Community === We are happy to report that multiple organizations are already represented by initial team. We hope to
[jira] [Created] (INCUBATOR-116) XML Beans CXX project is in limbo
XML Beans CXX project is in limbo - Key: INCUBATOR-116 URL: https://issues.apache.org/jira/browse/INCUBATOR-116 Project: Incubator Issue Type: Bug Environment: http://mail-archives.apache.org/mod_mbox/incubator-general/201108.mbox/%3ccaogo0vbxyrd_tktsgke+bkc8g0pzzpvjxuh7zzylu5wccjf...@mail.gmail.com%3E Reporter: Sebb The XML Beans C++ project is in limbo: It has a website [1], a status page [2] but is not mentioned in clutch [3] or the summary projects page [4] as dormant or retired. It still has a RW podling SVN directory [5] but that was last updated in 2007. AFAICT the project needs to be retired, and SVN deleted if the copyright issues have not been addressed, otherwise made read-only As an initial step, I have made SVN read-only (the access group was empty anyway). [1] http://incubator.apache.org/xmlbeanscxx/ [2] http://incubator.apache.org/projects/xmlbeanscxx.html [3] http://incubator.apache.org/clutch.html [4] http://incubator.apache.org/projects/index.html [5] http://svn.apache.org/repos/asf/incubator/xmlbeanscxx/ -- This message is automatically generated by JIRA. 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
Removal of graduated and obsolete web-site files
There are quite a few web-sites still under /www/incubator.apache.org/ that are for graduated podlings, as well as a few sites marked 'old': For example: 467 ./old-activemq 130790 ./activemq drwxrwsr-x 34 apbackup incubator 445 Feb 6 2007 activemq drwxrwsr-x 5 apbackup incubator 20 Jan 27 2006 old-activemq There are redirects in place for the graduated podlings, so (for example) the activemq pages are not accessible via HTTP, only as files on minotaur. However the 'old' directories can be accessed if one knows their name. It seems to me that these obsolete directory trees should be deleted. If so, I'm happy to do so (I would need unix incubator karma) S - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
DISCLAIMER files - why are they being overlooked?
AIUI, DISCLAIMER files (*) should be present alongside NOTICE and LICENSE files in all releases and in the top-level SVN directory, and the disclaimer text should be prominently displayed on the podling web-site. These items are easy to do, but are frequently overlooked, so I wonder if the podling templates should be updated with appropriate sections that have to be completed? Or perhaps there's a better way to ensure it happens? (*) alternatively, the text can be added to the README file. But I think that should be discouraged - it's easy for users to miss. Also on graduation it's simple just to delete the DISCLAIMER file. - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: [VOTE] Release for Bigtop version 0.1.0-incubating
My last patch for centos5 broke openSUSE/Mageia (here lies the troubles of having different set of VMs at home and at work). I am booting up right now a bunch of VMs to ensure next patch won't break anything. Could we re-cut a rc after that patch? On 08/19/2011 11:25 AM, Andrew Bayer wrote: This is the first incubator release for Apache Bigtop, version 0.1.0-incubating. It fixes the following issues: https://issues.apache.org/jira/secure/ReleaseNote.jspa?version=12317549styleName=HtmlprojectId=12311420 *** Please download, test, and vote by Wednesday, August 24 (3 working days from now) Note that we are voting on the source (tag). Source tarball, checksums, signature: http://people.apache.org/~abayer/bigtop-0.1.0-incubating-candidate-0/ The tag to be voted on: http://svn.apache.org/repos/asf/incubator/bigtop/tags/release-0.1.0-incubating Bigtop's KEYS file, containing the PGP keys used to sign the release: http://svn.apache.org/repos/asf/incubator/bigtop/dist/KEYS Note that the Incubator PMC needs to vote on the release after a successful PPMC vote before any release can be made official. Thanks! A. - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: [VOTE] release deltacloud 0.4.0, rc2
Hi all, I was testing Eucalyptus driver using the web UI, and found a couple problems: - In firewall, I couldn't create a new rule. It looks like opts['id'] is empty when create_firewall_rule of a driver (EC2 or Eucalyptus) is invoked. - Create new address doesn't work - Couldn't attach a volume to an instance Again, please note these issues were found while using web UI, not client tools or cucumber tests. --SM On Wed, Aug 17, 2011 at 6:59 AM, Chris Lalancette clala...@redhat.comwrote: On 08/16/11 - 04:54:30PM, David Lutterkort wrote: Hi all, I just uploaded the second release candidate for Deltacloud 0.4.0. The rc is available from http://people.apache.org/~lutter/deltacloud/0.4.0/rc2/ Please vote on the release candidate by Friday, 2011-08-19 15:00 PDT The rc2 differs from rc1 in only two small changes: 1. Fix cucumber tests that failed because of the version bump 2. Fix an issue where POST requests containing matrix params were not processed correctly (e.g. POST /api;driver=mock/instances was failing) I include the announcement for rc1 for convenience: Many thanks to all those who contributed patches, reported bugs, and asked for features. It's great to see that the list of committers and patch contributors is steadily increasing. I think I just found a backwards-compatibility problem in the bucket and blob creation stuff (see my Blob creation mail from today). We might want to hold off on the release until we get that resolved. -- Chris Lalancette -- Sang-Min Park Engineer Eucalyptus Systems
Re: Websites of retired podlings (was Re: Retired podlings with RW SVN access)
On Sat, Aug 20, 2011 at 7:06 PM, Marvin Humphrey mar...@rectangular.com wrote: On Sat, Aug 20, 2011 at 05:25:00PM -0400, Benson Margulies wrote: On Sat, Aug 20, 2011 at 02:59:33PM +0300, Daniel Shahaf wrote: Gavin McDonald wrote on Sat, Aug 20, 2011 at 16:35:47 +1000: The retirement guide [1] makes no mention of removing podling websites but I think they should all be removed at retirement, thoughts? This doesn't need to be on private@... Good catch, Daniel. My preference would be to avoid erasing podling web presences on retirement, If an RO svn is retained, some sort of web presence explaining it makes sense to me. But I agree that a pseudo-active-project web site is not the right sort of web presence. Yes, I also agree that a site which misleads visitors into thinking that a retired podling is active is not desirable. When a top-level project enters the Attic, its website gets updated to reflect the fact that it has been retired. For instance, all of Hivemind's web pages have a big red banner alerting visitors to the project's status: http://hivemind.apache.org/ http://hivemind.apache.org/download.html Provided that someone is willing to do that work, that there is zero ongoing maintenance burden, and that there are no practical or legal difficulties, I think something similar would also be OK for a retired podling -- however, that's not necessarily my preferred approach. Btw, the work is a search and replace on the body... tag. I generally find one that works on the site content but fails on javadoc (as inserting a header into a frame system is painful). Hen - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: [VOTE] Release for Bigtop version 0.1.0-incubating
The README is formatted for GitHub - will update that shortly. The tarball contents being weird I think is due to me having built the tar on OS X - I'll build the next one on a Linux box to be safe. I'll try to get the files missing headers today as well. A. On Sat, Aug 20, 2011 at 4:28 AM, sebb seb...@gmail.com wrote: Just noticed that the README.md file contains the following: You can get in touch with us on the [user list](https://groups.google.com/a/cloudera.org/group/bigtop-user/topics) or [developer list]( https://groups.google.com/a/cloudera.org/group/bigtop-dev/topics). This also needs to be fixed before release. Why is this not a .txt file? On 20 August 2011 03:08, sebb seb...@gmail.com wrote: On 19 August 2011 23:14, Andrew Bayer andrew.ba...@gmail.com wrote: Ack, I screwed up and overwrote RC0 with RC1. In any case, please find RC1 at http://people.apache.org/~abayer/bigtop-0.1.0-incubating-candidate-1/. NOTICE looks good, and I can see DISCLAIMER. Archive still contains .gitignore files, which should be excluded. Website should update shortly. No sign yet. A. On Fri, Aug 19, 2011 at 3:00 PM, Andrew Bayer andrew.ba...@gmail.com wrote: Oh, and I'm reformatting NOTICE now as well. The .gitignore files - I'll open a bug to remove the top-level one from the tarball, but the ones that show up deeper are expected by the build process. A. On Fri, Aug 19, 2011 at 2:58 PM, Andrew Bayer andrew.ba...@gmail.com wrote: Which source files are missing the headers? I know there are some files without headers, but the ones I know of are that way because they're expected to be in certain formats, they don't allow comments, etc - these should only be Debian/RPM packaging files, unless I'm missing something. As to the package contents - as far as I can tell, everything is under bigtop-0.1.0-incubating. The contents there are the same as in SVN, same layout as in SVN, etc. The content under test is not yet being built/used, and may well be reorganized later, but it's all there. If there are any inconsistencies with what's in SVN, let me know and I'll check it out. Adding DISCLAIMER now. A. On Fri, Aug 19, 2011 at 2:48 PM, sebb seb...@gmail.com wrote: On 19 August 2011 19:25, Andrew Bayer andrew.ba...@gmail.com wrote: This is the first incubator release for Apache Bigtop, version 0.1.0-incubating. It fixes the following issues: https://issues.apache.org/jira/secure/ReleaseNote.jspa?version=12317549styleName=HtmlprojectId=12311420 *** Please download, test, and vote by Wednesday, August 24 (3 working days from now) Note that we are voting on the source (tag). Source tarball, checksums, signature: http://people.apache.org/~abayer/bigtop-0.1.0-incubating-candidate-0/ A lot of source files don't have any license headers. There's no DISCLAIMER in the archive; needs also to be added to SVN alongside NOTICE and LICENSE. The DISCLAIMER text must also be prominently displayed on the bigtop website. IMO these must be fixed before a release. The NOTICE file has a slightly different layout from normal (not a blocker). It would look better if the paragraph were wrapped after developed at - as is normally done - because the URL would then not be left dangling. I would not expect the .gitignore files to be included in the source release. There seems to be a problem with the packaging of the archive - I would expect all files to be under the top-level directory bigtop-0.1.0-incubating, but there are also parallel directories package, sqoop, smokes etc. This makes it very difficult to check the archive against the source archive. Again, I think this needs to be fixed before release. The tag to be voted on: http://svn.apache.org/repos/asf/incubator/bigtop/tags/release-0.1.0-incubating Bigtop's KEYS file, containing the PGP keys used to sign the release: http://svn.apache.org/repos/asf/incubator/bigtop/dist/KEYS sig is OK Note that the Incubator PMC needs to vote on the release after a successful PPMC vote before any release can be made official. Thanks! A. - 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: Removal of graduated and obsolete web-site files
On Sun, Aug 21, 2011 at 3:38 PM, sebb seb...@gmail.com wrote: There are quite a few web-sites still under /www/incubator.apache.org/ that are for graduated podlings, as well as a few sites marked 'old': For example: 467 ./old-activemq 130790 ./activemq drwxrwsr-x 34 apbackup incubator 445 Feb 6 2007 activemq drwxrwsr-x 5 apbackup incubator 20 Jan 27 2006 old-activemq There are redirects in place for the graduated podlings, so (for example) the activemq pages are not accessible via HTTP, only as files on minotaur. However the 'old' directories can be accessed if one knows their name. It seems to me that these obsolete directory trees should be deleted. +1 If so, I'm happy to do so (I would need unix incubator karma) +1 Robert - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: DISCLAIMER files - why are they being overlooked?
On Sun, Aug 21, 2011 at 5:16 PM, sebb seb...@gmail.com wrote: AIUI, DISCLAIMER files (*) should be present alongside NOTICE and LICENSE files in all releases and in the top-level SVN directory, and the disclaimer text should be prominently displayed on the podling web-site. These items are easy to do, but are frequently overlooked, so I wonder if the podling templates should be updated with appropriate sections that have to be completed? +1 Or perhaps there's a better way to ensure it happens? In general, more ways are better. Automated checks using components in Rat would probably make sense... (*) alternatively, the text can be added to the README file. But I think that should be discouraged - it's easy for users to miss. Also on graduation it's simple just to delete the DISCLAIMER file. +1 Robert - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: Podlings needing copyright sign-off
Etch and Tashi are signed off. Droids (seems the easiest one to sign off on) and Olio (likely to be retired) left from 2008 inductees. 2009 list remains unchanged from below. Hen On Sat, Jul 23, 2011 at 12:50 PM, Henri Yandell flame...@gmail.com wrote: Noting that vcl have signed off on the first copyright item. That leaves 2008 with: * etch * olio [sounds like this might be retired] * droids * tashi From 2009: * kato * stonehenge * ace * socialsite * wink * vxquery * hise * clerezza Hen On Sat, Jul 16, 2011 at 9:37 PM, Henri Yandell flame...@gmail.com wrote: Noting that the following have signed off on the below item now: * lucene.net * jspwiki * rat * empire-db With bluesky being retired, that closes out projects starting in 2007 and the first half of 2008. The remaining 2008 projects are: * 2008-09-23 etch * 2008-09-29 olio * 2008-10-01 vcl * 2008-10-23 droids * 2008-11-12 tashi [My view is that anyone whose been in the incubator longer than 6 months should have successfully resolved this item] Hen On Thu, Jul 7, 2011 at 7:20 PM, Henri Yandell flame...@gmail.com wrote: Here's a list of the projects in the Incubator who need to sign off their copyright item; namely: Check and make sure that the papers that transfer rights to the ASF been received. It is only necessary to transfer rights for the package, the core code, and any new code produced by the project. The list is: 2007-10-06 jspwiki 2008-01-06 rat 2008-04-15 bluesky (pending retirement) 2008-08-01 empire-db 2008-09-23 etch 2008-09-29 olio 2008-10-01 vcl 2008-10-23 droids 2008-11-12 tashi 2009-02-09 kato 2009-02-13 stonehenge 2009-05-08 ace 2009-05-13 socialsite 2009-06-25 wink 2009-08-07 vxquery 2009-11-08 hise 2009-12-15 clerezza 2010-01-27 manifoldcf 2010-05-19 amber 2010-05-21 deltacloud 2010-05-24 zetacomponents 2010-07-19 chukwa 2010-09-05 nuvem 2010-09-27 alois 2010-11-02 celix 2010-11-12 kitty 2010-11-24 stanbol 2010-12-02 jena 2010-12-02 opennlp 2010-12-08 wave 2011-01-03 mesos 2011-02-01 easyant 2011-02-05 lucene.net 2011-04-30 ognl 2011-06-13 flume 2011-06-13 openofficeorg 2011-06-13 sqoop Some are new podlings, so no huge surprise, but others have been around for a long time. I think each podling needs to focus on getting this checklist item resolved. Hen - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: [VOTE] Release for Bigtop version 0.1.0-incubating
On 22 August 2011 00:49, Andrew Bayer andrew.ba...@gmail.com wrote: New candidate up at http://people.apache.org/~abayer/bigtop-0.1.0-incubating-candidate-2/. The only files RAT still sees missing license headers are Debian packaging files that are just lists of files, and test data files. README.md has been replaced with README. The gitignore files are, at least for now, excluded from the tarball. The webpage has been updated. The tarball has been built with GNU tar, rather than BSD tar. Let me know if there are any more issues. Thanks! Can't find an SVN tag for the source. A. On Sun, Aug 21, 2011 at 11:45 AM, Andrew Bayer andrew.ba...@gmail.comwrote: The README is formatted for GitHub - will update that shortly. The tarball contents being weird I think is due to me having built the tar on OS X - I'll build the next one on a Linux box to be safe. I'll try to get the files missing headers today as well. A. On Sat, Aug 20, 2011 at 4:28 AM, sebb seb...@gmail.com wrote: Just noticed that the README.md file contains the following: You can get in touch with us on the [user list](https://groups.google.com/a/cloudera.org/group/bigtop-user/topics) or [developer list]( https://groups.google.com/a/cloudera.org/group/bigtop-dev/topics). This also needs to be fixed before release. Why is this not a .txt file? On 20 August 2011 03:08, sebb seb...@gmail.com wrote: On 19 August 2011 23:14, Andrew Bayer andrew.ba...@gmail.com wrote: Ack, I screwed up and overwrote RC0 with RC1. In any case, please find RC1 at http://people.apache.org/~abayer/bigtop-0.1.0-incubating-candidate-1/. NOTICE looks good, and I can see DISCLAIMER. Archive still contains .gitignore files, which should be excluded. Website should update shortly. No sign yet. A. On Fri, Aug 19, 2011 at 3:00 PM, Andrew Bayer andrew.ba...@gmail.com wrote: Oh, and I'm reformatting NOTICE now as well. The .gitignore files - I'll open a bug to remove the top-level one from the tarball, but the ones that show up deeper are expected by the build process. A. On Fri, Aug 19, 2011 at 2:58 PM, Andrew Bayer andrew.ba...@gmail.com wrote: Which source files are missing the headers? I know there are some files without headers, but the ones I know of are that way because they're expected to be in certain formats, they don't allow comments, etc - these should only be Debian/RPM packaging files, unless I'm missing something. As to the package contents - as far as I can tell, everything is under bigtop-0.1.0-incubating. The contents there are the same as in SVN, same layout as in SVN, etc. The content under test is not yet being built/used, and may well be reorganized later, but it's all there. If there are any inconsistencies with what's in SVN, let me know and I'll check it out. Adding DISCLAIMER now. A. On Fri, Aug 19, 2011 at 2:48 PM, sebb seb...@gmail.com wrote: On 19 August 2011 19:25, Andrew Bayer andrew.ba...@gmail.com wrote: This is the first incubator release for Apache Bigtop, version 0.1.0-incubating. It fixes the following issues: https://issues.apache.org/jira/secure/ReleaseNote.jspa?version=12317549styleName=HtmlprojectId=12311420 *** Please download, test, and vote by Wednesday, August 24 (3 working days from now) Note that we are voting on the source (tag). Source tarball, checksums, signature: http://people.apache.org/~abayer/bigtop-0.1.0-incubating-candidate-0/ A lot of source files don't have any license headers. There's no DISCLAIMER in the archive; needs also to be added to SVN alongside NOTICE and LICENSE. The DISCLAIMER text must also be prominently displayed on the bigtop website. IMO these must be fixed before a release. The NOTICE file has a slightly different layout from normal (not a blocker). It would look better if the paragraph were wrapped after developed at - as is normally done - because the URL would then not be left dangling. I would not expect the .gitignore files to be included in the source release. There seems to be a problem with the packaging of the archive - I would expect all files to be under the top-level directory bigtop-0.1.0-incubating, but there are also parallel directories package, sqoop, smokes etc. This makes it very difficult to check the archive against the source archive. Again, I think this needs to be fixed before release. The tag to be voted on: http://svn.apache.org/repos/asf/incubator/bigtop/tags/release-0.1.0-incubating Bigtop's KEYS file, containing the PGP keys used to sign the release: http://svn.apache.org/repos/asf/incubator/bigtop/dist/KEYS sig is OK Note that the Incubator PMC needs to vote on the release after a successful PPMC vote before any release can be made official. Thanks! A.
Re: [VOTE] Release for Bigtop version 0.1.0-incubating
Tag replaced. A. On Sun, Aug 21, 2011 at 5:26 PM, sebb seb...@gmail.com wrote: On 22 August 2011 00:49, Andrew Bayer andrew.ba...@gmail.com wrote: New candidate up at http://people.apache.org/~abayer/bigtop-0.1.0-incubating-candidate-2/. The only files RAT still sees missing license headers are Debian packaging files that are just lists of files, and test data files. README.md has been replaced with README. The gitignore files are, at least for now, excluded from the tarball. The webpage has been updated. The tarball has been built with GNU tar, rather than BSD tar. Let me know if there are any more issues. Thanks! Can't find an SVN tag for the source. A. On Sun, Aug 21, 2011 at 11:45 AM, Andrew Bayer andrew.ba...@gmail.com wrote: The README is formatted for GitHub - will update that shortly. The tarball contents being weird I think is due to me having built the tar on OS X - I'll build the next one on a Linux box to be safe. I'll try to get the files missing headers today as well. A. On Sat, Aug 20, 2011 at 4:28 AM, sebb seb...@gmail.com wrote: Just noticed that the README.md file contains the following: You can get in touch with us on the [user list]( https://groups.google.com/a/cloudera.org/group/bigtop-user/topics) or [developer list]( https://groups.google.com/a/cloudera.org/group/bigtop-dev/topics). This also needs to be fixed before release. Why is this not a .txt file? On 20 August 2011 03:08, sebb seb...@gmail.com wrote: On 19 August 2011 23:14, Andrew Bayer andrew.ba...@gmail.com wrote: Ack, I screwed up and overwrote RC0 with RC1. In any case, please find RC1 at http://people.apache.org/~abayer/bigtop-0.1.0-incubating-candidate-1/. NOTICE looks good, and I can see DISCLAIMER. Archive still contains .gitignore files, which should be excluded. Website should update shortly. No sign yet. A. On Fri, Aug 19, 2011 at 3:00 PM, Andrew Bayer andrew.ba...@gmail.com wrote: Oh, and I'm reformatting NOTICE now as well. The .gitignore files - I'll open a bug to remove the top-level one from the tarball, but the ones that show up deeper are expected by the build process. A. On Fri, Aug 19, 2011 at 2:58 PM, Andrew Bayer andrew.ba...@gmail.com wrote: Which source files are missing the headers? I know there are some files without headers, but the ones I know of are that way because they're expected to be in certain formats, they don't allow comments, etc - these should only be Debian/RPM packaging files, unless I'm missing something. As to the package contents - as far as I can tell, everything is under bigtop-0.1.0-incubating. The contents there are the same as in SVN, same layout as in SVN, etc. The content under test is not yet being built/used, and may well be reorganized later, but it's all there. If there are any inconsistencies with what's in SVN, let me know and I'll check it out. Adding DISCLAIMER now. A. On Fri, Aug 19, 2011 at 2:48 PM, sebb seb...@gmail.com wrote: On 19 August 2011 19:25, Andrew Bayer andrew.ba...@gmail.com wrote: This is the first incubator release for Apache Bigtop, version 0.1.0-incubating. It fixes the following issues: https://issues.apache.org/jira/secure/ReleaseNote.jspa?version=12317549styleName=HtmlprojectId=12311420 *** Please download, test, and vote by Wednesday, August 24 (3 working days from now) Note that we are voting on the source (tag). Source tarball, checksums, signature: http://people.apache.org/~abayer/bigtop-0.1.0-incubating-candidate-0/ A lot of source files don't have any license headers. There's no DISCLAIMER in the archive; needs also to be added to SVN alongside NOTICE and LICENSE. The DISCLAIMER text must also be prominently displayed on the bigtop website. IMO these must be fixed before a release. The NOTICE file has a slightly different layout from normal (not a blocker). It would look better if the paragraph were wrapped after developed at - as is normally done - because the URL would then not be left dangling. I would not expect the .gitignore files to be included in the source release. There seems to be a problem with the packaging of the archive - I would expect all files to be under the top-level directory bigtop-0.1.0-incubating, but there are also parallel directories package, sqoop, smokes etc. This makes it very difficult to check the archive against the source archive. Again, I think this needs to be fixed before release. The tag to be voted on: http://svn.apache.org/repos/asf/incubator/bigtop/tags/release-0.1.0-incubating Bigtop's KEYS file, containing the PGP keys used to sign the release:
