Re: ARIA TOSCA Project Proposal

[dsh]

Hi,

just a note on the ARAI acronym if used as such. That acronym usually
refers to: https://developer.mozilla.org/en-US/docs/Web/Accessibility/ARIA
aka https://www.w3.org/TR/wai-aria/ .

Cheers
Daniel

On Thu, Aug 4, 2016 at 4:47 PM, Arthur Berezin 
wrote:

> Hi All
>
>
> I would like to propose ARIA TOSCA to be an Apache Incubator Project.
>
> ARIA TOSCA project offers an easily consumable Software Development
> Kit(SDK) and a Command Line Interface(CLI) to implement TOSCA(Topology and
> Orchestration Specification of Cloud Applications) based solutions which
> will help in driving adoption of TOSCA, and help in market consolidation
> around TOSCA based Orchestration.
>
> One of the key attributes of the TOSCA specification by OASIS is that it is
> a vendor neutral and technology agnostic specification, allowing to
> describe applications and then to orchestrate them using various
> technologies of choice, such as Amazon AWS, Google GCP, OpenStack, VMware,
> Puppet, Ansible Chef, etc’. The reality is such that TOSCA is a complex
> specification,making software vendors trying to implement the specification
> make implementation decisions, ending up with different and incompatible
> implementations, creating even more market segmentation instead of
> consolidating around a single standard for orchestration.
>
> ARIA a vendor neutral and technology agnostic(via plugins mechanism)
> reference implementation of the TOSCA specification. It is an open source
> python library that helps orchestrators and management tools in developing
> TOSCA enabled solutions. ARIA aims to become the main reference
> implementation of the OASIS TOSCA(Topology and Orchestration Specification
> for Cloud Applications) specification for orchestrating cloud applications.
>
> ARIA TOSCA targets NFV Orchestration and Hybrid/Multi Cloud orchestration
> as main use-cases it solves.
>
> ARIA can be executed via CLI to orchestrate application templates,
> additionally it allows embedding its python library for creating TOSCA
> compatible services, and includes rich set of plugins for Iaas
> orchestration, such as Amazon AWS, Google GCP, OpenStack and VMWare; It
> Includes plugins for Container orchestration, with Docker and Kubernetes
> plugins, configuration management tools(Puppet,Chef, Ansible) and a rich
> API that allows to create plugins for any new technology.
>
> ARIA also serves as a codebase that allows to test the TOSCA specification,
> and experiment with new approaches of modeling and orchestration of
> applications, providing feedback and real world use cases OASIS to further
> refine and advance the standard specification.
>
> Please find the full project proposal here:
> https://wiki.apache.org/incubator/AriaProposal
>
> *Champion:*
> Suneel Marthi
>
> *Nominated Mentors*
> Jakob Homan
> John D. Ament
> Suneel Marthi
>
>
>
>
> Thank You,
> Arthur Berezin
>

Re: Single person developed project

[dsh]

Hi Amareshwari,

please have a look at the Apache Incubator Proposal Guide [1]. Under the
section "Community" [2] you'll find the following statement:

"Apache is interested only in communities."

Does this answer your question?

[1] http://incubator.apache.org/guides/proposal.html
[2] http://incubator.apache.org/guides/proposal.html#template-community

Cheers
Daniel

On Mon, Feb 15, 2016 at 9:47 AM, Amareshwari Sriramdasu <
amareshw...@apache.org> wrote:

> Hi all,
>
> Wanted to know if a single person developed project can get incubated in
> Apache. Any doc links would be helpful as well.
>
> Thanks
> Amareshwari
>

Re: [DISCUSS] Geode Incubation proposal

[dsh]

Just as a quick remark. Geode might be a trademark owned by AMD:
http://en.wikipedia.org/wiki/Geode_%28processor%29

Cheers
Daniel

On Sun, Apr 12, 2015 at 8:46 PM, Roman Shaposhnik r...@apache.org wrote:

 Hi!

 I would like to open up a discussion thread on
 the proposals for the core of Pivotal's GemFire
 to join ASF as an incubating project under the
 name Geode.

 The proposal wiki is available here:
https://wiki.apache.org/incubator/GeodeProposal
 and the text of the proposal is attached to the
 bottom of this email as well.

 Given the timing of ApacheCON, we would love to
 chat with anybody interested in giving us feedback.
 That said, of course, the bulk of the discussion is
 expected to happen on this thread.

 Thanks for your time and consideration!
 Roman (Geode proposal champion and a nominated mentor).

 == Abstract ==
 Geode is a data management platform that provides real-time,
 consistent access to data-intensive applications throughout widely
 distributed cloud architectures.

 Geode pools memory (along with CPU, network and optionally local disk)
 across multiple processes to manage application objects and behavior.
 It uses dynamic replication and data partitioning techniques for high
 availability, improved performance, scalability, and fault tolerance.
 Geode is both a distributed data container and an in-memory data
 management system providing reliable asynchronous event notifications
 and guaranteed message delivery.

 == Proposal ==
 The goal of this proposal is to bring the core of Pivotal Software,
 Inc.’s (Pivotal) Pivotal GemFireⓇ codebase into the Apache Software
 Foundation (ASF) in order to build a vibrant, diverse and
 self-governed open source community around the technology. Pivotal
 will continue to market and sell Pivotal GemFire based on Geode. Geode
 and Pivotal GemFire will be managed separately. This proposal covers
 the Geode source code (mainly written in Java), Geode documentation
 and other materials currently available on GitHub.

 While Geode is our primary choice for a name of the project, in order
 to facilitate PODLINGNAMESEARCH we have come up with two alternatives:
   * Haptic
   * FIG

 == Background ==
 GemFire is an extremely mature and robust product that can trace its
 legacy all the way back to one of the first Object Databases for
 Smalltalk: GemStone. The GemFire code base has been maintained by the
 same group of engineers as a closed source project. Because of that,
 even though the engineers behind GemFire are the de-facto knowledge
 leaders for distributed in-memory management, they have had little
 exposure to the open source governance process.The original
 company developing GemStone and GemFire was acquired by VMWare in 2010
 and later spun off as part of Pivotal Software in 2013. Today GemFire
 is used by over 600 enterprise customers. An example deployment
 includes China National Railways that uses Pivotal GemFire to run
 railway ticketing for the entire country of China with a 10 node
 cluster that manages 2 gigabytes hot data in memory, and 10 backup
 nodes for high availability and elastic scale.

 == Rationale ==
 Modern-day data management architectures require a robust in-memory
 data grid solution to handle a variety of use cases, ranging from
 enterprise-wide caching to real-time transactional applications at
 scale. In addition, as memory size and network bandwidth growth
 continues to outpace those of disk, the importance of managing large
 pools of RAM at scale increases. It is essential to innovate at the
 same pace and Pivotal strongly believes that in the Big Data space,
 this can be optimally achieved through a vibrant, diverse,
 self-governed community collectively innovating around a single
 codebase while at the same time cross-pollinating with various other
 data management communities. ASF is the ideal place to meet these
 ambitious goals.

 == Initial Goals ==
 Our initial goals are to bring Geode into the ASF, transition internal
 engineering processes into the open, and foster a collaborative
 development model according to the Apache Way. Pivotal plans to
 develop new functionality in an open, community-driven way. To get
 there, the existing internal build, test and release processes will be
 refactored to support open development.

 == Current Status ==
 Currently, the project code base is licensed for evaluation purposes
 and is available for download from Pivotal.io
 (https://network.pivotal.io/products/project-geode). The documentation
 and wiki pages are available as public GitHub repositories under
 Project Geode organization on GitHub
 (https://github.com/project-geode). Although Pivotal GemFire was
 developed as a proprietary, closed-source product, the internal
 engineering practices adopted by the development team lend themselves
 well to an open, collaborative and meritocratic environment.

 The Pivotal GemFire team has always focused on building a robust end
 user community of paying and 

Re: [VOTE] Apache Tamaya for Incubation

[dsh]

 [ X ] +1 accept Tamaya in the Incubator
 [ ] ±0
 [ ] -1 because...

Cheers
Daniel S. Haischt

On Thu, Nov 13, 2014 at 3:49 PM, David Blevins david.blev...@gmail.com
wrote:

 +1

 On Thu, Nov 13, 2014 at 9:56 AM, Gerhard Petracek gpetra...@apache.org
 wrote:

  +1
 
  regards,
  gerhard
 
 
 
  2014-11-13 9:16 GMT+01:00 Mark Struberg strub...@yahoo.de:
 
   +1 (binding)
  
   LieGrue,
   strub
  
  
  
  
On Tuesday, 11 November 2014, 12:20, John D. Ament 
   john.d.am...@gmail.com wrote:
 Anatole,
   
Actually the name suitability is a long, drawn out process.  i
 started
  it
here just now for the project:
https://issues.apache.org/jira/browse/PODLINGNAMESEARCH-60
You can read the details here:
   http://incubator.apache.org/guides/names.html
   
  
   -
   To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
   For additional commands, e-mail: general-h...@incubator.apache.org
  
  
 

Re: [VOTE] Graduate Apache Celix as Top Level Project

[dsh]

[ X ] +1 Graduate the Apache Celix podling from Apache Incubator as a TLP
[ ] +0 Indifferent to the graduation status of Apache Celix podling
[ ] -1 Reject graduation of Apache Celix podling from Apache Incubator
because ...

Cheers
Daniel


On Thu, Jun 19, 2014 at 4:26 PM, Alexander Broekhuis a.broekh...@gmail.com
wrote:

 Hi All,

 Since entering Incubation in November 2010, the Celix podling been working
 towards graduation. The community has grown, releases have been made and
 new committers have been added.
 Over the last couple of months all items on the checklist for graduation
 have been ticked of [1].
 This resulted in a, positive, vote on te dev list of Celix itself [2]. Also
 the namesearch has been performed [3].
 As far as we can tell the project status is up to date [4], and Celix is
 ready for graduation.

 After the discussion in the [DISCUSS] thread on [5], some changes were made
 to the PMC list to have enough members for binding votes etc.

 Now I'd like to ask the IPMC to vote for the graduation of Celix.

 Please cast your vote:

 [ ] +1 Graduate the Apache Celix podling from Apache Incubator as a TLP
 [ ] +0 Indifferent to the graduation status of Apache Celix podling
 [ ] -1 Reject graduation of Apache Celix podling from Apache Incubator
 because ...

 The vote will be open for 72 hours, after which I will tally and post the
 results.

 Thanks in advance,

 Alexander Broekhuis
 (PPMC member of Apache Celix)

 [1]: http://incubator.apache.org/guides/graduation.html#checklist
 [2]: http://markmail.org/thread/7y3a2l6qqm56cvud
 [3]: https://issues.apache.org/jira/browse/PODLINGNAMESEARCH-50
 [4]: http://incubator.apache.org/projects/celix.html
 [5]: http://markmail.org/thread/7udzxyd7ey2nyqsr

 
 X. Establish the Apache Celix 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 a native implementation of the OSGi
specification.

NOW, THEREFORE, BE IT RESOLVED, that a Project Management
Committee (PMC), to be known as the Apache Celix Project,
be and hereby is established pursuant to Bylaws of the
Foundation; and be it further

RESOLVED, that the Apache Celix Project be and hereby is
responsible for the creation and maintenance of software
related to a native implementation of the OSGi
specification;
and be it further

RESOLVED, that the office of Vice President, Apache Celix 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 Celix Project, and to have primary responsibility
for management of the projects within the scope of
responsibility of the Apache Celix 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 Celix Project:

  * Alexander Broekhuis   abroekh...@apache.org
  * Pepijn Noltes  pnol...@apache.org
  * Bjoern Petribpe...@apache.org
  * Erik Jansman ejans...@apache.org
  * Marcel Offermans   ma...@apache.org
  * Roman Shaposhnik r...@apache.org
  * Konstantin Boudnik c...@apache.org


NOW, THEREFORE, BE IT FURTHER RESOLVED, that Alexander Broekhuis
be appointed to the office of Vice President, Apache Celix, 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 Celix 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 Celix Project; and be it further

RESOLVED, that the Apache Celix Project be and hereby
is tasked with the migration and rationalization of the Apache
Incubator Celix podling; and be it further

RESOLVED, that all responsibilities pertaining to the Apache
Incubator Celix podling encumbered upon the Apache Incubator
Project are hereafter discharged.

 --
 Met vriendelijke groet,

 Alexander Broekhuis

Re: [VOTE] fleece as new incubator project

[dsh]

 [ X ] +1 accept Fleece in the Incubator
 [ ] +/-0
 [ ] -1 because...

Cheers
Daniel


On Fri, Jun 6, 2014 at 9:31 AM, Romain Manni-Bucau rmannibu...@gmail.com
wrote:

 Following the discussion earlier, I'm calling a vote to accept Fleece as a
 new Incubator project.

  The proposal draft is available at:
 https://wiki.apache.org/incubator/Fleece, and is also included  below.

  Vote is open for at least 72h and closes at the earliest on 09 June 09:30
  GMT.

  [ ] +1 accept Fleece in the Incubator
  [ ] +/-0
  [ ] -1 because...

  Here's my +1.

 
 Apache Fleece Proposal

 Abstract

 Apache Fleece is an implementation of JSR-353 (JavaTM API for JSON
 Processing).

 Proposal

 Apache Fleece will consist of a number of modules. Mainly an implementation
 of JSR-353 but also a set of usefule modules to help with the usage of
 JSR-353 (surely a mapping module and a jaxrs provider module).

 Background

 JSon being more and more important JavaEE 7 specified an API to read and
 create JSon objects/arrays.

 Apache Fleece builds on this specification a potential base to do Json at
 Apache (hopefully it will be integrated with CXF for instance).

 Rationale

 There is not yet a Json related project at Apache but a lot of projects
 rely on some specific implementions (jettison, jackson, others...).
 Proposing a default would be great. The other point is a set of Apache
 projects related to JavaEE (CXF, TomEE, Geronimo, Axis2...) will need an
 implementation. Having one built at Apache is a really nice to have.

 Initial Goals

 The initial goal of the Apache Fleece project is to get a JSR-353 compliant
 implementation

 Current Status

 Initial codebase was developped on github but designed to be integrated in
 Apache.

 Meritocracy

 Initial community will be mainly composed of already Apache committers so
 meritocracy is already something well known.

 Community

 Initial community will be composed of TomEE community for sure, hopefully
 CXF and potentially all JSon users of Apache.

 Initial committers

- Romain Manni-Bucau (individual, ASF)
- Jean-Louis Monteiro (individual, ASF)
- Mark Struberg (individual, ASF member)
- Gerhard Petracek (individual, ASF member)
- David Blevins (individual, ASF member)
- Sagara Gunathunga (ASF)

 Alignment

 Several Apache project will need a JSR-353 implementation. Having a project
 which can be shared is better than having a sub project of a particular
 project. Moreover this project makes sense alone since users can
 integrate it without any other dependencies and use it to read/generate
 Json in their project so it makes sense to create a dedicated project.

 Known Risks

 Main risk is to get a not so active project since the specification is not
 that big.

 Documentation

 There is no documentation to import today but it will be created using
 standard ASF tools (ASF CMS mainly).

 Initial Source

 Initial sources are on this git repository:
 https://github.com/rmannibucau/json-impl.git

 Source and IP Submission Plan

 Initial sources are under Apache license v2.

 Side note: it was really developed to be integrated in this project
 (without waiting it to be created).

 Required Resources

 Mailing Lists

-

- d...@fleece.incubator.apache.org - comm...@fleece.incubator.apache.org
- priv...@fleece.incubator.apache.org

 Version Control

 It is proposed that the source code for the Apache Fleece project be hosted
 in the Apache Git repository, under the following directory:

- git.apache.org/incubator-fleece.git

 Issue Tracking

 The following JIRA project would be required to track issues for the Apache
 Fleece project:

- FLEECE

 Initial Committers

- Romain Manni-Bucau
- Jean-Louis Monteiro
- Mark Struberg
- Gerhard Petracek
- David Blevins

 Sponsors

 Champion

- Mark Struberg

 Nominated Mentors

- Justin Mclean
- Christian Grobmeier
- Daniel Kulp

 Project Name

 Seems *Fleece* is the name which satisfies most of people but we can still
 ask for a new name if we feel it needed before being graduated.
 

 Romain Manni-Bucau
 Twitter: @rmannibucau
 Blog: http://rmannibucau.wordpress.com/
 LinkedIn: http://fr.linkedin.com/in/rmannibucau
 Github: https://github.com/rmannibucau

Re: Obfuscating' 3rd party jars

[dsh]

If Emma enacts your bytecode like Cobertura does for instance, you may
consider not shipping such bytecode as well. Instead ship the one without
debug symbols and the one which hasn't been enacted to be consumed by
code coverage tools et al.

Cheers
Daniel


On Tue, Dec 4, 2012 at 12:36 PM, Benson Margulies bimargul...@gmail.comwrote:

 On Tue, Dec 4, 2012 at 12:35 AM, Michael MacFadden
 michael.macfad...@gmail.com wrote:
  Benson,
 
  I agree.  There was some progress in mavenizing the build.  I suspect
 that
  that solution will take some time.  The build process is somewhat
  complicated at the moment, if this is the long term solution, we may need
  to do something simpler to start off with.
 
  In the case of Junit, we should probably be able to remove it from a
  binary release.  There is no reason to include it in my mind since it's
  only used during the build.  Not sure on emma.  Regardless a temporary
  work around would be to remove them and simply required the users to
  download them.  We could even provide a simple script to do that.

 Now you are thinking in the usual ASF terms. Use a build tool, or tell
 users to download.

 Emma is a code coverage tool, so it should just be like junit:
 certainly not in a runtime package, and, if not at least 'category b',
 'download it yourself' in the source release.


 
  ~Michael
 
 
 
  On 12/3/12 3:45 PM, Benson Margulies bimargul...@gmail.com wrote:
 
 On Mon, Dec 3, 2012 at 4:39 PM, Michael MacFadden
 michael.macfad...@gmail.com wrote:
  Benson,
 
  Yes, Angus had been working this issue for us and found a few third
 party
  Jars.  Here is an extract from his email:
 
  --
  There's a couple of things going on at once at the moment:
  -i'm in contact with the libIDN author, who is happy to release the
  software under the Apache license, which means we can keep using that
 once
  a new release comes out
  -the other two libraries junit and emma both think the best option is
 to
  obfuscate the code somehow like ant, if anyone has any experience in
 doing
  it speaking up would be greatly appreciated
  ---
 
 
  Apparently, there is some precedent for obfuscating third party jars.
 My
  assumption is that something about the license views distributing Java
  jars as being akin to a source distribution do to the ease of
  decompilation.
 
 I cannot think of any reason why any Apache project should be
 concerned with obfuscation or decompilation. We are open source, and
 our dependencies are open source. Junit is a testing tool, so you
 should never need to redistribute it, just arrange to have it
 available for builds, and maven or ant/ivy will do that, and the same
 with emma, which is another development tool.
 
 There are many examples of this at other project. If it would be
 helpful, I could join the dev list to help with the discussion here.
 
 
 
 
  Angus,
 
  Can you she some light on this?
 
  ~Michael
 
  On 12/3/12 12:54 PM, Benson Margulies bimargul...@gmail.com wrote:
 
 Dear Wave,
 
 I don't understand the remark in your report about the need to
 'obfuscate' third party jar files. Could you please elaborate? Do you
 have problems with dependencies with incompatible licenses, or
 something else?
 
 Thanks,
 Benson
 
 -
 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
 
 
 -
 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
 

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

Re: [PROPOSAL] Apache Linda

[dsh]

Heh yeah I as well had the tuplespace implementation associated with Linda
as I read Apache Linda :) Where Linda itself might have become historic,
the concept still is in use. E.g. [1].

[1]
http://dl.acm.org/citation.cfm?id=1739850CFID=202524342CFTOKEN=19022440

Cheers
Daniel


On Fri, Nov 16, 2012 at 7:30 PM, Roy T. Fielding field...@gbiv.com wrote:

 I suggest choosing a different name.

http://en.wikipedia.org/wiki/Linda_%28coordination_language%29

 We generally don't use names that have been (and continue to be)
 used extensively by other software projects.

 Roy

 On Nov 16, 2012, at 9:14 AM, Sebastian Schaffert wrote:

  Dear all,
 
  we would like to propose a new project called Apache Linda as a Linked
 Data Platform implementation to the incubator. Andy Seaborne was so kind as
 to volunteer as a champion for the project. The proposal is available at
 
  http://wiki.apache.org/incubator/LindaProposal
 
  The goal of Apache Linda is to provide an open implementation of a
 Linked Data Platform that can be used, extended, and deployed easily by
 organizations who want to publish Linked Data or build custom applications
 on Linked Data. Linda will follow the core recommendations of the W3C on
 RDF, SPARQL and Linked Data publishing, particularly the emerging Linked
 Data Platform (LDP) recommendation. It will also offer extensions for
 frequently needed additional functionalities like Linked Data Querying,
 WebID, WebACL, Reasoning, and Versioning. Linda aims to cover both, Linked
 Open Data, as well as Enterprise Linked Data scenarios, providing
 facilities to deal with different data sources and requirements (small
 data/big data, open access/restricted access, etc).
 
  We are looking forward to your feedback and suggestions on how to
 improve the proposal and idea!
 
 
  Sergio, Thomas, Jakob and Sebastian
 
 
 
  --
  | Dr. Sebastian Schaffert
 sebastian.schaff...@salzburgresearch.at
  | Salzburg Research Forschungsgesellschaft
 http://www.salzburgresearch.at
  | Head of Knowledge and Media Technologies Group  +43 662 2288
 423
  | Jakob-Haringer Strasse 5/II
  | A-5020 Salzburg
 


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

Re: [PROPOSAL] Apache Linda

[dsh]

tuplespaces are STILL well known and Linda is one or even its original
implementation where JavaSapces is another and later on grid computing
borrowed some ideas [1] from it etc pp. So I wouldn't make a statement as
such as Linda nowadays is ancient technology (to use a strong term).
Anyway we had similar discussions in the past in terms of keeping the name
or not and if my memory serves me right most times the conclusion of each
discussion was that it's probably better to drop the proposed name in the
first place in favor of a better one that causes less confusion and such.

There seems to be a connection to the semantic web too which is Triple
Space Computing [2].

PS: Have a look at this slidedeck to get a feeling about how commonly know
tuplespaces are:
http://www.slideshare.net/luccastera/concurrent-programming-with-ruby-and-tuple-spaces

[1]
http://ieeexplore.ieee.org/xpl/login.jsp?tp=arnumber=4208870url=http%3A%2F%2Fieeexplore.ieee.org%2Fxpls%2Fabs_all.jsp%3Farnumber%3D4208870
[2]
http://dip.semanticweb.org/documents/RoleofTripleSpaceinSemanticWebServices.pdf

Cheers
Daniel


On Sat, Nov 17, 2012 at 8:08 PM, Andy Seaborne a...@apache.org wrote:

 On 17/11/12 09:01, Sergio Fernández wrote:

 Hi Roy,

 we were aware of the possible conflict/confusion with the name; but
 since the Linda model is quite old, not really spread nowadays and
 completely far away of the Linked Data topic, personally I can't see a
 really big issue here. But of course the Incubator PMC has a deeper
 knowledge of such a kind of decisions and its implications, so we'll do
 out best to address it during this discussion.

 Anyway, we'd prefer to focus the discussion on the proposal itself.
 After all, the name is something we can change. But the project is
 something important to discuss.

 BTW, regarding that, in other to provide some more background about the
 proposal, I'd also like to point you the slides we presented one week
 ago at ApacheCon Europe: http://slidesha.re/VUQ7ia

 Thanks for all your feedback.

 Best,


 On 16.11.2012 19:30, Roy T. Fielding wrote:

 I suggest choosing a different name.


 http://en.wikipedia.org/wiki/**Linda_%28coordination_**language%29http://en.wikipedia.org/wiki/Linda_%28coordination_language%29

 We generally don't use names that have been (and continue to be)
 used extensively by other software projects.

 Roy


 You're right changing the name can be done later but the name tends to get
 embedded both in the system (e.g. URLs, JIRA project) and more importantly
 in people knowing about the community.

 Renaming for the community is hard and risky - I would say it is easier to
 sort it out as part of project initialization if you believe the name
 change is likely.

 I did a quick search and found 2 lindas: Linda Spaces (the blackboard
 system that, I guess, is triggering the comments here) and TCP Linda, a
 parallel execution environment (which may well be related to the blackboard
 linda).

 TCP Linda ==
 http://www.gaussian.com/g_**prod/linda.htmhttp://www.gaussian.com/g_prod/linda.htm

 Linda spaces leads to JavaSpaces so is a known name in the Java world at
 least.  There is a SourceForge project linda (but looks dormant)

 Andy



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

Re: [PROPOSAL] Apache Linda

[dsh]

Btw, I think the Wikipedia reference in the Tuple Space article to the
blackboard metaphor is misleading cause it's already bound to AI expert
systems such as Hofstadter's copycat... if I have collected enough evidence
I'll change the article accordingly :)

Cheers
Daniel


On Sat, Nov 17, 2012 at 11:12 PM, Sebastian Schaffert 
sebastian.schaff...@salzburgresearch.at wrote:

 Dear all,

 first of all, thanks for the feedback so far...

 Am 17.11.2012 um 20:08 schrieb Andy Seaborne:


  You're right changing the name can be done later but the name tends to
 get embedded both in the system (e.g. URLs, JIRA project) and more
 importantly in people knowing about the community.
 
  Renaming for the community is hard and risky - I would say it is easier
 to sort it out as part of project initialization if you believe the name
 change is likely.
 
  I did a quick search and found 2 lindas: Linda Spaces (the blackboard
 system that, I guess, is triggering the comments here) and TCP Linda, a
 parallel execution environment (which may well be related to the blackboard
 linda).
 
  TCP Linda ==
  http://www.gaussian.com/g_prod/linda.htm
 
  Linda spaces leads to JavaSpaces so is a known name in the Java world at
 least.  There is a SourceForge project linda (but looks dormant)
 
Andy
 
 


 I agree that Linda is a very generic name and as such there are already
 several projects out there with this name. On the other hand, we chose
 Linda as an acronym for Linked Data in order to increase
 recognizability especially in the domain we are targeting. For our
 community, we think it would be quite easy to identify Apache Linda with
 the Linked Data Platform and not with a blackboard system or a methodology
 for parallel execution. A more artificial name would probably have a harder
 time establishing a brand (but of course the project is good enough to
 manage ;-) ).

 In case the Incubator PMC still recommends to rename the project, I agree
 we should do it BEFORE starting up the project. We will discuss options for
 renaming on Monday (European Time) and come up with suggestions.

 Greetings,


 Sebastian
 --
 | Dr. Sebastian Schaffert  sebastian.schaff...@salzburgresearch.at
 | Salzburg Research Forschungsgesellschaft  http://www.salzburgresearch.at
 | Head of Knowledge and Media Technologies Group  +43 662 2288 423
 | Jakob-Haringer Strasse 5/II
 | A-5020 Salzburg


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

Re: [PROPOSAL] Apache Linda

[dsh]

Btw, the important part missing up to now in this discussion is the OPEN in
Linked OPEN Data. If I get it right without openness the whole idea will be
crippled to a certain extend.

Cheers
Daniel


On Sun, Nov 18, 2012 at 1:12 AM, Sebastian Schaffert 
sebastian.schaff...@salzburgresearch.at wrote:

 Dear Ted,

 even though I agree that the term Linked Data is very generic, this is
 out of my influence, and it describes quite well what the topic is about.
 The term Linked Data has actually been proposed by Tim Berners-Lee:

 http://www.w3.org/DesignIssues/LinkedData.html

 and is used in the various standardisation efforts (like the W3C Linked
 Data Platform recommendation mentioned in the proposal). There is also a
 nice presentation from 2009 at TED:

 http://www.ted.com/talks/tim_berners_lee_on_the_next_web.html

 Linked Data is also already used by major enterprises like:
 - BBC: http://www.w3.org/2001/sw/sweo/public/UseCases/BBC/
 - Volkswagen:
 http://semanticweb.com/volkswagen-das-auto-company-is-das-semantic-web-company_b23233
 - German National Library:
 http://www.dnb.de/EN/Service/DigitaleDienste/LinkedData/linkeddata_node.html

 So my fear that 'nobody is likely to understand the phrase Linked Data'
 is very low for the future. If there have been other uses of the phrase in
 Computer Science before they are now marginalized (if you can trust a
 Google search for Linked Data).

 That said, we take your concern serious (especially the legal issue) and
 will discuss the issue on Monday. I am also grateful for the proposals that
 have already been done on the list.

 Greetings,

 Sebastian


 Am 17.11.2012 um 23:49 schrieb Ted Dunning:

  Frankly, the phrase linked data is also so generic as to be essentially
  meaningless outside your community.  There are many, many uses of this
  phrase in computer science that mean something completely different from
  what you guys seem to mean.
 
  It took me quite a bit of reading to figure out what you were talking
  about.  At the very least, you need to look at your supporting materials
  with a naive eye so that you can avoid the confusion that your name and
  terminology are likely to cause.
 
  Having a project name that memorializes a phrase that nobody is likely to
  understand without (lots of) supporting material and which is used by
 other
  projects in roughly the same domain is problematic.
 
  My feeling is that I would be -0 on the name meaning that I think that it
  isn't good, but I wouldn't stand in the way by vetoing it.  You guys seem
  pretty attached to your terminology regardless of the merits and it
 doesn't
  seem a big enough issue to be worth causing friction over it.
 
  You should be aware, however, that with these defects, it seems very
  unlikely to me that Apache would be able to help with trademark and name
  conflict issues.  That may not seem like a big deal now, but if your
  project really does get going and then somebody tries to take over your
  community with a nearly identically named product, it will definitely
 feel
  like a big deal.  Take a look at what happens with Open Office all the
 time.
 
  On Sat, Nov 17, 2012 at 2:12 PM, Sebastian Schaffert 
  sebastian.schaff...@salzburgresearch.at wrote:
 
  I agree that Linda is a very generic name and as such there are
 already
  several projects out there with this name. On the other hand, we chose
  Linda as an acronym for Linked Data in order to increase
  recognizability especially in the domain we are targeting. For our
  community, we think it would be quite easy to identify Apache Linda
 with
  the Linked Data Platform and not with a blackboard system or a
 methodology
  for parallel execution. A more artificial name would probably have a
 harder
  time establishing a brand (but of course the project is good enough to
  manage ;-) ).
 
  In case the Incubator PMC still recommends to rename the project, I
 agree
  we should do it BEFORE starting up the project. We will discuss options
 for
  renaming on Monday (European Time) and come up with suggestions.
 

 Sebastian
 --
 | Dr. Sebastian Schaffert  sebastian.schaff...@salzburgresearch.at
 | Salzburg Research Forschungsgesellschaft  http://www.salzburgresearch.at
 | Head of Knowledge and Media Technologies Group  +43 662 2288 423
 | Jakob-Haringer Strasse 5/II
 | A-5020 Salzburg


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

Re: Openmeetings - A Shepherd's View

[dsh]

Well I still opt to use Meta descriptors such as Maven POMs or CMake
(probably only applicable for native projects) files in such cases
which would allow to generate Eclipse/IDE you name it specific files
once the sources has been obtained.

Cheers
Daniel

On Mon, Sep 17, 2012 at 10:22 PM, sebb seb...@gmail.com wrote:
 On 14 September 2012 13:57, Alexei Fedotov alexei.fedo...@gmail.com wrote:
 The most useful file containing the project classpath is only formatted
 automatically, it cannot be generated without project-specific knowledge.

 There is no techical problem to drop these files, yet developers who
 download our source release loose a useful code navigation tool without
 these files.

 Unfortunately, Eclipse .classpath and .project files are *not*
 portable; the contents can depend on the individual Eclipse setup.
 In particular, unless all developers use the same default JDK as
 required by the project, the classpath files will vary.
 Also, the .project file will vary if some developers have added
 certain plugins, e.g. FindBugs or Maven.

 Having the files in SVN in the location where Eclipse expects to find
 them will cause problems for some developers, as they will need to
 modify the files locally in order to build. They cannot commit the
 files without causing problems for others, and so their workspace will
 always contain modifications.

 If you do wish to release IDE build files, I suggest you release them
 as separate files, e.g. under

 res/ide-support/eclipse
 res/ide-support/netbeans

 etc.

 The files can be named

 eclipse.classpath
 eclipse.profile

 as files without names can cause problems.

  14.09.2012 16:46 пользователь Jim Jagielski j...@jagunet.com написал:


 On Sep 14, 2012, at 5:02 AM, Mohammad Nour El-Din nour.moham...@gmail.com
 wrote:

 
  But can we add ASL headers to files which are defined and considered
  to be, even structure wise (please correct me if I am wrong), under
  the license of Eclipse ?
 

 If they are build artifacts (like stuff created by autoconf
 for example), then there's no need to add AL headers (AL, not ASL).
 AL headers are for actual work products (like source code, etc)...


 -
 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


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

Re: Openmeetings - A Shepherd's View

[dsh]

@Mohammad: And btw, in reference to that big (blue) company, I'd say
your statement is hearsay and needs to be proofed. For instance why is
that very big (blue) company adding their own, proprietary license
header to such generated files and in one way or another even Java
files are Eclipse-generated in the beginning ;)

Cheers
Daniel

On Fri, Sep 14, 2012 at 11:07 AM, dsh daniel.hais...@gmail.com wrote:
 The more practical and pragmatic question to pose is: why would you
 want to add license headers to generated files. You would have to take
 care of that they won't disappear each time the file (e.g. .classpath)
 is getting re-generated. Again from a practical point of view a
 mentoring suggestion could be to suggest moving such configuration
 settings over to Maven over the course of time and let Maven generate
 the Eclipse project-specific files.

 Cheers
 Daniel

 On Fri, Sep 14, 2012 at 11:02 AM, Mohammad Nour El-Din
 nour.moham...@gmail.com wrote:
 Hi Marcel...

 On Fri, Sep 14, 2012 at 10:40 AM, Marcel Offermans
 marcel.offerm...@luminis.nl wrote:
 On Sep 14, 2012, at 10:24 AM, Mohammad Nour El-Din 
 nour.moham...@gmail.com wrote:
 On Fri, Sep 14, 2012 at 4:24 AM, Alexei Fedotov
 alexei.fedo...@gmail.com wrote:
 14.09.2012 3:46 пользователь Mohammad Nour El-Din mn...@apache.org
 написал:
 One minor note:
 - In [1] I noticed files related to Eclipse like .classpath and
 .project, I am not sure that these files should be in a release tag.
 Comments about that ?

 Well my concern was more like a question to raise here not actually
 something to take on the project itself, to be honest I am not aware
 about any rules that might prohibit that, but for at least most of the
 projects I didn't see them committing IDE specific files into the
 repository. Thats why I raised the question here to see what others
 do.

 Since these are xml files and you can definitely edit them like other build 
 files, I can't see any reason why they could not be part of a source 
 release either. However, I do think they need a proper license header (the 
 file I quickly checked [1] did not have that). I'm not aware of a way to 
 tell Eclipse to add such headers automatically, so you might have to do 
 that by hand or some script.

 But can we add ASL headers to files which are defined and considered
 to be, even structure wise (please correct me if I am wrong), under
 the license of Eclipse ?

 I really don't know I am also just raising a question here

 DETAILS: My concern here comes from information I learned when I was
 working in a big company (not mentioning names here) and they had
 their own development tools which are totally built based on Eclipse.
 And IIRC even the files generated from these tools, also XML files and
 such, were opt to some license some how. So IDK if the case hold here
 as well or not


 Greetings, Marcel


 [1] 
 https://svn.apache.org/repos/asf/incubator/openmeetings/tags/2.0/.project




 --
 Thanks
 - Mohammad Nour
 
 Life is like riding a bicycle. To keep your balance you must keep moving
 - Albert Einstein

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


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

Re: Openmeetings - A Shepherd's View

[dsh]

The more practical and pragmatic question to pose is: why would you
want to add license headers to generated files. You would have to take
care of that they won't disappear each time the file (e.g. .classpath)
is getting re-generated. Again from a practical point of view a
mentoring suggestion could be to suggest moving such configuration
settings over to Maven over the course of time and let Maven generate
the Eclipse project-specific files.

Cheers
Daniel

On Fri, Sep 14, 2012 at 11:02 AM, Mohammad Nour El-Din
nour.moham...@gmail.com wrote:
 Hi Marcel...

 On Fri, Sep 14, 2012 at 10:40 AM, Marcel Offermans
 marcel.offerm...@luminis.nl wrote:
 On Sep 14, 2012, at 10:24 AM, Mohammad Nour El-Din nour.moham...@gmail.com 
 wrote:
 On Fri, Sep 14, 2012 at 4:24 AM, Alexei Fedotov
 alexei.fedo...@gmail.com wrote:
 14.09.2012 3:46 пользователь Mohammad Nour El-Din mn...@apache.org
 написал:
 One minor note:
 - In [1] I noticed files related to Eclipse like .classpath and
 .project, I am not sure that these files should be in a release tag.
 Comments about that ?

 Well my concern was more like a question to raise here not actually
 something to take on the project itself, to be honest I am not aware
 about any rules that might prohibit that, but for at least most of the
 projects I didn't see them committing IDE specific files into the
 repository. Thats why I raised the question here to see what others
 do.

 Since these are xml files and you can definitely edit them like other build 
 files, I can't see any reason why they could not be part of a source release 
 either. However, I do think they need a proper license header (the file I 
 quickly checked [1] did not have that). I'm not aware of a way to tell 
 Eclipse to add such headers automatically, so you might have to do that by 
 hand or some script.

 But can we add ASL headers to files which are defined and considered
 to be, even structure wise (please correct me if I am wrong), under
 the license of Eclipse ?

 I really don't know I am also just raising a question here

 DETAILS: My concern here comes from information I learned when I was
 working in a big company (not mentioning names here) and they had
 their own development tools which are totally built based on Eclipse.
 And IIRC even the files generated from these tools, also XML files and
 such, were opt to some license some how. So IDK if the case hold here
 as well or not


 Greetings, Marcel


 [1] https://svn.apache.org/repos/asf/incubator/openmeetings/tags/2.0/.project




 --
 Thanks
 - Mohammad Nour
 
 Life is like riding a bicycle. To keep your balance you must keep moving
 - Albert Einstein

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


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

Re: [VOTE] CloudStack for Apache Incubator

[dsh]

[X] +1: accept CloudStack into Incubator (non-binding)
[] +0: don't care
[] -1: do not accept CloudStack into Incubator (please explain the objection)

Cheers
Daniel

On Tue, Apr 10, 2012 at 3:32 AM, Kevin Kluge kevin.kl...@citrix.com wrote:
 Hi All.  I'd like to call for a VOTE for CloudStack to enter the Incubator.  
 The proposal is available at [1] and I have also included it below.   Please 
 vote with:
 +1: accept CloudStack into Incubator
 +0: don't care
 -1: do not accept CloudStack into Incubator (please explain the objection)

 The vote is open for at least 72 hours from now (until at least 19:00 US-PST 
 on April 12, 2012).

 Thanks for the consideration.

 -kevin

 [1] http://wiki.apache.org/incubator/CloudStackProposal




 Abstract

 CloudStack is an IaaS (Infrastracture as a Service) cloud orchestration 
 platform.

 Proposal

 CloudStack provides control plane software that can be used to create an IaaS 
 cloud. It includes an HTTP-based API for user and administrator functions and 
 a web UI for user and administrator access. Administrators can provision 
 physical infrastructure (e.g., servers, network elements, storage) into an 
 instance of CloudStack, while end users can use the CloudStack self-service 
 API and UI for the provisioning and management of virtual machines, virtual 
 disks, and virtual networks.

 Citrix Systems, Inc. submits this proposal to donate the CloudStack source 
 code, documentation, websites, and trademarks to the Apache Software 
 Foundation (ASF).

 Background

 Amazon and other cloud pioneers invented IaaS clouds. Typically these clouds 
 provide virtual machines to end users. CloudStack additionally provides 
 baremetal OS installation to end users via a self-service interface. The 
 management of physical resources to provide the larger goal of cloud service 
 delivery is known as orchestration. IaaS clouds are usually described as 
 elastic -- an elastic service is one that allows its user to rapidly scale 
 up or down their need for resources.

 A number of open source projects and companies have been created to implement 
 IaaS clouds. Cloud.com started CloudStack in 2008 and released the source 
 under GNU General Public License version 3 (GPL v3) in 2010. Citrix 
 acquired Cloud.com, including CloudStack, in 2011. Citrix re-licensed the 
 CloudStack source under Apache License v2 in April, 2012.

 Rationale

 IaaS clouds provide the ability to implement datacenter operations in a 
 programmable fashion. This functionality is tremendously powerful and 
 benefits the community by providing:

 - More efficient use of datacenter personnel
 - More efficient use of datacenter hardware
 - Better responsiveness to user requests
 - Better uptime/availability through automation

 While there are several open source IaaS efforts today, none are governed by 
 an independent foundation such as ASF. Vendor influence and/or proprietary 
 implementations may limit the community's ability to choose the hardware and 
 software for use in the datacenter. The community at large will benefit from 
 the ability to enhance the orchestration layer as needed for particular 
 hardware or software support, and to implement algorithms and features that 
 may reduce cost or increase user satisfaction for specific use cases. In this 
 respect the independent nature of the ASF is key to the long term health and 
 success of the project.

 Initial Goals

 The CloudStack project has two initial goals after the proposal is accepted 
 and the incubation has begun.

 The Cloudstack Project's first goal is to ensure that the CloudStack source 
 includes only third party code that is licensed under the Apache License or 
 open source licenses that are approved by the ASF for use in ASF projects. 
 The CloudStack Project has begun the process of removing third party code 
 that is not licensed under an ASF approved license. This is an ongoing 
 process that will continue into the incubation period. Third party code 
 contributed to CloudStack under the CloudStack contribution agreement was 
 assigned to Cloud.com in exchange for distributing CloudStack under GPLv3. 
 The CloudStack project has begun the process of amending the previous 
 CloudStack contribution agreements to obtain consent from existing 
 contributors to change the CloudStack project's license. In the event that an 
 existing contributor does not consent to this change, the project is prepared 
 to remove that contributor's code. Additionally, there are binary 
 dependencies on redistributed libraries that are not provided with an 
 ASF-approved license. Finally, the CloudStack has source files incorporated 
 from third parties that were not provided with an ASF-approved license. We 
 have begun the process of re-writing this software. This is an ongoing 
 process that will extend into the incubation period. These issues are 
 discussed in more detail later in the proposal.

 Although CloudStack is open source, many 

Re: Is there an ASF license for Apple's Apple Developer Program ?

[dsh]

+1

Cheers
Daniel

On Tue, Apr 3, 2012 at 7:43 PM, William A. Rowe Jr. wr...@rowe-clan.net wrote:
 On 3/31/2012 8:43 AM, Rob Weir wrote:
 On Fri, Mar 30, 2012 at 7:20 AM, Ross Gardler 
 rgard...@opendirective.comwrote:

 There isn't (to my knowledge), I can imagine an increasing number of
 projects wanting such a thing though. Unless someone tells me I'm
 wrong and we already have one would you be interested in seeing if
 Apple are open to such an arrangement?



 I'd recommend first very careful review of the licensing terms first, on
 legal-discuss, to ensure that we're comfortable with any restrictions use
 of their SDK brings.  This would also help with other potential
 contributors who might have iOS apps they would like to contribute, but
 whose current analysis suggests that the Apple terms are incompatible.

 nonsense

 These are the very same SDK tools that these very same Apache Committers 
 already
 use on a daily basis.

 The only modulo here is that some have access through work.  Some purchase 
 their
 own access.  Some have been comp'ed subscriptions individually or through 
 other
 organizations.

 This simply makes the same tool for a committer free or discounted from what
 they already paid.  For example, I was an MSDN subscriber through work for 
 some
 years, as a consultant for some years, took a break from my subscription on 
 some
 other years.  Now, I'm using a subscription donated for ASF committers.  
 Nothing
 changed.

 Sure, you can have a discussion about whether some WizBang API introduces new
 licensing restrictions, platform lock-in, etc.  But we are NOT GOING TO BEGIN
 auditing the Oracle Developer Suite, the Microsoft Developer Network, the 
 Apple
 Developer Network, the IBM HP VMware Google RedHat Citrix Adobe Amazon (OH GOD
 MAKE IT STOP!!!) developer tool program for every possible future quirk.

 There are real questions to be asked about specific tools and specific api's 
 in
 the open source and closed source world and the projects which are affected 
 need
 to do their homework and work with ASF legal to resolve ambiguity.  But any of
 these examples includes hundreds of tools and api's and sdk's which have no
 intersection with an ASF code base.

 If Jim works out some connections for ASF  Apple and you use Apple then 
 enjoy
 that perk, and otherwise, please EIGNORE?  Thanks :)


 -
 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: Is there an ASF license for Apple's Apple Developer Program ?

[dsh]

It might as well be worth discussing whether it would be possible to
arrange something similar as the MSDN agreement with Microsoft where
ASF committers would have wild card access to the iOS developer
program, the Mac developer program and the Safari developer program. I
currently have each of these three but am paying for them on my own.

For instance if your app should be running on OSX too and be
downloadable via the app store you would as well need to have access
to the Mac developer program.

Cheers
Daniel

On Fri, Mar 30, 2012 at 5:16 PM, Luciano Resende luckbr1...@gmail.com wrote:
 On Fri, Mar 30, 2012 at 4:33 AM, seba.wag...@gmail.com
 seba.wag...@gmail.com wrote:
 That would be great!
 I guess http://incubator.apache.org/cordova/ would also appreciate it

 Thanks!
 Sebastian


 PhotArk is moving to the mobile space based on Apache Cordova and
 would appreciate this as well.

 --
 Luciano Resende
 http://people.apache.org/~lresende
 http://twitter.com/lresende1975
 http://lresende.blogspot.com/

 -
 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 Openmeetings to Apache Incubator

[dsh]

[ x ] +1 Accept Openmeetings for incubation
[ ] +0 Don't care
[ ] -1 Reject for the following reason:

Cheers
Daniel

On Tue, Nov 8, 2011 at 7:53 AM, Andrus Adamchik and...@objectstyle.org wrote:
 Opemeetings proposal has been discussed a few times here before. The group of 
 developers behind it worked hard (and succeeded) to address all potential 
 obstacles to the Incubator acceptance and to the following incubation. They 
 even went an extra mile and collected all ICLAs in adbvance.

 So now I am starting the vote to accept Openmeetings to Apache Incubator.

 The proposal is also available at: 
 http://wiki.apache.org/incubator/OpenmeetingsProposal

 Please cast your votes:

 [ ] +1 Accept Openmeetings for incubation
 [ ] +0 Don't care
 [ ] -1 Reject for the following reason:

 The vote is open for 72 hours.

 Andrus

 ---
 Andrus Adamchik
 Apache Cayenne ORM: http://cayenne.apache.org/
 Twitter: http://twitter.com/andrus_a



 ---

 == OpenMeetings Project Proposal ==

 == Abstract ==
 Openmeetings is a web conferencing solution.

 == Proposal ==
 Openmeetings provides video conferencing, instant messaging, white board, 
 collaborative document editing and other groupware tools using API functions 
 of the Red5 Streaming Server for Remoting and Streaming.

 == Background ==
 Openmeetings was developed since 2007 by Sebastian Wagner and willing 
 developers. The project ships a release approximately once per quarter. It 
 was developed using LGPL license, and developers are currently thinking of 
 re-licensing it under Apache License 2.0.

 The project started as module by Sebastian Wagner for an ELearning platform 
 (Dokeos) and was then split into a separated project. That is the reason why 
 there is a strong relation to educational institutions that are using 
 OpenMeetings and there are integrations for platforms like Moodle, ATutor, 
 Sakai, STudIP or ILias available 
 (http://code.google.com/p/openmeetings/wiki/MoodlePlugins). The relation to 
 educational institutions also subsequently lead to some projects funded by 
 the EU where OpenMeetings was involved, for example by the Swedish/Finnish 
 Centre of Open-Source !OpenKarken (Case-Study about the EU project at 
 OSOR.eu: http://www.osor.eu/studies/finland-and-sweden-collaborate-using-oss )

 The integration and internationalization of the project was a primary focus 
 right from the start of the project. Since Version 0.5 there is a 
 Language-Editor (http://code.google.com/p/openmeetings/wiki/LanguageEditor) 
 to edit labels, export and import them as XML and you can use those XML files 
 for future installations (or contribute it to the community). There are 
 currently around 30 languages available.  Since version 0.5.1 there is also a 
 SOAP API to integrate !OpenMeetings. We constantly improve this SOAP/REST API 
 (http://code.google.com/p/openmeetings/wiki/SoapMethods) with new 
 functionality with a strong focus on security and usability. The 
 auth-mechnism is quite similar to OAuth, you create some token and then 
 assign rights to the token. (Documentation for Single Sign On: 
 http://code.google.com/p/openmeetings/wiki/DirectLoginSoapGeneralFlow)

 The project name !OpenMeetings and logos are inspired by Ludovic Gasc who 
 has been the project manager at Dokeos at the time Sebastian split 
 !OpenMeetings as separated project.

 Red5 Server provides an Edge-Orion-Clustering 
 (http://trac.red5.org/wiki/Documentation/Tutorials/EdgeOriginClusteringConfiguration).
   We hope to extend this clustering solution with support for rtmpt and  
 rtmps and integrate that into our application as native clustering  option.

 == Rationale ==
 Last year most major vendors started commercial web conferencing solutions. 
 This is an important part of software ecosystem, and there is an urge to 
 consolidate open source development efforts in this direction.

 According to several studies demand for synchronous Communication, in 
 opposite to asynchronous Communication like wiki's or email, will raise the 
 upcoming years. For example Gartner promises that 2011 the market will grow 
 20% according to their Magic Quadrant report 2010 ( 
 http://www.gartner.com/DisplayDocument?doc_cd=205941 ).

 Openmeetings is a unique solution in terms of patent purity and potentially 
 can grow into solution built on top of the fully open source stack. That is 
 why it is a good candidate for consolidating web conferencing community 
 efforts.

 == Initial Goals ==
 Each of project committers has their own set of goals, but we all share the 
 following.

  * Move to Apache.
  * Become popular.

 To become popular we plan to do the following.

  * Improve ecosystem around the project.
  * Improve release process.
  * Improve project testing and stability.
  * Apply modular architecture/SOA for better integration with other projects.

 == Current Status ==
 We have agreed on applying for the Apache Foundation and preparing our 
 proposal for the 

Re: [PROPOSAL] PhoneGap for Apache Incubator

[dsh]

Out of curiosity, are there any reasons to not develop the proposal on
the incubator wiki [1]?

[1] http://wiki.apache.org/incubator/

Cheers
Daniel

On Sat, Oct 1, 2011 at 11:41 AM, Jukka Zitting jukka.zitt...@gmail.com wrote:
 Hi,

 On Sat, Oct 1, 2011 at 8:52 AM, Francis De Brabandere
 franci...@gmail.com wrote:
 Just a small remark: first two github links are incorrect
 https://github.com/phonegap/android should be
 https://github.com/phonegap/phonegap-android same for iphone

 Good catch! Fixed.

 BR,

 Jukka Zitting

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



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

Re: [PROPOSAL] Apache OpenMeetings incubator for Web Conferencing

[dsh]

Sebastian,

btw, I noticed that the JNLP app remains open after you closed the
browser. That's probably because the main browser app and the JNLP app
are not tightly coupled if it comes to even notivication such as a
browser close even (it's been a will since I did Java webstart apps
the last time so I don't remember whether the Java webstart app could
register with the main app to listen for certain events). Anyway from
an end user perspective one might find it more intuitive if everuthing
closes right at the time the browser would be closed.

Cheers
Daniel

On Fri, Jul 29, 2011 at 9:27 AM, seba.wag...@gmail.com
seba.wag...@gmail.com wrote:
 @Daniel

 thanks for the excellent  extended testing on your host environments. That
 the screensharing does not close on the clients after the publisher hit the
 *stop* is definitly a bug that we did already fix in previous versions.

 The check to do not start the ScreenSharing Application several time on the
 same client machine would be also quite usefull thats right. It is however a
 bit complex as you need either handle on server side a *flag* that marks
 clients that run the screensharing = that is only possible if the user hits
 the *start-sharing* or *start-recording* button, otherwise there is no
 connect from the client to the server. Or you try to implement some hook
 that checks on startup of the screensharing client if its already running =
 I am not sure if the Java Web-Start Sandbox allows access to the
 process/task-manager to check that ... also it would be a bit nasty as you
 would need to download the hole app first, start it to see that you have it
 already running :-/.
 So the only acceptable fix would be to open an additionaly socket from the
 screensharing client to the server as long as the client is open. That would
 be sth. for upcoming version, I'll add it to our Issue tracker.

 Thanks again
 Sebastian


 2011/7/29 Pavel Rebriy pavel.reb...@gmail.com

 +1 from me too!

 Mikhail Fursov mike.fursov at gmail.com writes:

 
  Used OpenMeetings yesterday for our local video web conference with 3
  sites online . It worked flawlessly.
 
  +1 from me!
 





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




 --
 Sebastian Wagner
 http://www.webbase-design.de
 http://openmeetings.googlecode.com
 http://www.wagner-sebastian.com
 seba.wag...@gmail.com


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

Re: [PROPOSAL] Apache OpenMeetings incubator for Web Conferencing

[dsh]

Sebastian and Alexei,

your are welcome! Btw, here is my +1

On Fri, Jul 29, 2011 at 9:47 AM, Alexei Fedotov
alexei.fedo...@gmail.com wrote:
 Daniel,
 Thank you for an excellent report!

 --
 With best regards / с наилучшими пожеланиями,
 Alexei Fedotov / Алексей Федотов,
 http://dataved.ru/
 +7 916 562 8095




 On Thu, Jul 28, 2011 at 10:20 PM, dsh daniel.hais...@googlemail.com wrote:
 Hi,

 please find my feedback below:

 OS X Lion:

 * tested with:
 ** Firefox 5.0.1 and Adobe Flash Player 10.3
 ** Safari 5.1 and Adobe Flash Player 10.3
 * Observations:
 ** Openmeetings did not work with Firefox/Safari if using a webcam/mic
 cause on the adobe flash player settings dialog it was not possible to
 click allow nor deny
 ** In Safari clicking the share/record screen button N times did open
 the screen sharing app N times (maybe you want to check whether an
 instance of the app is already running)
 ** I understand if sharing screens everybody has control over your
 screen. you may consider adding a view only mode too.
 ** you might check while signing up whether popup blockers are active.
 if yes you could prompt the user to disable popup blockers first
 before signing in.
 ** pressing the share/record screen button opens a new, blank window
 just to download the JNLP app. maybe you want to change that to not
 open a separate window that needs to be closed after starting the JNLP
 app
 ** It looks like after stopping screen sharing the shared screen still
 remains on each participants screen. Maybe it would make sense to
 provide a message to each participant that the host stopped sharing
 its screen.

 OS X Snow Leopard:

 * tested with:
 ** Firefox 5.0.1 and Adobe Flash Player 10.3
 ** Safari 5.1 and Adobe Flash Player 10.3
 * Observations:
 ** Openmeetings did not work with Firefox cause the initial screen did
 not load after signing up
 ** In Safari clicking the share/record screen button N times did open
 the screen sharing app N times (maybe you want to check whether an
 instance of the app is already running)
 ** I understand if sharing screens everybody has control over your
 screen. you may consider adding a view only mode too.
 ** you might check while signing up whether popup blockers are active.
 if yes you could prompt the user to disable popup blockers first
 before signing in.
 ** pressing the share/record screen button opens a new, blank window
 just to download the JNLP app. maybe you want to change that to not
 open a separate window that needs to be closed after starting the JNLP
 app
 ** It looks like after stopping screen sharing the shared screen still
 remains on each participants screen. Maybe it would make sense to
 provide a message to each participant that the host stopped sharing
 its screen.

 Windows 7 Ultimate:

 * tested with:
 ** Firefox 4.0.1 and Adobe Flash Player 10.3
 ** Firefox 5.0.1 and Adobe Flash Player 10.3
 ** Safari 5.1 and Adobe Flash Player 10.3
 * Observations:
 ** In Firefox clicking the share/record screen button N times did open
 the screen sharing app N times (maybe you want to check whether an
 instance of the app is already running)
 ** I understand if sharing screens everybody has control over your
 screen. you may consider adding a view only mode too.
 ** you might check while signing up whether popup blockers are active.
 if yes you could prompt the user to disable popup blockers first
 before signing in.
 ** In Safari signing up did open a new window instead of opening a new
 tab which is different to Firefoxs behaviour (maybe this can be
 changed in the Safari prefs)
 ** pressing the share/record screen button opens a new, blank window
 just to download the JNLP app. maybe you want to change that to not
 open a separate window that needs to be closed after starting the JNLP
 app
 ** It looks like after stopping screen sharing the shared screen still
 remains on each participants screen. Maybe it would make sense to
 provide a message to each participant that the host stopped sharing
 its screen.

 Fedora Core 15 Gnome Edition:

 * tested with:
 ** Firefox 4.0.1 and Adobe Flash Player 11
 * Observations:
 * I had to download the JNLP file and execute it using javaws on the
 command line. Did expect it would be run more seamlessly cause the
 IcedTea-Web plug-in is installed
 ** In Firefox clicking the share/record screen button N times did open
 the screen sharing app N times (maybe you want to check whether an
 instance of the app is already running)
 ** I understand if sharing screens everybody has control over your
 screen. you may consider adding a view only mode too.
 ** you might check while signing up whether popup blockers are active.
 if yes you could prompt the user to disable popup blockers first
 before signing in.
 ** pressing the share/record screen button opens a new, blank window
 just to download the JNLP app. maybe you want to change that to not
 open a separate window that needs to be closed after starting the JNLP
 app
 ** It looks

Re: [PROPOSAL] Apache OpenMeetings incubator for Web Conferencing

[dsh]

Hi,

please find my feedback below:

OS X Lion:

* tested with:
** Firefox 5.0.1 and Adobe Flash Player 10.3
** Safari 5.1 and Adobe Flash Player 10.3
* Observations:
** Openmeetings did not work with Firefox/Safari if using a webcam/mic
cause on the adobe flash player settings dialog it was not possible to
click allow nor deny
** In Safari clicking the share/record screen button N times did open
the screen sharing app N times (maybe you want to check whether an
instance of the app is already running)
** I understand if sharing screens everybody has control over your
screen. you may consider adding a view only mode too.
** you might check while signing up whether popup blockers are active.
if yes you could prompt the user to disable popup blockers first
before signing in.
** pressing the share/record screen button opens a new, blank window
just to download the JNLP app. maybe you want to change that to not
open a separate window that needs to be closed after starting the JNLP
app
** It looks like after stopping screen sharing the shared screen still
remains on each participants screen. Maybe it would make sense to
provide a message to each participant that the host stopped sharing
its screen.

OS X Snow Leopard:

* tested with:
** Firefox 5.0.1 and Adobe Flash Player 10.3
** Safari 5.1 and Adobe Flash Player 10.3
* Observations:
** Openmeetings did not work with Firefox cause the initial screen did
not load after signing up
** In Safari clicking the share/record screen button N times did open
the screen sharing app N times (maybe you want to check whether an
instance of the app is already running)
** I understand if sharing screens everybody has control over your
screen. you may consider adding a view only mode too.
** you might check while signing up whether popup blockers are active.
if yes you could prompt the user to disable popup blockers first
before signing in.
** pressing the share/record screen button opens a new, blank window
just to download the JNLP app. maybe you want to change that to not
open a separate window that needs to be closed after starting the JNLP
app
** It looks like after stopping screen sharing the shared screen still
remains on each participants screen. Maybe it would make sense to
provide a message to each participant that the host stopped sharing
its screen.

Windows 7 Ultimate:

* tested with:
** Firefox 4.0.1 and Adobe Flash Player 10.3
** Firefox 5.0.1 and Adobe Flash Player 10.3
** Safari 5.1 and Adobe Flash Player 10.3
* Observations:
** In Firefox clicking the share/record screen button N times did open
the screen sharing app N times (maybe you want to check whether an
instance of the app is already running)
** I understand if sharing screens everybody has control over your
screen. you may consider adding a view only mode too.
** you might check while signing up whether popup blockers are active.
if yes you could prompt the user to disable popup blockers first
before signing in.
** In Safari signing up did open a new window instead of opening a new
tab which is different to Firefoxs behaviour (maybe this can be
changed in the Safari prefs)
** pressing the share/record screen button opens a new, blank window
just to download the JNLP app. maybe you want to change that to not
open a separate window that needs to be closed after starting the JNLP
app
** It looks like after stopping screen sharing the shared screen still
remains on each participants screen. Maybe it would make sense to
provide a message to each participant that the host stopped sharing
its screen.

Fedora Core 15 Gnome Edition:

* tested with:
** Firefox 4.0.1 and Adobe Flash Player 11
* Observations:
* I had to download the JNLP file and execute it using javaws on the
command line. Did expect it would be run more seamlessly cause the
IcedTea-Web plug-in is installed
** In Firefox clicking the share/record screen button N times did open
the screen sharing app N times (maybe you want to check whether an
instance of the app is already running)
** I understand if sharing screens everybody has control over your
screen. you may consider adding a view only mode too.
** you might check while signing up whether popup blockers are active.
if yes you could prompt the user to disable popup blockers first
before signing in.
** pressing the share/record screen button opens a new, blank window
just to download the JNLP app. maybe you want to change that to not
open a separate window that needs to be closed after starting the JNLP
app
** It looks like after stopping screen sharing the shared screen still
remains on each participants screen. Maybe it would make sense to
provide a message to each participant that the host stopped sharing
its screen.

Fedora Core 15 KDE Edition:

* tested with:
** Firefox 5.0 and Adobe Flash Player 11
* Observations:
* The JNLP app was started using IcedTea-Web on the fly. So I guess on
Fedora Core Gnome Edition one would need to manually setup some mime
types etc. in firefox to recognize 

Re: [PROPOSAL] Apache OpenMeetings incubator for Web Conferencing

[dsh]

Amendment: If using the FreeBSD Linuxulator together with the Adobe
Flash Player 11b1 and OpenJDK 6, Openmeetings works on PCBSD :)

PS: Observation on Win XP SP3 with Symantec Client Firewall - The
signup/connect attempt has been catched by the firewall software.

Cheers
Daniel

On Thu, Jul 28, 2011 at 8:20 PM, dsh daniel.hais...@googlemail.com wrote:
 Hi,

 please find my feedback below:

 OS X Lion:

 * tested with:
 ** Firefox 5.0.1 and Adobe Flash Player 10.3
 ** Safari 5.1 and Adobe Flash Player 10.3
 * Observations:
 ** Openmeetings did not work with Firefox/Safari if using a webcam/mic
 cause on the adobe flash player settings dialog it was not possible to
 click allow nor deny
 ** In Safari clicking the share/record screen button N times did open
 the screen sharing app N times (maybe you want to check whether an
 instance of the app is already running)
 ** I understand if sharing screens everybody has control over your
 screen. you may consider adding a view only mode too.
 ** you might check while signing up whether popup blockers are active.
 if yes you could prompt the user to disable popup blockers first
 before signing in.
 ** pressing the share/record screen button opens a new, blank window
 just to download the JNLP app. maybe you want to change that to not
 open a separate window that needs to be closed after starting the JNLP
 app
 ** It looks like after stopping screen sharing the shared screen still
 remains on each participants screen. Maybe it would make sense to
 provide a message to each participant that the host stopped sharing
 its screen.

 OS X Snow Leopard:

 * tested with:
 ** Firefox 5.0.1 and Adobe Flash Player 10.3
 ** Safari 5.1 and Adobe Flash Player 10.3
 * Observations:
 ** Openmeetings did not work with Firefox cause the initial screen did
 not load after signing up
 ** In Safari clicking the share/record screen button N times did open
 the screen sharing app N times (maybe you want to check whether an
 instance of the app is already running)
 ** I understand if sharing screens everybody has control over your
 screen. you may consider adding a view only mode too.
 ** you might check while signing up whether popup blockers are active.
 if yes you could prompt the user to disable popup blockers first
 before signing in.
 ** pressing the share/record screen button opens a new, blank window
 just to download the JNLP app. maybe you want to change that to not
 open a separate window that needs to be closed after starting the JNLP
 app
 ** It looks like after stopping screen sharing the shared screen still
 remains on each participants screen. Maybe it would make sense to
 provide a message to each participant that the host stopped sharing
 its screen.

 Windows 7 Ultimate:

 * tested with:
 ** Firefox 4.0.1 and Adobe Flash Player 10.3
 ** Firefox 5.0.1 and Adobe Flash Player 10.3
 ** Safari 5.1 and Adobe Flash Player 10.3
 * Observations:
 ** In Firefox clicking the share/record screen button N times did open
 the screen sharing app N times (maybe you want to check whether an
 instance of the app is already running)
 ** I understand if sharing screens everybody has control over your
 screen. you may consider adding a view only mode too.
 ** you might check while signing up whether popup blockers are active.
 if yes you could prompt the user to disable popup blockers first
 before signing in.
 ** In Safari signing up did open a new window instead of opening a new
 tab which is different to Firefoxs behaviour (maybe this can be
 changed in the Safari prefs)
 ** pressing the share/record screen button opens a new, blank window
 just to download the JNLP app. maybe you want to change that to not
 open a separate window that needs to be closed after starting the JNLP
 app
 ** It looks like after stopping screen sharing the shared screen still
 remains on each participants screen. Maybe it would make sense to
 provide a message to each participant that the host stopped sharing
 its screen.

 Fedora Core 15 Gnome Edition:

 * tested with:
 ** Firefox 4.0.1 and Adobe Flash Player 11
 * Observations:
 * I had to download the JNLP file and execute it using javaws on the
 command line. Did expect it would be run more seamlessly cause the
 IcedTea-Web plug-in is installed
 ** In Firefox clicking the share/record screen button N times did open
 the screen sharing app N times (maybe you want to check whether an
 instance of the app is already running)
 ** I understand if sharing screens everybody has control over your
 screen. you may consider adding a view only mode too.
 ** you might check while signing up whether popup blockers are active.
 if yes you could prompt the user to disable popup blockers first
 before signing in.
 ** pressing the share/record screen button opens a new, blank window
 just to download the JNLP app. maybe you want to change that to not
 open a separate window that needs to be closed after starting the JNLP
 app
 ** It looks like after stopping screen sharing

Re: Policy on t-shirts for incubating projects

[dsh]

Only mankinis are allowed. Look that up on Google :)

Cheers
Daniel

On Thu, Jul 21, 2011 at 5:15 PM, Alan D. Cabrera l...@toolazydogs.com wrote:
 What's the policy on making t-shirts for an incubating project?


 Regards,
 Alan


 -
 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: [PROPOSAL] Kafka for the Apache Incubator

[dsh]

I guess the official proposal is here, right?

 - http://wiki.apache.org/incubator/KafkaProposal

Cheers
Daniel

On Wed, Jun 22, 2011 at 8:47 PM, Chris Burroughs
chris.burrou...@gmail.com wrote:
 Clearspring was persuaded by the excellent design document [1] to adopt
 Kafka for some of our recent internal products.  That's gone well and we
 will likely have a significantly larger deployment in the near future.

 As one of the earlier adapters of Kafka I've enjoyed watching it mature
 as a project and am excited to see this proposal.  Looking forward to
 giving a +1.

 Chris Burroughs

 [1] http://sna-projects.com/kafka/design.php

 -
 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 OpenOffice.org for incubation

[dsh]

Btw, your mails appear to be sent twice to the ML. I recognized that
before already...

Cheers
Daniel

On Sun, Jun 12, 2011 at 10:23 PM, Mathias Bauer nospamfor...@gmx.de wrote:
 Sorry,

 this was a mistake, I used a wrong mail address; ignore this posting,
 please.

 regards,
 Mathias

 On 12.06.2011 15:51, Mathias Bauer wrote:

 +1 (non-binding)

 Regards,
 Mathias

 On 10.06.2011 18:02, Sam Ruby wrote:

 *** Please change your Subject: line for any [DISCUSSION] of this [VOTE]

 As the discussions on the OpenOfficeProposal threads seem to be winding
 down, I would like to initiate the vote to accept OpenOffice.org as an
 Apache Incubator project.

 At the end of this mail, I've put a copy of the current proposal. Here
 is a link to the document in the wiki:

 http://wiki.apache.org/incubator/OpenOfficeProposal?action=recallrev=207

 As the proposal discussion threads are numerous, I encourage people to
 scan and review the archives for this month:


 http://mail-archives.apache.org/mod_mbox/incubator-general/201106.mbox/browser



 Please cast your votes:

 [ ] +1 Accept OpenOffice.org for incubation
 [ ] +0 Indifferent to OpenOffice.org incubation
 [ ] -1 Reject OpenOffice.org for incubation

 This vote will close 72 hours from now.

 - Sam Ruby

 = OpenOffice.org - An open productivity environment =
 == Abstract ==
 !OpenOffice.org is comprised of six personal productivity applications:
 a word processor (and its web-authoring component), spreadsheet,
 presentation graphics, drawing, equation editor, and database.
 !OpenOffice.org is released on Windows, Solaris, Linux and Macintosh
 operation systems, with more
 [[http://porting.openoffice.org/|communities]] joining, including a
 mature [[http://porting.openoffice.org/freebsd/|FreeBSD port]].
 !OpenOffice.org is localized, supporting over 110 languages worldwide.

 == Proposal ==
 Apache !OpenOffice.org will continue the mission pursued by the
 !OpenOffice.org project while under the sponsorship of Sun and Oracle,
 namely:

 To create, as a community, the leading international office suite that
 will run on all major platforms and provide access to all functionality
 and data through open-component based APIs and an XML-based file format.

 In addition to to building the !OpenOffice.org product, as an end-user
 facing product with many existing individual and corporate users, this
 project will also be active in supporting end-users via tutorials, user
 forums, document template repositories, etc. The project will also work
 to further enable !OpenOffice.org to be used as a programmable module in
 document automation scenarios.

 == Background ==
 !OpenOffice.org was launched as an open source project by Sun
 Microsystems in June 2000. !OpenOffice.org was originally developed
 under the name of StarOffice by Star Division, a German company, which
 was acquired by Sun Microsystems in 1999. Sun released this as open
 source in 2000. !OpenOffice.org is the leading alternative to MS-Office
 available. Its most recent major version, the 3.x series saw over

 [[http://www.webmasterpro.de/portal/news/2010/02/05/international-openoffice-market-shares.html|100

 million downloads]] in its first year. The

 [[http://www.webmasterpro.de/portal/news/2010/02/05/international-openoffice-market-shares.html|most

 recent estimates]] suggest a market share on the order of 8-15%.

 The !OpenOffice source is written in C++ and delivers language-neutral
 and scriptable functionality. This source technology introduces the
 next-stage architecture, allowing use of the suite elements as separate
 applications or as embedded components in other applications. Numerous
 other features are also present including XML-based file formats based
 on the vendor-neutral !OpenDocument Format (ODF) standard from OASIS and
 other resources.

 == Rationale ==
 !OpenOffice.org core development would continue at Apache following the
 contribution by Oracle, in accordance with Apache bylaws and its usual
 open development processes. Both Oracle and ASF agree that the
 !OpenOffice.org development community, previously fragmented, would
 re-unite under ASF to ensure a stable and long term future for
 OpenOffice.org. ASF would enable corporate, non-profit, and volunteer
 stakeholders to contribute code in a collaborative fashion.

 Supporting tooling projects will accompany the !OpenOffice.org
 contribution, providing APIs for extending and customizing
 !OpenOffice.org.

 Both !OpenOffice.org and the related tooling projects support the OASIS
 Open Document Format, and will attract an ecosystem of developers, ISVs
 and Systems Integrators. ODF ensures the users of !OpenOffice.org and
 related solutions will own their document data, and be free to choose
 the application or solution that best meets their requirements.

 The !OpenOffice.org implementation will serve as a reference
 implementation of the Open Document Format standard.

 = Current Status =
 == Meritocracy ==
 We understand the 

Re: What is Champion?

[dsh]

Hi Kazunari,

that's an explanation of the role Champion as it can be found at the
Apache incubator proposal guide [1]:

The Champion is a person already associated with Apache who leads the
proposal process. It is common - but not necessary - for the Champion
to also be proposed as a Mentor.

A Champion should be found before the proposal is formally submitted.

[1] 
http://incubator.apache.org/incubation/Roles_and_Responsibilities.html#Champion

Cheers
Daniel

On Sat, Jun 11, 2011 at 11:26 PM, Kazunari Hirano khir...@gmail.com wrote:
 Hi Sam Ruby san,

 Thanks for your proposal.
 http://wiki.apache.org/incubator/OpenOfficeProposal
 As written in the proposal, you are Champion of Apache
 OpenOffice.org incubator project (Apache calls this podling,
 right?).

 What is Champion?
 What does Champion do?

 Thanks,
 khirano

 -
 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: Request: Can proposed committers introduce themselves?

[dsh]

On Wed, Jun 8, 2011 at 3:58 PM,  robert_w...@us.ibm.com wrote:
 A sufficiently complex business application based on OpenOffice is going
 to involve document manipulations at both tiers.  For example, we recently
 (at IBM) made an insurance solution that involved using Symphony, extended
 with a Plugin, submitting documents into a workflow, where they were
 introspected and validated using the ODF Toolkit.


Of course the ODF Toolkit isn't a golden fleece for server side ODF
processing. I would rather call it a good compromise offering some
room for improvement. If we would have had a choice we would have
preferred a headless OO runing on either AIX or z/OS ;) For instances
you still have to code a comprehensive amount of XSL stylesheets if
using the ODF toolkit. One drawback we faced was that customers
created their ODF documents during design time using Symphony and
during runtime while mass-producing business correspondence documents
the ODF Toolkit generated documents which were not 100% formatted
equal to what has been created in Symphony earlier on. Thus our
preference to use the same formatting engine (i.e. Symphony/OO) during
both design time and run time.

Cheers
Daniel

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

Re: Dcument automation with ODF (was Re: Request: Can proposed committers introduce themselves?)

[dsh]

Actually I evaluated XSL-FO rendering engines quite excessively
including Apache FOP. At that point in time (2009) Apache FOP still
had performance issues in scenarios where you would generate thousands
of business correspondence documents to be sent to clients on a daily
basis. In the end we decided to go with a commercial XSL-FO rendering
engine vendor where we had been using Apache FOP initially.
Additionally at that point in time the most recent Apache FOP version
did not have an open source approval which is of course an
IBM-internal detail.

The reason why we picked a commercial XSL-FO rendering engine was it's
stability, some proof records such as clients already using this
particular commercial XSL-FO rendering engine and it's feature
richness such as AFP and 2D barcode (e.g. data matrix) support which
is essential if you want to directly print to commercial printers.
IIRC besides those issues one issue that probably applies to any
XSL-FO rendering engine at least to a certain degree is that depending
on how much time you spend on the XSL stylesheet it might be pretty
expensive (in terms of man hours) to reassemble the layout of the
original ODF document in the PDF document (e.g. the final document
generated during runtime does not look the same to what has been
defined by the business user during design time either using Symphony
or OO). Hence my statement that it would have been nice if the core
Symphony/OO ODF-PDF transformation would have been available as a
separate library/module which could have been run on the server (AIX
or z/OS). That way the business user would have been using the same
transformation engine as the one used on the backend.

These days, if I would be in a position to redo the design I would be
tempted to figure out whether the whole transformation process could
be off-loaded to a self-contained appliance such as datapower XA35 or
even XI50. The datapower blade extension unit would even offer to
off-load MIPS from the mainframe, something that illustrates that
efficient ODF transformation is key in commercial environments where
MIPS are expensive.

But anyway I guess this scenario is a pretty advanced scenario cause
it involves a distributed server infrastructure and a business
application that generates large amounts of either PDF or AFP
documents on a daily basis.

Cheers
Daniel

On Wed, Jun 8, 2011 at 6:51 PM,  robert_w...@us.ibm.com wrote:
 dsh daniel.hais...@googlemail.com wrote on 06/08/2011 12:15:52 PM:


 Of course we had been using ODFDOM but the issue is how do you get ODF
 transformed accordingly to other formats such as RTF, AFP or PDF and
 make those formats look consistent with what you would get if doing
 the transformation natively during design time in OO or Symphony.



 I think your observation is correct.  The ODF Toolkit does not currently
 have a good way of generating print or print equivalent output from an ODF
 document.  The Toolkit had no layout or rendering support.

 But I wonder if this is something that Apache FOP could help solve?

 The styling vocabulary of ODF is loosely borrowed from XSL Formatting
 Objects (XSL:FO).   It may be possible to generate XSL:FO from ODF much
 more easily than converting from ODF to PDF or Postscript directly.  But
 once we have the XSL:FO intermediary, then the pipeline could continue
 with Apache FOP to target formats ranging from PDF to raster images.

 Does that sound plausible?  Someone needs to do the layout and rendering.
 But I hate to see that code written more than once.  The ODF-XSL:FO
 conversion would be a great toolkit enhancement.  Has POI done this with
 the Microsoft formats?

 -Rob

 -
 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: Legal concern: Are we getting to close ot a division of markets conversation?

[dsh]

I guess if I get it correct the point in here is that most of us are
legal layman and thus it's not necessarily efficient if we try to sort
out legal concerns on our own. Instead this is supposed to be IP and
patent attorney business from my PoV. If assistance in this regards is
required it might be reasonable to involve
http://www.apache.org/legal/.

If IBM has legal concerns in this regards they may involve their own
IP and patent attorney stuff IBM-internally.

Cheers
Daniel

On Mon, Jun 6, 2011 at 10:27 AM, Dirk-Willem van Gulik
di...@webweaving.org wrote:
 On 6 Jun 2011, at 09:13, Andreas Kuckartz wrote:
 Am 06.06.2011 09:25, schrieb Greg Stein:
 One of the main topics of the whole discussion regarding the
 OpenOffice.org incubation proposal was and is collaboration with TDF /
 LO. And now the first initial committer from IBM in the proposal
 states that some ways of collaborating with TDF /LO might be illegal and
 should not even be discussed.


 I think that this is a very *very* valid concern. And one I've certainly 
 heard expressed in recent months more regularly than in the years past.

 And it is one which is common for 'industry consortia' like ours - who end up 
 having a lot of market impact due to their neutrality combined strength of 
 their respective markets. And that is not a theoretical thing - nor is 
 intervention (though historically such intervention has usually been at the 
 source - i.e. the amount of leeway a large company/organisation gets to work 
  bestow their good-will onto others).

 However - it is just a concern. I do not think that it is a problem - as 
 these effects are well understood at a regulatory level - and are common to a 
 lot of standards bodies and industry coordination entities.

 One of the things we could do on this side of the pond (e.g. in Europe) is 
 pro-actively open a dialogue with, say, the EU, under the digital agenda[1]. 
 I'd suggest the latter - as it has identified a number of 'actions' to which 
 collaboration between the ASF, TDF and LO would be very conductive. As 
 opposed to working with the enforcement side of the regulatory arm.

 That way we'd have the right-hand of the regulators help us shape this, we 
 help the regulators by introducing them into relatively new technology  
 power systems and we'd also further some of the Digital Agenda - which I 
 personally think is a good thing.

 Thanks,

 Dw

 1: http://ec.europa.eu/information_society/digital-agenda/index_en.htm



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

Re: OO.o and web widgets

[dsh]

The only widget's I used with Lotus Symphony are widgets similar to
[1]. Not sure whether it would be possible to use iWidgets originating
from Lotus Mashups or even OpenSocial Gadgets in a similar way like
they could be consumed by Rational Team Concert [2].

[1] http://www-10.lotus.com/ldd/lswiki.nsf/dx/08062009095857AMJDOJBL.htm
[2] http://rollerweblogger.org/roller/entry/ibm_talking_opensocial_googleio

Cheers
Daniel

On Sun, Jun 5, 2011 at 10:09 AM, Ross Gardler rgard...@apache.org wrote:
 Sent from my mobile device (so please excuse typos)

 On 4 Jun 2011, at 23:31, robert_w...@us.ibm.com wrote:

 For
 example, with Lotus Symphony we've added a mechanism to integrate web
 widgets.

 I'd like to know a little more about this.

 What are web widgets in this context? Does Lotus Symphony use either of the 
 two common web widgets standards W3C Widgets or OpenSocial Gadgets?

 If so (or if there is interest in doing so) the Apache Wookie and Rave (both 
 incubating) and Apache Shindig may be relevant.

 Ross

 -
 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: OpenOffice.org: Question to IBM regarding license of Lotus Symphony

[dsh]

Andreas,

On Sat, Jun 4, 2011 at 12:24 PM, Andreas Kuckartz a.kucka...@ping.de wrote:
 I also notice that IBM currently does not sell Lotus Symphony but makes
 binaries available for free:
 http://www.ibm.com/software/lotus/symphony


Although you can download IBM Lotus Symphony for free it is still
licensed as an IBM commercial product using a particular license (ILAN
[1]). Besides that IBM Lotus Symphony is part of IBM LotusLive [2] so
the product is certainly a bit more than just the Eclipse-based client
(actually it uses a variation of Eclipse called IBM Lotus Expeditor
[3]) that one can download for free.

[1] http://www-03.ibm.com/software/sla/sladb.nsf/viewbla/
[2] https://www.lotuslive.com/
[3] http://de.wikipedia.org/wiki/Lotus_Expeditor

Cheers
Daniel

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

Re: Apache OpenOffice.org Incubator Proposal: Collaboration with TDF/LO

[dsh]

Rob,

I think being more open concerning collaboration can't hurt what do
you think? So it would be nice if the proposal could be open and
diplomatic in this regards. Probably the intention should be to not
shut the door in the very beginning and thus omit collaboration with
other parties. Tho, whether those parties accept the invitation or not
can't probably assured by the proposal BUT at least you tried your
very best.

Besides that, I was asking myself why Rob is the only one who could
add such a tone to the proposal? If there would be consensus that open
and proactive collaboration with other parties is important it's up to
the community to add such a tone to the proposal.

What do you think?

Cheers
Daniel

On Fri, Jun 3, 2011 at 9:24 PM, Greg Stein gst...@gmail.com wrote:
 On Fri, Jun 3, 2011 at 15:12,  robert_w...@us.ibm.com wrote:
...
 This is the OpenOffice proposal, not the LO proposal.  So we should be

 This is the section on how we collaborate with LO, among others. I
 consider that part of the OpenOffice proposal.

 Look at it this way: you can exclude them from the proposal in the
 name of purity (and division of community), or you can be inclusive.
 The LO community is going to be a huge influence here at Apache. It
 would be silly not to recognize that, and downright *detrimental* to
 try and pretend otherwise. I just call that divisive and not what we
 want to see here.

...
 Collaboration is not always reciprocal (heh). We can make changes in
 our codebase to support them. They can take any and all changes. They
 can ask us if we could do $X and then they'll incorporate our modified
 code into LO.

 If you don't call that collaboration, then we've got big issues.

 That would certainly be collaboration, but that is in the nature of having
 user lists and a bug tracker.  I was thinking that the IPMC would
 especially want to see any *extra* things that the proposers foresaw that
 should be noted.

 There might be more concrete things we could do, but that would be in the
 details, e.g., synching schedules for coordinated releases, coordinating
 version numbers, etc.  I can add that.

  I think that it is the very nature of Apache that anyone can take
 source
  code from our projects and reuse them on whatever fashion they wish.
  I'm
  not opposed to saying that explicitly in the wiki, but I was thinking
 that
  the proposal is a good place to note any places where we foresee
  collaboration that goes beyond the downstream rights that are inherent
 in
  the license.

 Calling TDF/LO one of many who can take our source is disingenuous.
 They are VERY definitely NOT just one of the crowd.


 I see this distinction:

 -- An extraordinary downstream consumer of OpenOffice

 versus

 -- An extraordinary collaboration


 I'll grant you that TDF/LO could be seen as the former.

 Could be? If you don't start writing down that they *will* and that
 the project should *plan* for that, then they never will be.

 I'm starting to get annoyed by your reticence here. Gonna end this
 email now. Come back later.

 -g

 -
 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: Apache OpenOffice.org Incubator Proposal: Collaboration with TDF/LO

[dsh]

+1 (I like the positive tone that tries to omit words having a
negative connotation)

Cheers
Daniel

On Sat, Jun 4, 2011 at 12:16 AM, Simon Phipps si...@webmink.com wrote:
 I suggest:

 The LibreOffice project is an important partner in the OpenOffice.org
 community, with an established potentially highly complementary focus on the
 GNU/Linux community as well as on Windows and Mac consumer end-users. We
 will seek to build a constructive working and technical relationship so that
 the source code developed at Apache can be readily used downstream by
 LibreOffice, as well as exploring ways for upstream contributions to be
 received as much as possible within the constraints imposed by mutual
 licensing choices.

 There will be other ways we may be able to collaborate, including jointly
 sponsored public events, interoperability 'plugfests', standards, shared
 build management infrastructure, shared release mirrors, coordination of
 build schedules, version numbers, defect lists, and other downstream
 requirements. We will make this relationship a priority early in the life of
 the podlet.

 S.


-
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

[dsh]

Yep and that's why I just felt tempted that it is important to
just point out that people just lost the to me in my message ;)

Cheers
Daniel

On Thu, Jun 2, 2011 at 1:18 AM, Greg Stein gst...@gmail.com wrote:
 Ease up... people just lost the to me in your message. And others
 didn't see it in the quoted sections.

 It happens

 Cheers,
 -g

 On Wed, Jun 1, 2011 at 18:31, dsh daniel.hais...@googlemail.com wrote:
 Again,

 to me means to me as in it's my personal opinion and nothing else.
 How could I be somebody defining the rules? I suspect the rules are
 all documented anyway. So you did the interpretation of an opinion
 expressed by somebody else and of course if you treat that opinion as
 a requirement or a re-definition of the rules you got it all wrong.

 Cheers
 Daniel

 On Thu, Jun 2, 2011 at 12:13 AM, Ross Gardler rgard...@apache.org wrote:
 On 01/06/2011 22:26, Greg Stein wrote:

 On Wed, Jun 1, 2011 at 17:20, Benson Marguliesbimargul...@gmail.com
  wrote:

 On Wed, Jun 1, 2011 at 5:18 PM, Ross Gardlerrgard...@apache.org  wrote:

 On 01/06/2011 19:51, robert_w...@us.ibm.com wrote:

 dshdaniel.hais...@googlemail.com    wrote on 06/01/2011 02:16:58 PM:

 ...

 And is it generally held to be a criterion
 for a podling to graduate or even initiate, that it first persuade all
 Linux distros to include it

 Generally held by whom? Citation please?

 Rob is *posing the question*. Basically, I read his message as a
 diplomatic way to say you're full of it, if you think distro adoption
 is a requirement. take your red herring elsewhere. :-)

 We don't care where it is used or how it is used. What we care about is
 whether there is a healthy community around the code base. Who makes up
 that
 community is not our concern, just as long as it is healthy.

 That's basically what Rob said. Read it again :-)

 I don't need to, I was answering Robs question with an IPMC hat. I was
 trying to support his position. I'm British I can't be as direct as you :-P

 Ross

 -
 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



 -
 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: Blondie's Parallel Lines...

[dsh]

Of course I now some more magic than just re-indent a codebase... that
would be to easy to spot wouldn't it ;)

Seriously: I doubt some code analysis or commit log analysis practices
especially if the goal would be to make an assertion about someones
performance. IMHO that leaves a bad taste in an OSS environment and
is probably counter productive and it's probably a dead end in a
commercial environment if you want to performance measure people
that way.

Cheers
Daniel

On Thu, Jun 2, 2011 at 10:10 PM, Greg Stein gst...@gmail.com wrote:
 On Thu, Jun 2, 2011 at 16:05, dsh daniel.hais...@googlemail.com wrote:
...
 Final note on commit log analysis - if that's a criterion how to
 define an active ASF participant my most active times are certainly
 pretty dated but of course I would know how to teak commit logs to
 make me look more active if I'd ever like to go down that road ;)

 Dude. Reindent the codebase. That does *wonders* for the amount of
 code that you've worked on in a project.

 :-D :-D


 Cheers,
 -g

 ps. we have a couple points in the Apache Subversion history were that
 effectively happened. A couple developers now have a seemingly huge
 level of contribution over the entire codebase. hehehe

 -
 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: Blondie's Parallel Lines...

[dsh]

Sorry no tab keys involved ... I'd like to indent with spaces :D :D

Cheers
Daniel

On Thu, Jun 2, 2011 at 10:55 PM,  robert_w...@us.ibm.com wrote:
 dsh daniel.hais...@googlemail.com wrote on 06/02/2011 04:44:26 PM:


 IMHO the project is on track the community just needs to discuss
 some more things and sort them out. It is just that I don't even think
 it's required to provide proof-points based on questionable
 analytics at this point in time. There is a saying in this regards I
 only believe in statistics that I doctored myself and that's
 certainly one reason why I feel suspicious about these kind of
 analysis :)


 Questionable?  If only 54 people have checked in code in the last 6
 months, then no amount of magic with source code indentation is going to
 get you to 400 developers.  If you disagree, I'd like to see the magic you
 can do with the tab key!

 -Rob

 -
 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: Blondie's Parallel Lines...

[dsh]

Excellent Rob! FYI Celix [1] entered the inucbator with just one
single initial committer and thus I'd say there's was no point at any
time requiring hundreds of developers backing the proposal.

[1] http://incubator.apache.org/projects/celix.html

Cheers
Daniel

On Fri, Jun 3, 2011 at 12:12 AM,  robert_w...@us.ibm.com wrote:
 Greg Stein gst...@gmail.com wrote on 06/02/2011 05:45:57 PM:


 On Thu, Jun 2, 2011 at 16:55,  robert_w...@us.ibm.com wrote:
  dsh daniel.hais...@googlemail.com wrote on 06/02/2011 04:44:26 PM:
 
 
  IMHO the project is on track the community just needs to discuss
  some more things and sort them out. It is just that I don't even
 think
  it's required to provide proof-points based on questionable
  analytics at this point in time. There is a saying in this regards I
  only believe in statistics that I doctored myself and that's
  certainly one reason why I feel suspicious about these kind of
  analysis :)
 
 
  Questionable?  If only 54 people have checked in code in the last 6
  months, then no amount of magic with source code indentation is going
 to
  get you to 400 developers.  If you disagree, I'd like to see the magic
 you
  can do with the tab key!

 Rob: does this need to continue?


 If we're all now satisfied of the plausibility of growing a sufficiently
 large developer base this code base, and no one is still maintaining that
 we need hundreds of developers, then I think we're done.

 -Rob


 -
 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: OpenOffice.org Apache Incubator Proposal

[dsh]

To me the proof point whether this proposal will be successful or not
is whether Linux distributions having already dropped support for
OpenOffice and switched to LibreOffice instead would be willing to
reverse that decision and move back to OpenOffice again now that it is
in a process to be proposed to become an Apache incubator project.

Cheers
Daniel

On Wed, Jun 1, 2011 at 8:08 PM, Jochen Wiedmann
jochen.wiedm...@gmail.com wrote:
 I view this proposal very critical. IMO, OpenOffice@Apache would be a dead 
 end:

 - There is an existing community over at LibreOffice. So what good
 does it, to build a second community here?
 - The afore mentioned community was built exactly, because the
 initiators of the current proposal have been unable to hold the
 community. Why should they do any better, if the code base where moved
 to Apache?
 - While LibreOffice could take over any ASL'ed code, the opposite
 wouldn't be true. In other words, LibreOffice would have a very clear
 advantage that could never be eliminated as long as the project where
 ASL'ed.

 Jochen

 --
 I Am What I Am And That's All What I Yam (Popeye)

 -
 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: OpenOffice.org Apache Incubator Proposal

[dsh]

Guys,

to me means to me as in it's my personal opinion and nothing else.
And that opinion of course still stands unchanged. I never wrote
anything about requirements especially not in a sense of formal
requirements.

Cheers
Daniel

On Wed, Jun 1, 2011 at 11:30 PM, Benson Margulies bimargul...@gmail.com wrote:
 Greg,

 I'm happy to see more people throw tomatoes at the 'distro
 requirement'. At the quote depth at the time, I though I was just
 joining Ross in challenging that supposed requirement.

 --benson


 On Wed, Jun 1, 2011 at 5:26 PM, Greg Stein gst...@gmail.com wrote:
 On Wed, Jun 1, 2011 at 17:20, Benson Margulies bimargul...@gmail.com wrote:
 On Wed, Jun 1, 2011 at 5:18 PM, Ross Gardler rgard...@apache.org wrote:
 On 01/06/2011 19:51, robert_w...@us.ibm.com wrote:

 dshdaniel.hais...@googlemail.com  wrote on 06/01/2011 02:16:58 PM:

 ...

 And is it generally held to be a criterion
 for a podling to graduate or even initiate, that it first persuade all
 Linux distros to include it

 Generally held by whom? Citation please?

 Rob is *posing the question*. Basically, I read his message as a
 diplomatic way to say you're full of it, if you think distro adoption
 is a requirement. take your red herring elsewhere. :-)

 We don't care where it is used or how it is used. What we care about is
 whether there is a healthy community around the code base. Who makes up 
 that
 community is not our concern, just as long as it is healthy.

 That's basically what Rob said. Read it again :-)

 Cheers,
 -g

 -
 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



-
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

[dsh]

Again,

to me means to me as in it's my personal opinion and nothing else.
How could I be somebody defining the rules? I suspect the rules are
all documented anyway. So you did the interpretation of an opinion
expressed by somebody else and of course if you treat that opinion as
a requirement or a re-definition of the rules you got it all wrong.

Cheers
Daniel

On Thu, Jun 2, 2011 at 12:13 AM, Ross Gardler rgard...@apache.org wrote:
 On 01/06/2011 22:26, Greg Stein wrote:

 On Wed, Jun 1, 2011 at 17:20, Benson Marguliesbimargul...@gmail.com
  wrote:

 On Wed, Jun 1, 2011 at 5:18 PM, Ross Gardlerrgard...@apache.org  wrote:

 On 01/06/2011 19:51, robert_w...@us.ibm.com wrote:

 dshdaniel.hais...@googlemail.com    wrote on 06/01/2011 02:16:58 PM:

 ...

 And is it generally held to be a criterion
 for a podling to graduate or even initiate, that it first persuade all
 Linux distros to include it

 Generally held by whom? Citation please?

 Rob is *posing the question*. Basically, I read his message as a
 diplomatic way to say you're full of it, if you think distro adoption
 is a requirement. take your red herring elsewhere. :-)

 We don't care where it is used or how it is used. What we care about is
 whether there is a healthy community around the code base. Who makes up
 that
 community is not our concern, just as long as it is healthy.

 That's basically what Rob said. Read it again :-)

 I don't need to, I was answering Robs question with an IPMC hat. I was
 trying to support his position. I'm British I can't be as direct as you :-P

 Ross

 -
 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 Howl as an Incubator Project

[dsh]

There as well existed an open source project called Howl in 2005 or so
which implemented Zeroconf (Apple calls the commercial incarnation
Bonjour).

See: http://www.porchdogsoft.com/ - About

Howl is available in the FreeBSD ports collection and on SF.NET

 - http://www.freebsd.org/cgi/url.cgi?ports/net/howl/pkg-descr
 - http://sourceforge.net/projects/howl/

Cheers
Daniel

On Wed, Mar 9, 2011 at 7:00 PM, Roy T. Fielding field...@gbiv.com wrote:
 On Mar 9, 2011, at 8:23 AM, Alan Gates wrote:

 Some context here for you.  Howl is a project that was recently accepted to 
 the Incubator.  It is a proposed new component in the Hadoop eco system.  
 There is significant concern in the Incubator that this will clash with the 
 name of the Howl OW2 project (http://howl.ow2.org/) and thus cause Apache 
 legal troubles.  The relevant email threads can be seen at 
 http://tinyurl.com/5w7y9p9 and http://tinyurl.com/4t7jjt9.  As can be seen 
 in the email threads some are concerned about legal issue while some feel 
 that the use of the name is acceptable.

 There is interest in the team proposing Howl to keep the name since the name 
 has already been in use for 9 months in the Hadoop, Pig, and Hive 
 communities (without confusion or legal issues I might add).  However, we 
 would like to get legal's input on whether using Howl for this project name 
 presents a risk for Apache.  Thanks.

 It isn't just a legal issue.  Generally speaking, it is rude to use a
 product name for an open source project when that name is already in
 use by another open source project (and in this case has been in use
 since 2004).  What's more, their use of the name actually makes sense.
 We try not to be rude to OW, and they try not to be rude to us.

 So, the answer from this board member is no, you will not be allowed
 to use that name at Apache.  Even if the incubator accepted it, the
 board would insist on a change later on because it isn't a nice thing
 to do to others.  9 months discussion in Hadoop/Pig/Hive is irrelevant
 when compared to seven years of actual product releases by that other
 project.

 Roy


 -
 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 Howl as an Incubator Project

[dsh]

http://www.porchdogsoft.com/ as well provides a Zeroconf
implementation called Howl and I am not sure whether Porchdog Software
finally got acquired by Apple. The favicon and certain information on
the site could make you think Apple did exactly that.

Cheers
Daniel

On Wed, Feb 23, 2011 at 5:17 PM, ant elder ant.el...@gmail.com wrote:
 On Wed, Feb 23, 2011 at 3:59 PM, Kevan Miller kevan.mil...@gmail.com wrote:

 On Feb 23, 2011, at 4:55 AM, Alex Karasulu wrote:

 +1

 However there might be a name conflict with the Howl transaction log over at
 object web here:

   http://howl.ow2.org/

 http://howl.ow2.org/Originally from the title, I immediately thought the
 proposal was for OW's HOWL implementation to enter the incubator.

 Agreed about the name conflict. I made the same assumption.


 And I also did too.

 IMHO this should pick a different name. And i think this should be
 resolved before the incubation starts so that if the decision is taken
 to rename then all the mailing lists etc don't need to get renamed
 after they're created.

  ...ant


   ...ant

 -
 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: [PROPOSAL] Propose Howl as an Apache Incubator project

[dsh]

There as well exists a Zeroconf implementation called Howl and I am
pretty certain that some other projects are using that name too.

Cheers
Daniel

On Sun, Feb 13, 2011 at 6:57 PM, Mohammad Nour El-Din
nour.moham...@gmail.com wrote:
 Good catch, but allow me to disagree with you. Howl here is a name,
 while OW2 HOWL is an acronym for High-speed ObjectWeb Logger and on
 [1] it is all written in capital letters.

 [1] - http://howl.ow2.org/

 On Sun, Feb 13, 2011 at 5:52 PM, Brian McCallister bri...@skife.org wrote:
 The proposal looks fine, but the name collides with http://howl.ow2.org/

 -Brian

 On Thu, Feb 10, 2011 at 1:37 PM, Alan Gates ga...@yahoo-inc.com wrote:
 I would like to propose Howl as an Apache Incubator project.  Howl is a
 table and storage management service for data created using Apache Hadoop.
  The proposal is on the Incubator wiki at
 http://wiki.apache.org/incubator/HowlProposal and is pasted below.  Thanks.

 Alan.

 == Abstract ==
 Howl is a table and storage management service for data created using Apache
 Hadoop.

 == Proposal ==
 The vision of Howl is to provide table management and storage management
 layers for Apache Hadoop.  This includes:
  * Providing a shared schema and data type mechanism.
  * Providing a table abstraction so that users need not be concerned with
 where or how their data is stored.
  * Providing interoperability across data processing tools such as Pig, Map
 Reduce, Streaming, and Hive.

 == Background ==
 Data processors using Apache Hadoop have a common need for table management
 services.  The goal of a table management service is to track data that
 exists in a Hadoop grid and present that data to users in a tabular format.
  Such a table management service needs to provide a single input and output
 format to users so that individual users need not be concerned with the
 storage formats that are chosen for particular data sets.  As part of having
 a single format, the data will need to be described by one type of schema
 and have a single datatype system.

 Additionally, users should be free to choose the best tools for their use
 cases.  The Hadoop project includes Map Reduce, Streaming, Pig, and Hive,
 and additional tools exist such as Cascading.  Each of these tools has users
 who prefer it, and there are use cases best addressed by each of these
 tools.  Two users on the same grid who need to share data should not be
 constrained to use the same tool but rather should be free to choose the
 best tool for their use case.  A table management service that presents data
 in the same way to all of the tools can alleviate this problem by providing
 interfaces to each of the data processing tools.

 There are also a few other features a table management service should
 provide, such as notification of when data arrives.

 A couple of developers at Yahoo! started the project. It is based on the
 Hive !MetaStore component. There is good amount of interest in such a
 service expressed from Yahoo!, Facebook, !LinkedIn, and, others. We are
 therefore proposing to place Howl in the Apache incubator and to build an
 open source community around it.


 == Rationale ==
 There is a strong need for a table management service, especially for large
 grids with petabytes of data, and where the data volume is increasing by the
 day. Hadoop users need to find data to read and have a place to store their
 data.  Currently users must understand the location of data to read, the
 storage format, compression techniques used, etc.  To write data they need
 to understand where on HDFS their data belongs, the best compression format
 to use, how their data should be serialized, etc.

 Most users do not want to be concerned with these issues.  They want these
 managed for them.

 Having it as an Apache Open Source project will highly benefit Howl from the
 point of view of getting a large community that currently uses Hadoop and
 the other products built around Hadoop (like Pig, Hive, etc.). Users of the
 Hadoop ecosystem can influence Howl’s roadmap, and contribute to it. Looking
 at it in another way, we believe having Howl as part of the Hadoop ecosystem
 will be a great benefit to the current Hadoop/Pig/Hive community too.

 == Current Status ==
 === Meritocracy ===
 Our intent with this incubator proposal is to start building a diverse
 developer community around Howl following the Apache meritocracy model. We
 have wanted to make the project open source and encourage contributors from
 multiple organizations from the start. We plan to provide plenty of support
 to new developers and to quickly recruit those who make solid contributions
 to committer status.

 === Community ===
 Howl is currently being used by developers at Yahoo! and there has been an
 expressed interest from !LinkedIn and Facebook. Yahoo! also plans to deploy
 the current version of Howl in production soon. We hope to extend the user
 and developer base further in the future. The current developers 

Re: [VOTE] Accept Lucene.Net for incubation

[dsh]

[X ] +1 Accept Lucene.Net for incubation
[ ] +0 Don't care
[ ] -1 Reject for the following reason:

Cheers
Daniel

On Thu, Jan 27, 2011 at 7:05 AM, Troy Howard thowar...@gmail.com wrote:
 All,

 Since posting the Lucene.Net Incubator proposal announcement on Jan
 12th, we now have three mentors signed up and would like to call a
 vote to accept Lucene.Net into the Apache Incubator.

 The proposal is included below and can also be found at:

 http://wiki.apache.org/incubator/Lucene.Net%20Proposal

 Please cast your votes:

 [ ] +1 Accept Lucene.Net for incubation
 [ ] +0 Don't care
 [ ] -1 Reject for the following reason:

 Thanks,
 Troy


 = Lucene.Net - A .NET port of Lucene =
 == Preface ==
 Lucene.Net is a sub-project which is being spun off from the Lucene
 TLP but is not yet ready for graduation. We propose to address certain
 needs of the project by transitioning to an Incubator Podling.

 == Abstract ==
 Lucene.Net will be a port of the Lucene search engine library, written
 in C# and targeted at .NET runtime users.

 == Proposal ==
 Lucene.Net has three aims. First, it will maintain the existing
 line-by-line port from Java to C#, fully automating and commoditizing
 the process such that the project can easily synchronize with the Java
 Lucene release schedule. Second, it will be a high-performance C#
 search engine library. Third, it will maximize its usability and power
 when used within the .NET runtime. To that end, it will present a
 highly idiomatic, carefully tailored API that takes advantage of many
 of the special features of the .NET runtime.

 == Background ==
 Lucene.Net, began as a independent project focused on creating a
 line-by-line, API for API port of Java Lucene to C#. It continued
 successfully in this way and eventually became a ASF Incubator project
 in April of 2006 and graduated as a sub-project of Lucene in October
 of 2009.

 The last year has been challenging for the project. The committers who
 originally lead the project have stopped maintaining it and
 development has stagnated since June of 2010. The user community has
 spoken out requesting a change in philosophy and direction for the
 project, but those requests have been unheeded. This has led to a
 number of forks outside of the ASF. We would like to bring those forks
 back in as branches and be responsive to the needs of community
 without the need for multiple non-ASF forks.

 The Lucene PMC wants to see the project continue to thrive and has
 indicated that a return to the Incubator is an appropriate step, with
 the end goal of building a new team of committers and maintaining a
 steady release cycle meeting the previously stated goals. Because
 Lucene is working to move away from being an umbrella project, a
 long term goal of the Lucene.Net project is to graduate to an ASF TLP.

 == Rationale ==
 There is great need for a search engine library in the mode of Lucene
 within the .NET runtime. Individuals naturally wish to code in their
 language of choice. Organizations which do not have significant Java
 expertise may not want to support Java strictly for the sake of
 running a Lucene installation. Developers may want to take advantage
 of C#'s unique language features and the .NET runtime's unique
 execution and interoperability model. Lucene.Net will meet all these
 demands.

 Apache is a natural home for our project given the way it has always
 operated: user-driven innovation, lively and amiable mailing list
 discussions, strength through diversity, and so on. We feel
 comfortable here, and we believe that we will become exemplary Apache
 citizens.

 == Initial Goals (to be completed before Feb 2011) ==
  * Build a new list of committers
  * Make a 2.9.2 compatible release as quickly as possible (this
 already exists, it just needs to be packaged correctly)
  * Update website, documentation, etc.
  * Create a well documented repeatable and fully automated language
 porting process
  * Start a .NET style API branch, either by incorporating some or
 all existing fork projects or by starting a new branch to this end

 == Current Status ==
 === Meritocracy ===
 We understand meritocracy and will fully embrace this concept in our
 project management methodology. One of the proposed committers, DIGY,
 has been a committer on the current Lucene.Net project since November
 2008. Prescott Nasser has been a contributor on the project,
 submitting patches, documentation, and website enhancements. Three of
 the other proposed initial committers, Troy Howard, Chris Currens and
 Sergey Mirvoda are both already actively involved in other open source
 projects, either as committers of code or in coordination roles. Troy,
 Chris, Sergey and Prescott are currently committers on a Lucene.Net
 fork known as Lucere, and as such are intimately familiar with the
 code base and share a vision for the future direction of the project.
 Scott Lombard and Michael Herndon are passionate about Lucene.Net as
 well and have already 

Re: [VOTE][PROPOSAL] EasyAnt incubator

[dsh]

[X] +1 to accept EasyAnt into the Incubator
[] 0 don't care
[] -1 object and reason why.

Cheers
Daniel

On Mon, Jan 24, 2011 at 6:14 PM, Antoine Levy-Lambert anto...@gmx.de wrote:
 I would like to present for a vote the following proposal to be sponsored by
 the Ant PMC for a new EasyAnt podling.

 The proposal is available on the wiki at and included below:

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

 [] +1 to accept EasyAnt into the Incubator
 [] 0 don't care
 [] -1 object and reason why.

 Thanks,
 Antoine Levy-Lambert

 --- Proposal text from the wiki ---


 EasyAnt Proposal

 The following presents the proposal for creating a new EasyAnt project
 within the Apache Software Foundation.

 = Abstract =

 Easyant is a build system based on Apache Ant and Apache Ivy.

 = Proposal =

 EasyAnt goals are :

 * to leverage popularity and flexibility of Ant.
 * to integrate Apache Ivy, such that the build system combines a
 ready-to-use dependency manager.
 * to simplify standard build types, such as building web applications, JARs
 etc, by providing ready to use builds.
 * to provide conventions and guidelines.
 * to make plugging-in of fresh functionalities easy as writing simple Ant
 scripts as Easyant plugins.

 To still remain adaptable,

 * Though Easyant comes with a lot of conventions, we never lock you in.
 * Easyant allows you to easily extend existing modules or create and use
 your own modules.
 * Easyant makes migration from Ant very simple. Your legacy Ant scripts
 could still be leveraged with Easyant.

 = Rationale =

 On the Ivy and Ant mailing list, an often asked question is Why Ivy is not
 shipped with Ant ?. Ant users (and some opponents) complains also about the
 bootstrapping of an Ant based build system: it is mainly about copying an
 existing one. EasyAnt is intended to response to both of these requirements:
 a prepackaged Ant + Ivy solution with standard build script ready to be
 used.

 Also taking inspiration from the success of Apache Maven, EasyAnt is
 adopting the convention over configuration principle. Then it could be
 easy to build standard project at least for all commons steps (no more need
 to reinvent the wheel between each projects). The common part should be
 easy enough to tune parameters without having deep ant knowledge (example
 changing the default directory of sources, force compilation to be java 1.4
 compatible, etc...).

 Last but not least, EasyAnt is intended to provide a plugin based
 architecture to make it easy to contribute on a specific step of the build.
 Build plugins are pieces of functionality that can be plugged into or
 removed from a project. Plugins could actually perform a piece of your
 regular build, e.g. compile java classes during build of a complete war. Or,
 do a utility action, e.g. deploy your built web application onto a packaged
 Jetty server!

 = Current Status =

 == Meritocracy ==

 Some of the core developers are already committers and members of the Apache
 Ant PMC, so they understand what it means to have a process based on
 meritocracy.

 == Community ==

 EasyAnt have a really small community (around 100 downloads per release). It
 is not a problem as the team is currently making restructuring changes. The
 team plans to make more promotion after those changes and strongly believe
 that community is the priority as the tool is designed to be easy to use.

 == Core Developers ==

 Xavier Hanin and Nicolas Lalev ¡ ée are members of the PMC of Apache Ant.
 Jerome Benois is an Acceleo committer, he was a committer in Eclipse MDT
 Papyrus for two years and he's an active contributor in Eclipse Modeling and
 Model Driven community. He's a committer on Bushel project now contribute to
 the Ivy code base. He leads the EasyAnt for Eclipse plugin development.
 Jason Trump is leading Beet project on sourceforge
 (http://beet.sourceforge.net/).
 Jean-Louis Boudart is Hudson committer.

 == Alignment ==

 EasyAnt is based on Apache Ant and Ivy. Being part of Apache could help for
 a closer collaboration between projects.
 The team plans to reinject as much as possible stuff into Ant or Ivy like
 they've done in the past on :
 * extensionPoint : kind of IoC for targets (Ant)
 * import/include mechanism (Ant)
 * module inheritance (Ivy)

 = Known risks =

 == Orphaned products ==

 Jean-Louis Boudart is the main developer of EasyAnt. Other developers got
 interested in this project and are now touching to every aspect of EasyAnt.
 Thus the risk of being orphaned is quite limited.

 == Inexperience with Open Source ==

 Many of the committers have experience working on open source projects. Two
 of them have experience as committers on other Apache projects.

 == Homogenous Developers ==

 The existing committers are spread over a number of countries and employers.

 == Reliance on Salaried Developers ==

 None of the developers rely on EasyAnt for consulting work.

 == Relationships with Other Apache Products ==

 As already stated 

Re: ManifoldCF - jars should not be stored in SVN

[dsh]

I just offered an advice based on my own experience nothing more :)

Cheers
Daniel

On Mon, Jan 10, 2011 at 3:48 AM, Benson Margulies bimargul...@gmail.com wrote:
 Gang,

 Please be clear about when you are offering advice to podlings and
 when you are conveying policy. The people in the podlings get
 justifiably rattled when they get email that seems to suggest that
 they are somehow not following some rule that isn't, apparently,
 written down anywhere.

 --benson


 On Sun, Jan 9, 2011 at 8:05 PM, Michael MacFadden
 michael.macfad...@gmail.com wrote:
 There are additional benefits to dependency management systems like Maven or 
 Ivy as well.  Beyond avoiding checking in jar files, you can reference a 
 dependency once and not have to proliferate references if you have multi 
 module builds (with multiple build files).  Also, if your project gets 
 separated into multiple modules, then the build system can actually mange 
 internal dependancies.

 Of course checking Jars in to SVN is usually simpler in the short term.

 ~Michael

 On Jan 9, 2011, at 4:55 PM, dsh wrote:

 s/way/idea/

 On Mon, Jan 10, 2011 at 1:54 AM, dsh daniel.hais...@googlemail.com wrote:
 Hi,

 I'd suggest to consider dependency management systems such as Apache
 Maven or Apache Ivy as an advantage in the long run. They allow to
 precisely document your dependencies and both support an offline mode.
 Additionally both of course provide a very reliable way to define
 exactly what version of what jars are required and ensure everyone has
 the same ones.

 So don't put the way aside to migrate to a dependency management
 system as soon as possible.

 Cheers
 Daniel

 On Mon, Jan 10, 2011 at 1:46 AM, Alex North ano...@google.com wrote:
 The Wave project also has jars in its repository (on its way to Apache 
 SVN).
 That seems to be the most reliable way to define exactly what version of
 what jars are required and ensure everyone has the same ones.

 On 10 January 2011 11:16, Grant Ingersoll gsing...@apache.org wrote:

 This seems a bit over the top.  I prefer them in SVN so I can get them 
 all
 at once, which is especially nice when one is working offline.

 On Jan 9, 2011, at 5:53 PM, sebb wrote:

 I've just noticed that there are lots of jars stored in SVN under


 http://svn.apache.org/repos/asf/incubator/lcf/branches/release-0.1-branch

 AIUI, SVN should not be used for storing library jars.

 ==

 The way other projects manage this is to define the jar dependencies
 in a build file, and get the build process to download the jars.

 If using Maven, this is trivial, as declared dependencies are
 automatically downloaded.

 It's not that difficult when using Ant either - see for example the
 Tomcat or JMeter projects.

 There is also an Ant Maven task:
 http://maven.apache.org/ant-tasks/examples/dependencies.html

 and Apache Ivy
 http://ant.apache.org/ivy/

 though I've not used either of those.

 -
 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





 -
 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



 -
 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: [PROPOSAL] Accept Wave for incubation

[dsh]

+1 (non-binding)

Cheers
Daniel

On Tue, Nov 23, 2010 at 9:16 PM, Dan Peterson dpeter...@google.com wrote:
 Hello all,

 We'd like to propose Wave for entry into the ASF incubator.

 The draft proposal is available at:
 http://wiki.apache.org/incubator/WaveProposal
 (for your convenience, a snapshot is also copied below)

 A wave is a hosted, live, concurrent data structure for rich communication.
 It can be used like email, chat, or a document. Wave in a Box (WIAB) is the
 name of the main product at the moment, which is a server that hosts and
 federates waves, supports extensive APIs, and provides a rich web client.
 This project also includes an implementation of the Wave Federation
 protocol, to enable federated collaboration systems (such as multiple
 interoperable Wave In a Box instances).

 As a result of the recent Wave Summit, beyond growing a few new committers,
 we've put together the following proposal for migrating the community into
 the ASF incubator. More details on the summit  Wave in a Box progress in
 this blogpost:
 http://googlewavedev.blogspot.com/2010/11/this-weeks-wave-protocol-summit-updates.html

 We are looking forward to your feedback and suggestions.

 By the way, if you're looking to learn more about the technology related to
 wave, you can see the videos and presentations from the recent Wave Summit
 in: https://wave.google.com/wave/waveref/googlewave.com/w+rwFyiw47A

 Kind regards,
 -Dan, on behalf of the Wave Community

 P.S. For those on the wave-protocol Google Group (that aren't yet on
 general@incubator.apache.org), please participate in this discussion
 by sending a message to general-subscribe at incubator dot apache dot org


 Apache Wave Proposal (Apache Incubator)

 = Abstract =

 Apache Wave is the project where wave technology is developed at Apache.
 Wave in a Box (WIAB) is the name of the main product at the moment, which is
 a server that hosts and federates waves, supports extensive APIs, and
 provides a rich web client. This project also includes an implementation of
 the Wave Federation protocol, to enable federated collaboration systems
 (such as multiple interoperable Wave In a Box instances).

 = Proposal =

 A wave is a hosted, live, concurrent data structure for rich communication.
 It can be used like email, chat, or a document.

 WIAB is a server that hosts waves. The best analogy for this is a mail
 server with a web client. WIAB is comprised of a few high-level components:
 the client and the server. They have the following major functionality
 (though this is not an exhaustive list):

  * Client
  *A dynamic web client for users to create, edit, and search waves. Users
 can access this client by directly visiting the server in a browser.
  * Gadgets provide the ability to insert, view, and modify the UI --
 exposing the Wave Gadgets API (
 http://code.google.com/apis/wave/extensions/gadgets/guide.html)
  * A console client that can create and edit waves via a command-line-like
 interface.
  * Server
  * Hosts and stores waves. WIAB comes with a default storage mechanism. The
 administrators of the server may configure it to use alternative storage
 mechanisms.
  * Indexing, allowing for searching the waves a user has access to.
  * Basic authentication, configurable to delegate to other systems.
  * Federation, allowing separate Wave in a Box servers to communicate with
 each other using the Wave Federation Protocol (
 http://www.waveprotocol.org/federation).
  * Robots, using the Wave Robots API, (
 http://code.google.com/apis/wave/extensions/robots/) may interact with waves
 on a WIAB instance.

 = Background =

 Wave expresses a new metaphor for communication: hosted conversations. This
 was created by Lars and Jens Rasmussen after observation of people's use of
 many separate forms of communication to get something done, e.g, email,
 chat, docs, blogs, twitter, etc.

 The vision has always been to better the way people communicate and
 collaborate. Building open protocols and sharing code available in an open
 and free way is a critical part of that vision. Anyone should be able to
 bring up their own wave server and communicate with others (much like SMTP).

 We hope this project will allow everyone to easily gain the benefits of Wave
 with a standard implementation of Wave – in a box.

 = Rationale =

 Wave has shown it excels at small group collaboration when hosted by Google.
 Although Wave will not continue as a standalone Google product, there is a
 lot of interest from many organizations in both running Wave and building
 upon the technology for new products.

 We are confident that with the community-centric development environment
 fostered by the Apache Software Foundation, WIAB will thrive.

 = Initial Goals =

 The initial goals of the project are:

  1.  To migrate the codebase from code.google.com and integrate the project
 with the ASF infrastructure (issue management, build, project site, etc).
  1.  To quickly reach a state 

Re: [VOTE] Aries Graduation to TLP

[dsh]

+1 (non-binding)

On Mon, Nov 22, 2010 at 12:51 PM, Jeremy Hughes hugh...@apache.org wrote:
 Hi IPMCers and Incubator community,

 The Aries community has been discussing graduation and we feel we are
 ready to graduate to a new TLP [1]. We subsequently voted [2]. As a
 commnunity we were unanimous in deciding to graduate to a new TLP. We
 voted [3] on putting forward the resolution below for the next Board
 meeting to promote Aries to an Apache TLP and graduate from the
 Incubator. As per the graduation guide [4], the Aries PPMC voted on
 the position of Chair. That Vote is here [5] and Result is here [6]
 (Aries PPMC list membership required).

 Please VOTE on the below resolution for promoting Aries to an Apache
 TLP and graduating from the Incubator. The VOTE is open for 72 hours.

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


 ## Resolution to create a TLP from graduating Incubator podling

   X. Establish the Apache Aries 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 related to a set of pluggable Java
      components enabling an enterprise OSGi application programming
      model for deployment to a variety of OSGi based runtimes, for
      distribution at no charge to the public.

      NOW, THEREFORE, BE IT RESOLVED, that a Project Management
      Committee (PMC), to be known as the Apache Aries Project,
      be and hereby is established pursuant to Bylaws of the
      Foundation; and be it further

      RESOLVED, that the Apache Aries Project be and hereby is
      responsible for the creation and maintenance of software
      related to a set of pluggable Java components enabling an
      enterprise OSGi application programming model for deployment to
      a variety of OSGi based runtimes;
      and be it further

      RESOLVED, that the office of Vice President, Apache Aries 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 Aries Project, and to have primary responsibility
      for management of the projects within the scope of
      responsibility of the Apache Aries 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 Aries Project:

        * A. J. David Bosschaert    dav...@apache.org
        * Adam Wojtuniak    awojtun...@apache.org
        * Alan Cabrera    a...@apache.org
        * Alan T Keane    a...@apache.org
        * Alasdair Nottingham    n...@apache.org
        * Andrew Osborne    o...@apache.org
        * Bartosz Kowalewski    bko...@apache.org
        * Bertrand Delacretaz    bdelacre...@apache.org
        * Carsten Ziegeler    cziege...@apache.org
        * Chris Wilkinson    cwil...@apache.org
        * Davanum Srinivas    d...@apache.org
        * David Jencks    djen...@apache.org
        * Emily Jiang    eji...@apache.org
        * Eoghan Glynn    egl...@apache.org
        * Graham Charters    g...@apache.org
        * Guillaume Nodet    gno...@apache.org
        * Hiram R. Chirino    chir...@apache.org
        * Holly Cummins    cummi...@apache.org
        * Ian Robinson    irob...@apache.org
        * J. Daniel Kulp    dk...@apache.org
        * James Strachan    jstrac...@apache.org
        * Jarek Gawor    ga...@apache.org
        * Jean Sebastien Delfino    jsdelf...@apache.org
        * Jeremy Hughes    hugh...@apache.org
        * Joseph Alan Bohn    jb...@apache.org
        * Kevan Lee Miller    ke...@apache.org
        * Kiril Malenkov Mitov    kmi...@apache.org
        * Lei Wang    rwo...@apache.org
        * Lin Sun    lin...@apache.org
        * Mark Nuttall    mnutt...@apache.org
        * Niklas Gustavsson    n...@apache.org
        * Nikolai Dimitrov Tankov    nikol...@apache.org
        * Par Niclas Hedhman    nic...@apache.org
        * Richard McGuire    rickmcgu...@apache.org
        * Sabine Heider    heider...@apache.org
        * Sergey Beryozkin    serg...@apache.org
        * Stuart McCulloch    mccu...@apache.org
        * Timothy James Ward    timothyjw...@apache.org
        * Valentin Mahrwald    mahrw...@apache.org
        * Violeta Georgieva Georgieva    violet...@apache.org
        * Zhaohui Feng    rf...@apache.org
        * Zoe Slattery    z...@apache.org


      NOW, THEREFORE, BE IT FURTHER RESOLVED, that Jeremy
      Hughes be appointed to the office of Vice President, Apache Aries,
      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,
      

Re: [Proposal] Accept Jena into the Incubator

[dsh]

+1 (non-binding)

Cheers
Daniel

On Tue, Nov 9, 2010 at 12:36 AM, Ross Gardler rgard...@apache.org wrote:
 I am pleased to offer, for your consideration, the following proposal to
 accept Jena, a semantic web framework into the incubator. The text of the
 proposal is copied here for your convenience and can be found at
 http://wiki.apache.org/incubator/JenaProposal

 We currently have two mentors so we're looking for at least one more.

 Note that there is already an overlapping discussion about interaction
 between this and other semantic web projects in the incubator. As champion
 of this proposal I have recommended that the Jena team participate in this
 discussion. I'm not able to speak for the Jena committers, but I am keen to
 see *appropriate* sharing of code between projects.

 However, I don't believe that this should be forced upon the three projects
 as part of their incubation. Such collaboration should emerge through
 community engagement, with mentor guidance, rather than through incubator
 conditions of entry or graduation.

 Comments and volunteers welcome.

 Now for the proposal:

 = Jena, a Semantic Web Framework =
 == Abstract ==
 Jena is a semantic web framework for Java, based on W3C standards.

 == Proposal ==
 Jena provides a semantic web framework in Java that implements the key W3C
 recommendations for the core semantic web technologies of RDF and SPARQL.
  Jena is a number of components and modules built on this core system.  It
 currently includes:

  * an API for working with RDF
  * Parsers and writers for the RDF formats (RDF/XML, Turtle, N-triples,
 NQuads, TriG)
  * an implementation of SPARQL, the W3C standard RDF query language
  * multiple storage systems for RDF data including in-memory, file-backed,
 in SQL databases and in custom scalable storage systems
  * an API for manipulation of OWL
  * a rule-based inference engine
  * an implementation of GRDDL for extraction of RDF from XML formats
  * a standards compliant IRI library.

 The project includes facilities based around this core to encourage the
  creation of components and contributions both as part of Jena and also  as
 companion open source activities.

 This proposal includes the main components of Jena: the main Jena download,
 ARQ, GRDDL, SDB, TDB, the IRI  library and Joseki.  Other components may be
 contributed later - we're  just starting with the main part of Jena for now.

 == Background ==
 The W3C recommendations provide detailed specifications and it is important
 to follow these standards so that independently built applications can
 exchange data over the web.  Jena provides high quality  Java
 implementations of RDF input/output and storage so that application  writers
 can concentrate on the application, not the low-level details.

 W3C Semantic Web: http://www.w3.org/standards/semanticweb/

 Jena has been on !SourceForge since 2001.
 http://sourceforge.net/projects/jena/

 == Rationale ==
 The open source project was originally created as part of a research
 activity in HPLabs.  In building new systems, the researchers identified
  the value of a common platform that dealt with the low level details of
  the standards.  This lead to engagement with the standards process and  the
 creation of a framework that provided a library to deal with the  details of
 semantic web standards.  This work was released as Jena. The  developers
 have contributed implementation experience back to the working groups.

 None of the contributors now work for HP.  Providing a uniform contributor
 and licensing framework assists commercial use of Jena.

 == Current Status ==
 Jena is already an established project with a large user base in industry
 and academia.  It currently uses a BSD-style three-clause license with a
 number of contributing copyright holders. Support is primarily provided via
 the jena-...@groups.yahoo.com mailing list. The majority of the team was
 employed in HPLabs, and HP holds the majority of the copyright over the code
 - there are contributions from non-HP companies.  HP decided to close the
 research group as of October 2009 and the people from HPLabs connected with
 the project have moved on to several different semantic web companies.

 This change does not immediately affect Jena because the people who were  in
 HP still remain active contributors to Jena.  The project continues to be
 supported and actively enhanced.  There is now the  opportunity to become an
 open source project without a single large  organisation involved.

 === Meritocracy ===
 The Jena team has always been self-determining; there has not been a project
 manager in charge of the effort.  Instead, it has grown through  individuals
 contributing to the codebase as part of their research activities.  The team
 has organised itself to create the framework for builds, releases and public
 support, and people who had worked on Jena in HP, and moved to other
 companies and institutions, have continued to  contribute.