Re: [VOTE] Release Apache HAWQ 2.1.0.0-incubating (RC4)

[Justin Erenkrantz]

+1 (binding)
Verified hashes and sigs
Reviewed DISCLAIMER, README.md, and LICENSE

Cheers.  -- justin

On Tue, Feb 21, 2017 at 8:54 PM, Ed Espino  wrote:

> Hello Incubator PMC (IPMC),
>
> The Apache HAWQ community has voted on and approved a proposal to
> release Apache HAWQ 2.1.0.0-incubating (source only release).
>
> We kindly request that the IPMC members review and vote on this
> incubator release.
>
> The PPMC VOTE thread is here:
> https://lists.apache.org/thread.html/b641ddf4519feba01d3d4c55180be8
> 42a27e75bdaef640175b623e12@%3Cdev.hawq.apache.org%3E
>
> The PPMC VOTE RESULT is here:
> https://lists.apache.org/thread.html/9d3025c12dc032437d1317d662f0e4
> 434754c00258ca1abdd5c0ab9f@%3Cdev.hawq.apache.org%3E
>
> All JIRAs completed for this release are tagged with:
>   fixVersion = 2.1.0.0-incubating
>
> A complete JIRA list can be reviewed here:
> *
> https://issues.apache.org/jira/secure/ReleaseNote.jspa?
> projectId=12318826=12339640
>
> The tag to be voted on: 2.1.0.0-incubating-rc4
> (f5033eaa3c7c1d9f85bbcc56e9d921d96337831a), located here:
> *
> https://git-wip-us.apache.org/repos/asf?p=incubator-hawq.git;a=commit;h=
> 12c7df017551f1c3b0deb38c7243db3e018ef62c
>
> Git release branch:
> *
> https://git-wip-us.apache.org/repos/asf?p=incubator-hawq.
> git;a=shortlog;h=refs/heads/2.1.0.0-incubating
>
> Source release package:
> *
> https://dist.apache.org/repos/dist/dev/incubator/hawq/2.1.0.
> 0-incubating.RC4/apache-hawq-src-2.1.0.0-incubating.tar.gz
>
> Source release verification:
> * PGP Signature:
>
> https://dist.apache.org/repos/dist/dev/incubator/hawq/2.1.0.
> 0-incubating.RC4/apache-hawq-src-2.1.0.0-incubating.tar.gz.asc
> * SHA256/MD5 Hash:
>
> https://dist.apache.org/repos/dist/dev/incubator/hawq/2.1.0.
> 0-incubating.RC4/apache-hawq-src-2.1.0.0-incubating.tar.gz.sha256
>
> https://dist.apache.org/repos/dist/dev/incubator/hawq/2.1.0.
> 0-incubating.RC4/apache-hawq-src-2.1.0.0-incubating.tar.gz.md5
>
> Keys to verify the signature of the release artifact are available at:
> * https://dist.apache.org/repos/dist/dev/incubator/hawq/KEYS
>
> The artifact(s) has been signed with Key ID: 57325522 ("esp...@apache.org
> ")
>
> Build instructions are included in the project's wiki:
> https://cwiki.apache.org/confluence/display/HAWQ/Build+and+Install
>
> When voting, please list the actions taken to verify the release. To
> facilitate Apache license review and conformance, an Apache Release
> Audit Tool (RAT) pom.xml file is included in the source root
> directory.
>
> The vote will be open for at least 72 hours.
>
> Please vote:
> [ ] +1 Approve the release
> [ ] +0 no opinion
> [ ] -1 Don't approve the release (please provide specific comments)
>
> Thanks,
> -=ed espino
>
> --
> *Ed Espino*
> *esp...@apache.org *
>

Re: Concerning Sentry: A disagreement over the Apache Way and graduation

[Justin Erenkrantz]

On Saturday, November 14, 2015, Rich Bowen  wrote:

> No. I can use whatever criteria I like to justify my vote on a podlings
> graduation, if it's in line with asf philosophy. This document is,  and
> accurately reflects the criteria I use when voting on a graduation. That
> is, the document reflects me, not vice versa, as I said above.
>
> It's very akin to the docs that circulate around member election time. They
> are useful guidelines but nobody is compelled to adhere to any particular
> one of them.
>

The difference is that member elections are majority-based - graduation
votes are essentially subject to veto.

There's a huge difference there.  If you are subjecting all of your votes
to that checklist and will actively block podlings that do not meet your
personal guidelines, you are making everyone else subject to it.  -- justin

Re: Concerning Sentry: A disagreement over the Apache Way and graduation

[Justin Erenkrantz]

On Wed, Nov 4, 2015 at 12:50 PM, Roman Shaposhnik  wrote:
> Correct. It is a tool, but not a requirement (at least not yet).
> And since I repeatedly suggested this tool on this thread let me explain why.

And, this is the root of my concern expressed in the other general@
thread: I fear that this is going to quickly evolve to yet another
bureaucratic form that the IPMC is going to quickly require all
projects to complete.

We should not be trying to force rote learning.  Every community is different.

Trust the mentors or don't - but, I am very much opposed to more
overhead.  Forcing projects to feel like they have to report monthly
is against what we should be about.  I believe that the IPMC should be
imposing the barest amount of overhead to what the Board requires from
the full projects.  To that end, having mentors explicitly sign-off is
fair - but, additional paperwork is not.  -- justin

-
To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
For additional commands, e-mail: general-h...@incubator.apache.org

Re: maturity guidelines (was Re: Concerning Sentry: A disagreement over the Apache Way and graduation)

[Justin Erenkrantz]

On Thu, Nov 5, 2015 at 4:37 PM, Roman Shaposhnik  wrote:
> ...that brought us to our current, much less forceful, treatment
> of the maturity model. Which is what I (and a few others including
> it seems yourself) have been advocating on *this* thread.

I took the tenor of the conversation as heading in a direction where
mentors would be expected to fill it out or the IPMC would stop any
graduation conversations.

If a podling chooses to voluntarily fill it out, great.  But, don't
put the burden on mentors to fill out some crazy paperwork.  -- justin

-
To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
For additional commands, e-mail: general-h...@incubator.apache.org

Re: Mentor disengagement - a suggestion

[Justin Erenkrantz]

I will just note that I disagree with adding bureaucracy like this.
We already require podlings to submit reports as frequently as
monthly.  (Geode somehow had to report monthly for no discernible
reason.)

This further adds to the burden on being a mentor - probably to
something like being a teacher enforcing a pedagogical structure on
the podlings.  I don't think that is what we should be striving for.
For the two podlings I currently mentor (Geode and HAWQ), I keep an
eye on the mailing lists and try to ensure that any process questions
that are raised are addressed.  In the early days of Geode, there was
a bit of that - less so now as the community is finding its way.  HAWQ
seems to be doing well - nothing surprising that I can tell so far.

I believe in a "big tent" foundation - we should welcome new projects
of any stripe.  If they fail within the Incubator to graduate, so be
it.  But, that is separate from asking the mentors to somehow be
"responsible" for the podlings.  I have an interest to see them
succeed, but if it doesn't, *shrug* and we move on.  I don't see any
value in adding more bureaucracy as it will further sap any motivation
to truly "mentor" projects.  I view the mentor as someone that can be
called upon, but doesn't necessarily require active involvement on a
daily basis.  If I wanted that, I would be a committer to the project.
Let's not confuse the two.

My $.02.  -- justin

On Mon, Oct 12, 2015 at 7:18 AM, Rich Bowen  wrote:
> Fellow mentors,
>
> There was a conversation at ApacheCon about the Incubator. I'll leave it to
> the other participants to champion the particular parts that they are
> passionate about, but I was particularly concerned with mentor
> disengagement, and suggestions for improving it.
>
> A mentor's role is to help a project learn the ropes at the ASF, and that
> mentor might not necessarily be deeply versed in the particular technology
> that the podling works with. As such, it can frequently be the case that the
> mentor becomes disengaged from the daily conversation of the lists, and
> eventually with the entire process.
>
> As a means of refocusing the mentors' efforts, and keeping them engaged, I'd
> like to encourage each mentor (or group of mentors) to consider writing a
> running report (ie, evolving, updated every quarter) based on
> https://community.apache.org/apache-way/apache-project-maturity-model.html
> where they evaluate each point on the maturity model, as a path towards
> graduation. This gives a concrete target, and a lens through which to view
> the podling's progress towards that target.
>
> This could be kept in the incubator wiki, and linked from the official
> project report, or it could be maintained just for your own benefit. I think
> it would be particularly useful to attach to a graduation recommendation, as
> a sign that the recommendation is more than just checking the various boxes,
> but is a glowing endorsement of the project's readiness to be TLP.
>
> As a side-note, I'd also encourage mentors who are mentors in name only, and
> not reality, to consider cleaning up the paperwork by removing themselves
> from the roster. It doesn't look great when a podling can't get mentor
> signoff on their reports.
>
> --
> Rich Bowen - rbo...@rcbowen.com - @rbowen
> http://apachecon.com/ - @apachecon
>
> -
> To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
> For additional commands, e-mail: general-h...@incubator.apache.org
>

-
To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
For additional commands, e-mail: general-h...@incubator.apache.org

Re: [DISCUSS] [REVISED] Mentor neutrality policy

[Justin Erenkrantz]

On Sun, Oct 11, 2015 at 5:39 PM, Daniel Gruno  wrote:
> First off: Can we *please* focus on the revised proposal and not get
> into a loop about the original email? I'll change the topic if that helps.
>
> The revised edition, as partly suggested by Sam (and echoed by Bertrand)
> was:
>
> - Binding votes on incubation, graduation and/or retirement are only
> valid when given by members of the IPMC who are independent from the
> podling in question. Mentors are free to recommend such actions, but
> cannot cast a vote themselves.

I am -1 to this revised proposal as well.

I think this proposal would even further politicize or inhibit
projects from coming to the Incubator.

I stand by the criteria that mentors should be ASF members.  If you
don't believe that the members can be trusted, then you should be
campaigning to get those individuals removed from membership.

My $.02.  -- justin

-
To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
For additional commands, e-mail: general-h...@incubator.apache.org

Re: [VOTE] Accept HAWQ into the Apache Incubator

[Justin Erenkrantz]

 to convert that interest directly into
> participation and will be investing in activities to recruit
> additional committers from other companies.
>
> === Reliance on Salaried Developers ===
> Most of the contributors are paid to work in the Big Data space. While
> they might wander from their current employers, they are unlikely to
> venture far from their core expertise and thus will continue to be
> engaged with the project regardless of their current employers.
>
> === Relationships with Other Apache Products ===
> As mentioned in the Alignment section, HAWQ may consider various
> degrees of integration and code exchange with Apache Hadoop, Apache
> Spark and Apache Hive projects. We expect integration points to be
> inside and outside the project. We look forward to collaborating with
> these communities as well as other communities under the Apache
> umbrella.
>
> === An Excessive Fascination with the Apache Brand ===
> While we intend to leverage the Apache ‘branding’ when talking to
> other projects as testament of our project’s ‘neutrality’, we have no
> plans for making use of Apache brand in press releases nor posting
> billboards advertising acceptance of HAWQ into Apache Incubator.
>
> == Documentation ==
> The documentation is currently available at http://hawq.docs.pivotal.io/
>
> == Initial Source ==
> Initial source code will be available immediately after Incubator PMC
> approves HAWQ joining the Incubator and will be licensed under the
> Apache License v2.
>
> == Source and Intellectual Property Submission Plan ==
> As soon as HAWQ is approved to join the Incubator, the source code
> will be transitioned via an exhibit to Pivotal's current Software
> Grant Agreement onto ASF infrastructure and in turn made available
> under the Apache License, version 2.0.  We know of no legal
> encumberments that would inhibit the transfer of source code to the
> ASF.
>
> == External Dependencies ==
>
> Runtime dependencies:
>   * gimli (BSD)
>   * openldap (The OpenLDAP Public License)
>   * openssl (OpenSSL License and the Original SSLeay License, BSD style)
>   * proj (MIT)
>   * yaml (Creative Commons Attribution 2.0 License)
>   * python (Python Software Foundation License Version 2)
>   * apr-util (Apache Version 2.0)
>   * bzip2 (BSD-style License)
>   * curl (MIT/X Derivate License)
>   * gperf (GPL Version 3)
>   * protobuf (Google)
>   * libevent (BSD)
>   * json-c (https://github.com/json-c/json-c/blob/master/COPYING)
>   * krb5 (MIT)
>   * pcre (BSD)
>   * libedit (BSD)
>   * libxml2 (MIT)
>   * zlib (Permissive Free Software License)
>   * libgsasl (LGPL Version 2.1)
>   * thrift (Apache Version 2.0)
>   * snappy (Apache Version 2.0 (up to 1.0.1)/New BSD)
>   * libuuid-2.26 (LGPL Version 2)
>   * apache hadoop (Apache Version 2.0)
>   * apache avro (Apache Version 2.0)
>   * glog (BSD)
>   * googlemock (BSD)
>
> Build only dependencies:
>   * ant (Apache Version 2.0)
>   * maven (Apache Version 2.0)
>   * cmake (BSD)
>
> Test only dependencies:
>   * googletest (BSD)
>
> Cryptography N/A
>
> == Required Resources ==
>
> === Mailing lists ===
>   * priv...@hawq.incubator.apache.org (moderated subscriptions)
>   * comm...@hawq.incubator.apache.org
>   * d...@hawq.incubator.apache.org
>   * iss...@hawq.incubator.apache.org
>   * u...@hawq.incubator.apache.org
>
> === Git Repository ===
> https://git-wip-us.apache.org/repos/asf/incubator-hawq.git
>
> === Issue Tracking ===
> JIRA Project HAWQ (HAWQ)
>
> === Other Resources ===
>
> Means of setting up regular builds for HAWQ on builds.apache.org will
> require integration with Docker support.
>
> == Initial Committers ==
>   * Lirong Jian
>   * Hubert Huan Zhang
>   * Radar Da Lei
>   * Ivan Yanqing Weng
>   * Zhanwei Wang
>   * Yi Jin
>   * Lili Ma
>   * Jiali Yao
>   * Zhenglin Tao
>   * Ruilong Huo
>   * Ming Li
>   * Wen Lin
>   * Lei Chang
>   * Alexander V Denissov
>   * Newton Alex
>   * Oleksandr Diachenko
>   * Jun Aoki
>   * Bhuvnesh Chaudhary
>   * Vineet Goel
>   * Shivram Mani
>   * Noa Horn
>   * Sujeet S Varakhedi
>   * Junwei (Jimmy) Da
>   * Ting (Goden) Yao
>   * Mohammad F (Foyzur) Rahman
>   * Entong Shen
>   * George C Caragea
>   * Amr El-Helw
>   * Mohamed F Soliman
>   * Venkatesh (Venky) Raghavan
>   * Carlos Garcia
>   * Zixi (Jesse) Zhang
>   * Michael P Schubert
>   * C.J. Jameson
>   * Jacob Frank
>   * Ben Calegari
>   * Shoabe Shariff
>   * Rob Day-Reynolds
>   * Mel S Kiyama
>   * Charles Alan Litzell
>   * David Yozie
>   * Ed Espino
>   * Caleb Welton
>   * Parham Parvizi
>   * Dan Baskette
>   * Christian Tzolov
>   * Tushar Pednekar
>   * Greg Chase
>   * Chloe Jackson
>   * Michael Nixon
>   * Roman Shaposhnik
>   * Alan Gates
>   * Owen O'Malley
>   * Thejas Nair
>   * Don Bosco Durai
>   * Konstantin Boudnik
>   * Sergey Soldatov
>   * Atri Sharma
>
> == Affiliations ==
>   * Barclays:  Atri Sharma
>   * Bloomberg: Justin Erenkrantz
>   * Hortonworks: Alan Gates, Owen O'Malley, Thejas Nair, Don Bosco Durai
>   * WANDisco: Konstantin Boudnik, Sergey Soldatov
>   * Pivotal: everyone else on this proposal
>
> == Sponsors ==
>
> === Champion ===
> Roman Shaposhnik
>
> === Nominated Mentors ===
>
> The initial mentors are listed below:
>   * Alan Gates - Apache Member, Hortonworks
>   * Owen O'Malley - Apache Member, Hortonworks
>   * Thejas Nair - Apache Member, Hortonworks
>   * Konstantin Boudnik - Apache Member, WANDisco
>   * Roman Shaposhnik - Apache Member, Pivotal
>   * Justin Erenkrantz - Apache Member, Bloomberg
>
> === Sponsoring Entity ===
> We would like to propose Apache incubator to sponsor this project.
>
> -
> To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
> For additional commands, e-mail: general-h...@incubator.apache.org
>
>

Re: [DISCUSS] HAWQ Incubation Proposal

[Justin Erenkrantz]

On Fri, Aug 28, 2015 at 7:45 PM, Roman Shaposhnik ro...@shaposhnik.org wrote:
 I would much prefer a smaller list of initial committers who have been
 identified as having experience or a solid potential to be ASF
 committers, and let others be elected based on merit as the project
 progresses.

 I would agree that this could be a problem if the project didn't have
 enough active mentors to help a large # of folks master the Apache Way.
 With Justin volunteering at this point we've got 6 very active, very
 experienced mentors. I really don't think the # of committers should be
 a problem.

I agree with Roman.

I think that it would be better to have the list of initial committers
be closer to reality (in the eyes of the proposed project) than
artificially limit it.

During the incubation process, the community can work through the
process of expanding (or contracting if needed - hopefully not!) the
community.

Cheers.  -- justin

-
To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
For additional commands, e-mail: general-h...@incubator.apache.org

Re: [DISCUSS] HAWQ Incubation Proposal

[Justin Erenkrantz]

On Thu, Aug 20, 2015 at 11:14 PM, Roman Shaposhnik r...@apache.org wrote:
 Hi!

 I would like to start a discussion on accepting HAWQ
 into ASF Incubator. The proposal is available at:
 https://wiki.apache.org/incubator/HAWQProposal
 and is also attached to the end of this email.

If HAWQ desires more mentors, I'd be willing to be included as well.

Cheers.  -- justin

-
To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
For additional commands, e-mail: general-h...@incubator.apache.org

Re: [DISCUSS] Communicating intent around non-release, downstream integration binary artifacts

[Justin Erenkrantz]

On Tue, Jun 23, 2015 at 10:48 PM, Roman Shaposhnik ro...@shaposhnik.org wrote:
 On Tue, Jun 23, 2015 at 3:20 PM, Ross Gardler (MS OPEN TECH)
 ross.gard...@microsoft.com wrote:
 There is nothing preventing clearly identifiable non-release artifacts
 available to the general public. Many projects make automated nightly 
 builds available for example.

 This! Honestly this has always been my personal interpretation of the policy
 (although now that I'm re-reading it I see how it could be interpreted in a
 radically different way).

 IOW, I've been mentoring a lot of poddlings and advising them that as
 long as they go out of their way to label 'nightly' artifacts as NON RELEASE,
 DON'T TRY IT AT HOME, DANGER!!! it is ok to make them available to
 general public (*). I have always though that, for example, -SNAPSHOT 
 version
 designation is enough to communicate that  type of intent. Same as
 SNAPSHOT/NONRELEASE tag on Docker image, etc.

I agree.  As long as the version designation of the artifact includes
-SNAPSHOT or -DEV or whatever, I think that's sufficient to qualify as
a clearly identifiable non-release artifact.

FWIW, httpd always had nightly tarballs available for consumption and testing.

I do think that the threshold is that it needs to come from an
automated process blessed by the [P]PMC.  If it requires a human to
publish the nightly into the distribution channel, then I think
that's probably where the line gets crossed and our voting rules
apply.

Nightly builds shouldn't be easily found - except deep inside
developer-facing documentations.  All obvious materials should point
at the official, blessed releases.  But, it's important to provide a
channel for downstream people to test trunk/master/develop (whatever
shiny name the project calls it).

In today's day and age, producing Docker-like thingys is akin to
producing RPMs.  I won't go into why I think the centralized Docker
Hub is a huge mistake - it's simply how you consume Docker thingys.  I
do wish that we could point folks at a specific Docker registries (a
la an apt or yum repos), but having a single global registry is how
Docker, Inc. apparently thinks that it'll justify its valuations.
Sigh.

Cheers.  -- justin

-
To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
For additional commands, e-mail: general-h...@incubator.apache.org

Re: [DISCUSS] Communicating intent around non-release, downstream integration binary artifacts

[Justin Erenkrantz]

On Tue, Jun 23, 2015 at 11:06 PM, Sean Busbey bus...@cloudera.com wrote:
 While I agree that this is a general issue that should be discussed, an
 example might help. This discussion started because the Geode PMC is
 publishing a docker artifact from their nightly builds and then pointing
 the general public to make use of that image. They have no released
 artifacts, so any downstream user necessarily will be using those
 non-vetted artifacts.

Once releases are made, then I think any Geode documentation would
definitely shift to referring to the released versions.  However,
Geode isn't yet ready to cut a release.

I do doubt that anyone who picks up a nightly Geode build right now is
going to put it into production.  So, I'm not overly worried.

By the time the project is ready to graduate, there will be several
releases (if not more) and I fully expect that this'll be a moot
point.

 Downstream developers and users *will* take the path of lease resistance.
 If that PMC wanted to continue relying on a binary docker image for
 community outreach indefinitely, would that be okay? If they wanted to rely
 on it and only have PMC blessed releases quarterly?

As I mentioned in my other email, as long as it's automated and
producing a nightly artifact that is appropriately labeled, then, sure
go for it, IMO.

Cheers.  -- justin

-
To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
For additional commands, e-mail: general-h...@incubator.apache.org

Re: [VOTE] Accept Mysos into the Apache Incubator

[Justin Erenkrantz]

On Sat, May 30, 2015 at 6:42 PM, Ted Dunning ted.dunn...@gmail.com wrote:
 It is vexed because when pronounced by many people, it sounds almost
 identical to how those same people would pronounce Mesos.

 That can lead to confusion.

As there has been no trademark confusion raised, I would strongly
prefer that we provide a tremendous amount of deference towards the
desire of the contributors/community to the naming of the project.

They've expressed their desire to keep Mysos as their name.  That is
more than sufficient for me.  -- justin

P.S. FWIW, I definitely don't pronounce Mysos the same as Mesos...but, YMMV.

-
To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
For additional commands, e-mail: general-h...@incubator.apache.org

Re: [VOTE] Accept Mysos into the Apache Incubator

[Justin Erenkrantz]

On Thu, May 28, 2015 at 12:14 PM, Jake Farrell jfarr...@apache.org wrote:
 Based on the earlier discussion in thread [1], I would like to call a VOTE
 to accept Mysos, an Apache Mesos framework for running MySQL instances, as
 a new Apache Incubator project.

 The proposal is available on the wiki at [2] and is also attached below

 The VOTE is open for at least the next 72 hours:

   [ ] +1 Accept Mysos into the Apache Incubator
   [ ] ±0
   [ ] -1 Do not accept Mysos into the Apache Incubator because...

+1.  -- justin

-
To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
For additional commands, e-mail: general-h...@incubator.apache.org

Re: [VOTE] Accept Trafodion into Apache Incubator

[Justin Erenkrantz]

On Tue, May 19, 2015 at 2:27 PM, Stack st...@duboce.net wrote:
 Following the discussion earlier in the thread [1], I would like to call a
 VOTE to accept Trafodion as a new Apache Incubator project.

 The proposal is available on the wiki at [2] and is also attached to this
 mail.

 The VOTE is open for at least the next 72 hours:

  [ ] +1 accept Trafodion into the Apache Incubator
  [ ] ±0 Abstain
  [ ] -1 because...

+1.  Good luck!  -- justin

-
To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
For additional commands, e-mail: general-h...@incubator.apache.org

Re: [VOTE] Apache Ignite 1.1.0 release (RC5)

[Justin Erenkrantz]

On Tue, May 19, 2015 at 6:09 PM, Branko Čibej br...@apache.org wrote:
 On 20.05.2015 00:44, Justin Mclean wrote:
 Hi,

 +0 (binding) from me until these 2 issues are resolved. Of course other IPMC 
 members may vote differently.

 Several bundled files have GPL license headers e.g. 
 ./ipc/shmem/config.guess, ./ipc/shmem/ltmain.sh etc. While these look like 
 auto generated build files but I'm not sure that they can be included in a 
 source release.

 There's no way around including such files; any normal (i.e., not Java
 :) source package that uses configure and libtool needs those files
 bundled in the source.

If you read the license text in those files, those files carry
well-known exceptions - see below.  So, it should be fine.
(httpd/Subversion/APR release tarballs usually end up with similar
files.)  -- justin

config.guess:
# As a special exception to the GNU General Public License, if you
# distribute this file as part of a program that contains a
# configuration script generated by Autoconf, you may include it under
# the same distribution terms that you use for the rest of that
# program.  This Exception is an additional permission under section 7
# of the GNU General Public License, version 3 (GPLv3).

ltmain.sh:
# As a special exception to the GNU General Public License,
# if you distribute this file as part of a program or library that
# is built using GNU Libtool, you may include this file under the
# same distribution terms that you use for the rest of that program.

-
To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
For additional commands, e-mail: general-h...@incubator.apache.org

Re: [VOTE] Accept Geode into the Apache Incubator

[Justin Erenkrantz]

* commons-io
* commons-lang
* commons-modeler
* fastutil
* findbugs annotations
* guava
* jackson
* jansi
* javax.activation
* javax.mail-api
* javax.resource-api
* javax.servlet-api
* javax.transaction-api
* jetty
* jline
* jna
* json4s
* log4j
* mx4j
* paranamer
* scala
* slf4j
* snappy-java
* spring
* swagger

 Module or optional dependencies:
* None

 Build only dependencies:
* None

 Test only dependencies:
* cglib
* hamcrest
* jmock
* junit
* multithreadedtc
* objenesis

 Cryptography
 N/A

 == Required Resources ==

 === Mailing lists ===
   * priv...@geode.incubator.apache.org (moderated subscriptions)
   * comm...@geode.incubator.apache.org
   * d...@geode.incubator.apache.org
   * iss...@geode.incubator.apache.org
   * u...@geode.incubator.apache.org

 === Git Repository ===
 https://git-wip-us.apache.org/repos/asf/incubator-geode.git

 === Issue Tracking ===
 JIRA Project Geode (GEODE)

 === Other Resources ===

 Means of setting up regular builds for Geode on builds.apache.org

 == Initial Committers ==
   * Amey Barve
   * Adib Saikali
   * Alan Strait
   * Amogh Shetkar
   * Anil Gingade
   * Anilkumar Gingade
   * Anthony Baker
   * Ashvin Agrawal
   * Asif Shahid
   * Avinash Dongre
   * Barry Oglesby
   * Ben Reser
   * Bruce Schuchardt
   * Bruce Szalwinski
   * Catherine Johnson
   * Chip Childers
   * Christian Tzolov
   * Dan Smith
   * Darrel Schneider
   * Dave Muirhead
   * David Yozie
   * Dick Cavender
   * Edin Zulich
   * Eric Shu
   * Gideon Low
   * Greg Chase
   * Hemant Bhanawat
   * Henry Saputra
   * Hitesh Khamesra
   * Jacob Barrett
   * Jags Ramnarayan
   * Jan Iversen
   * Jason Huynh
   * Jens Deppe
   * Jianxia Chen
   * John Blum
   * Justin Erenkrantz
   * Ketan Deshpande
   * Kirk Lund
   * Kishor Bachhav
   * Konstantin Boudnik
   * Konstantin Ignatyev
   * Lise Storc
   * Luke Shannon
   * Lyndon Adams
   * Lynn Gallinat
   * Lynn Hughes-Godfrey
   * Mark Bretl
   * Michael Schubert
   * Namrata Thanvi
   * Neeraj Kumar
   * Nilkanth Patel
   * Qihong Chen
   * Rahul Diyewar
   * Randy May
   * Roman Shaposhnik
   * Severine Tymon
   * Shatarupa Nandi
   * Shirish Deshmukh
   * Sonal Agarwal
   * Soubhik Chakraborty
   * Sourabh Bansod
   * Stephane Maldini
   * Stuart Williams
   * Sudhir Menon
   * Sunil Jigyasu
   * Supriya Pillai
   * Suranjan Kumar
   * Suyog Bhokare
   * Swapnil Bawaskar
   * Swati Sawant
   * Tushar Khairnar
   * Udo Kohlmeyer
   * Vince Ford
   * Vinesh Prasanna Manoharan
   * Vivek Bhaskar
   * Wes Williams
   * William A. Rowe Jr.
   * William Markito
   * Will Schipp
   * Xiaojian Zhou
   * Yogesh Mahajan

 == Affiliations ==
   * WANDisco: Konstantin Boudnik
   * Bloomberg LP: Justin Erenkrantz
   * Cloud Foundry Foundation: Chip Childers
   * NASA JPL: Chris Mattmann
   * Unaffiliated: Jan Iversen
   * CDK Global: Ben Reser, Konstantin Ignatyev, Bruce Szalwinski
   * Pivotal: everyone else on this proposal

 == Sponsors ==

 === Champion ===
 Roman Shaposhnik

 === Nominated Mentors ===

 The initial mentors are listed below:
   * Chip Childers - Apache Member, Cloud Foundry Foundation
   * Justin Erenkrantz - Apache Member, Bloomberg LP
   * Konstantin Boudnik - Apache Member, WANDisco
   * Jan Iversen - Apache Member, Self employed
   * William A. Rowe Jr. - Apache Member, Pivotal
   * Henry Saputra - Apache Member, Pivotal
   * Roman Shaposhnik - Apache Member, Pivotal
   * Chris Mattmann - Apache Member, NASA JPL

 === Sponsoring Entity ===
 We would like to propose Apache incubator to sponsor this project.

 -
 To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
 For additional commands, e-mail: general-h...@incubator.apache.org

Re: [PROPOSAL] Apache Atlas for Data Governance on Hadoop

[Justin Erenkrantz]

On Wed, Apr 15, 2015 at 8:55 AM, Ted Dunning ted.dunn...@gmail.com wrote:
 I hate to be a pissant, but why does it follow that new code has to be
 implemented in private?

 Building community can start with the first semi-colon.  It doesn't have to
 wait until the code is frozen.

We were having this conversation with a bunch of folks last night here
in Austin.

One thing Brian mentioned in his keynote this week is that our culture
borrows from the IETF for rough consensus, running code.

It's extremely hard to come to Apache when you have a vague idea and no code.

The Incubator is simply too high a bar for folks who just want to play
with an idea and aren't sure where it is heading.

So, I wouldn't hold it against people - turn it on ourselves - how can
we create a process to facilitate people who aren't ready yet?

FWIW, my opinion from last night is that is exactly what GitHub is
for.  (Apache Labs was that place at one time, but it's only for
members - not external folks.)  Once you have that rough consensus and
running code and have a fledgling community of stakeholders, then it's
time to bring it to Apache via the Incubator.  To be fair, there were
others who disagreed; but, the rough consensus (ha!) was that the
Incubator hasn't yet cracked that model.

My $.02.  -- justin

-
To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
For additional commands, e-mail: general-h...@incubator.apache.org

Re: [DISCUSS] Geode Incubation proposal

[Justin Erenkrantz]

On Mon, Apr 13, 2015 at 3:20 PM, Ross Gardler (MS OPEN TECH)
ross.gard...@microsoft.com wrote:
 If I understand the response below correctly you misspoke when you said there 
 were export issues. That in fact there is no related export restriction, 
 it's actually about the licensing issue. If that's the case then the proposal 
 is correct in not highlighting these issues - thanks for clarifying that.

 I replied to the third part in response to Bill's question. However, to be 
 sure my point gets across. Now that you have confirmed there are in fact no 
 export restrictions then I have no problem with the proposal. However, I'd 
 still like to be able to evaluate the code and to do so I would need to know 
 what I'm agreeing to under the evaluation license.

FWIW, the clickthrough license et al worked for me on my Mac with Chrome.

Inspecting the code will be a lot easier once the proposal is accepted
and we can import the code under ALv2 into our repositories.

*grin*  -- justin

-
To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
For additional commands, e-mail: general-h...@incubator.apache.org

Re: [DISCUSS] Geode Incubation proposal

[Justin Erenkrantz]

 On 13 Apr 2015, at 06:39, Ted Dunning ted.dunn...@gmail.com wrote:

 I think it is common to take a quick look at code coming in.  In

To be clear, there were conversations with Jim (as VP Legal) prior to
this submission.  The ASF wouldn't accept the software grant until the
Incubator approved the proposal.  Pivotal wouldn't release it as ALv2
until the ASF accepted the grant.

It's a chicken-and-egg problem - seeing the code through the
click-through evaluation license is the least bad scenario that drives
this proposal forward.

As a mentor unaffiliated with Pivotal, I'm not worried about the
provenance checks - Pivotal is ready to execute the software grant and
release it as ALv2.

On Mon, Apr 13, 2015 at 7:40 AM, Steve Loughran ste...@hortonworks.com wrote:
 looking at the list of committers -it looks like a whole organisation is 
 going to move to doing OSS dev. That's a pretty big move.

Yes, it is.  I'm confident in my conversations with the Pivotal team
that they fully understand what will be asked of them.  However, as a
mentor, the proof will be in the pudding and will be demonstrated
through the Incubation process...or not.

 1. The withdrawal of support for Groovy shows that pivotal have been ruthless 
 in the past about where to invest their OSS dev. It's a bit dangerous to list 
 Groovy as a reference for pivotal's OSS experience. It shows they've done it, 
 but it shows that the commitment is not indefinite funding (to be fair, no 
 single org can guarantee that). Spring is the one to really emphasis.

Companies are always free to re-evaluate where they spend their time
and resources.  I actually view the experience with Groovy as a
positive thing in the macro sense.  The point of submitting Geode to
the ASF is to ensure the longevity of the project and community - the
lesson from Groovy is to ensure it is in appropriate foundation that
will care for it.

 2. It will make it more of a barrier to getting other developers in; it'll 
 take active effort to bring them in, especially a transition to a process of 
 decision making over the lists, rather than in meetings. Again, a perennial 
 problem that we all encounter -not an argument against the proposal, just 
 something that will take active effort.

This is why we have an Incubator.  =)

 I don't see it leaving incubation with more non-pivotal dev/contrib than the 
 pivotal team, just because of the numbers. The mentors/vote will have to 
 consider how many external developers constitutes enough to be an active, 
 open dev community. Again, a permanent problem (*), it just means here that 
 it will be very skewed towards pivotal. I think that open-source discussion 
 and decision making should be a key metric here, rather than just looking at 
 numbers.

Fully agreed for exit criteria, but let's get it in first!  -- justin

-
To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
For additional commands, e-mail: general-h...@incubator.apache.org

Re: [DISCUSS] Poddling new committer process

[Justin Erenkrantz]

On Fri, Nov 12, 2010 at 12:20 AM, ant elder ant.el...@gmail.com wrote:
 I'd like to propose that the process for Incubator poddlings to make
 someone a new committer is simplified so that all that is needed are
 votes from poddling committers and that there is no longer any need
 for votes from Incubator PMC members or a separate Incubator PMC vote.

+1.

As Bertrand said, I'm ok with requiring at least one mentor voting and
notice sent to private@ *afterwards*.  -- justin

-
To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
For additional commands, e-mail: general-h...@incubator.apache.org

Re: [VOTE] OODT Graduation to TLP

[Justin Erenkrantz]

On Thu, Nov 11, 2010 at 7:18 AM, Mattmann, Chris A (388J)
chris.a.mattm...@jpl.nasa.gov wrote:
 Please VOTE on the below resolution for promoting OODT to an Apache TLP and
 graduating from the Incubator. The VOTE is open for 72 hrs.

 [ ] +1 Accept OODT's graduation from the Incubator
 [ ] +0 Don't care.
 [ ] -1 Don't accept OODT's graduation from the Incubator because...

+1.  -- justin

-
To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
For additional commands, e-mail: general-h...@incubator.apache.org

Re: [VOTE] Apache OODT 0.1-incubating release (rc4)

[Justin Erenkrantz]

On Sun, Oct 31, 2010 at 5:29 PM, david woollard wooll...@gmail.com wrote:
 [X] +1 Release the packages as Apache OODT 0.1-incubating

Just did a visual comparison (diff -ru) between RC1 and RC4.  Changes look fine.

+1 for release.

Thanks.  -- justin

-
To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
For additional commands, e-mail: general-h...@incubator.apache.org

Re: [VOTE] Apache OODT 0.1-incubating release (rc4)

[Justin Erenkrantz]

On Mon, Nov 1, 2010 at 2:10 PM, Alan D. Cabrera l...@toolazydogs.com wrote:
 The release doesn't need to be tagged?

It's...uh...version controlled.  So, it's still easy to create a tag:

svn cp 
https://svn.apache.org/repos/asf/incubator/oodt/branches/0.1-incubat...@1029464
https://svn.apache.org/repos/asf/incubator/oodt/tags/0.1-rc4
(or just 0.1)

Cheers.  -- justin

-
To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
For additional commands, e-mail: general-h...@incubator.apache.org

Re: No dev-, user- lists for small podlings (was: Re: [PROPOSAL] Kitty to Enter the Incubator)

[Justin Erenkrantz]

On Thu, Sep 9, 2010 at 12:20 PM, Greg Stein gst...@gmail.com wrote:
 For reference:

 * Subversion created its dev list in April 2000.
 * The user list was created in July 2003. 238 messages were posted that month.

 As you can see, we waited a very long time before sending users to
 their own list. Our dev list was very heavily trafficked by our users.
 It kept the larger community together until the point where they could
 safely work on their own.

I think my post at the time gives light as to why we waited so long
and why I felt it was time for the user list to be created:

http://svn.haxx.se/dev/archive-2003-07/1363.shtml

BTW, those 238 messages in July all came in 10 days...  =P  -- justin

-
To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
For additional commands, e-mail: general-h...@incubator.apache.org

Re: Name change from Lucene Connectors Framework to Apache Connectors Framework

[Justin Erenkrantz]

On Tue, Aug 24, 2010 at 2:55 PM, Upayavira u...@odoko.co.uk wrote:
 If the name is going to change (which sounds like a good idea) I'd
 suggest going for something more abstract, to which you can give
 meaning: Apache Connecto, or some such.

+1.  -- justin

-
To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
For additional commands, e-mail: general-h...@incubator.apache.org

Re: [VOTE] experimental delegation of new committer votes to PPMC

[Justin Erenkrantz]

On Wed, Aug 18, 2010 at 4:11 PM, Joe Schaefer joe_schae...@yahoo.com wrote:
 Now that the board has declared there are no legal
 obstacles to what I have proposed, I'd like to
 restart the vote.

+1.  -- justin

-
To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
For additional commands, e-mail: general-h...@incubator.apache.org

Re: an experiment

[Justin Erenkrantz]

On Mon, Aug 16, 2010 at 2:32 PM, Gav... ga...@16degrees.com.au wrote:
 have something to say about it. I'm surprised no-one has mentioned about the
 Incubator PMC Chair
 up until now (actually I'm not, and I bet that no one steps up to agree with
 me here, I expect
 to be alone in my opinion.)

I agree with you.

I hate having to be cranky whenever I deal with the Incubator - it's
no fun.  So, any experiments we can foster, yay, I want more - not
less.  -- justin

-
To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
For additional commands, e-mail: general-h...@incubator.apache.org

Re: Radical revamp

[Justin Erenkrantz]

On Tue, Aug 17, 2010 at 4:55 PM, Joe Schaefer joe_schae...@yahoo.com wrote:
 Agreed, but I will claim that my proposal has worked successfully for httpd,
 so it's not coming out of the clear blue sky.  Perhaps you're onto something,
 that diversifying the podling incubation process so we can pick the right 
 fit
 has the best chance of overall success.

+1.  -- justin

-
To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
For additional commands, e-mail: general-h...@incubator.apache.org

Re: an experiment

[Justin Erenkrantz]

On Mon, Aug 16, 2010 at 9:36 AM, Noel J. Bergman n...@devtech.com wrote:
 And if the Mentors aren't being active, voting, etc., then *that* is what
 needs to be addressed.

As I've repeatedly stated before (here and elsewhere), in the podlings
I've been recently involved with, having three mentors isn't the
issue.  It's the PMC members who aren't involved sticking their nose
in and trying to poison the community.

 We have one of the largest PMCs in the ASF.  If we

I view this as potentially the crux of the problem - people who aren't
stakeholders in the community shouldn't have a say.  Right now, they
feel they do.  So, if we want to mandate at least 3 mentors - fine,
but that must come at the cost of telling the rest of the IPMC to go
away - unless they actively contribute to the community and earn
merit...of course.  -- justin

-
To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
For additional commands, e-mail: general-h...@incubator.apache.org

Re: an experiment

[Justin Erenkrantz]

On Mon, Aug 16, 2010 at 10:06 AM, Joe Schaefer joe_schae...@yahoo.com wrote:
 Perhaps that's true for the projects you work on, but it certainly
 isn't true of Thrift, where mentorship has been a revolving door
 for years.

True.  I've never been a big fan of requiring 3 mentors - as I think
certain personalities can do the teaching by themselves.  However, if
accepting that minimum requirement resolves the over-reach by others,
I'd accept that tradeoff.  Yes, it might kill off Thrift, but harming
podlings with 3+ active mentors is even worse behavior.  -- justin

-
To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
For additional commands, e-mail: general-h...@incubator.apache.org

Re: an experiment

[Justin Erenkrantz]

On Mon, Aug 16, 2010 at 10:37 AM, Noel J. Bergman n...@devtech.com wrote:
 Where are you seeing this over-reach problem to which you refer?  I have
 heard of a few isolated incidents, and those can be addressed.  But by far
 and way, the biggest complaint is LACK of involvement, e.g.,
...
 And most cases of PMC members getting involved in projects of which they
 aren't a Mentor have been with respect to release packaging, where the
 involvement has generally been valid and valuable, even if bothersome to
 those whose packages weren't quite up to snuff.

 But, seriously, if there is systemic overreaching, lets address *that*
 issue.

The cases of overreaching in Subversion and OODT related to adding
new committers - not releases.  So, I'm definitely in favor of Joe's
proposal to let the PPMC have control over who gets to be in the
community.  -- justin

-
To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
For additional commands, e-mail: general-h...@incubator.apache.org

Re: an experiment

[Justin Erenkrantz]

On Mon, Aug 16, 2010 at 11:22 AM, Noel J. Bergman n...@devtech.com wrote:
 What happened?

It's all in the archives, but a quick recap.

For Subversion, an Incubator PMC member who was never involved in the
SVN community jumped in the middle of a committer vote to vote -1.
Greg wrote a cranky email telling him to go away.  Most of the
committers in SVN were taken aback by the behavior.  Who is this
person? Why do they get to vote -1? 

For OODT, we voted on a committer - but forgot to do the
pre-acknowledgement and Chris got taken out to the woodshed by some
members because we sent the ack *after* the vote.  Chris didn't go
cranky, but I would have.  (I was in the middle of moving when that
happened - even then I threw away a few cranky emails...)

 And given that Subversion clearly (should have) had more
 than 3 PMC members, how did it impact?

Even after graduation, in Subversion, Greg has had to constantly
reinforce that the Subversion PMC gets to make the decisions in the
project and stop looking for others to set policy - as that's the
(false) precedent set by the Incubator.  The behavior of the Incubator
PMC can set a bad tone - and those of us mentoring have often had to
take proactive efforts to undo the damage.  -- justin

-
To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
For additional commands, e-mail: general-h...@incubator.apache.org

Re: Radical revamp (was: an experiment)

[Justin Erenkrantz]

On Mon, Aug 16, 2010 at 7:41 PM, Mattmann, Chris A (388J)
chris.a.mattm...@jpl.nasa.gov wrote:
 Hey Guys,

 I suspect the OODT guys might want to try this (it has four ASF
 Members as Mentors who could comprise the PMC). Subversion would have
 done this, based on my own thoughts/experiences and knowledge of what
 the ASF needs/wants.

 +1 from me with my OODT hat on.

 Also, I like Greg's proposal b/c it puts the onus on those (proposed)
 $podling.apache.org PMC members who are active, without external peanut
 gallery oversight.

Generally speaking, I'm supportive of trying different things to break
through the logjam that we currently have within the Incubator.

However, I think we should probably have a discussion on the OODT list
as we should think through what this means and how it'd affect the
nascent community.  With Subversion, it already had a very vibrant,
diverse, and self-governing community - OODT isn't quite there so
there's a bit of a risk there.  Perhaps this will act as a prod to
promote the self-governance - which is ideally what we want anyway.

At the moment, I probably don't have the time necessary to sit down
and lead the conversation within OODT.  That alone does give me a bit
of a reservation about what exactly we're signing up for.  =)  --
justin

-
To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
For additional commands, e-mail: general-h...@incubator.apache.org

Re: an experiment

[Justin Erenkrantz]

On Mon, Aug 16, 2010 at 6:26 PM, Ross Gardler rgard...@apache.org wrote:
 I've already decided that I'm going to have to recruit a number of key
 mentors to help me protect the project during incubation.

Historically, I think there are two classes of podlings:
 - one which has a self-governing community and just needs to get
indoctrinated in the Apache Way (SpamAssassin, Subversion, etc.)
 - one which doesn't have a self-governing community (thrift, traffic
server, etc.)

Perhaps Greg is on to something with having us split up the process.
It's always bugged me that there were two different classes that we
tried to shoehorn into one process.

Accordingly, in these two models, the role of the mentor is very different:
 - self-governing community: making sure they get introduced to the
right people and understand the minimum requirements; but, really,
they shouldn't interfere with the actual day-to-day governance.
 - no self-governing community: helping the developers understand what
it means to self-govern.

For an existing self-governing case, I would ideally like it so that
the mentors were purely advisory - the ultimate responsibility lies
with the community - as it must, or we're teaching them the wrong
things.  I don't know (or really care) how that reconciles with any
corporate structures - but I'm sure we can certainly get creative in
solving this.

In Subversion, the mentors we had were already full committers and had
earned their merit within the community.  So, when Greg, Dan, Sander,
or I said something, the rest of the community knew we weren't
crackpots.  Based on Ross's description of the community, it doesn't
sound like there's enough coverage to get a 3 member minimum - but,
the very fact that a community can decide to come to Apache is itself
a form of self-governance.  So...it's a touch circular, but I go back
to thinking that a purely advisory role is right for any mentors
coming in when there's self-governance already existing.

Considering Thrift's situation in trying to bootstrap their
self-governance, I can totally see why Joe likes that particular tweak
and why that might be sufficient for their case.

I don't have any clear answers, but, I'd really like to continue
exploring where this thought takes us as I think there's a solution
here that can ease the pain somewhat.  -- justin

-
To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
For additional commands, e-mail: general-h...@incubator.apache.org

Re: [DISCUSS] OODT Podling Incubator Experiment (was Re: Radical revamp (was: an experiment))

[Justin Erenkrantz]

[ CCing gene...@incubator as I think I can now place my finger a bit
as to why I'm discomforted with Greg's proposal in the OODT context ;
and more importantly, another potential experiment at the end; leaving
context in for those on gene...@incubator ]

On Mon, Aug 16, 2010 at 9:21 PM, Mattmann, Chris A (388J)
chris.a.mattm...@jpl.nasa.gov wrote:
 (moving to oodt-...@incubator.a.o, context coming in separate email FWD)

 Hey Justin,

 +1 from me with my OODT hat on.

 Also, I like Greg's proposal b/c it puts the onus on those (proposed)
 $podling.apache.org PMC members who are active, without external peanut
 gallery oversight.

 However, I think we should probably have a discussion on the OODT list
 as we should think through what this means and how it'd affect the
 nascent community.  With Subversion, it already had a very vibrant,
 diverse, and self-governing community - OODT isn't quite there so
 there's a bit of a risk there.  Perhaps this will act as a prod to
 promote the self-governance - which is ideally what we want anyway.

 +1


 At the moment, I probably don't have the time necessary to sit down
 and lead the conversation within OODT.  That alone does give me a bit
 of a reservation about what exactly we're signing up for.  =)  --

 To me, all we are signing up for with Greg's proposal is basically to have
 something like:

 1. oodt.apache.org exists today
 2. Ian, Chris, Justin and Jean Frederic are OODT PMC members + committers
 3. OODT committers continue as-is
 5. There is no more IPMC oversight
 5. VOTEs on releases are approved by 3 +1s of OODT PMC members
   - OODT committers weigh in on releases and their weigh in is taken into
 consideration by OODT PMC members (as is done today even with PPMC and IPMC)
 6. VOTEs on new committers are approved by 3 +1s of OODT PMC members
   - OODT committers weigh in on new committers and their weigh in is taken
 into consideration by OODT PMC members (as is done today even with PPMC and
 IPMC)
 7. When we're ready (we can even keep the same Incubator checklist), we put
 up a board resolution to graduate into *true* oodt.apache.org TLP. To me,
 ready =
   - we've made at least 1 release (we're close!)
   - we've VOTE'd in a couple new committers (keep those patches coming
 people!) hopefully with some diversity in mind, but if we don't get there,
 and the committers are still vibrant and healthy, then we move forward.

 OODT already has a pretty vast user community and healthy community that I'm
 slowing working to get signed up over here in the Incubator. We've had
 contributions from folks from Children's Hospital (thanks guys!), interest
 from other NASA centers (welcome Mark and others!), and some new folks from
 JPL stepping up and earning merit (welcome Cameron, and thanks for popping
 up Rishi!).

 Is that your take too?

Yes, I think that roughly outlines what Greg proposed.

See, here's where I get a bit discomforted by this entire process: I
honestly don't feel that I deserve a vote on OODT releases.  I've
known you and Dave for long enough that I have no concerns advising
the OODT community and trying to help out - but...giving me a binding
vote?

I want to encourage a process where the people doing the work get to
have the power.  At the core, that is what Apache is about - and
having doofus's like me casting a vote for a release seems like
straying from that.  I'm *totally* fine turning on cranky mode and
keeping the peanut gallery away so ya'll on oodt-dev@ get real work
done.

For Subversion, I was already a full committer and earned my merit.
So, I had zero qualms about giving my $.02 there whether they wanted
it or not.  =)

Given your (Chris) experience with other ASF projects (and, heck,
being a PMC Chair), I can see exactly how the Subversion analogy (in
my head) applies to you.  You're a member, you know how things work,
you have merit within OODT - so, yah, perfect sense.  Smucks like me
who get confuzzled reading Maven build scripts?  Nah, not right that I
should have a binding vote.

Now, could we say that I would act as a certifier/observer that
all of the major processes were followed?  Heck yah.  No qualms there.
 Here's an analogy I'm coming around to: in a lot of new democracies,
there are observers who are sent in to monitor elections.  They
witness the elections, poke around, and make sure nothing unseemly is
going on.  They don't vote, but they do observe.  They then issue a
certification or report to be filed with the vote.  (I'm catching up
on my backlog of issues of The Economist; just read their article
about nascent democracies in Africa on the plane...)

Hmm, maybe there's something to this observer model as this
reconciles my qualms and could provide the basis for an oversight
model.  Does this analogy move the needle for anyone else?  Could a
combination of mentor and observer be sufficient?  I think so...
-- justin

-
To unsubscribe, e-mail: 

Re: [DISCUSS] OODT Podling Incubator Experiment (was Re: Radical revamp (was: an experiment))

[Justin Erenkrantz]

On Mon, Aug 16, 2010 at 10:08 PM, Mattmann, Chris A (388J)
chris.a.mattm...@jpl.nasa.gov wrote:
 So basically you are moving more towards Joe's proposal, that the PPMC would
 have the binding VOTEs in e.g., new committers/PMC members, and on releases?
 Of course, with the caveats below, as you mention, i.e., the observers can
 observe and step in where necessary, but ultimately, they're there to
 ensure things are going great, and not to get in the way, unless they
 aren't? +1 to that.

Yes, I know Joe was looking to only try something small and
incremental.  Given its history, a small incremental change in process
is probably right for Thrift, but perhaps we can use OODT as an
experiment for something even more bonkers.  I don't see how we have
much to lose - we've already been taken out to the woodshed once by
the Incubator PMC.  =)

 +1. So our OODT observers would be:

 You, Jean Frederic, Ross, Ian, and me?

 PPMC stays the same, but they are given:

 * binding release/committer VOTEs

Yes, I think so.

Perhaps to satisfy the governance rules, the observers (in the eyes
of the Board, the PMC for the TLP) certify the votes from the PPMC
(in the eyes of the PMC, the real ones).  So, maybe it's not directly
a binding vote, but the expectation is that the observers are meant
to only certify and *not* provide technical oversight - unless they
are *also* part of that PPMC.

 In this case, observers are just really the mentors, and we move towards the
 mentors ensuring all is going well (which they should do now anyways), but
 IPMC ratification isn't required, and PPMC gets to self-govern. +1 from me
 on that, I think that's the right thing to teach, and with mentors that pay
 attention, I think we'll be great.

Yes.

 Hmm, maybe there's something to this observer model as this
 reconciles my qualms and could provide the basis for an oversight
 model.  Does this analogy move the needle for anyone else?  Could a
 combination of mentor and observer be sufficient?  I think so...

 If my interpretation above is correct, big +1 from me.

I think we could perhaps make something workable from this.  Dunno.
Need to see who else chimes in...hey, a message from Greg.  =)  --
justin

-
To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
For additional commands, e-mail: general-h...@incubator.apache.org

Re: [DISCUSS] OODT Podling Incubator Experiment (was Re: Radical revamp (was: an experiment))

[Justin Erenkrantz]

On Mon, Aug 16, 2010 at 10:20 PM, Greg Stein gst...@gmail.com wrote:
 You know when to vote and *how* to vote. I see no reason to deny your vote.

Of course.  It's always seemed awkward if you can't contribute
technically to suddenly have a binding vote.  I'm sure if I *wanted*
to learn how to build something with Maven, I could.  But, why?  =)

So, it makes me leery on being forced to cast a vote on a release - on
par with those who have actually tested it and know something about
the codebase.  The standard that I force myself to adhere to on
Subversion and httpd for example would be something that I'd fall
short with in OODT.

 The (only) problem to arise would be if OODT was at the minimum of (3)
 ASF Members, and your vote was required. With Chris becoming a Member,
 OODT is at 5 Members that could comprise the mini/pseudo TLP that I
 propose. (maybe there are others interested, but I have zero insight
 into this community)

Sure.  It's just that Chris and I have discussed the pain points in
the Incubation process, so we're on the lookout for making it easier
on us.  =)  Plus, the experience with Subversion also showed me where
things break down too.

 I'm not sure that I'm reading the above properly, but... whatevs.
 Under my proposed TLP-based approach, the PMC would be comprised of:
 justin, jean, ross, ian, chris. The current committers (who are also
 on the PPMC, presumably) would be invited to the private@ list, but
 would not be on the PMC. Thus, they would have non-binding votes
 across all project decisions. But that should not be a problem as
 those PMC members also understand how to build and listen to
 consensus. If there are issues in the community, then the difference
 between binding and non-binding votes makes *zero* difference.

If we ran it with the intention that the PMC is there to solely
provide non-technical oversight and that the PPMC does the actual
work, I think that's something I could live with and address my
concerns in the overall process.

I don't think this is at odds with what you are saying nor would it
run afoul of any corporate structures.  It could just be the informal
agreement between the PMC members that the PPMC should be the ones
making the technical decisions.  (If some other set of mentors wanted
to run it differently, they could.  But, this separation is one I
could live with myself.)

 The (podling) project/PMC would report directly to the Board. No more
 peanut gallery, or a second-guessing group.

Right.  The listed members of the PMC are on the line dealing with the
Board.  (Hmm...would the PMC require a VP?  I guess so.)  If the Board
has an issue with how they are running things, the Board can chime in.

 I do agree there is a lot of hand-waving around how to graduate, but
 I presume that the community can figure that out and provide
 information for future projects and communities.

I very much like the Incubator providing what the general checklist
form would look like.  The Board could receive the checklist, review
it, and then vote on the Graduation resolution.

It'd also raise the oversight of the podlings (in this structure) back
to the Board...which is likely a good thing so as things don't get
hidden.  -- justin

-
To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
For additional commands, e-mail: general-h...@incubator.apache.org

Re: an experiment

[Justin Erenkrantz]

On Wed, Aug 11, 2010 at 10:49 AM, Mattmann, Chris A (388J)
chris.a.mattm...@jpl.nasa.gov wrote:
 Hi Joe,

 The first idea should be fairly straightforward: that for
 the projects I participate in (so far thrift and sis), that
 the IPMC delegates to the PPMC the decision-making process
 for voting in new committers: basically rolling back the clock
 to May 1, 2007 on guides/ppmc.html.

 +1 from me, and I'd like to OODT to that experimental list as well :) It
 would probably make sense for Lucy too, but we're in our nascence there (not
 that it should matter).

+1 to trying this out in OODT as well.  =P

As far as the ACK process, I'd be okay with an after-the-vote ACK (a
la what the Board does with PMC members), but the goofy pre-vote ACK
is what got us in OODT-land taken out to the woodshed by the IPMC.  --
justin

-
To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
For additional commands, e-mail: general-h...@incubator.apache.org

Re: Future of RAT

[Justin Erenkrantz]

On Tue, Aug 10, 2010 at 12:50 PM, Greg Stein gst...@gmail.com wrote:
 It is *very* true that Infra, Legal, and (all?) ASF PMCs will be
 clients/users of the tool. But are they interested in its development?

If it goes under infra (as some are pushing for), then Joe gets to
rewrite it in Perl.  Hey, that's not a bad idea!  =P  -- justin

-
To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
For additional commands, e-mail: general-h...@incubator.apache.org

Re: [PROPOSAL] Zeta Components

[Justin Erenkrantz]

On Mon, Apr 19, 2010 at 6:52 AM, Tobias Schlitt tob...@schlitt.info wrote:
 -BEGIN PGP SIGNED MESSAGE-
 Hash: SHA1

 Hi all,

 please find below our proposal for Zeta Components. The proposal is also
 available in the wiki:

        http://wiki.apache.org/incubator/ZetaComponentsProposal

Sorry that I don't have time to review the proposal yet, but I did see:

http://css.dzone.com/articles/ez-components-php-library

It might be good to reach out to the author to clarify that you
haven't joined Apache just yet.  =)

For reference, the publicity/branding rules for podlings are at:

http://incubator.apache.org/guides/branding.html

Good luck!  -- justin

-
To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
For additional commands, e-mail: general-h...@incubator.apache.org

Re: [VOTE] Apache UIMA as a TLP

[Justin Erenkrantz]

On Mon, Feb 22, 2010 at 6:24 AM, Marshall Schor m...@schor.com wrote:
 [X] +1 to recommend UIMA's graduation

Good luck!  -- justin

-
To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
For additional commands, e-mail: general-h...@incubator.apache.org

Re: [VOTE] Subversion podling for graduation

[Justin Erenkrantz]

On Thursday, February 11, 2010, Greg Stein gst...@gmail.com wrote:
 Hello all,

 I started a discussion thread a week-ish ago to seek out issues for
 Subversion's graduation. The couple bits that were raised[1] have been
 handled, I believe. So with that said, I am unaware of any potential
 showstoppers, and would like to request a vote for graduating the
 Subversion podling. Should this result in a successful vote, I will
 put a resolution before the Board (for its Feb 17 mtg) to construct a
 new Subversion PMC.

 Please vote:

 [ ] +1 Graduation
 [ ] -1 Hold, and continue incubating

+1 for graduation.  I believe that Subversion is capable of managing
itself in accordance with our standards and practices.  -- justin

-
To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
For additional commands, e-mail: general-h...@incubator.apache.org

Re: (Is|Was) PHP part of ASF?

[Justin Erenkrantz]

On Wed, Feb 10, 2010 at 8:01 AM, Kamesh Jayachandran kam...@collab.net wrote:
 I ask this as I was involved in PHP development 5 years back and am never
 aware of PHP being part of ASF.

PHP was a sister project for a long while - after we moved to the
Apache License v.2, the PHP Group decided that it was best to go their
own way and are now fully independent.  -- justin

-
To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
For additional commands, e-mail: general-h...@incubator.apache.org

Re: Source code dumps via JIRA?

[Justin Erenkrantz]

On Mon, Feb 8, 2010 at 9:47 PM, Paul Querna p...@querna.org wrote:
 For most projects they just put a URL in the jira, and Joe just imports it.

So, is this just a failure of the documentation to reflect what is
actually done?

If so, I'm happy to update the documentation.  -- justin

-
To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
For additional commands, e-mail: general-h...@incubator.apache.org

Source code dumps via JIRA?

[Justin Erenkrantz]

For OODT, we think we want to import the prior history of the project
into the podling via a Subversion dump file. However, in:

http://incubator.apache.org/guides/mentor.html#initial-import-code-dump

it says:

---
In either case, the code to be imported should be attached to a JIRA
and then imported. It is recommended that the previous version control
system is tagged so that the imported version is precisely known.

A public record MUST be made of the code imported. If the import is
not attached to JIRA then it MUST be committed to version control.
---

I can understand the rationale for having a public record, but I'm not
seeing the reasoning for JIRA.

Can someone please shed some light on this?  Is this really reflective
of actual best practices?

As a counter-example, I'd believe providing a URL to the dump (or
uploading it to people.a.o) and providing a SHA checksum via email
(PGP-signed?) would be sufficient for our purposes.  -- justin

-
To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
For additional commands, e-mail: general-h...@incubator.apache.org

Re: Switching incubator.apache.org to svnpubsub?

[Justin Erenkrantz]

On Fri, Feb 5, 2010 at 12:26 AM, Paul Querna p...@querna.org wrote:
 It is possible to run an incubator.staging.apache.org, syncing off a
 branch, and the live site off trunk, or vice versa.

 (possible, but I wouldn't recommend it, merging html changes like that
 is pretty meh)

I think we pretty much have consensus so far to switch the main site.
However, I know before we can deploy this for incubator.a.o that we
need to determine how to get svnpubsub to deal with subdirs that
aren't necessarily using svnpubsub - as we do not necessarily want to
force all of the podlings to switch their sites right now.
So...thoughts here?  I think you mentioned tweaking our rsync scripts,
right?

(Perhaps we should move this conversation to infra-dev?)  -- justin

-
To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
For additional commands, e-mail: general-h...@incubator.apache.org

Re: New project

[Justin Erenkrantz]

On Wed, Feb 3, 2010 at 1:46 PM, Peter pfran...@hotmail.com wrote:

 Hello,
 I have 2 projects, both alpha and written in C++, that I am considering 
 making open source. I would like to know whether you are interested in 
 hosting them as projects and what support you can give me. You can see the 
 screenshots here: http://jaskolskit.facebook.joyent.us/alpha.html. A 
 server-based (Solaris) version of ReforMath can be found here: 
 http://jaskolskit.facebook.joyent.us/. You can download both programs: 
 http://jaskolskit.facebook.joyent.us/reformath.zip and 
 http://jaskolskit.facebook.joyent.us/svgconvlib.zip.
 I hope to hear from you.

Hi Peter,

Those look kinda cool!

As far as the first step, you've come to the right place.  If you
haven't had a chance to review our proposal guide, I'd recommend
taking a look at: http://incubator.apache.org/guides/proposal.html.
That should hopefully give you an idea of what the beginning process
is.  More importantly, however, at this stage, you need to find some
members who are interested in helping guide you through this
Incubation process and they can explain things as you go along - and
even explain why Apache makes sense, or why it doesn't!

Sadly, I've got my hands full with two other podlings, so I'm maxed
out.  But, maybe some interested folks will chime in!

Good luck!  -- justin

-
To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
For additional commands, e-mail: general-h...@incubator.apache.org

Re: Switching incubator.apache.org to svnpubsub?

[Justin Erenkrantz]

On Wed, Feb 3, 2010 at 5:02 PM, David Crossley cross...@apache.org wrote:
 Does 'svnpubsub' also dispense with the hourly rsync step
 to truly be live.
 i.e. http://apache.org/dev/project-site.html
 find-in-page: rsync

Yes.

 Is there a description of svnpubsub?

Other than:

https://svn.apache.org/repos/infra/infrastructure/trunk/projects/svnpubsub/svnpubsub.py

and emails Paul has sent to all projects, I'm not sure.  I know infra
has some docs about how they configure it on their end, but from the
project's perspective, they just commit and magic happens.  --
justin

-
To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
For additional commands, e-mail: general-h...@incubator.apache.org

Re: Incubator PMC/Board report for February 2010 (OODT Developers general@incubator.apache.org)

[Justin Erenkrantz]

On Mon, Feb 1, 2010 at 10:41 PM, Mattmann, Chris A (388J)
chris.a.mattm...@jpl.nasa.gov wrote:
 Hi All,

 A draft OODT report has been submitted to the Incubator wiki. 
 Comments/updates from mentors and from the OODT/incubator community are 
 welcome.

Cool - thanks!  I made some minor tweaks, so please review.  Namely, I
shifted the notice about the sw grant from issues to the progress
section.  The issues section is primarily for things that we need
either Incubator PMC or Board-level assistance in resolving - for
example, when we are stuck or need advice further than what the
mentors can provide.  At this time, I think we're fine - I expect
we'll have the lists and such created by the time the report is due.

Thanks!  -- justin

-
To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
For additional commands, e-mail: general-h...@incubator.apache.org

Re: Incubator PMC/Board report for February 2010 (OODT Developers general@incubator.apache.org)

[Justin Erenkrantz]

On Tue, Feb 2, 2010 at 8:47 PM, Mattmann, Chris A (388J)
chris.a.mattm...@jpl.nasa.gov wrote:
 Thanks Justin!

 I went ahead and updated the incubator site oodt.xml document in 
 incubator/public/trunk/site-author/projects/oodt.xml with the February 2010 
 report based off the wiki:

 http://svn.apache.org/viewvc?rev=905884view=rev

Ooh, good catch.

 Is there a command I can run to rebuild the site or is some automated thing?

In general, take a look at http://incubator.apache.org/guides/website.html ;

The quick-and-dirty guide (should work fine on Mac OS X) is:

% make your changes
% ./build.sh
% if adding any files, svn add, etc, etc. ; specifically check
site-publish dir
% svn ci

Then:

% ssh people.apache.org
% cd /www/incubator.apache.org
% svn up
...wait at least 1hr for it to appear on http://incubator.apache.org/...

If you have any questions, please yell though...  =)  -- justin

-
To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
For additional commands, e-mail: general-h...@incubator.apache.org

Switching incubator.apache.org to svnpubsub?

[Justin Erenkrantz]

Hi general@,

I'd like to suggest switching incubator.apache.org over to svnpubsub.
(We can do so by filing a JIRA like INFRA-2349:
http://issues.apache.org/jira/browse/INFRA-2349)

This would mean that any commits made to the site-publish tree would
automatically be deployed to the site.  No more delays, no more SSH
and SVN up fun.  Yay.  This does mean you trade off the fact that you
can't delay anything - but, in general, I think that's fine for the
incubator site and would substantially lower the barrier of entry to
folks working on the Incubator site.  Often times, people's first
experience with the ASF is through the podlings, so I think it would
be nice if we could make it a bit easier to publish the incubator.a.o
site.

What do folks think?  -- justin

P.S. On IRC, Paul mentions there may be some complications with
respect to podling sites as sub-directories, but he promises that it
is feasible to address.  *grin*

-
To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
For additional commands, e-mail: general-h...@incubator.apache.org

Re: Switching incubator.apache.org to svnpubsub?

[Justin Erenkrantz]

On Tue, Feb 2, 2010 at 11:01 PM, Mattmann, Chris A (388J)
chris.a.mattm...@jpl.nasa.gov wrote:
 +1 from me on this - I'd see the OODT changes more quickly, right?

Indeed!  Your note re: OODT is what triggered me to send this email.
=P  -- justin

-
To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
For additional commands, e-mail: general-h...@incubator.apache.org

Re: Web site updates

[Justin Erenkrantz]

On Mon, Jan 25, 2010 at 10:30 AM, Noel J. Bergman n...@devtech.com wrote:
 Thanks, Justin.  I appreciate the work that you just committed.  Looked
 reasonable to me.  I hope that others have also reviewed it.

I certainly don't intend for any of my changes to alter policy - just
make some wording clearer to n00bs (which, at times, include me!).  =P

Thanks.  -- justin

-
To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
For additional commands, e-mail: general-h...@incubator.apache.org

Re: [VOTE] Accept OODT for Incubation

[Justin Erenkrantz]

On Mon, Jan 18, 2010 at 12:17 PM, Justin Erenkrantz
jus...@erenkrantz.com wrote:
 Per the previous proposal that was sent to gene...@incubator, I'd like
 to now call a vote for accepting OODT into the Incubator.

 [ ] +1 - Accept OODT into the Incubator
 [ ] -1 - Do not accept OODT into the Incubator (rationale strongly desired!)

 Per the proposal below, the mentors for this proposal are myself,
 Ross, Jean-Frederic, and Ian.

 Unless there are any extenuating circumstances, I will close this vote
 on Thursday morning, January 21.

I now count 8 +1s and no -1s, so OODT is now a part of the Incubator.

I'll coordinate with the OODT folks as to the next steps from here.

Thanks!  -- justin

-
To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
For additional commands, e-mail: general-h...@incubator.apache.org

[VOTE] Accept OODT for Incubation

[Justin Erenkrantz]

 of such dependencies (taken from
one of the OODT sub-components, the CAS file manager) is shown below.

Library | License
commons-codec | AL v2
commons-dbcp | AL v2
commons-httpclient | AL v2
commons-io | AL v2
commons-pool | AL v2
cas-metadata |  (to be AL v2)
edm-commons | (to be AL v2)
hsqldb | LGPL v2.1
jug-asl | AL v2
lucene-core | AL v2
xmlrpc | AL v2

There are also some LGPL components that would be useful. Whether and
how such dependencies could be handled will be discussed during
incubation. No such dependencies will be added to the project before
the legal implications have been cleared. Existing LGPL dependencies,
such as hsqldb above for the CAS file manager, will be removed and a
suitable ASL friendly alternative will be investigated and used to
replace the LGPL dependencies.

Cryptography
OODT itself will not use cryptography, but it is possible that some of
the external product or profile server or CAS libraries will include
cryptographic code to handle features present in various science data
formats. The current OODT code base relies on Apache Tika which
contains an export control statement regarding cryptographic code per
Apache policy. We will follow a similar approach with OODT. Mattmann
led this effort in Apache Nutch and saw Jukka Zitting lead this effort
in Apache Tika, so he is familiar with this process.

Required Resources
Mailing lists

oodt-...@incubator.apache.org
oodt-comm...@incubator.apache.org
oodt-priv...@incubator.apache.org
Subversion Directory

https://svn.apache.org/repos/asf/incubator/oodt
Issue Tracking

JIRA OODT (OODT)
Other Resources

OODT Wiki http://cwiki.apache.org/OODT

Initial Committers

Name | Email | Affiliation | CLA
Chris A. Mattmann | mattmann at apache dot org | NASA Jet Propulsion
Laboratory | yes
Daniel J. Crichton | crichton at jpl dot nasa dot gov | NASA Jet
Propulsion Laboratory | no
Paul Ramirez | pramirez at jpl dot nasa dot gov | NASA Jet Propulsion
Laboratory | no
Sean Kelly | kelly at jpl dot nasa dot gov | NASA Jet Propulsion
Laboratory | yes
Sean Hardman | shardman at jpl dot nasa dot gov | NASA Jet Propulsion
Laboratory | no
Andrew F. Hart | ahart at jpl dot nasa dot gov | NASA Jet Propulsion
Laboratory | no
Joshua Garcia | joshua at jpl dot nasa dot gov | NASA Jet Propulsion
Laboratory | no
David Woollard | woollard at jpl dot nasa dot gov | NASA Jet
Propulsion Laboratory | yes
Brian Foster | bfoster at jpl dot nasa dot gov | NASA Jet Propulsion
Laboratory | no
Sean McCleese | smcclees at jpl dot nasa dot gov | NASA Jet Propulsion
Laboratory | no

Sponsors

Champion
Justin Erenkrantz (jerenkrantz at apache dot org)

Nominated Mentors
Justin Erenkrantz (jerenkrantz at apache dot org)
Ross Gardler (rgardler at apache dot org)
Jean-Frederic Clere (jfclere at apache dot org)
Ian Holsman (ianh at apache dot org)

Sponsoring Entity
Apache Incubator

-
To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
For additional commands, e-mail: general-h...@incubator.apache.org

Re: Missing reports due NOW

[Justin Erenkrantz]

On Mon, Jan 18, 2010 at 5:28 AM, Noel J. Bergman n...@devtech.com wrote:
 Missing:

        Subversion

Hmm.  Something went wrong with the automated notifier as this ball
got dropped, I guess.  Subversion should have something submitted by
this evening.  -- justin

-
To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
For additional commands, e-mail: general-h...@incubator.apache.org

Re: [VOTE] Accept OODT for Incubation

[Justin Erenkrantz]

On Mon, Jan 18, 2010 at 9:17 PM, Justin Erenkrantz
jus...@erenkrantz.com wrote:
 Per the previous proposal that was sent to gene...@incubator, I'd like
 to now call a vote for accepting OODT into the Incubator.

 [X] +1 - Accept OODT into the Incubator
 [ ] -1 - Do not accept OODT into the Incubator (rationale strongly desired!)

-
To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
For additional commands, e-mail: general-h...@incubator.apache.org

Re: [PROPOSAL] OODT: a grid middleware framework for science data processing, information integration, and retrieval

[Justin Erenkrantz]

On Wed, Jan 6, 2010 at 11:45 PM, jean-frederic clere jfcl...@gmail.com wrote:
 On 01/06/2010 10:56 AM, Ross Gardler wrote:
 Count me in as a mentor for this excellent proposal.

 If you still need more mentors count on me too.

Thanks - I've added you and Ian to the proposal.  (Ross already added
himself on the wiki.  Thx.)

I'll let this proposal sit over the weekend and then call for a vote
early next week.  -- justin

-
To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
For additional commands, e-mail: general-h...@incubator.apache.org

[PROPOSAL] OODT: a grid middleware framework for science data processing, information integration, and retrieval

[Justin Erenkrantz]

 Dependencies

OODT depends on a number of external connector libraries with various
licensing conditions. An initial list of such dependencies (taken from
one of the OODT sub-components, the CAS file manager) is shown below.

Library | License
commons-codec | AL v2
commons-dbcp | AL v2
commons-httpclient | AL v2
commons-io | AL v2
commons-pool | AL v2
cas-metadata | (to be AL v2)
edm-commons | (to be AL v2)
hsqldb | LGPL v2.1
jug-asl | AL v2
lucene-core | AL v2
xmlrpc | AL v2

There are also some LGPL components that would be useful. Whether and
how such dependencies could be handled will be discussed during
incubation. No such dependencies will be added to the project before
the legal implications have been cleared. Existing LGPL dependencies,
such as hsqldb above for the CAS file manager, will be removed and a
suitable ASL friendly alternative will be investigated and used to
replace the LGPL dependencies.

Cryptography

OODT itself will not use cryptography, but it is possible that some of
the external product or profile server or CAS libraries will include
cryptographic code to handle features present in various science data
formats. The current OODT code base relies on Apache Tika which
contains an export control statement regarding cryptographic code per
Apache policy. We will follow a similar approach with OODT. Mattmann
led this effort in Apache Nutch and saw Jukka Zitting lead this effort
in Apache Tika, so he is familiar with this process.

Required Resources

Mailing lists

* oodt-...@incubator.apache.org
* oodt-comm...@incubator.apache.org
* oodt-priv...@incubator.apache.org

Subversion Directory

* https://svn.apache.org/repos/asf/incubator/oodt

Issue Tracking

* JIRA OODT (OODT)

Other Resources

* OODT Wiki http://cwiki.apache.org/OODT

Initial Committers

Name | Email | Affiliation | CLA

Chris A. Mattmann | mattmann at apache dot org | NASA Jet Propulsion
Laboratory | yes
Daniel J. Crichton | crichton at jpl dot nasa dot gov | NASA Jet
Propulsion Laboratory | no
Paul Ramirez | pramirez at jpl dot nasa dot gov | NASA Jet Propulsion
Laboratory | no
Sean Kelly | kelly at jpl dot nasa dot gov | NASA Jet Propulsion Laboratory | no
Sean Hardman | shardman at jpl dot nasa dot gov | NASA Jet Propulsion
Laboratory | no
Andrew F. Hart | ahart at jpl dot nasa dot gov | NASA Jet Propulsion
Laboratory | no
Joshua Garcia | joshua at jpl dot nasa dot gov | NASA Jet Propulsion
Laboratory | no
David Woollard | woollard at jpl dot nasa dot gov | NASA Jet
Propulsion Laboratory | no
Brian Foster | bfoster at jpl dot nasa dot gov | NASA Jet Propulsion
Laboratory | no
Sean McCleese | smcclees at jpl dot nasa dot gov | NASA Jet Propulsion
Laboratory | no

Sponsors

Champion

* Justin Erenkrantz (jerenkrantz at apache dot org)

Nominated Mentors

* Justin Erenkrantz (jerenkrantz at apache dot org)

Sponsoring Entity

* Apache Incubator

-
To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
For additional commands, e-mail: general-h...@incubator.apache.org

Re: JavaHL package namespace / migration / compatability

[Justin Erenkrantz]

On Wed, Nov 18, 2009 at 5:57 AM, Christopher Brind bri...@brindy.org.uk wrote:
 I can understand why Subversion should be made a top level project quickly,
 but I personally believe the namespace change is a reasonable request in
 order to graduate for all the same reasons that convinced me Pivot should
 change its namespace.

 It sends the wrong message not to change given the importance of the Apache
 namespace, imho.

If Subversion were a Java project, maybe I would consider it more
important that it change.

However, the Java bindings are a very small (and largely
insignificant, IMO) part of Subversion.  Holding a C-based project up
for graduation because their Java bindings aren't in the org.apache.*
namespace starts to sound petty.  -- justin

-
To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
For additional commands, e-mail: general-h...@incubator.apache.org

Re: JavaHL package namespace / migration / compatability

[Justin Erenkrantz]

On Tue, Nov 17, 2009 at 2:57 PM, Ralph Goers ralph.go...@dslextreme.com wrote:
 There is a more practical reason for this. If I have a need to debug a 
 package or get further documentation, the package name gives me a pointer as 
 to where to look. If tigris.org disappeared users would get very confused.

 IMO, whether the package names are changed in 1.7 or in some future release 
 is up to the project to decide. But they should change sooner or later.

 You asked for our input and this is it.

It's noted, but, as others have mentioned, binary/source compatibility
is a very strong concern for Subversion.

Since subversion.tigris.org is still going to be up (at least as a
pointer, if not in some stronger form), I think we're fine for folks
who want documentation or references well after Subversion is an
official ASF project.

As Hyrum suggests, we can use org.apache.subversion.* if we want to
create a new (better) Java interface within our versioning rules - but
that isn't necessary nor should it be a pre-req for graduation.

Thanks.  -- justin

-
To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
For additional commands, e-mail: general-h...@incubator.apache.org

Re: svn status update (was: svn commit: r880911 [1/13] - in /subversion/trunk: ./ build/ build/generator/ build/win32/ notes/obliterate/ packages/python-windows/ packages/windows-WiX/BuildSubversion

[Justin Erenkrantz]

On Tue, Nov 17, 2009 at 3:48 PM, Branko Čibej br...@xbc.nu wrote:
 Is there any way to make RAT slightly smarter so that it doesn't require
 license headers in README files and such?

http://svn.apache.org/repos/asf/incubator/rat/main/trunk/

*duck*

 Does policy dictate these
 files must have license headers, too?

No.  -- justin

-
To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
For additional commands, e-mail: general-h...@incubator.apache.org

Re: Review-Then-Commit

[Justin Erenkrantz]

On Thu, Nov 12, 2009 at 4:16 AM, Greg Stein gst...@gmail.com wrote:
 I've participated in both styles of development. RTC is *stifling*. I
 would never want to see that in any Apache community for its routine
 development (branch releases are another matter).

 My opinion is that it is very unfortunate that Cassandra feels that it
 cannot trust its developers with a CTR model, and pushes RTC as its
 methodology. The group-mind smashes down the creativity of the
 individual, excited, free-thinking contributor.

+1.

I think part of Cassandra's problem is that they do releases directly
from trunk and don't have a 'stable' et al branch.

As I understood Owen's Intro to Hadoop talk at AC, Hadoop has
changed their methodology lately to CTR and found it to work far
better.  (Duh.)  -- justin

-
To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
For additional commands, e-mail: general-h...@incubator.apache.org

Re: Insanity. Apache Incubator should be about education (was: [PROPOSAL][VOTE] Subversion)

[Justin Erenkrantz]

On Mon, Nov 9, 2009 at 2:25 AM, Greg Stein gst...@gmail.com wrote:
 The Apache Incubator is about EDUCATION. It is about TEACHING podlings
 how to work here at Apache.
...
 The Incubator PMC is here to TEACH podlings. Stop and think before
 attempting to apply rules and procedures.

+1.

The Incubation process is about certifying whether the new community
can stand on its own and follow Apache practices and procedures.

Greg has pointed at the public records and discussions surrounding
Subversion doing releases - as a mentor, I feel that these processes
are in-line (if not exceeding) the Apache practices and procedures and
no more needs to be proven here regarding releases.  If someone can
point out where that process falls noticeably short of Apache
standards, please let us know and we'll take it into consideration.

To be clear, it's on the mentors to decide what is applicable and
necessary for graduation - not the IPMC as a whole.  The IPMC as a
whole has only two roles: approving a proposal and recommending
graduation - in between those two stages, it's up to the mentors to
drive the show on behalf of the IPMC.  Non-mentors don't get to hold a
podling hostage and all votes by the IPMC are majority-based (no vetos
apply).

To be fair, there are some minor points and variations that we're
already aware of.  But, that's why Greg, Sander, Dan, and I (and
others who aren't formally named) are around to teach the more subtle
mechanics of the ASF to those within Subversion: where to submit CLAs,
how to post releases in our mirroring system, what to do with (L)GPL
scripts, etc.  Given our personal long track records within both
Apache and Subversion (nearing or surpassing a decade; geez, we've
been at this a long time!), I believe it's reasonable to ask for the
trust that goes with ensuring that we'll be sure to keep Subversion in
line with Apache practices and procedures - and we will continue to do
so long after the Incubator has recommended Subversion for graduation.
 =)  -- justin

-
To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
For additional commands, e-mail: general-h...@incubator.apache.org

Re: Insanity. Apache Incubator should be about education (was: [PROPOSAL][VOTE] Subversion)

[Justin Erenkrantz]

On Mon, Nov 9, 2009 at 3:26 PM, Martijn Dashorst
martijn.dasho...@gmail.com wrote:
 On Mon, Nov 9, 2009 at 3:15 PM, Justin Erenkrantz jus...@erenkrantz.com 
 wrote:
 To be clear, it's on the mentors to decide what is applicable and
 necessary for graduation - not the IPMC as a whole.

 Nope... The whole IPMC has been tasked with oversight. The mentors are
 proxies for the whole IPMC.

You can't have it both ways.  By approving the proposal, the IPMC
delegates its oversight authority to the mentors.  The IPMC then
confirms that the proper process was followed when it votes for
graduation.  The mentors can ask for pre-approval for certain
'waivers' like Greg is asking for - but it's unfair for a non-mentor
to try to tell a podling what it can or can not do.  -- justin

-
To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
For additional commands, e-mail: general-h...@incubator.apache.org

Re: Insanity. Apache Incubator should be about education (was: [PROPOSAL][VOTE] Subversion)

[Justin Erenkrantz]

On Mon, Nov 9, 2009 at 4:03 PM, Leo Simons m...@leosimons.com wrote:
 Also, to be clear, as an IPMC member I spend quite a bit of time with
 projects where I am not a mentor, casting (binding) votes on things
 like their releases. I will continue to do that, inline with procedure
 and policy and common sense. I'm pretty sure you're not really meaning
 to question that :)

This is where I think the Incubator has gone awry: the claim that you
are an IPMC member implies that you have merit on a project (in the
form of a binding vote) is false.

Merit should be earned and should be local - and, in that, I think
there are some re-adjustments in order as to how the Incubator
operates.

I'm mildly uncomfortable with mentors who aren't actually involved in
the project telling a community what to do - but I accept that as a
necessity of the Incubation process.  However, I'm much more
uncomfortable when folks who have *zero* affiliation (except for being
on some distant PMC) telling a podling what to do because *they*
personally believe it is right even when others disagree.

 PS: Just make sure to keep close tabs on the bearded Slovenian ;-)

Riiight.  =)  -- justin

-
To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
For additional commands, e-mail: general-h...@incubator.apache.org

Re: Insanity. Apache Incubator should be about education (was: [PROPOSAL][VOTE] Subversion)

[Justin Erenkrantz]

On Mon, Nov 9, 2009 at 4:39 PM, Bertrand Delacretaz
bdelacre...@apache.org wrote:
 OTOH, podlings that don't have 3 active mentors can't get 3 binding
 votes internally, so IPMC members have to jump in sometimes. Thanks to
 those of us who do!

I view the proposal accepting the projects with the listed mentors as
delegating the oversight to the mentors.  So, I don't know if it
should be required that you must get three IPMC members to vote on
every little thing a podling does.  I think it tends to let projects
think that people who don't contribute anything deserve merit and have
rights to tell them what to do.  I'm not sure that sets an appropriate
precedent.

Let me put it another way: if the IPMC accepts a proposal with one
mentor, then I'm fine with that one mentor acting on behalf of the
IPMC without the need to constantly go back to the IPMC for approval.
-- justin

-
To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
For additional commands, e-mail: general-h...@incubator.apache.org

Re: [PROPOSAL][VOTE] Subversion

[Justin Erenkrantz]

On Wed, Nov 4, 2009 at 12:12 PM, Greg Stein gst...@gmail.com wrote:
  The Subversion project would like to join the Apache Software
 Foundation to remove the overhead of having to run its own
 corporation.  The Subversion project is already run quite like an
 Apache project, and already counts a number of ASF Members amongst
 its committers.

 Sponsors
  * Champion: Greg Stein
  * Nominated Mentors: Justin Erenkrantz, Greg Stein, Sander Striker, Daniel 
 Rall

+1 for acceptance.

w...0...0...t.  =)  -- justin

-
To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
For additional commands, e-mail: general-h...@incubator.apache.org

Re: [VOTE] Accept Libcloud proposal for incubation

[Justin Erenkrantz]

On Wed, Oct 28, 2009 at 11:39 AM, Paul Querna p...@querna.org wrote:
 Please cast your votes:

 [X] +1 Accept Libcloud for incubation
 [ ] +0 Indifferent to Libcloud incubation
 [ ] -1 Reject Libcloud for incubation

 Vote Closes 72 hours from now.

Good luck!  -- justin

-
To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
For additional commands, e-mail: general-h...@incubator.apache.org

Re: [PROPOSAL] Commons Incubator

[Justin Erenkrantz]

On Thu, Apr 9, 2009 at 9:23 AM, Matt Benson gudnabr...@yahoo.com wrote:
 The Commons Incubator would act as a perpetual podling or mini-Incubator 
 overseeing the influx of components to be adopted into Apache Commons.

-1 (vote, not veto).

If Commons PMC wants to import code, then it can file IP clearances.
If it wants to incubate communities, then it needs to follow the rest
of the Incubator procedures.  -- justin

-
To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
For additional commands, e-mail: general-h...@incubator.apache.org

Re: [VOTE] Abdera Graduation to TLP

[Justin Erenkrantz]

On Thu, Nov 13, 2008 at 8:59 AM, Garrett Rooney
[EMAIL PROTECTED] wrote:
 After some brief discussion here and a vote on the Abdera private
 list, it seems everyone is in favor of this, so I'd like to propose
 that we ask the board to make Abdera a new TLP.  It's been quite the
 long incubation process (started in May 2006!), but I think the Abdera
 community, while small, is now diverse enough that I have no question
 as to its ability to survive as its own Apache project.

 So please vote away.  A +1 vote is for sending the following motion to
 the board for its approval.

+1.  -- justin

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Possible software grant for POI

[Justin Erenkrantz]

On Wed, Sep 24, 2008 at 8:03 AM, Nick Burch [EMAIL PROTECTED] wrote:
 Is the process as documented at
 http://incubator.apache.org/ip-clearance/ip-clearance-template.html
 the correct one to follow for this?

Yup.  -- justin

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: [PROPOSAL] Catacomb

[Justin Erenkrantz]

On Sun, Sep 21, 2008 at 9:45 AM,  [EMAIL PROTECTED] wrote:
 Hello Justin,

 we would be glad to welcome you as a mentor for catacomb incubation process! 
 Your idea to fold catacomb into the HTTP
 Server Project is realy nice, maybe later in the incubation process we could 
 start a discussion with someone from the HTTP Server Project.

Yup, we can cross that bridge later.

 Can you tell us what is the next step for catacomb to get into the incubation 
 process?

Let the proposal sit for another few days, then we can call a vote for
accepting the proposal.

Ideally, it'd be nice to find another mentor besides me and Gianugo.
(Is Gianugo around?  I haven't seen him on-list in a long time.)  --
justin

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: status of PGP support in Maven

[Justin Erenkrantz]

On Fri, Sep 19, 2008 at 6:12 AM, Hiram Chirino [EMAIL PROTECTED] wrote:
 How about we include the signatures in the source distros?  That way
 if you trust your source, then you can trust the dependencies it
 downloads.

Eww.  That'd be a giant gaping security hole.  -- justin

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: [PROPOSAL] Catacomb

[Justin Erenkrantz]

On Fri, Sep 19, 2008 at 1:55 AM,  [EMAIL PROTECTED] wrote:
  This is a proposal to enter the incubator.

 See http://wiki.apache.org/incubator/CatacombProposal for the most
 up-to-date version.

Nifty!

 As Champion we have Gianugo Rabellino gianugo at apache.org from the
 ASF.

 We look forward to comments and discussion.

If you're looking for more mentors, I'll volunteer.  Though, if enough
other people step up, I'll gladly defer; but I'm happy to help mentor
this.  (I know a fair chunk of the initial committers.)

A possibility is for Catacomb to eventually be folded into the HTTP
Server Project, but I don't know if that is the 'best' thing to do or
not.  We can incubate it, see where it goes, and then decide on that
later on.  -- justin

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: [VOTE] [POLICY] Allow extra release distribution channels like the central Maven repository

[Justin Erenkrantz]

On Mon, Sep 15, 2008 at 11:13 AM, Emmanuel Lecharny [EMAIL PROTECTED] wrote:
 Craig L Russell wrote:

 -1

 I believe that allowing incubating releases to be treated as full Apache
 releases diminishes the Apache brand and makes incubation disclaimers moot.

 With Maven, it is too easy to depend on a release with transitive
 dependencies on incubating releases without even knowing it. When the
 incubating release subsequently is abandoned, blame will be cast widely,
 including Apache itself.

 Considering that dependencies on incubating releases can be resolved by
 explicitly adding an incubating Maven repository into your settings, I don't
 think that wide, mirrored, distribution is warranted.

 Craig

 -1 too, for the same reasons.

-1.  Craig pointed out my objections as well.  -- justin

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: [VOTE] [POLICY] Allow extra release distribution channels like the central Maven repository

[Justin Erenkrantz]

On Tue, Sep 16, 2008 at 2:10 PM, William A. Rowe, Jr.
[EMAIL PROTECTED] wrote:
 Just so everyone understands this in context, the objection above is moot
 because...

No, it's not.  Anything that creates an impetus for a podling to get
out of the Incubator is goodness.  Too many podlings view the
Incubator as a comfy place - I believe that the Incubator PMC needs to
create more of a reason for projects to get in gear and graduate.
This isn't college - you don't get to stay here for the best seven
years of your life.  =)

I would almost say we should revisit the entire policy of letting a
podling release at all, but yah, I'm not really caring to reopen
*that* can of worms.  -- justin

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: [PROPOSAL] Tashi

[Justin Erenkrantz]

On Wed, Jul 23, 2008 at 3:12 PM, Niall Pemberton
[EMAIL PROTECTED] wrote:
 I really don't see what the problem is here, there are two named
 committers in the proposal. Whatever the interests of the companies
 they work for, Tashi will have to create a healthy community to
 graduate and I don't think corporate backing should be used as a
 reason to deny entry in the first place. Also its a *good thing* IMO
 that the proposal is open about the three companies that are prepared
 to fund work and I would hate to see that rewarded with a -1, since it
 may prompt others to be less open in the future.

+1.  -- justin

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: [DISCUSS] Do we really need an incubator?

[Justin Erenkrantz]

On Mon, Jul 7, 2008 at 2:49 PM, Daniel Kulp [EMAIL PROTECTED] wrote:
 So, my question is, if Apache is about Community over code, why are we
 putting up barriers to getting the code if that is also creating barriers to
 building the community?

Apache isn't about 'community over code'.  The code is just as
important - if not more so.  For Incubator releases, the releases
aren't held to the same legal standard as releases from other PMCs.
The Incubator PMC is generally comfortable releasing code that is not
yet legally at the same standard as other PMCs would.  Everyone
understands that and it's okay.  This is why we have explicit
disclaimers regarding releases.  In light of that, I believe it is
prudent for us to place certain reasonable low barriers at getting the
code.  Since Maven can't display any notices when it downloads a
binary, then that isn't a tool that we should be recommending for
implicit distribution.  The Maven devs are fully aware what it would
take to satisfy that, but it's not very high on their priority list.
Hence, it's not high on my list to work around a tool that doesn't
support our desired policies.  -- justin

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: [DISCUSS] Do we really need an incubator?

[Justin Erenkrantz]

On Mon, Jul 7, 2008 at 5:21 PM, Roy T. Fielding [EMAIL PROTECTED] wrote:
 Huh?  The only difference I know of is the possible presence
 of external dependencies on LGPL code, which is not a legal
 question at all.  All legal issues are satisfied before we
 even let the code be imported, let alone released.

My understanding is quite the opposite.

In the past, we've been quite happy to import code into the Incubator
repository before all of the legal issues are resolved, and we have
very often issued releases without the appropriate disclaimers, CLAs,
license texts, etc, etc.  I know that many (if not most!) previously
open-sourced projects within our Incubator only get iCLAs on file well
after the code has been imported and very likely after a few releases
were made.  -- justin

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Again: The Maven Repository

[Justin Erenkrantz]

On Thu, Jun 26, 2008 at 10:32 AM, Bertrand Delacretaz
[EMAIL PROTECTED] wrote:
 On Thu, Jun 26, 2008 at 6:45 PM, Davanum Srinivas [EMAIL PROTECTED] wrote:
 I'd be very surprised if it does close the issue :)...

 IMHO voting about where to put incubator Maven artifacts is a majority
 vote among of the Incubator PMC, so that should allow us to move
 forward, even if we're not unanimous.

IIRC, we have voted on precisely this matter in the past.  It just
seems that the issue will constantly be reopened until folks get their
personally desired result.  -- justin

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: INCUBATOR-57 aka IPMC votes to ratify PPMC committers

[Justin Erenkrantz]

On Tue, Jun 3, 2008 at 9:58 PM, Bertrand Delacretaz
[EMAIL PROTECTED] wrote:
 How do you see infra checking that the account requests that they
 receive have been voted on according to this procedure?

The account reqs from the PPMC should CC Incubator PMC.  So, the
responsibility is on the Incubator PMC members to ensure that the
internal process is followed not on Infra.  (Infra will/should reject
the req if the Incubator PMC isn't CCed.)  -- justin

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

INCUBATOR-57 aka IPMC votes to ratify PPMC committers

[Justin Erenkrantz]

Currently on http://incubator.apache.org/guides/ppmc.html, we have:
---
Vote on the podling's private (PPMC) list, with notice posted to the
Incubator private list. The notice is a separate email forwarding the
vote email with a cover statement that this vote is underway on the
podling's private list. Many consider this approach to be best
practice. After completing the vote on the PPMC list, the proposer
calls a vote on the Incubator PMC private list, summarizing the
discussion and vote, with a reference to the archived discussion and
vote threads by the PPMC. The Incubator vote is done even if there are
three +1 votes from Incubator PMC members during the PPMC vote, in
order to give all Incubator PMC members a chance to express their
support or disapproval after seeing the PPMC discussion and vote
results. Note that only the Incubator PMC members can see the
Incubator private discussion, and the podling's Mentors should review
all Incubator PMC feedback with the PPMC. Moreover, only Apache
members may review the private PPMC list (this is normally not an
issue since most Incubator PMC members are Apache members).
---

I'd like to make the suggestion that we alter this to:
---
Vote on the podling's private (PPMC) list, with notice posted to the
Incubator private list. The notice is a separate email forwarding the
vote email with a cover statement that this vote is underway on the
podling's private list. Many consider this approach to be best
practice. After completing the vote on the PPMC list, the proposer
*sends a note to* the Incubator PMC private list, summarizing the
discussion and vote, with a reference to the archived discussion and
vote threads by the PPMC.  *Any member of the Incubator PMC can ACK
the receipt of the vote.  This starts a 72-hour window for lazy
consensus.  After 72 hours and no requests by any Incubator PMC member
for a full vote by the Incubator PMC, the committer request is
approved by the Incubator PMC and the PPMC can start the committer
invitation process.*
---

This intentionally follows the procedure for adding a PMC member wrt
full ASF board.  I like the concept of expanding this for committers
as well for Incubation, so there.  I don't like needless 'dual
voting', but I do want the IPMC to have the chance to execute
oversight.

WDYT?-- justin

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: INCUBATOR-57 aka IPMC votes to ratify PPMC committers

[Justin Erenkrantz]

On Tue, Jun 3, 2008 at 1:37 PM, Davanum Srinivas [EMAIL PROTECTED] wrote:
 Quick question, haven't thought thru, but raising it here...Does it make
 sense to align voting in a new committer with
 Voting in a new PPMC member? (on the same page)?

Makes sense to me.  The policy for IPMC oversight should be the same.
And, IMO, it'd be nice to instill in the PPMCs that all committers
should be on the PPMC.  -- justin

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Size of websites in incubator.apache.org

[Justin Erenkrantz]

On Wed, Apr 23, 2008 at 11:26 AM, Robert Burrell Donkin
[EMAIL PROTECTED] wrote:
  AIUI using the top level .htaccess is better for performance so that's
  what i recommend (but hopefully someone will jump in and correct me if

+1.

(Not having .htaccess at all is actually best; but that requires us
tweaking the master httpd conf files whenever a PMC wants a redirect -
doable but feh.)  -- justin

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Size of websites in incubator.apache.org

[Justin Erenkrantz]

On Tue, Apr 22, 2008 at 12:53 PM, Tony Stevenson [EMAIL PROTECTED] wrote:
 Justin

  Is the prefereed method of handling these, moving them to 
 archive.a.o/incubator.a.o/($podling)/ ?? Or is there an alternate location?

If the projects have indeed graduated, and they already have
$podling.apache.org up, and no one responds to clean them up within,
say, a week, I'd toss 'em entirely and enforce a redirect from the old
incubator.apache.org URL to the new tlp.apache.org site.

If you feel charitable and want to save the artifacts on the backup
box somewhere (since they're already copied over) for a little while
longer, feel free...but, IMO, we don't need to persist these sites.
-- justin

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Subversion vs other source control systems

[Justin Erenkrantz]

On Feb 18, 2008 1:01 PM, Robert Burrell Donkin
[EMAIL PROTECTED] wrote:
 the last time i tried SVK, changes would be needed to SVK before it
 could work with a repository as big as apache

FWIW, the partial svnsync changes that SVK would need are present in
1.5.  I don't know if the SVK community has picked up on that yet, but
SVN 1.5 clients/servers will support it.  -- justin

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Subversion vs other source control systems

[Justin Erenkrantz]

On Feb 17, 2008 7:51 AM, Noel J. Bergman [EMAIL PROTECTED] wrote:
 But visibility of the content and process very much IS part of the Apache 
 Way.

 Most of the use cases mentioned so far for git, including some where people 
 are using it on top of SVN with ASF projects, run counter to ASF principles.  
 It is *NOT* in our best interests and practices for people to work in private 
 on bulk code, and periodically submit big changes.  We want those changes 
 made in public view in Subversion branches where the Community can see the 
 work in progress, not when it is complete.  We need to reeducate people who 
 believe otherwise.

 That said, I am not saying that people can't use whatever SVN client(s) they 
 want to use.  I am saying that (a) the ASF has a uniform source control 
 infrastructure, which is currently based on SVN servers, and (b) our 
 practices mean that development is done in public, not done in private and 
 submitted en masse as a fait accompli.  These statements are independent of 
 the SCM technology used by the ASF.

+1.  -- justin

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Subversion vs other source control systems

[Justin Erenkrantz]

On Feb 17, 2008 3:34 PM, Santiago Gala [EMAIL PROTECTED] wrote:
 Also: you keep a long term branch for doing some refactoring, and you
 fix small bugs both in HEAD and in a release branch, merging and
 backporting/forwardporting as you go. Again, something like git makes
 the work simpler and keeps the disk requirements under control.

In an attempt to stop some of the outright FUD in this thread before
it goes on to yet another mailing list...

I've found that svnmerge.py (distributed with SVN) handles pretty much
all of the branch/merge tracking capabilities that I personally care
about.  (The drawback is that it isn't as efficient as we'd like, but
it's good enough.  The 1.5 stuff is *way* faster.)  From your
statements, you probably haven't bothered to try svnmerge.py (usable
with 1.4.x) or any of the new reintegrate merge stuff in 1.5.  It
makes it pretty brain-dead simple to handle most branch-oriented
merging cases.  There are a few pathological cases that don't work
well, but that's 'reflective' merging which isn't the 95% use case -
so it got punted to post-1.5.  (svnmerge.py is probably the 80% use
case, with 1.5 merge tracking being 90%, and reflective merging being
that last gap...)

FWIW, for svn.apache.org, I have a feeling we'll probably be a tad
aggressive on rolling out 1.5.
(Besides merge tracking, there are a number of excellent features in
1.5: changelist support, interactive conflict resolution, read/write
transparent proxies, integrated 'diff -x -p' support, substantial
svnsync speed improvements, partial svnsync ability, etc.)  Note that
nothing is stopping you from using svnmerge.py today.  If folks are
going to complain about switching to another SCM because of a lack of
decent merging, then they owe it to themselves to check out what
Subversion can actually do rather than what they think it can do...
-- justin

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Board Resolution - Promote Apache Synapse to a Top Level Project

[Justin Erenkrantz]

On Dec 6, 2007 7:09 PM, Paul Fremantle [EMAIL PROTECTED] wrote:
 The Apache Synapse project (part of the Web Services PMC) and the Web
 Services PMC would respectfully like to propose the following resolution for
 review by the Board at the December meeting.
 Both communities have voted to propose this resolution and a number of
 members of the community have nominated themselves as would be members of
 the potential PMC.

I don't recall seeing a positive vote on [EMAIL PROTECTED] for Synapse
- or rather the last vote thread has a bunch of -1s that are still
standing.

Did I miss something?  -- justin

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Board Resolution - Promote Apache Synapse to a Top Level Project

[Justin Erenkrantz]

On Dec 7, 2007 1:36 AM, Martijn Dashorst [EMAIL PROTECTED] wrote:
 AFAIK, Synapse has graduated on Jan 2, 2007 9:43 AM to a sub project of the
 WS TLP. Therefore the resolution doesn't involve the incubator anymore.
 I think the confusion comes from the tuscany graduation vote a couple of
 weeks ago held on [EMAIL PROTECTED]

Ugh, mea culpa.  Sorry.  Never mind me.

(But, then, why was [EMAIL PROTECTED] CCed?  That's what threw me for
a loop and got me confused...)  -- justin

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: [VOTE] Allow podling members to set up their own infra

[Justin Erenkrantz]

On Nov 21, 2007 5:03 PM, Craig L Russell [EMAIL PROTECTED] wrote:
 Since there has been no discussion, and this is a change to policy,
 I'd like to formally propose adopting the policy change in https://
 issues.apache.org/jira/browse/INCUBATOR-71

 [ ] +1 Allow podlings with karma to set up their own infrastructure
 [ ] -1 Require a Mentor to set up infrastructure

How is a non-member going to have karma to actually do any of those things?

Or, do you mean file the JIRAs?  -- justin

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: [VOTE] Accept Composer in the Incubator

[Justin Erenkrantz]

On Oct 22, 2007 12:13 AM, Jason van Zyl [EMAIL PROTECTED] wrote:
 [X] +1 Accept Composer project for incubation

Try try try again.  =)

Best of luck to ya'll.  -- justin

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Graduation: how do we check three or more independent committers ?

[Justin Erenkrantz]

On 10/16/07, Bertrand Delacretaz [EMAIL PROTECTED] wrote:
 d) Which other committers do you have a backchannel with, i.e. who
 do you regularly talk to outside of the project's mailing lists?

 I think d) is also an important measure of independence, as it's hard
 for people who meet for coffee every day to restate on the public
 lists everything that happens on their backchannel.

I talk to lots of other httpd committers outside of the project
mailing list - so I'm not sure that's a useful metric.  I get what you
mean, but I doubt its relevance.  -- justin

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: [VOTE] graduate stdcxx to TLP

[Justin Erenkrantz]

On Oct 13, 2007 12:38 PM, Noel J. Bergman [EMAIL PROTECTED] wrote:
 I would like to see the legal stuff resolved first.  I don't believe that we
 should release a project with existing copyright issues.  If this were to
 mean that stdcxx graduation would wait until November's Board meeting, I'd
 be comfortable with that.  How extensive is the issue, and how long will it
 take to complete?

It's not a 'copyright issue' per se (as all the paperwork is in
place), but rather ensuring the license headers follow the currently
recommended template.  Many of our other projects don't follow the
templates - and, yes, this will be a blocker for a release - but I
don't think it needs to hold up graduation.

 My second is simply a question about diversity.  How diverse is the
 community at this time?  I did not see any discussion of that in the voting
 thread.

Besides OtherBill and myself, the core of the community is from two
organizations with RogueWave still being predominate.  There has been
discussions between stdcxx and Tuscany folks about collaborating in
the past - so there is dialogue and receptiveness to new contributors
and organizations.  However, I don't think anything came out of the
Tuscany discussions though.  I think (and hope OtherBill agrees) that
the community is managing itself properly and is open to new
contributors.  I don't see what more stdcxx can learn from the
Incubator.

Like OtherBill, I'll stick around stdcxx for a while to ensure things
go smoothly.  -- justin

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: [VOTE] graduate stdcxx to TLP

[Justin Erenkrantz]

On Oct 13, 2007 4:28 PM, Noel J. Bergman [EMAIL PROTECTED] wrote:
 I feel that we start down a slippery slope when we graduate projects which 
 are not yet compliant, but will be.  When?  Craig points out that it has 
 been some months since the issue was raised by you, and it is still not 
 resolved.  Hence:

Who said it wasn't compliant?  It is [1] - and it was one of the first
projects to be in compliance in general with the updated licensing
requirements that Cliff drew up.

Your objection is solely about running a tool (which isn't documented
or linked to anywhere) to *prove* the compliance rather than looking
through it yourself - and that has nothing to do with the state of the
community and whether the podling should graduate.

FWIW, I just ran RAT and stdcxx is fine.  RAT is largely flagging the
automated test suite files output as missing the licenses.  These
particular files are used as a comparison so it can't have the license
text anyway or risk screwing up the tests.   IMO, there's nothing here
to warrant vetoing or tabling the graduation vote.  As I said before,
we can (and will) go through it with a fine-tooth comb before the
release; but the state of the licensing notices is comparable with any
other ASF project and graduation doesn't deserve to be held hostage to
some unreasonable expectations.  -- justin

1. Just see 
http://svn.apache.org/repos/asf/incubator/stdcxx/trunk/src/strtol.cpp
and others.

---

Summary
---
Notes: 4
Binaries: 125
Archives: 0
Standards: 2818

Apache Licensed: 2676
Generated Documents: 0

JavaDocs are generated and so license header is optional
Generated files do not required license headers

142 Unknown Licenses

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: [VOTE] graduate stdcxx to TLP

[Justin Erenkrantz]

On Oct 11, 2007 6:51 PM, Martin Sebor [EMAIL PROTECTED] wrote:
 After over two years in the incubator, two releases under our belt
 (one snapshot and one official release) and a third one coming,
 the stdcxx community with the support of our mentors feel that we
 are ready to propose to the Incubator PMC to graduate stdcxx to
 a Top Level Project. See the following vote thread in the archives:

 http://www.nabble.com/-VOTE--ready-to-graduate-tf4386148.html#a12504335

 To that end we have prepared the resolution for the Board below
 to be presented for consideration at the upcoming Board meeting.

 We invite everyone to vote to approve this proposal.

+1.  -- justin

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: [VOTE][policy] Release Distribution Directory

[Justin Erenkrantz]

On Oct 8, 2007 10:14 AM, Robert Burrell Donkin
[EMAIL PROTECTED] wrote:
 --8---
 [X] +1 Insist that releases are distributed within
 http://www.apache.org/dist/incubator
 

=)  -- justin

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: September 2007 Incubator Board Report

[Justin Erenkrantz]

On 9/17/07, Jim Jagielski [EMAIL PROTECTED] wrote:
 This was past our 48hour cutoff and, as is usually the case
 for the Incubator reports, pretty long. You are the shep for
 the Incubator this month. I am leaning towards not accepting
 this but if, as shepherd, you feel comfortable with it
 being added, I will defer to your judgement.

I just did my reviews and it wasn't in there, so +1 for not accepting.
 -- justin

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Do we meet the definition of ECCN 5D002 ?

[Justin Erenkrantz]

On 8/16/07, Gilles Scokart [EMAIL PROTECTED] wrote:
 I just found [1], and I was wonderiing if we don't fall under the
 definition of ECCN 5D002 for our binary distribution with deps.  In
 this distribution we include binaries that support https, sft and ssh (and
 maybe other via vfs).

If you have any code which directly invokes a dependency which is
covered by 5D002, yes, our policy is you must file a notice.  APR had
to file simply because it can optionally link against OpenSSL.

From the FAQ:
---
What are examples of when a crypto item is publicly accessible through
ASF servers?

The obvious example is including something like an OpenSSL binary
within a product distribution from a /dist URL. The less obvious
example, is the point at which a subversion repository starts to
include code that is specially designed to work with any other 5D002
item, whether that item is ever to be included within a product
distribution or not. In other words, a project should send out a
notification email just after making the decision to include code that
is specially designed to work with crypto APIs but before actually
committing such code. No need to worry about surprise JIRA attachments
with such code -- only the event of committing the code to the ASF
product repository.
---

So, sounds like Ivy falls under the latter example.

HTH.  -- justin

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]