Re: [VOTE] Accept NuttX into the Apache Incubator

[Greg Trasuk]

+1 binding.

Greg 

> 
>> Hi folks,
>> 
>> 
>> The [DISCUSS] thread on NuttX has died down.
>> 
>> 
>> Accordingly, I would like to call a VOTE to accept NuttX into the
>> 
>> Apache Incubator.
>> 
>> 
>> Please cast your vote:
>> 
>> 
>>  [ ] +1, bring NuttX into the Incubator
>> 
>>  [ ] +0, I don't care either way
>> 
>>  [ ] -1, do not bring NuttX into the Incubator, because...
>> 
>> 
>> The vote will open at least for 72 hours and only votes from the
>> 
>> Incubator PMC are binding, but votes from everyone are welcome.
>> 
>> 
>> =Abstract=
>> 
>> NuttX is a mature, real-time embedded operating system (RTOS).  It has wide
>> usage in IoT projects, control systems, robotics, drones, and many other
>> systems.  Unique properties of NuttX are its strict adherence to standards
>> and its scalability. NuttX follows the Unix standards as defined
>> by OpenGroup.org (POSIX, ANSI, and others).  This allows for a high degree
>> of portability. Scalability is supported through a configuration system
>> that allows NuttX to run on the smallest embedded platforms and through
>> high end single board computers.
>> 
>> 
>> =Proposal=
>> 
>> NuttX was released under a BSD 3-Clause license on February 17, 2007.  From
>> that time until now it has been managed by a single person, Gregory Nutt.
>> The user base of NuttX has grown to probably thousands of projects and
>> perhaps a hundred active developments at any time.  The code base has grown
>> to around 1.5 million lines of code (according to OpenHub.com).
>> 
>> NuttX has benefited from this single person management because this has
>> resulted in a consistent architecture and controlled growth.  But now it is
>> time to open this project to the participation of others because this
>> consistent architecture assures solid future growth, and because the
>> magnitude of effort required to support the RTOS exceeds the capability of
>> a single person, but also because users of NuttX require a stable road map
>> going forward that does not depend on a single person.
>> 
>> For these reasons, I propose that NuttX enter the Apache Incubator as a
>> first step in opening the project to wider participation.
>> 
>> 
>> =Initial Goals=
>> 
>> The initial goal will be to move the existing BSD code base to Apache and
>> integrate with the Apache development process and infrastructure. A primary
>> goal of incubation will be to grow and diversify the NuttX community. We
>> will convert that code base to the Apache license during incubation.
>> 
>> 
>> =Current Status=
>> 
>> As previously mentioned, NuttX is a mature, stable product in wide use in
>> embedded products.
>> 
>> 
>> ==Meritocracy==
>> 
>> We value meritocracy and we understand that it is the basis for an open
>> community that encourages multiple companies and individuals to contribute
>> and be invested in the project’s future. We will encourage and monitor
>> participation and make sure to extend privileges and responsibilities to
>> all contributors.
>> 
>> Being a mature project, NuttX already has an extensive user base with many
>> people who understand the software, who have committed hundreds of changes,
>> and are happy to participate in the project.  I believe that with a little
>> guidance and formalization, a PMC and a large group of experienced
>> committers can quickly be established.
>> 
>> 
>> ==Community==
>> 
>> NuttX has a large, active community.  Communication is via a Google group
>> at https://groups.google.com/forum/#!forum/nuttx where there are 395
>> members as of this writing.  Code is currently maintained
>> at Bitbucket.org at https://bitbucket.org/nuttx/.  Other communications
>> are
>> through Bitbucket issues and also via Slack for focused, interactive
>> discussions.
>> 
>> Keeping up with the communications, requests for help, issues, and
>> contributions is more than a full time job at this time.
>> 
>> 
>> ==Core Developers==
>> 
>> NuttX was initially developed by Gregory Nutt, released as an open source
>> project on February 17, 2007, and is still under active development.  There
>> are several dozen, active, frequent contributors involved with the project.
>> The core OS can be considered finished at this point, but development
>> continues in specialized areas of networking, IoT, cryptography, tools, and
>> other more specialized functions.
>> 
>> 
>> =Alignment=
>> 
>> NuttX is an original development with some small percentage of ported
>> code.  It stands alone depends on no other projects.
>> 
>> 
>> =Known Risks=
>> 
>> ==Orphaned Products==
>> 
>> We are committed to the future development of NuttX and understand that
>> graduation to a TLP, while preferable, is not the only positive outcome of
>> incubation.
>> 
>> Should the NuttX project be accepted by the Incubator, the prospective PPMC
>> would be willing to agree to a target incubation period of 2 years or less,
>> knowing that every Incubator project incurs a certain cost in terms of ASF
>> infrastructure 

Re: [VOTE] Release Apache PLC4X (Incubating) 0.3.1 [RC1]

[Greg Trasuk]

Delinquent mentor here….

+1 binding.

Greg Trasuk.

> On Mar 8, 2019, at 7:36 AM, Christofer Dutz  wrote:
> 
> Hi all,
> 
> carrying over my vote from the plc4x dev list.
> 
> +1
> 
> Chris
> 
> 
> 
> 
> Am 08.03.19, 13:02 schrieb "Julian Feinauer" :
> 
>Hello all,
> 
>This is a call for vote to release Apache PLC4X (Incubating) version 0.3.1.
> 
>The Apache PLC4X community has voted on and approved a proposal to release
>Apache PLC4X (Incubating) version 0.3.1.
> 
>We now kindly request the Incubator PMC members review and vote on this
>incubator release.
> 
>Apache PLC4X (incubating) is a set of libraries for communicating with
>industrial programmable logic controllers (PLCs) using a variety of
>protocols but with a shared API.
> 
>PLC4X community vote and result thread:
>Result: 
> https://lists.apache.org/thread.html/44904efe6d2ded6442605e627d501dba097e79622308d91eb00799e7@%3Cdev.plc4x.apache.org%3E
>Vote: 
> https://lists.apache.org/thread.html/7e9c475d07c0e12f813226aa123f54969ebb21a2277b32e9bd366d96@%3Cdev.plc4x.apache.org%3E
> 
>The release candidates (RC1):
>https://dist.apache.org/repos/dist/dev/incubator/plc4x/0.3.1-incubating/
> 
>Git tag for the release (RC1):
>https://github.com/apache/incubator-plc4x/releases/tag/release%2F0.3.1
> 
>Hash for the release tag:
>7852b6d78a2b4c36ecf0f7c902816131e339adff
> 
>Release Notes:
>
> https://github.com/apache/incubator-plc4x/blob/7852b6d78a2b4c36ecf0f7c902816131e339adff/RELEASE_NOTES
> 
> 
>The artifacts have been signed with Key : C336E0143A553B89, which can be
>found in the keys file:
>https://dist.apache.org/repos/dist/dev/incubator/plc4x/KEYS
> 
>Look at here for how to verify this release candidate:
>
> https://cwiki.apache.org/confluence/display/PLC4X/Validating+a+staged+Release
> 
>The vote will be open for at least 72 hours or until necessary number of
>votes are reached.
> 
>Please vote accordingly:
>[ ] +1 approve
>[ ] +0 no opinion
>[ ] -1 disapprove with the reason
> 
>Julian
>Apache PLC4X
> 
> 
> 
> 
> -
> To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
> For additional commands, e-mail: general-h...@incubator.apache.org


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

Re: [VOTE] Accept Zipkin into the Apache Incubator

[Greg Trasuk]

+1 Accept Zipkin (binding).

Greg Trasuk.

> On Aug 26, 2018, at 11:14 PM, Mick Semb Wever  wrote:
> 
> After a brief discussion¹ I would like to call a VOTE to accept Zipkin into 
> the Apache Incubator. 
> The full proposal is available on the wiki² and is pasted below in text form 
> as well.
> 
> This vote will run at least 72 hours. Please VOTE as follows:
> 
> [ ] +1 Accept Zipkin into the Apache Incubator
> [ ] +0 No opinion
> [ ] -1 Do not accept Zipkin into the Apache Incubator because…
> 
> regards,
> Mick
> 
> [1] 
> https://lists.apache.org/thread.html/54798a5059db1d5716ed9910a15c92945509a25ec3b7ccb6b1215c53@%3Cgeneral.incubator.apache.org%3E
> [2] https://wiki.apache.org/incubator/ZipkinProposal
> 
> 
> 
> = Abstract =
> Zipkin is a distributed tracing system. It helps gather timing data needed to 
> troubleshoot latency problems in microservice architectures. It manages both 
> the collection and lookup of this data. Zipkin’s design is based on the 
> Google Dapper paper.
> 
> = Proposal =
> Zipkin provides a defined data model and payload type for distributed trace 
> data collection. It also provides an UI and http api for querying the data. 
> Its server implements this api and includes abstractions for storage and 
> transport of trace payloads. The combination of these parts avoid lock-in to 
> a specific tracing backend. For example, Zipkin includes integration with 
> different open source storage mechanisms like Apache Cassandra and 
> Elasticsearch. It also includes bridges to convert collected data and forward 
> it to service offerings such as Amazon X-Ray and Google Stackdriver. 
> Ecosystem offering extend this portability further.
> 
> While primarily focused on the system, Zipkin also includes tracing libraries 
> which applications use to report timing information. Zipkin's core 
> organization includes tracer libraries written in Java, Javascript, Go, PHP 
> and Ruby. These libraries use the formats mentioned above to report data, as 
> well "B3" which is a header format needed to send trace identifiers along 
> with production requests. Many Zipkin libraries can also send data directly 
> to other services such as Amazon X-Ray and Google Stackdriver, skipping any 
> Zipkin infrastructure. There are also more Zipkin tracing libraries outside 
> the core organization than inside it. This is due to the "OpenZipkin" culture 
> of promoting ecosystem work.
> 
> = Background =
> Zipkin began in 2012 at Twitter during a time they were investigating 
> performance problems underlying the "fail whale" seen by users. The name 
> Zipkin is from the Turkish word for harpoon: the harpoon that will kill the 
> failures! Incidentally, Zipkin was not the first tracing system, it had roots 
> in a former system at Twitter named BigBrotherBird. It is due to 
> BigBrotherBird that the de-facto tracing headers we still use today include 
> the prefix "X-B3".
> 
> In 2015, a community of users noticed the project was not healthy in so far 
> as it hadn't progressed and often didn't accept pull requests, and the 
> Cassandra backend was stuck on an unmaintained library. For example, the 
> Apache Incubator H-Trace project started in some ways as a reaction to the 
> inability to customize the code. The root cause of this was Twitter moving to 
> internal storage (Manhattan) and also the project not being managed as a 
> product. By mid 2015, the community regrouped as OpenZipkin and the codebase 
> moved from Twitter to an org also named OpenZipkin. This led to fast progress 
> on concerns including initially a server rewrite and Docker based deployment.
> 
> In 2018, the second version of the data model completed, and along the way, 
> many new libraries became standard, including javascript, golang and PHP. The 
> community is dramatically larger than 2015, and Zipkin remains the most 
> popular tracing system despite heavy competition.
> 
> = Rationale =
> Zipkin is a de-facto distributed tracing system, which is more important as 
> architectures become more fine grained due to popularity of microservice or 
> even serverless architectures. Applications transition to use more complex 
> communication including asynchronous code and service mesh, increasing the 
> need for tools that visualize the behavior of requests as they map across an 
> architecture.
> 
> Zipkin's server is focused only on distributed tracing. It is meant to be 
> used alongside existing logging and metrics systems. Generally, the community 
> optimizes brown field concerns such as interop over breaking changes such as 
> experimental features. The combination of code and community make Zipkin a 
> safe and easier

Re: [VOTE] Accept PLC4X into the Apache Incubator

[Greg Trasuk]

+1 (binding)

Greg Trasuk

> On Dec 14, 2017, at 10:55 PM, Sergio Fernández <wik...@apache.org> wrote:
> 
> +1 (binding)
> 
> On Dec 14, 2017 15:19, "Justin Mclean" <jus...@classsoftware.com> wrote:
> 
>> Hi All,
>> 
>> I would like to start a VOTE to propose the PLC4X project as a podling
>> into the Apache incubator.
>> 
>> The ASF voting rules are described:
>> 
>> https://www.apache.org/foundation/voting.html <https://www.apache.org/
>> foundation/voting.html>
>> 
>> A vote for accepting a new Apache Incubator podling is a majority vote for
>> which only Incubator PMC member votes are binding.
>> 
>> This vote will run for at least 72 hours. Please VOTE as follows
>> [] +1 Accept PLC4X into the Apache Incubator
>> [] +0 Abstain.
>> [] -1 Do not accept PLC4X into the Apache Incubator because ...
>> 
>> The proposal is listed below, but you can view it on the wiki:
>> https://wiki.apache.org/incubator/PLC4XProposal
>> 
>> = PLC4XProposal =
>> 
>> == Abstract ==
>> 
>> PLC4X is intended to become a set of libraries for communicating with
>> industrial programmable logic controllers (PLCs) using a variety of
>> protocols
>> but with a shared API.
>> 
>> For the most used of these protocols, PLC4X will provide implementations of
>> drivers. Each protocol driver is hereby provided by an individual artifact.
>> 
>> In a first step, we are concentrating on Java but will be hoping to be
>> able to
>> port implementation to C and other languages.
>> 
>> == Background ==
>> 
>> Industrial machines have been controlled by PLCs for more than 30 years. In
>> simpler pieces of machinery these may operate autonomously, in more complex
>> ones several to hundreds of these industrial computers communicate with
>> each
>> other.
>> 
>> == Rationale ==
>> 
>> Currently software for communicating with PLCs is mainly proprietary
>> software
>> and a whole ecosystem of closed-source solutions exist. Usually this
>> software
>> is very expensive and licensing implies a lot of restrictions on its usage.
>> There is a small set of open-source libraries available, but unfortunately
>> most
>> of these are GPL licensed and hereby disqualify themselves from commercial
>> use.
>> Most of these are direct ports from C/C++ implementations and therefore
>> inherit
>> their API. Usually these are implemented blocking socket operations and
>> have
>> great problems with concurrency. Also, the APIs of these tools differ
>> quite a
>> lot, so porting a software from communicating with one type of PLC to
>> another
>> sometimes requires re-writing a great part of the software.
>> 
>> There are multiple rationales behind this project:
>> 
>> 1. By providing libraries with Apache license, it will be possible to
>> create
>> commercial applications which access PLCs
>> 2. By providing a universal API for different protocols, it reduces the
>> vendor
>> lock-in when creating software
>> 3. Most of the proprietary commercial solutions are based on Windows
>> systems,
>> especially the Siemens solutions, sometimes require maintaining un-patched
>> versions of older Windows version in order to run, this is a huge security
>> risk
>> (See Stuxnet)
>> 4. Most of the proprietary commercial solutions don't scale. Running them
>> in
>> public/private clouds and/or in containers is completely out of the
>> question.
>> 
>> As a result of above, it would be possible to start writing secure,
>> scalable
>> and reliable software using the full stack of open-source solutions and
>> hereby
>> open a complete new market for developers. In order to make this even
>> easier,
>> we are planning on directly providing adapters and examples for using PLC4X
>> together with other Apache frameworks.
>> 
>> == Initial Goals ==
>> 
>> Develop a universal API for accessing industrial programmable logic
>> controllers
>> in a protocol-agnostic way. Also implement Java versions of drivers for the
>> most prominent protocols: S7, Modbus and OPC-UA - but not limited to
>> those. On
>> the side of the adapters, for existing OS solutions, we are currently
>> working
>> on adapters for: Apache Edgent (incubating), Apache Camel and eventually
>> even
>> Apache Brooklyn.
>> 
>> Also, we will be providing a Scala wrapper to ease integration of PLC4X in
>> Scala based systems with an API Scal

Re: [VOTE] Graduate Apache Guacamole as TLP

[Greg Trasuk]

> 

+1 for Graduation (binding).

>> Hello Incubator PMC,
>> 
>> The Apache Guacamole community has discussed  [1] [2], voted on, and
>> approved a resolution to graduate to a top-level project. The draft
>> resolution has since been given to the IPMC for review and discussion [3],
>> and with no further feedback, we would now like to call a VOTE to graduate
>> and establish Apache Guacamole as a top-level project.
>> 
>> Apache Guacamole began incubation in February of 2016. Since entering the
>> Incubator, the podling has gone through four releases [4], added three
>> committers, and grown a healthy and active community on the mailing lists.
>> Our completed maturity evaluation can be found here:
>> 
>> http://guacamole.incubator.apache.org/maturity-evaluation/
>> 
>> and the community graduation VOTE result can be found here:
>> 
>> https://lists.apache.org/thread.html/0de2c49ee556b0e024d25be6092d40
>> 5ce8d1cccbb9df1823ba79713e@%3Cdev.guacamole.apache.org%3E
>> 
>> The full text of the proposed resolution can be found below.
>> 
>> Please review and vote:
>> 
>> [X ] +1 Graduate Apache Guacamole podling from the Incubator
>> [ ] +0 Don't care
>> [ ] -1 Don't graduate Apache Guacamole from the Incubator because...
>> 
>> This vote will be open for at least 72 hours.
>> 
>> Thanks,
>> 
>> - Mike
>> 
>> [1] https://lists.apache.org/thread.html/0848dd53b6acc1a0edea2ed
>> a1f385294eeb041a88c3d1f6221fa1ef2@%3Cdev.guacamole.apache.org%3E
>> [2] https://lists.apache.org/thread.html/a5259173a8ef4a1d2bb7be2
>> d99d3cbc2ccf8856130ae6e3fe54e079e@%3Cdev.guacamole.apache.org%3E
>> [3] https://lists.apache.org/thread.html/da03d479209b6f7a254a301de9bcd4
>> 07a6eaf65f632227e76395f32d@%3Cgeneral.incubator.apache.org%3E
>> [4] http://guacamole.incubator.apache.org/releases/
>> 
>> --
>> 
>> Establish the Apache Guacamole Project
>> 
>> WHEREAS, the Board of Directors deems it to be in the best interests of
>> the Foundation and consistent with the Foundation's purpose to establish
>> a Project Management Committee charged with the creation and maintenance
>> of open-source software, for distribution at no charge to the public,
>> related to providing performant, browser-based remote access.
>> 
>> NOW, THEREFORE, BE IT RESOLVED, that a Project Management Committee
>> (PMC), to be known as the "Apache Guacamole Project", be and hereby is
>> established pursuant to Bylaws of the Foundation; and be it further
>> 
>> RESOLVED, that the Apache Guacamole Project be and hereby is responsible
>> for the creation and maintenance of software related to providing
>> performant, browser-based remote access; and be it further
>> 
>> RESOLVED, that the office of "Vice President, Apache Guacamole" be and
>> hereby is created, the person holding such office to serve at the
>> direction of the Board of Directors as the chair of the Apache Guacamole
>> Project, and to have primary responsibility for management of the
>> projects within the scope of responsibility of the Apache Guacamole
>> Project; and be it further
>> 
>> RESOLVED, that the persons listed immediately below be and hereby are
>> appointed to serve as the initial members of the Apache Guacamole
>> Project:
>> 
>> * Carl Harris  <cehar...@apache.org>
>> * Daniel Gruno <humbed...@apache.org>
>> * Frode Langelo<fr...@apache.org>
>> * Greg Trasuk  <gtra...@apache.org>
>> * James Muehlner   <jmuehl...@apache.org>
>> * Jean-Baptiste Onofré <jbono...@apache.org>
>> * Jim Jagielski<j...@apache.org>
>> * Mike Jumper  <mjum...@apache.org>
>> * Nick Couchman<vn...@apache.org>
>> 
>> NOW, THEREFORE, BE IT FURTHER RESOLVED, that Mike Jumper be appointed to
>> the office of Vice President, Apache Guacamole, to serve in accordance
>> with and subject to the direction of the Board of Directors and the
>> Bylaws of the Foundation until death, resignation, retirement, removal
>> or disqualification, or until a successor is appointed; and be it
>> further
>> 
>> RESOLVED, that the initial Apache Guacamole PMC be and hereby is tasked
>> with the creation of a set of bylaws intended to encourage open
>> development and increased participation in the Apache Guacamole Project;
>> and be it further
>> 
>> RESOLVED, that the Apache Guacamole Project be and hereby is tasked with
>> the migration and rationalization of the Apache Incubator Guacamole
>> podling; and be it further
>> 
>> RESOLVED, that all responsibilities pertaining to the Apache Incubator
>> Guacamole podling encumbered upon the Apache Incubator PMC are hereafter
>> discharged.
>> 


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

Re: [DISCUSS] Resolution to graduate Apache Guacamole to TLP

[Greg Trasuk]

> On Nov 5, 2017, at 4:21 PM, Mike Jumper <mike.jum...@guac-dev.org> wrote:
> 
> On Sun, Oct 29, 2017 at 11:53 AM, Mike Jumper <mike.jum...@guac-dev.org> 
> wrote:
>> 
>> On Sat, Oct 28, 2017 at 6:37 AM, John D. Ament <johndam...@apache.org> wrote:
>>> Hi,
>>> 
>>> For the proposed PMC, could you share what the corporate affiliations are?
>>> 
>> 
>> To the best of my knowledge/research, the corporate affiliations are
>> as follows (with some members associated with multiple):
>> 
>>Capital One:
>>   Jim Jagielski
>> 
>>Coty, Inc.:
>>   Nick Couchman
>> 
>>Glyptodon, Inc.:
>>   James Muehlner
>>   Mike Jumper
>> 
>>OS3 Consulting LLC:
>>   Nick Couchman
>> 
>>Quenda:
>>   Daniel Gruno
>> 
>>Skytap:
>>   Frode Langelo
>> 
>>Talend:
>>   Jean-Baptiste Onofré
>> 
>>Planet Labs, Inc.:
>>   James Muehlner
>> 
>>Virginia Polytechnic Institute and State University:
>>   Carl Harris
>> 
>>Web Age Solutions:
>>   Greg Trasuk
>> 
>>Webtide LLC:
>>Olivier Lamy
>> 
>> I've reached out to the proposed PMC members for updates regarding
>> corporate affiliation, in case things have changed, but hopefully this
>> gives at least some perspective for the time being.
>> 
> 
> Any further feedback/discussion?
> 
> Thanks,
> 

Not from me.  I do work for Web Age Solutions, although I participate in Apache 
projects on my own time.

Cheers,

Greg Trasuk
> - Mike
> 
> -
> 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: [DRAFT] Incubator PMC Board Report - August 2017

[Greg Trasuk]

I’m a Guacamole mentor, and I have signed-off the report on the wiki page.

Cheers,

Greg Trasuk
> On Aug 8, 2017, at 11:03 PM, Dave Fisher <dave2w...@comcast.net> wrote:
> 
> All,
> 
> Please find the current draft below.  I'll be submitting end of day
> tomorrow assuming no issues, moving the remaining 2 podlings to
> non-reporting (Guacamole & S2Graph).
> 
> Incubator PMC report for August 2017
> 
> The Apache Incubator is the entry path into the ASF for projects and
> codebases wishing to become part of the Foundation's efforts.
> 
> There are currently 53 podlings incubating.  July was a quieter month for
> the incubator, summer holidays and what not.  We executed seven podling
> releases this month, one podling retired but otherwise no other changes.
> 
> * Community
> 
>  New IPMC members:
> 
>  - None
> 
>  People who left the IPMC:
> 
>  - None
> 
> * New Podlings
> 
>  - None
> 
> * Podlings that failed to report, expected next month
> 
>  - MRQL
>  - Ratis
> 
> * Podlings missing sign off, will be moved to failed to report
> 
>  - Guacamole
>  - S2Graph
> 
> * Graduations
> 
>  The board has motions for the following:
> 
>  - None
> 
> * Retirements
> 
>  The following podlings retired this month:
> 
>  - HORN
> 
> * Releases
> 
>  The following releases entered distribution during the month of
>  July:
> 
>  - 2017-07-06 Apache Gearpump 0.8.4
>  - 2017-07-06 Apaceh Traffic Control 2.0.0
>  - 2017-07-08 Apache Aria Tosca 0.1.0
>  - 2017-07-11 Apahce HAWQ 2.2.0.0
>  - 2017-07-18 Apache Griffin 0.1.5
>  - 2017-07-18 Apache Aria Tosca 0.1.1
>  - 2017-07-31 Apache Guacamole 0.9.13
> 
> 
> * IP Clearance
> 
>  - We have begun work to clean up IP Clearance policies.  First is to make
> it clear that the preference is ICLAs and CCLAs over SGAs.  We have also
> seen better responsiveness after reasserting that the IPMC owns
> responsibility for all incoming code donations.
> 
> * Legal / Trademarks
> 
> 
> 
> * Infrastructure
> 
> 
> 
> * Miscellaneous
> 
>  - A general issue of VPs within other cross functional areas of the ASF
> reaching out to podlings has started to surface.  Specifically, I would
> like to request that the board supports a request that those areas should
> be reaching out to podlings directly with issues, escalating to the IPMC
> due to lack of follow through, rather than approaching the IPMC first.  The
> Security team's model is a perfect example of what to do.
> 
> --
>   Table of Contents
> BatchEE
> DataFu
> Edgent
> Fluo
> Gobblin
> Guacamole
> Heron
> Impala
> iota
> Joshua
> Livy
> MRQL
> NetBeans
> PredictionIO
> Pulsar
> Ratis
> S2Graph
> Slider
> Superset
> Tamaya
> Toree
> Unomi
> 
> --
> 
> 
> BatchEE
> 
> BatchEE projects aims to provide a JBatch implementation (aka JSR352) and a
> set of useful extensions for this specification.
> 
> BatchEE has been incubating since 2013-10-03.
> 
> Three most important issues to address in the move towards graduation:
> 
>  1. Increase the community probably?
>  2. -
>  3. -
> 
> Any issues that the Incubator PMC (IPMC) or ASF Board wish/need to be
> aware of?
> 
> No
> 
> How has the community developed since the last report?
> 
> Not much as expected being in between "spec" releases.
> 
> How has the project developed since the last report?
> 
> BatchEE is quite stable and therefore should probably head to graduation
> soon.
> 
> How would you assess the podling's maturity?
> Please feel free to add your own commentary.
> 
>  [ ] Initial setup
>  [ ] Working towards first release
>  [ ] Community building
>  [X] Nearing graduation
>  [ ] Other:
> 
> Date of last release:
> 
>  2016-09-22
> 
> When were the last committers or PPMC members elected?
> 
> 2016-12-18
> 
> Signed-off-by:
> 
>  [ ](batchee) Jean-Baptiste Onofré
> Comments:
>  [X](batchee) Olivier Lamy
> Comments:
>  [X](batchee) Mark Struberg
> Comments: I think we should graduate indeed.
> It seems we had some confusion with the LDAP when we added rsandtner
> as committer.
> We need to scan our mailing lists and check what is missing on the
> official status page.
> 
> IPMC/Shepherd notes:
> team-list.html - this page shows no members or committers.
> I checked private and it looks like the last committer/ppmc add was in 

Re: Urgent: Regarding Java package name change to org.apache.*

[Greg Trasuk]

Does this actually need to be policy?  What’s the harm to the foundation if a 
project continues to use a non-Apache package name, assuming that the code was 
donated appropriately?  

Certainly, it should be a goal for all projects to use o.a.* package names, but 
if you look around the Foundation’s projects, you’re probably going to find 
lots of non-o.a.* packages.  So it seems like this is another case of 
“Incubator has one (sort-of) policy, while the rest of the Foundation does its 
own thing” cases.  And that being the case, it seems like an unreasonable 
imposition on podlings.

I’d suggest taking out the MUSTs wherever possible, and having mentors make 
“should”, or maybe even “oughta” recommendations.  Apache is already seen as 
unfriendly enough to podlings.

Cheers,

Greg.
> On Aug 3, 2017, at 12:34 PM, John D. Ament  wrote:
> 
> One caveat - if your packages are "com.theoldcompany.someproject" they
> should be renamed to "org.apache.someproject" before graduation.  If you
> have "org.someproject" already or just "someproject" as your package names,
> that's not a naming issue so I don't see that ever blocking graduation.
> 
> John
> 
> On Thu, Aug 3, 2017 at 12:25 PM Alex Harui  wrote:
> 
>> OK, so to summarize a more refined recommendation:
>> 
>> 1) package names with reverse domains MUST be renamed before graduation or
>> have an IPMC approved plan for renaming
>> 2) Projects who expect that their future users outnumber current users are
>> highly encouraged to rename packages
>> 3) Other projects are not required to rename packages and backward
>> compatibility is sufficient reason to not rename packages.
>> 
>> Or should #2 also be a MUST?
>> 
>> -Alex
>> 
>> On 8/3/17, 8:34 AM, "Andy Seaborne"  wrote:
>> 
>>> 
>>> 
>>> On 03/08/17 15:51, Julian Hyde wrote:
 It rarely comes down to the IPMC or the Board dictating how a project
 names its java classes (does anyone recall an instance?), so it’s mainly
 the project’s discretion. In my opinion, where the project is on its
 adoption curve is an important consideration.
>>> 
>>> +1
>>> 
 Most projects that enter the incubator are early on the adoption curve.
 Their future users outnumber their current users. The earlier these
 projects make the change to org.apache, the fewer people they will
 ultimately impact. It seems that gobblin is in this category.
 
 A few projects, such as Flex, are already near the top of their
 adoption curve. The cost/benefit of renaming is not as compelling.
>>> 
>>> Jena was not early on the adoption curve. Long term compatibility has
>>> been, and is, a major element of the project culture.  Importantly,
>>> there are active users who answer questions (here, elsewhere), external
>>> web tutorials, books etc referring to the pre-ASF API.  We have a
>>> responsibility to them as well.
>>> 
>>> "add an API" is more stuff that a small set of volunteer contributors
>>> (Jena has had no paid contributors working on) could not have coped
>>> with.  If a project has the capacity, sure. Not all project will.
>>> 
>>> Set the expectations too high and it is implicitly a filter for a
>>> certain kind of project in size and structure.
>>> 
>>>Andy
>>> 
>>> 
 
 Julian
 
 
> On Aug 3, 2017, at 7:37 AM, Alex Harui 
> wrote:
> 
> From the peanut gallery:
> 
> Does the PPMC get to decide what constitutes a "very good reason" or
> does
> the IPMC and after graduation, the board?
> 
> Flex has not changed its packages in the 5 years at Apache.  We felt
> backward compatibility was and is a "very good reason".  It was way
> more
> important to not require folks to alter their code in order to move to
> the
> Apache versions of Flex.  Also, we are not using Java/Maven so there
> isn't
> really a shading option.
> 
> On the other hand, it seems like it could be confusing for Apache
> projects
> to have packages starting with "com.".  Flex's packages start with
> "mx" or
> "spark" (the component set names).
> 
> Seems like a more refined guidance would be that:
> 1) packages starting with "com" (and maybe
> org.somethingOtherThanApache)
> should be changed as soon as possible/practical
> 2) there is no recommendation for other package prefixes
> 
> My 2 cents,
> -Alex
> 
> On 8/3/17, 5:42 AM, "Shane Curcuru"  > wrote:
> 
>> John D. Ament wrote on 8/2/17 9:13 PM:
>>> On Wed, Aug 2, 2017 at 8:54 PM Roman Shaposhnik
>>> 
>>> wrote:
>>> 
 On Wed, Aug 2, 2017 at 5:40 PM, Abhishek Tiwari 
 wrote:
> Hi all,
> 
> In regards to the recently incubated project - Gobblin, we were
> wondering

Can you un-open-source a product? Re: [DISCUSS] Olympian Incubation Proposal

[Greg Trasuk]

I’m kind of curious how we’d apply our “Community over Code” credo to a 
situation like this.

It sounds like DataStax acquired a “community” centred on a product that had 
been open-sourced by its previous steward.  And now their legal department is 
re-asserting control over the product.  Fair enough, but if there’s a community 
that wants to carry on development against a product that was properly and 
fairly ASL2 licensed, does the acquirer have the right to shut them down?  They 
certainly could assert control over the trademark that they own, but what if 
the community called it something else and carried on (which we generally 
require of an incubator product anyway)?  

I’m obviously thinking of Hudson and Jenkins here - the community forked the 
code over a weekend, and Oracle was left with a dead product.  When they 
asserted ownership of the “Hudson” trademark, the community simply said “OK, 
it’s Jenkins now”, and carried on.

If they had come to Apache, would we have shown them the door, for legalistic 
reasons? ( I don’t recall them coming to Apache at the time, but I could be 
wrong).  Is it a “hostile fork” if the bulk of the community is in favour, and 
it’s only the trademark owner that demurs?

It seems to me that one of the goals of Apache is to have a “neutral” corporate 
entity to host open-source projects under open but orderly governance, so that 
an open-source project stands a chance of outlasting the mercurial whims of a 
commercial entity (and also of individual maintainers).

So I wonder if we’re being a little quick to shut down a community that wants 
open governance.

Cheers,

Greg Trasuk


> On Sep 29, 2016, at 10:59 PM, Ross Gardler <ross.gard...@microsoft.com> wrote:
> 
> Yes, with a few binding -1's there is nothing to discuss unless Datastax wish 
> to reconsider. I doubt they want to discuss that on a public list.
> 
> Ross
> 
>> -Original Message-
>> From: Henry Saputra [mailto:henry.sapu...@gmail.com]
>> Sent: Thursday, September 29, 2016 10:57 PM
>> To: general@incubator.apache.org
>> Subject: Re: [DISCUSS] Olympian Incubation Proposal
>> 
>> With obvious block due to Datastax response, shall I CLOSE this DISCUSS 
>> thread
>> until further updates, if any?
>> 
>> On Thursday, September 29, 2016, P. Taylor Goetz <ptgo...@gmail.com>
>> wrote:
>> 
>>> For the record I'd be -1 as well unless DataStax chose to support it.
>>> 
>>> I would like to give them time to change their mind though.
>>> 
>>> -Taylor
>>> 
>>>> On Sep 29, 2016, at 10:37 PM, Greg Stein <gst...@gmail.com
>>> <javascript:;>> wrote:
>>>> 
>>>>> On Sep 29, 2016 19:22, "P. Taylor Goetz" <ptgo...@gmail.com
>>> <javascript:;>> wrote:
>>>>> ...
>>>>> They can block a move to the ASF, but they can’t block a fork of
>>>>> the
>>>> project moving elsewhere. Strong communities will regroup and live on.
>>>> DataStax' reluctance to allow it could very easily be interpreted as
>>>> a rejection of the ASF governance model or the Foundation itself.
>>>> 
>>>> Yes, the community could certainly launch their fork at GitHub or
>>>> some such. DataStax provided them with that ability via the ALv2
>>>> license. The ASF is not a necessary step for that community.
>>>> 
>>>>> ...
>>>>> Can we wait and see if DataStax is willing to do the right thing
>>>>> before
>>>> shooting down the proposal as a hostile fork?
>>>> 
>>>> My vote remains -1. That can change, based on their choices.
>>>> 
>>>> Cheers,
>>>> -g
>>> 
>>> -
>>> To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
>>> <javascript:;>
>>> For additional commands, e-mail: general-h...@incubator.apache.org
>>> <javascript:;>
>>> 
>>> 
> 
> -
> To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
> For additional commands, e-mail: general-h...@incubator.apache.org


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

Re: [VOTE] Accept NetBeans into the Apache Incubator

[Greg Trasuk]

> This vote will run for at least 72 hours. Please VOTE as follows
> [ X ] +1 Accept NetBeans into the Apache Incubator
> [] +0 Abstain.
> [] -1 Do not accept NetBeans into the Apache Incubator because …

i.e. +1 (Binding).

Greg Trasuk

> On Sep 27, 2016, at 4:30 PM, Ate Douma <a...@douma.nu> wrote:
> 
> Hi everyone,
> 
> Now that the discussion thread on the NetBeans Proposal has ended,
> please vote on accepting NetBeans into the Apache Incubator.
> 
> The ASF voting rules are described at:
>   http://www.apache.org/foundation/voting.html
> 
> A vote for accepting a new Apache Incubator podling is a majority vote
> for which only Incubator PMC member votes are binding.
> 
> Votes from other people are also welcome as an indication of peoples
> enthusiasm (or lack thereof).
> 
> Please do not use this VOTE thread for discussions.
> If needed, start a new thread instead.
> 
> This vote will run for at least 72 hours. Please VOTE as follows
> [] +1 Accept NetBeans into the Apache Incubator
> [] +0 Abstain.
> [] -1 Do not accept NetBeans into the Apache Incubator because ...
> 
> 
> The proposal is listed below, but you can also access it on the wiki:
>   https://wiki.apache.org/incubator/NetBeansProposal
> 
> 
> Thanks,
> Ate.
> 
> == Abstract ==
> 
> NetBeans is an open source development environment, tooling platform, and
> application framework, used by 1.5 million individuals each month.
> 
> == Proposal ==
> Apache NetBeans will continue to focus on the areas it has focused on while
> sponsored by Sun Microsystems and Oracle. It will continue to primarily focus 
> on
> providing tools for the Java ecosystem, while also being focused on tools for
> other ecosystems, languages and technologies, such as JavaScript, PHP, and
> C/C++. It will continue to actively support its community by means of mailing
> lists, tutorials, and documentation.
> 
> == Background ==
> NetBeans started in 1995/96 in Prague, in the Czech Republic, as a student
> project. Sun Microsystems acquired and open sourced it in 2000 and, with the
> acquisition of Sun Microsystems by Oracle in 2010, became part of Oracle.
> Throughout its history in Sun Microsystems and Oracle, NetBeans has been free
> and open source and has been leveraged by its sponsor as a mechanism for 
> driving
> the Java ecosystem forward.
> 
> == Rationale ==
> Although NetBeans is already open source, moving it to a neutral place like
> Apache, with its strong governance model, is expected to help get more
> contributions from various organizations. For example, large companies are 
> using
> NetBeans as an application framework to build internal or commercial
> applications and are much more likely to contribute to it once it moves to
> neutral Apache ground. At the same time, though Oracle will relinquish its
> control over NetBeans, individual contributors from Oracle are expected to
> continue contributing to NetBeans after it has been contributed to Apache,
> together with individual contributors from other organizations, as well as
> self-employed individual contributors.
> 
> == Initial Goals ==
> The initial goals of the NetBeans contribution under the Apache umbrella are 
> to
> establish a new home for an already fully functioning project and to open up 
> the
> governance model so as to simplify and streamline contributions from the 
> community.
> 
> == Current Status ==
>Meritocracy: NetBeans has been run by Oracle, with the majority of code
> contributions coming from Oracle. The specific reason for moving to Apache is 
> to
> expand the diversity of contributors and to increase the level of meritocracy 
> in
> NetBeans. Apache NetBeans will be actively seeking new contributors and will
> welcome them warmly and provide a friendly and productive environment for
> purposes of providing a development environment, tooling environment, and
> application framework.
> 
>Community: NetBeans has approximately 1.5 million active users around the
> world, in extremely diverse structures and organizations. NetBeans is used by
> teachers and instructors at schools and universities to teach Java and other
> languages. It is used by students as an educational tool. It is used by large
> organizations who base their software on the application framework beneath
> NetBeans. It is used by web developers for creating web sites and by 
> developers
> using a range of tools, languages, and technologies to be productive and
> efficient software developers.
> 
>Core Developers: The core developers will come from a range of
> organizations, including Oracle, which will continue its investment in 
> NetBeans.
> 
>Alignment: T

Re: [DISCUSS] [PROPOSAL] Omid for Apache Incubator

[Greg Trasuk]

I don’t think it’s the Incubator’s job to choose which competing projects 
should join the foundation.  All we’re here to do is to make sure that a 
community knows how to act like an Apache community, and that the artifacts are 
licensed properly.

It’s probably worth pointing out to both projects that the other one is out 
there, just because it’s possible they could work together, and a larger 
community is usually more stable.   But I certainly wouldn’t want to see the 
Incubator turn down a project just because it’s similar to one that’s already 
part of Apache.  Would we have turned down Tomcat because we already had an 
http server?

Cheers,

Greg Trasuk.

> On Mar 18, 2016, at 7:19 PM, Henry Saputra <henry.sapu...@gmail.com> wrote:
> 
> I know Apache incubator does not play favorite but it is getting awkward
> that TWO transaction engine for HBase coming to incubator at the same time.
> 
> As most people know, the other one is Tephra, that just coming to incubator
> few weeks ago.
> 
> As member of IPMC, I would like to see Omid provide some more details
> comparisons about the difference that the project bring,  in term of
> approach and possible integrations with other ASF projects.
> 
> If possible, I would prefer to see Omid team work together with Tephra to
> work on working together to make one solid transaction engine for HBase and
> later NoSQL databases.
> 
> 
> - Henry
> 
> On Thu, Mar 17, 2016 at 1:17 PM, Daniel Dai <dai...@gmail.com> wrote:
> 
>> Hi,
>> 
>> I would like to propose Omid as an Apache Incubator project:
>> 
>> https://wiki.apache.org/incubator/OmidProposal
>> 
>> I've posted posted the text of the proposal below:
>> 
>> Thanks,
>> Daniel
>> 
>> = Omid Proposal =
>> 
>> === Abstract ===
>> 
>> Omid is a flexible, reliable, high performant and scalable ACID
>> transactional framework that allows client applications to execute
>> transactions on top of MVCC key/value-based NoSQL datastores
>> (currently Apache HBase) providing Snapshot Isolation guarantees on
>> the accessed data.
>> 
>> 
>> === Proposal ===
>> 
>> Omid is a flexible open-source transactional framework that provides
>> ACID transactions with Snapshot Isolation guarantees on top of NoSQL
>> datastores. In particular, the current codebase brings the concept of
>> transactions to the popular Apache HBase datastore. Omid offers great
>> performance, it is highly available, and scalable. Omid's current
>> version is able to scale to thousands of clients triggering concurrent
>> transactions on application data stored in HBase. Omid can scale
>> beyond 100K transactions per second on mid-range hardware while
>> incurring in a minimal impact on the speed of data access in the
>> datastore. We’re currently experimenting with a prototype version that
>> can improve the performance up to ~380K TPS.
>> 
>> 
>> Omid has been publicly available as an open-source project in Github
>> under Apache License Version 2.0 since 2011 [1]. During these years,
>> it has generated certain interest in the open source community,
>> especially since the public presentation of the first version in
>> Hadoop Summit 2013 [2]. Currently the Github project has 241 Stars and
>> 93 forks. Yahoo Inc. submits this proposal to the Apache Software
>> Foundation with the aim to transfer the Omid project -including its
>> source code and documentation- to Apache in order to start the build
>> of a stable open source community around it.
>> 
>> 
>> [1] https://github.com/yahoo/omid
>> 
>> [2] Omid presentation at Hadoop Summit 2013:
>> 
>> https://www.youtube.com/watch?v=Rhdmo9pVGgU=68=PLSAiKuajRe2luyqLU464Nxz4aQe7EPBus
>> 
>> 
>> === Background ===
>> 
>> An Omid prototype was first released as an open-source project back in
>> 2011. Inspired by Google Percolator [1], it offered a lock-free
>> approach to transactions in NoSQL datastores (See [2]). However,
>> during these years, the design of Omid has evolved significantly.
>> Whilst the current open-sourced version maintains many aspects of the
>> original implementation, it is the result of a major redesign of the
>> first prototype released in 2011.
>> 
>> 
>> Omid has now a more decentralized design that does not sacrifice the
>> consistency and performance of the original version. The current
>> design also enables Omid to scale to thousands of clients executing
>> transactions concurrently on application data stored in HBase.
>> Internally, Omid still utilizes a lock-free approach to supp

Re: [VOTE] Accept Guacamole into the Apache incubator

[Greg Trasuk]

+1 (Binding) - Greg Trasuk


> On Feb 2, 2016, at 10:05 AM, Jean-Baptiste Onofré <j...@nanthrax.net> wrote:
> 
> Hi,
> 
> The Guacamole proposal was discussed couple of weeks ago.
> 
> The complete discussion thread is available here:
> 
> http://mail-archives.apache.org/mod_mbox/incubator-general/201601.mbox/%3c56a5c8c3.7070...@guac-dev.org%3E
> 
> As reminder the GuacamoleProposal is here:
> 
> https://wiki.apache.org/incubator/GuacamoleProposal
> 
> As we received only positive feedbacks in the discussion thread, we think 
> it's time to call for a vote to accept Guacamole into the Incubator.
> 
> Please cast your vote to:
> [] +1 - accept Apache Guacamole as a new incubating project
> []  0 - not sure
> [] -1 - do not accept the Apache Guacamole project (because: ...)
> 
> Thanks,
> Regards
> JB
> 
> 
> = GuacamoleProposal =
> 
> == Abstract ==
> 
> Guacamole is an enterprise-grade, protocol-agnostic, remote desktop gateway. 
> Combined with cloud hosting, Guacamole provides an excellent alternative to 
> traditional desktops. Guacamole aims to make cloud-hosted desktop access 
> preferable to traditional, local access.
> 
> == Background ==
> 
> Guacamole began in 2010 as a personal project - a means for Mike Jumper to 
> access to his own computer from work. Mike’s job at that time had a firewall 
> which blocked outbound access to everything except HTTP and HTTPS, and 
> directly circumventing the firewall (by changing the SSH server port, for 
> example) was a fireable offense. Mike needed a solution which provided remote 
> access and yet was a true web application. He found several projects 
> providing text-based terminal access, but decided that he wanted to make 
> something new and different.
> 
> The project began as a simple VNC client but grew rapidly in capability and 
> performance until it became an enterprise-grade, protocol-agnostic, remote 
> desktop gateway supporting both VNC and RDP. Support for SSH was added later, 
> followed by audio, file transfer, etc. By this point, Guacamole was fast and 
> stable enough to be used daily and in place of a traditional desktop.
> 
> Having used and developed Guacamole to its current state, and having observed 
> the general shift of the industry toward cloud computing and related 
> technologies, we now see Guacamole as the primary and only viable open source 
> solution for a future of cloud-hosted desktops.
> 
> Guacamole's purpose is twofold:
> 
> * To provide seamless and performant access to desktops over the web.
> * To provide an API which allows others, including commercial entities, to 
> integrate Guacamole's core into their own applications.
> 
> We believe that the lifestyle enabled by Guacamole should be preferable to 
> traditional, physically-anchored desktops, that the software enabling this 
> should be 100% free in every sense of the word, and that users should not be 
> limited by their current location, by the software installed on whatever 
> computer they are using at the moment, nor by how powerful/weak the hardware 
> of that computer happens to be.
> 
> Guacamole is stable and production-ready. It is in active production use by 
> several companies, including ESI, Glyptodon, HP, Nanocloud Software, as well 
> as individuals.
> 
> == Rationale ==
> 
> Due to the utility and popularity of cloud platforms, a logical extension to 
> traditional application hosting is to host complete desktops. The Guacamole 
> project is aimed at achieving this, and we believe that the best way to 
> fulfill the true potential of this project is to bring its development within 
> Apache and, by so doing, foster a larger community and higher visibility. The 
> resulting continuous improvements to its design and implementation will make 
> Guacamole the best tool for the job for a wide variety of use cases.
> 
> == Initial Goals ==
> 
> Our initial goals are to bring Guacamole into the ASF, transition internal 
> engineering processes into the open, and foster a collaborative development 
> model according to the "Apache Way."
> 
> == Current Status ==
> 
> Guacamole is production-ready and already provides a large set of features. 
> It is currently licensed under the MIT license, but will be relicensed under 
> the Apache license if accepted for incubation.
> 
> The source repositories are:
> 
> * https://github.com/glyptodon/guacamole-server
> * https://github.com/glyptodon/guacamole-client
> 
> == Meritocracy ==
> 
> We intend to radically expand the initial developer and user community by 
> running the project in accordance with the "Apache Way". Users and new 
> contributors will be tr

Re: [DISCUSS] Apache Guacamole Incubator Proposal

[Greg Trasuk]

> On Jan 25, 2016, at 4:31 PM, Marvin Humphrey <mar...@rectangular.com> wrote:
> 
> On Mon, Jan 25, 2016 at 8:47 AM, Greg Trasuk <tras...@stratuscom.com> wrote:
>> 
>> Checked into the policies - I’m not on the IPMC, so don’t qualify as a
>> Mentor, and I think the “Interested Contributors” section is more for
>> members of the existing community.
> 
> You're an ASF Member, so you can join the IPMC any time just by sending a
> request email to private@incubator. Personally, I hope you'll consider it
> because I've seen some great contributions from you from time to time.
> 

Hi Marvin:

Thank you for the kind words.  I’ve sent a note over to private@…  In the 
meantime, could you give me the required wiki karma?  ‘GregTrasuk’ is my wiki 
id.

Thanks,

Greg


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

Re: [DISCUSS] Apache Guacamole Incubator Proposal

[Greg Trasuk]

Hi there:

I don’t know if I have the time or experience to be called a Mentor (I was PMC 
chair for Apache River for a couple years), but I am interested in the project 
and would like to participate.  Not that it matters to this discussion, but my 
employer uses Guacamole and we quite like it.

Should I add myself to the Additional Interested Contributors?

Cheers,

Greg Trasuk
> On Jan 25, 2016, at 10:10 AM, Jean-Baptiste Onofré <j...@nanthrax.net> wrote:
> 
> Sure ! Go ahead ;)
> 
> Regards
> JB
> 
> On 01/25/2016 03:37 PM, Jim Jagielski wrote:
>> Thanks. I think I will add myself, if that's OK :)
>> 
>>> On Jan 25, 2016, at 9:02 AM, Jean-Baptiste Onofré <j...@nanthrax.net> wrote:
>>> 
>>> Hi Jim,
>>> 
>>> We are looking for additional mentors, so don't hesitate to add you on the 
>>> proposal.
>>> 
>>> Thanks !
>>> Regards
>>> JB
>>> 
>>> On 01/25/2016 02:54 PM, Jim Jagielski wrote:
>>>> This sounds like a neat project to round out the ASF.
>>>> 
>>>> +1. Let me know how/if I can help.
>>>> 
>>>>> On Jan 25, 2016, at 2:03 AM, Michael Jumper <mike.jum...@guac-dev.org> 
>>>>> wrote:
>>>>> 
>>>>> Hello All,
>>>>> 
>>>>> Attached to this message is a proposed new project - Apache Guacamole,
>>>>> an enterprise-grade, protocol-agnostic, remote desktop gateway. Combined
>>>>> with cloud hosting, Guacamole provides an excellent alternative to
>>>>> traditional desktops. Guacamole aims to make cloud-hosted desktop access
>>>>> preferable to traditional, local access.
>>>>> 
>>>>> The text of the proposal is included below. Additionally, the proposal
>>>>> is in draft form on the wiki where we will make any required changes:
>>>>> 
>>>>> https://wiki.apache.org/incubator/GuacamoleProposal
>>>>> 
>>>>> We look forward to your feedback and input.
>>>>> 
>>>>> Thanks,
>>>>> 
>>>>> - Mike
>>>>> 
>>>>> 
>>>>> = GuacamoleProposal =
>>>>> 
>>>>> == Abstract ==
>>>>> 
>>>>> Guacamole is an enterprise-grade, protocol-agnostic, remote desktop
>>>>> gateway. Combined with cloud hosting, Guacamole provides an excellent
>>>>> alternative to traditional desktops. Guacamole aims to make cloud-hosted
>>>>> desktop access preferable to traditional, local access.
>>>>> 
>>>>> == Background ==
>>>>> 
>>>>> Guacamole began in 2010 as a personal project - a means for Mike Jumper
>>>>> to access to his own computer from work. Mike’s job at that time had a
>>>>> firewall which blocked outbound access to everything except HTTP and
>>>>> HTTPS, and directly circumventing the firewall (by changing the SSH
>>>>> server port, for example) was a fireable offense. Mike needed a solution
>>>>> which provided remote access and yet was a true web application. He
>>>>> found several projects providing text-based terminal access, but decided
>>>>> that he wanted to make something new and different.
>>>>> 
>>>>> The project began as a simple VNC client but grew rapidly in capability
>>>>> and performance until it became an enterprise-grade, protocol-agnostic,
>>>>> remote desktop gateway supporting both VNC and RDP. Support for SSH was
>>>>> added later, followed by audio, file transfer, etc. By this point,
>>>>> Guacamole was fast and stable enough to be used daily and in place of a
>>>>> traditional desktop.
>>>>> 
>>>>> Having used and developed Guacamole to its current state, and having
>>>>> observed the general shift of the industry toward cloud computing and
>>>>> related technologies, we now see Guacamole as the primary and only
>>>>> viable open source solution for a future of cloud-hosted desktops.
>>>>> 
>>>>> Guacamole's purpose is twofold:
>>>>> 
>>>>> * To provide seamless and performant access to desktops over the web.
>>>>> * To provide an API which allows others, including commercial entities,
>>>>> to integrate Guacamole's core into their own applications.
>>>>> 
>>>>> We believe that the lifestyl

Re: [DISCUSS] Apache Guacamole Incubator Proposal

[Greg Trasuk]

Checked into the policies - I’m not on the IPMC, so don’t qualify as a Mentor, 
and I think the “Interested Contributors” section is more for members of the 
existing community.  So I will look forward to the project entering the 
incubator, and then join the mailing lists and see if I can help out.

Cheers,

Greg Trasuk

> On Jan 25, 2016, at 10:30 AM, Jean-Baptiste Onofré <j...@nanthrax.net> wrote:
> 
> Hi Greg,
> 
> it's up to you: you can add yourself as mentor or interested contributor.
> 
> Regards
> JB
> 
> On 01/25/2016 04:29 PM, Greg Trasuk wrote:
>> Hi there:
>> 
>> I don’t know if I have the time or experience to be called a Mentor (I was 
>> PMC chair for Apache River for a couple years), but I am interested in the 
>> project and would like to participate.  Not that it matters to this 
>> discussion, but my employer uses Guacamole and we quite like it.
>> 
>> Should I add myself to the Additional Interested Contributors?
>> 
>> Cheers,
>> 
>> Greg Trasuk
>>> On Jan 25, 2016, at 10:10 AM, Jean-Baptiste Onofré <j...@nanthrax.net> 
>>> wrote:
>>> 
>>> Sure ! Go ahead ;)
>>> 
>>> Regards
>>> JB
>>> 
>>> On 01/25/2016 03:37 PM, Jim Jagielski wrote:
>>>> Thanks. I think I will add myself, if that's OK :)
>>>> 
>>>>> On Jan 25, 2016, at 9:02 AM, Jean-Baptiste Onofré <j...@nanthrax.net> 
>>>>> wrote:
>>>>> 
>>>>> Hi Jim,
>>>>> 
>>>>> We are looking for additional mentors, so don't hesitate to add you on 
>>>>> the proposal.
>>>>> 
>>>>> Thanks !
>>>>> Regards
>>>>> JB
>>>>> 
>>>>> On 01/25/2016 02:54 PM, Jim Jagielski wrote:
>>>>>> This sounds like a neat project to round out the ASF.
>>>>>> 
>>>>>> +1. Let me know how/if I can help.
>>>>>> 
>>>>>>> On Jan 25, 2016, at 2:03 AM, Michael Jumper <mike.jum...@guac-dev.org> 
>>>>>>> wrote:
>>>>>>> 
>>>>>>> Hello All,
>>>>>>> 
>>>>>>> Attached to this message is a proposed new project - Apache Guacamole,
>>>>>>> an enterprise-grade, protocol-agnostic, remote desktop gateway. Combined
>>>>>>> with cloud hosting, Guacamole provides an excellent alternative to
>>>>>>> traditional desktops. Guacamole aims to make cloud-hosted desktop access
>>>>>>> preferable to traditional, local access.
>>>>>>> 
>>>>>>> The text of the proposal is included below. Additionally, the proposal
>>>>>>> is in draft form on the wiki where we will make any required changes:
>>>>>>> 
>>>>>>> https://wiki.apache.org/incubator/GuacamoleProposal
>>>>>>> 
>>>>>>> We look forward to your feedback and input.
>>>>>>> 
>>>>>>> Thanks,
>>>>>>> 
>>>>>>> - Mike
>>>>>>> 
>>>>>>> 
>>>>>>> = GuacamoleProposal =
>>>>>>> 
>>>>>>> == Abstract ==
>>>>>>> 
>>>>>>> Guacamole is an enterprise-grade, protocol-agnostic, remote desktop
>>>>>>> gateway. Combined with cloud hosting, Guacamole provides an excellent
>>>>>>> alternative to traditional desktops. Guacamole aims to make cloud-hosted
>>>>>>> desktop access preferable to traditional, local access.
>>>>>>> 
>>>>>>> == Background ==
>>>>>>> 
>>>>>>> Guacamole began in 2010 as a personal project - a means for Mike Jumper
>>>>>>> to access to his own computer from work. Mike’s job at that time had a
>>>>>>> firewall which blocked outbound access to everything except HTTP and
>>>>>>> HTTPS, and directly circumventing the firewall (by changing the SSH
>>>>>>> server port, for example) was a fireable offense. Mike needed a solution
>>>>>>> which provided remote access and yet was a true web application. He
>>>>>>> found several projects providing text-based terminal access, but decided
>>>>>>> that he wanted to make something new and different.
>>>>>>> 
>>>>&g

Re: [DISCUSS] Mentor neutrality policy

[Greg Trasuk]

Hi Daniel:

Discussion intertwined below…

Cheers,

Greg Trasuk

> On Oct 9, 2015, at 11:07 AM, Daniel Gruno <humbed...@apache.org> wrote:
> 
> Hi Incubator folks,
> 
> I would like to propose we adopt a mentor neutrality policy for
> incubating podlings:
> 
> - A mentor must not be financially tied to the project or its incubation
> status.

This requirement would seem to be against the idea that we participate in 
Apache as individuals, rather than as employees/representatives of some 
company.  If there is a case where a member appears to be representing their 
company’s interest rather than the Foundation’s interest, shouldn’t that be 
dealt with in itself?

> - A mentor must not have a vested interest in incubating, graduating or
> dismantling a podling that goes beyond the general Apache mission

Could you elaborate on “beyond the general Apache mission”?  You probably have 
some concrete examples in mind, and I’m sure we don’t want to start dissecting 
those examples rather than your overall suggestion, but personally, I’m not 
sure what you mean.

> - A mentor must not be affiliated with the entity granting the code
> (company or original project community)
> 

That suggestion would seem to preclude a knowledgable insider who happens to be 
an Apache member from helping out with incubating a project.  Which seems kind 
of inefficient.

> Furthermore, I would like to see this extended to votes on graduating or
> retiring podlings, so that only people with no organizational (aparty
> from the ASF) or financial ties to the project (or the companies behind
> it) can cast a binding vote on graduation or retirement.
> 
> This would essentially mean:
> 
> - If you work for a company (or are hired as consultant/advisor) that is
> entering a project into incubation, you cannot mentor it nor vote
> for/against its incubation, graduation or retirement.
> - If you are a in the original community behind the project, you cannot
> mentor it nor vote for/against it.
> 
> I believe this would create a neutral mentorship whose sole mission is
> to guide podlings with the interests of the ASF in mind.
> 
> 
> Please do discuss this. If there is (mostly) positive feedback, I would
> like to, at some point, have a vote on including this in the Incubator
> policy. I realize this would cut down on the number of potential
> mentors, and I would ask that more people step up to the challenge of
> mentoring if adopted.
> 
> With regards,
> Daniel
> 
> -
> 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] Communicating intent around non-release, downstream integration binary artifacts

[Greg Trasuk]

 On Jun 23, 2015, at 6:11 AM, Jochen Theodorou blackd...@gmx.org wrote:
 
 Am 23.06.2015 07:16, schrieb Marvin Humphrey:
 [...]
 How am I supposed to invite all the downstream developers of the
 world to start integrating with my awesome feature FOO before it
 gets formally released when our policy makes statement like:
 If the general public is being instructed to download a package,
 then that package has been released.
 
 Rather than invite them in before you make a release, why not release
 first and then invite them in?
 
 Are we really suggesting that I can not present at conference, tweet
 and otherwise promote the awesomeness of my project based on
 'what's coming'?
 
 Why not release before presenting, tweeting, or promoting?
 
 I am not Roman, but my interpretation in combination with the above would be, 
 that if releases require 72h+ and you cannot just upload it somewhere and say 
 it is no release, that it takes ages. Something like continuous delivery for 
 example looks for me impossible with apache.

I see statements like this frequently, and I don’t understand them.  There 
seems to be an assumption that during a 72-hour voting period, all work on a 
project has to grind to a halt, and everyone needs to focus on the release 
process.  That certainly isn’t true.  There’s no reason you can’t have a 
release process working on v3.62 (or whatever) while work proceeds on v3.63.  
Releases should be pipelined.  Move the release candidate over to the release 
candidate repository for final QA and signoff, then carry on developing in the 
development repository.

Yes, a 72-hour vote process imposes additional overall latency on the process, 
but surely the requirement to have at least three duly-empowered humans sign 
off on the release isn’t that onerous!

Greg Trasuk
 
 snip
 -- 
 Jochen blackdrag Theodorou
 blog: http://blackdragsview.blogspot.com/
 
 
 -
 To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
 For additional commands, e-mail: general-h...@incubator.apache.org
 

Re: Question about jar files in svn.

[Greg Trasuk]

Thanks everyone for the input.  To summarize, it appears that the consensus 
argument is:

- Jar files are not prohibited by policy in project repositories (svn), 
although they may not make a lot of sense.
- Source distributions must not distribute executable code in binary form.  
i.e. Don’t ship dependency jars in the source archive.  However it may be 
acceptable to include things like jar files that are processed during testing 
(sample archives, for instance).
- The project repositories are not generally considered “distributions”, but we 
need to be a little careful to avoid users’ confusion on this point.

And just to be clear, I take this as valuable input from from the experts at 
Incubator, not a ruling.  Obviously, the River PMC makes decisions for River, 
and Incubator bears no responsibility for anything we might get wrong.

Cheers,

Greg Trasuk
PMC Chair, Apache River.


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

Question about jar files in svn.

[Greg Trasuk]

Hi all:

We’re having a discussion over in d...@river.apache.org that was triggered by 
the recent discussion here about the Spark podling release.  In particular,
http://mail-archives.apache.org/mod_mbox/incubator-general/201312.mbox/%3CCAAS6%3D7iQSKTgNdO-0Qyd3T9--%2B%2BHQFEmhJi7CHoByqvQvp9_bg%40mail.gmail.com%3E
has caused me to start asking questions…

Since Incubator is a good repository of Apache’s institutional knowledge, I 
wonder if someone could point me towards resources that clarify the policy on 
dependency jars in releases and in the svn repository.  If I understand it 
correctly, there shouldn’t (perhaps even must not be) any jar files checked 
into subversion or included in a source release.  Is that correct?  To be more 
specific, there doesn’t seem to be any doubt that jars shouldn’t be included in 
source release packages, but would it be fair to say that they should also not 
be in the svn?

Thanks in advance,

Greg Trasuk
PMC Chair, Apache River.

Re: [DISCUSS] Usergrid BaaS Stack for Apache Incubator

[Greg Trasuk]

If a podling steadfastly refused to add any other committers, then I think its 
mentors would try to explain why that's a bad thing, and if that behaviour 
continued, then the incubator would vote against graduating it.

On 2013-09-25, at 2:12 AM, Deepal jayasinghe deep...@gmail.com wrote:

 Apache is community over code, but here is more like code over community.
 
 As a community we should be able to tolerate the conflicts of interest. 
 Once the project is incubated in Apache, the project belongs to Apache
 and direction and future of the project should be decided by the
 community, not just the people who bring the project.

It's a community that brings the project.  That community doesn't cease to 
exist just because it is subsumed into Apache.  A TLP's community gets to 
decide who to accept as a new community member, based on merit (with the 
board's oversight to make sure it isn't dominated by a single commercial 
entity).  Why should an incubating project not have the same privilege?  In 
fact, once a project is accepted for incubation, it does have the privilege of 
choosing its own committers, the same as a TLP does (given the oversight of the 
IPMC).  We're talking about a glitch in the system where an existing community 
can be destroyed by volunteering to come to Apache, during the short period 
between proposal of a podling and its acceptance, leaving a code dump.  That 
doesn't seem right.  If we want to encourage a community, then we have to 
respect a community.  It's not that hard, just --ask-- to be a committer on a 
podling rather than just editing the wiki.  Let the creator of the document 
edit it.

 I do not see that
 here. If this would have been a vote, I might -1.
 
 Deepal
 Are you guys wearing Apache hats or WS02 hats?  If you're wearing Apache 
 hats, then I'd expect a bit less fealty to your CEO's request and a little 
 more OK, I see your point, but I'm really excited about the project, here's 
 what I'd like to do on the project, do you mind adding me as an initial 
 committer?.  Granted that email doesn't convey tone-of-voice very well, but 
 the messages from WSO2 employees sound kind of snarky.
 
 Now, on the general question of piling-on I have to agree with Roy.  The 
 incubator always encourages people to build a community, and then bring that 
 community to Apache.  If an incubating project's existing community is 
 hugely diluted by Apache folks at the incubator proposal stage, then it 
 becomes a code dump, which we try to discourage.  If we care about 
 community over code, then surely we have to show some respect for the 
 community that comes to Apache.  Common courtesy suggest that you offer your 
 help to that community, not impose your help on it.
 
 Cheers,
 
 Greg.
 
 On 2013-09-25, at 12:52 AM, Nirmal Fernando nirmal070...@gmail.com wrote:
 
 hmm.. it appears to me that though you pushed the project into ASF, your
 intentions were not pure and you don't want any competitor of Apigee to be
 joined to the project (by going on your words, it is quite natural to think
 so.) even if they showed their genuine interest on helping the project out,
 with their know-how on related areas.
 
 As Sanjiva requested, I'm gonna hereby withdraw my humble request to be
 added as a committer.
 
 
 On Wed, Sep 25, 2013 at 9:21 AM, Niranjan Karunanandham 
 niranjan.k...@gmail.com wrote:
 
 I was actually looking forward to contributing for this project where ever
 possible but I think people have misunderstood our intentions. As requested
 by my CEO, I would like to withdraw my committer request.
 
 
 On Wed, Sep 25, 2013 at 7:36 AM, Dulitha Wijewantha dulit...@gmail.com
 wrote:
 +1 for the Dave Fisher's example. I believe most of the people have
 misunderstood our intentions. We were offering to help the project to
 grow
 and graduate faster. I am withdrawing my committer request as our CEO
 asked
 too. But honestly speaking - if you guys are *scared* of the *community*
 and what the *community* is - I don't believe you shouldn't mention the
 below words in the proposal -
 
 *Although we are aware of the strength of the Apache brand, we are
 primarily
 *
 *interested in the transforming power of the Apache Way to help guide*
 *Usergrid towards a more diversified and meritocratic community*
 
 
 In my humble opinion - the above line should not be a part of the
 proposal
 since the Apache way has always been to gather a community around the
 proposal who have shown interest towards the idea.
 
 Cheers
 
 
 On Wed, Sep 25, 2013 at 5:50 AM, Dave Fisher dave2w...@comcast.net
 wrote:
 
 On Sep 24, 2013, at 3:19 PM, Bertrand Delacretaz wrote:
 
 On Tue, Sep 24, 2013 at 10:23 PM, Alex Karasulu 
 akaras...@apache.org
 wrote:
 ...So fill the bus with anybody who volunteers? That does not sound
 meritocratic
 It's been like that for a while in the Incubator, people who sign up
 as initial committers for a podling usually don't have to demonstrate
 any merit.
 
 When the time comes 

Re: [DISCUSS] Usergrid BaaS Stack for Apache Incubator

[Greg Trasuk]

Are you guys wearing Apache hats or WS02 hats?  If you're wearing Apache hats, 
then I'd expect a bit less fealty to your CEO's request and a little more OK, 
I see your point, but I'm really excited about the project, here's what I'd 
like to do on the project, do you mind adding me as an initial committer?.  
Granted that email doesn't convey tone-of-voice very well, but the messages 
from WSO2 employees sound kind of snarky.

Now, on the general question of piling-on I have to agree with Roy.  The 
incubator always encourages people to build a community, and then bring that 
community to Apache.  If an incubating project's existing community is hugely 
diluted by Apache folks at the incubator proposal stage, then it becomes a 
code dump, which we try to discourage.  If we care about community over 
code, then surely we have to show some respect for the community that comes to 
Apache.  Common courtesy suggest that you offer your help to that community, 
not impose your help on it.

Cheers,

Greg.

On 2013-09-25, at 12:52 AM, Nirmal Fernando nirmal070...@gmail.com wrote:

 hmm.. it appears to me that though you pushed the project into ASF, your
 intentions were not pure and you don't want any competitor of Apigee to be
 joined to the project (by going on your words, it is quite natural to think
 so.) even if they showed their genuine interest on helping the project out,
 with their know-how on related areas.
 
 As Sanjiva requested, I'm gonna hereby withdraw my humble request to be
 added as a committer.
 
 
 On Wed, Sep 25, 2013 at 9:21 AM, Niranjan Karunanandham 
 niranjan.k...@gmail.com wrote:
 
 I was actually looking forward to contributing for this project where ever
 possible but I think people have misunderstood our intentions. As requested
 by my CEO, I would like to withdraw my committer request.
 
 
 On Wed, Sep 25, 2013 at 7:36 AM, Dulitha Wijewantha dulit...@gmail.com
 wrote:
 
 +1 for the Dave Fisher's example. I believe most of the people have
 misunderstood our intentions. We were offering to help the project to
 grow
 and graduate faster. I am withdrawing my committer request as our CEO
 asked
 too. But honestly speaking - if you guys are *scared* of the *community*
 and what the *community* is - I don't believe you shouldn't mention the
 below words in the proposal -
 
 *Although we are aware of the strength of the Apache brand, we are
 primarily
 *
 *interested in the transforming power of the Apache Way to help guide*
 *Usergrid towards a more diversified and meritocratic community*
 
 
 In my humble opinion - the above line should not be a part of the
 proposal
 since the Apache way has always been to gather a community around the
 proposal who have shown interest towards the idea.
 
 Cheers
 
 
 On Wed, Sep 25, 2013 at 5:50 AM, Dave Fisher dave2w...@comcast.net
 wrote:
 
 
 On Sep 24, 2013, at 3:19 PM, Bertrand Delacretaz wrote:
 
 On Tue, Sep 24, 2013 at 10:23 PM, Alex Karasulu 
 akaras...@apache.org
 wrote:
 ...So fill the bus with anybody who volunteers? That does not sound
 meritocratic
 
 It's been like that for a while in the Incubator, people who sign up
 as initial committers for a podling usually don't have to demonstrate
 any merit.
 
 When the time comes to graduate the podling, it's perfectly fine to
 ask it to prune its list of committers and PMC members in order to
 keep only people who have demonstrated their committment during
 incubation.
 
 When OpenOffice.org was brought to the Incubator there was open
 enrollment. There were over 70 Initial Committers. I had no experience
 with
 OpenOffice. I did have an understanding of the ASF. I could help and I
 did.
 It was tough to have such a large list many were OpenOffice.org people
 who
 never really adapted to the ASF. We had all these people on the PPMC.
 When
 graduation time came we managed to reduce the PMC to 25. We left the
 Initial Committers connected. It hasn't really been a problem.
 
 My point is that without the Initial Committer free for all I think
 that
 AOO would not be as successful as now.
 
 Regards,
 Dave
 -
 To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
 For additional commands, e-mail: general-h...@incubator.apache.org
 
 
 
 
 --
 *Dulitha R. Wijewantha** Software Engineer*
 Tel: 94112793140 | Mobile: 94112793140
 dulit...@gmail.com | http://dulithawijewantha.com
 
 
 
 
 --
 *Niranjan Karunanandham*
 Senior Software Engineer
 M: +94 777 749 661 http:///
 
 
 
 
 -- 
 Best Regards,
 Nirmal
 
 C.S.Nirmal J. Fernando
 Senior Software Engineer,
 WSO2 Inc.
 
 Blog: http://nirmalfdo.blogspot.com/


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

Re: OpenOffice.org Apache Incubator Proposal

[Greg Trasuk]

We're working on it (River, that is)!

Cheers,

Greg.

On Wed, 2011-06-01 at 12:49, Jukka Zitting wrote:
 Hi,
 
 On Wed, Jun 1, 2011 at 6:28 PM, Jim Jagielski j...@jagunet.com wrote:
  On Jun 1, 2011, at 12:21 PM, Ross Gardler wrote:
  There is a statement that Oracle will assist in the transition and 
  migration
  from OpenOffice.org., I am probably reading too much into it, but why is
  there not a statement that Oracle intend to continue development once
  the transition is complete?
 
  Most likely because they don't intend to.
 
 This should be clearly spelled out if it's the intention. I'd also
 like to see how the community plans to cope with such a major loss of
 experience and know-how.
 
 A related example is the Apache River podling that nearly died when
 the then Sun employees were pulled out of the project, which left next
 to nobody to look after the codebase. Only with major efforts by
 mentors and new contributors was the project salvaged, but even now
 it's only a shadow of what Jini used to be. I'd hate to see the same
 happen to OpenOffice.
 
 BR,
 
 Jukka Zitting
 
 -
 To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
 For additional commands, e-mail: general-h...@incubator.apache.org
-- 
Greg Trasuk, President
StratusCom Manufacturing Systems Inc. - We use information technology to
solve business problems on your plant floor.
http://stratuscom.com


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