Re: [VOTE] MXNet to enter the Incubator

[Lieven Govaerts]

On Tue, Jan 17, 2017 at 5:20 AM, Henri Yandell  wrote:
> Hi Incubator folk,
>
>I would like to call a vote for accepting "MXNet" for incubation in the
> Apache Incubator.
>
> The full proposal is available at this wiki link:
>
> https://wiki.apache.org/incubator/MXNetProposal?action=recall=19
>
> I will reply to this email with a copy of the proposal.
>
> MXNet already has a broad community, which I think is clear from the
> interest from many contributors in being a part of the project at Apache.
> There are four mentors signed up, along with 2 or 3 other Apache committers
> looking to be involved in the project.
>
> Please cast your vote:
>
>   [ ] +1, bring MXNet into the Incubator
>   [ ] -1, MXNet should not enter the Incubator, because...
>
>  The vote will be open for at least 72 hours, and only votes from the
> Incubator PMC are binding.
>
> As the proposer, I consider my vote already cast in favour (and binding as
> I'm a PMC member).
>
> Thanks all,
>
> Hen


+1

Lieven

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

Re: [VOTE] Accept HTrace into the Apache Incubator

[Lieven Govaerts]

On Wednesday, 5 November 2014, Roman Shaposhnik r...@apache.org wrote:

 On Wed, Nov 5, 2014 at 11:16 AM, Roman Shaposhnik r...@apache.org
 javascript:; wrote:
  Following the discussion earlier in the thread:
 http://s.apache.org/Dk7
 
  I would like to call a VOTE for accepting HTrace
  as a new incubator project.
 
  The proposal is available at:
 
  https://wiki.apache.org/incubator/HTraceProposal
 (a full version of the proposal is attached)
 
  Vote is open until at least Sunday, 9th November 2014, 23:59:00 UTC
 
   [ ] +1 accept Lens in the Incubator
   [ ] ±0
   [ ] -1 because...


+1 (non-binding)

Lieven


 Thanks,
 Roman.

 == Abstract ==
 HTrace is a tracing framework intended for use with distributed
 systems written in java.

 == Proposal ==
 HTrace is an aid for understanding system behavior and for reasoning
 about performance
 issues in distributed systems. HTrace is primarily a low impedance
 library that a java
 distributed system can incorporate to generate ‘breadcrumbs’ or
 ‘traces’ along the path
 of execution, even as it crosses processes and machines. HTrace also
 includes various
 tools and glue for collecting, processing and ‘visualizing’ captured
 execution traces
 for analysis ex post facto of where time was spent and what resources
 were consumed.

 == Background ==
 Distributed systems are made up of multiple software components
 running on multiple
 computers connected by networks. Debugging or profiling operations run
 over non-trivial
 distributed systems -- figuring execution paths and what services,
 machines, and
 libraries participated in the processing of a request -- can be involved.

 == Rationale ==
 Rather than have each distributed system build its own custom
 ‘tracing’ libraries,
 ideally all would use a single project that provides necessary
 primitives and saves
 each project building its own visualizations and processing tools anew.

 Google described “...[a] large-scale distributed systems tracing
 infrastructure”
 in Dapper, a Large-Scale Distributed Systems Tracing Infrastructure. The
 paper
 tells a compelling story of what is possible when disparate systems
 standardize
 on a single tracing library and cooperate, ‘passing the baton’, filling out
 trace context as executions cross systems.

 HTrace aims to provide a rough equivalent in open source of the described
 core
 Dapper tools and library.  As it is adopted by more projects, there will
 be a
 ‘network effect’ as HTrace will provide a more comprehensive view of
 activity
 on the cluster.  For example, as HDFS gets HTrace support, we can connect
 this
 with the HTrace support in HBase to follow HBase requests as they enter
 HDFS.

 Given the success of HTrace depends on its being integrated by many
 projects,
 HTrace should be perceived as unhampered, free of any commercial,
 political,
 or legal ‘taint’. Being an Apache project would help in this regard.

 == Initial Goals ==
 HTrace is a small project of narrow scope but with a grand vision:
   * Move the HTrace source and repository to Apache, a vendor-neutral
 location. Currently HTrace resides at a Cloudera-hosted repository.
   * Add past contributors as committers and institute Apache governance.
   * Evangelize and encourage HTrace diffusion. Initially we will
 continue a focus on the Hadoop space since that is where most of the
 initial contributors work and it is where HTrace has been initially
 deployed.
   * Building out the standalone visualization tool that ships with HTrace.
   * Build more community and add more committers

 == Current Status ==
 Currently HTrace has a viable Java trace library that can be interpolated
 to create ‘traces’.  The work that needs to be done on this library is
 mostly
 bug fixes, ease-of-use improvements, and performance tweaks.  In the
 future,
 we may add libraries for other languages besides Java.

 HTrace has means of dumping traces to the filesystem, Twitters’ Zipkin
 (a tracing
 sink and visualization system developed by Twitter
 https://github.com/twitter/zipkin),
 or Apache HBase.  Executions can be viewed either in Zipkin or in pygraph
 (https://code.google.com/p/python-graph/).

 Since the initial sprint in the summer of 2012 which saw HTrace patches
 proposed
 for Apache HDFS and committed to Apache HBase, development has been
 sporadic;
 mostly a single developer or two adding a feature or bug fixing. HTrace is
 currently undergoing a new “spurt” of development with the effort to get
 HTrace
 added to Apache HDFS revived and a new standalone viewing facility being
 added
 in to HTrace itself.

 HTrace has been integrated by Apache Phoenix.


 === Meritocracy ===
 HTrace, up to this, has been run by Apache committers and PMC members.
 We want to
 build out a diverse developer and user community and run the HTrace
 project in
 the Apache way.  Users and new contributors will be treated with respect
 and
 welcomed; they will earn merit in the project by tendering quality patches
 and 

Re: [VOTE] Usergrid BaaS Stack for Apache Incubator (revised proposal)

[Lieven Govaerts]

On Mon, Sep 30, 2013 at 9:27 PM, Dave snoopd...@gmail.com wrote:
 I would like to call for a new vote on Usergrid, a multi-tenant
 Backend-as-a-Service stack for web  mobile applications based on RESTful
 APIs, as an Apache Incubator podling.

+1 (non-binding)

I hope to be able to contribute to this project during incubation.

Lieven

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

Re: [DISCUSS] Usergrid BaaS Stack for Apache Incubator

[Lieven Govaerts]

Hi,


note that one of the WSO2 engineers has already started participating
on the usergrid-dev list with some (small) patches.

So relax a bit, and give people some time to read the existing
docs/code and start interacting with the existing community.
Continuing to escalate this topic is not going to help the Usergrid
project and community, at least not on its way to asf incubation.

A lot of this tension could have been avoided if the Usergrid
community was explained up front that interested developers can ask to
join a future podling as initial committers, and that the incubator
promotes this as 'the right thing to do' (which I didn''t know until
now). I honestly think the WSO2 guys want to put their shoulders under
this proposal and following common Incubator practice they did that by
asking the proposer to be added as initial committers.

Maybe I'm naive here, but I rather follow my positive interpretation
of what happened and give this a chance, then to be negative about it
and risk that people will not bother to give this project  community
a try altogether.

Lieven

On Wed, Sep 25, 2013 at 9:05 AM, Alex Karasulu akaras...@apache.org wrote:
 Stop talking and start contributing.

 Show your commitment by contributing.

 Show the present community who has worked on it for 2 years that you
 understand their software and care enough to spend the time applying it.

 This way when if your CEO says get out, you'll be like GTFO I value and I
 invested my time in it. That's different than entering the project with
 nothing to lose.

 Don't expect people to just drink the cool aid here.

 On Wed, Sep 25, 2013 at 12:57 PM, Dulitha Wijewantha 
 dulit...@gmail.comwrote:

 The question here is not CEO's involvement. But rather the way everything
 reacted. Nobody likes to be accused for doing good things right? I am truly
 interested about the project but I do fear what will happen according to
 the mails sent by initial committers.. Also I didn't add my name to the
 wiki - I asked the *previous champion* of the project to add me to the
 initial committer list.

 You guys blame many people from one company coming in and then says that
 they shouldn't backdown. It's contradiction on it's own. So let's see
 things as it is -

 # First I was interested in the User-grid project coming under the apache
 umbrella
 # I wanted to contribute and help the project and mold it into a better one
 # I asked the *previous champion* to add us to the initial committer list
 # I get accused as *pilling* (this partly accuse WSO2 as well)
 # Sanjiva ask us not get involved in the project since the *current
 community* isn't welcoming
 # I withdraw my committer requests since the *current community* is
 accusing us for pilling

 *Minions aren't obliging*. I personally feel disrespected in the way people
 accuse each other for having underlying agendas. I was asking to contribute
 not *kill* the project. If we have a misunderstanding we should clear it
 out without disrespecting each other.

 PS: Also any sane person who looked at all the threads will never feel like
 contributing if they are been accused of. I personally get the feeling that
 apigee has coveted mission in bringing User-grid to Apache and not having
 other's involved in it. But hey all this can be a misunderstanding.

 Cheers




 --
 Best Regards,
 -- Alex

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

Re: [DISCUSS] Usergrid BaaS Stack for Apache Incubator

[Lieven Govaerts]

On Tue, Sep 24, 2013 at 1:25 PM, Jim Jagielski j...@jagunet.com wrote:
 Alex, if people want to join and add themselves as
 committers, then they can. The bar to entry for podlings
 during the initial proposal stage is I'm interested :)

Is there some more background available on why the barrier is set this
low in the incubator? It seems unnatural to me. A large part of
incubation of course is to attract new committers, but why not let the
podling decide on which barrier it wants to use?

I'd expect apache committers or members that are interested in a
podling's product will express that by joining with code and/or
documentation improvements, and as a result get voted in as committers
just like anyone else.

In fact, the Incubation Policy says about mentors (section Committers
at the bottom of [1]):
On acceptance of a candidate project, the assigned Mentors shall be
given access to the Podling's repository for the duration of the
incubation process. [...]
To be given full committer privileges, such as the right to add new
code to the repository, the Mentor must earn them as would any other
potential new committer.

I'm not specifically against it, I just like to understand why this is
a good idea.

Lieven

 On Sep 24, 2013, at 3:14 AM, Alex Karasulu akaras...@apache.org wrote:

 Hi Niranjan, Dulitha,

 It's fantastic to see you and others wanting to dive in and you're all more
 than welcome. We're looking forward to your involvement to the fullest
 extent possible in this community.

 The initial aim of the community right now is to meet the incubator entry
 requirements, enter the incubator, and immediately form the PPMC and
 associated mailing lists. That way we can evaluate new committers based on
 their contribution activity via standard meritocratic guidelines.

 Without cluttering this thread, we can continue with these and other
 discussions there once these structures are in place. Hopefully this will
 not take long and we can get started quickly. Until then please start
 looking at the initial code and trying to find low hanging issues to get a
 jump start.

 Cheers,
 Alex



 On Tue, Sep 24, 2013 at 9:06 AM, Niranjan Karunanandham 
 niranjan.k...@gmail.com wrote:

 +1 for the proposal and I would like to be added as a committer to the
 usergrid project. I wasn't able to add myself as a committer before voting
 was called for. Therefore I request if the champion or a mentor can add me
 to the proposal.

 Thanks.


 On Tue, Sep 24, 2013 at 7:30 AM, Dulitha Wijewantha 
 dulit...@gmail.comwrote:

 +1 for the proposal. I would liked to get added as an initial committer to
 the user-grid project. I didn't get a chance to add to the proposal before
 the vote was called. It would be great if the champion or a mentors can
 add
 it in the proposal (since now going under a vote).

 Thanks


 On Mon, Sep 23, 2013 at 11:46 PM, Marvin Humphrey mar...@rectangular.com
 wrote:

 On Mon, Sep 23, 2013 at 9:15 AM, Jim Jagielski j...@jagunet.com wrote:
 Did you see what you replied too?? propose a vote and
 the subject sez [VOTE]. :)

 It's probably an email client issue.   From the `Message-Id:` header of
 Sanjiva's emails, it looks like might be using Gmail.  With Gmail,
 changing
 the subject from '[PROPOSAL]...' to '[VOTE]...' -- or from '[VOTE]...'
 to
 '[DISCUSS]...' as I've done here -- is not enough to start a new
 conversation, i.e. thread.  Gmail de-dupes subjects where only
 bracketed
 text changes.

 There's not much to do for it except to raise awareness every once in a
 while.

 Marvin Humphrey

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




 --

 *Dulitha R. Wijewantha** Software Engineer*
 Tel: 94112793140 | Mobile: 94112793140
 dulit...@gmail.com | http://dulithawijewantha.com




 --
 *Niranjan Karunanandham*
 Senior Software Engineer
 M: +94 777 749 661 http:///




 --
 Best Regards,
 -- Alex


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


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

Re: [DISCUSS] Usergrid BaaS Stack for Apache Incubator

[Lieven Govaerts]

Forgot to add the link.

On Tue, Sep 24, 2013 at 2:40 PM, Lieven Govaerts
lieven.govae...@gmail.com wrote:
 On Tue, Sep 24, 2013 at 1:25 PM, Jim Jagielski j...@jagunet.com wrote:
 Alex, if people want to join and add themselves as
 committers, then they can. The bar to entry for podlings
 during the initial proposal stage is I'm interested :)

 Is there some more background available on why the barrier is set this
 low in the incubator? It seems unnatural to me. A large part of
 incubation of course is to attract new committers, but why not let the
 podling decide on which barrier it wants to use?

 I'd expect apache committers or members that are interested in a
 podling's product will express that by joining with code and/or
 documentation improvements, and as a result get voted in as committers
 just like anyone else.

 In fact, the Incubation Policy says about mentors (section Committers
 at the bottom of [1]):

[1]: http://incubator.apache.org/incubation/Incubation_Policy.html#Committers

 On acceptance of a candidate project, the assigned Mentors shall be
 given access to the Podling's repository for the duration of the
 incubation process. [...]
 To be given full committer privileges, such as the right to add new
 code to the repository, the Mentor must earn them as would any other
 potential new committer.

 I'm not specifically against it, I just like to understand why this is
 a good idea.

 Lieven

 On Sep 24, 2013, at 3:14 AM, Alex Karasulu akaras...@apache.org wrote:

 Hi Niranjan, Dulitha,

 It's fantastic to see you and others wanting to dive in and you're all more
 than welcome. We're looking forward to your involvement to the fullest
 extent possible in this community.

 The initial aim of the community right now is to meet the incubator entry
 requirements, enter the incubator, and immediately form the PPMC and
 associated mailing lists. That way we can evaluate new committers based on
 their contribution activity via standard meritocratic guidelines.

 Without cluttering this thread, we can continue with these and other
 discussions there once these structures are in place. Hopefully this will
 not take long and we can get started quickly. Until then please start
 looking at the initial code and trying to find low hanging issues to get a
 jump start.

 Cheers,
 Alex



 On Tue, Sep 24, 2013 at 9:06 AM, Niranjan Karunanandham 
 niranjan.k...@gmail.com wrote:

 +1 for the proposal and I would like to be added as a committer to the
 usergrid project. I wasn't able to add myself as a committer before voting
 was called for. Therefore I request if the champion or a mentor can add me
 to the proposal.

 Thanks.


 On Tue, Sep 24, 2013 at 7:30 AM, Dulitha Wijewantha 
 dulit...@gmail.comwrote:

 +1 for the proposal. I would liked to get added as an initial committer to
 the user-grid project. I didn't get a chance to add to the proposal before
 the vote was called. It would be great if the champion or a mentors can
 add
 it in the proposal (since now going under a vote).

 Thanks


 On Mon, Sep 23, 2013 at 11:46 PM, Marvin Humphrey mar...@rectangular.com
 wrote:

 On Mon, Sep 23, 2013 at 9:15 AM, Jim Jagielski j...@jagunet.com wrote:
 Did you see what you replied too?? propose a vote and
 the subject sez [VOTE]. :)

 It's probably an email client issue.   From the `Message-Id:` header of
 Sanjiva's emails, it looks like might be using Gmail.  With Gmail,
 changing
 the subject from '[PROPOSAL]...' to '[VOTE]...' -- or from '[VOTE]...'
 to
 '[DISCUSS]...' as I've done here -- is not enough to start a new
 conversation, i.e. thread.  Gmail de-dupes subjects where only
 bracketed
 text changes.

 There's not much to do for it except to raise awareness every once in a
 while.

 Marvin Humphrey

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




 --

 *Dulitha R. Wijewantha** Software Engineer*
 Tel: 94112793140 | Mobile: 94112793140
 dulit...@gmail.com | http://dulithawijewantha.com




 --
 *Niranjan Karunanandham*
 Senior Software Engineer
 M: +94 777 749 661 http:///




 --
 Best Regards,
 -- Alex


 -
 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] Usergrid BaaS Stack for Apache Incubator

[Lieven Govaerts]

+1 (non-binding)

Lieven


On Mon, Sep 23, 2013 at 2:44 PM, Jim Jagielski j...@jagunet.com wrote:
 After a useful and successful proposal cycle, I would like to propose
 a VOTE on accepting Usergrid, a multi-tenant Backend-as-a-Service
 stack for web  mobile applications based on RESTful APIs, as an Apache
 Incubator podling.

 Voting to run for 72+ hours...

 Here is a link to the proposal:
   https://wiki.apache.org/incubator/UsergridProposal

 It is also pasted below:

 = Usergrid Proposal =

 == Abstract ==

 Usergrid is a multi-tenant Backend-as-a-Service stack for web  mobile
 applications, based on RESTful APIs.


 == Proposal ==

 Usergrid is an open-source Backend-as-a-Service (“BaaS” or “mBaaS”) composed
 of an integrated distributed NoSQL database, application layer and client
 tier with SDKs for developers looking to rapidly build web and/or mobile
 applications. It provides elementary services (user registration 
 management, data storage, file storage, queues) and retrieval features (full
 text search, geolocation search, joins) to power common app features.

 It is a multi-tenant system designed for deployment to public cloud
 environments (such as Amazon Web Services, Rackspace, etc.) or to run on
 traditional server infrastructures so that anyone can run their own private
 BaaS deployment.

 For architects and back-end teams, it aims to provide a distributed, easily
 extendable, operationally predictable and highly scalable solution. For
 front-end developers, it aims to simplify the development process by
 enabling them to rapidly build and operate mobile and web applications
 without requiring backend expertise.


 == Background ==

 Developing web or mobile applications obviously necessitates writing and
 maintaining more than just front-end code. Even simple applications can
 implicitly rely on server code being run to store users, perform database
 queries, serve images and video files, etc. Developing and maintaining such
 backend services requires skills not always available or expected of app
 development teams. Beyond that, the proliferation of apps inside of
 companies leads to the creation of many different, ad-hoc, unequally
 maintained backend solutions created by employees and contractors alike and
 hosted on a wide variety of environments. This is causing poor resource
 usage, operational issues, as well as security, privacy  compliance
 concerns.

 In response to this problem, companies have long tried to standardize their
 server-side stack or unify them behind an ESB or API strategy.
 Backends-as-a-Service follow a similar approach but their unique
 characteristic is strongly tying  1) a persistence tier (typically a
 database), 2) a server-side application tier delivering a set of common
 services and 3) a set of client-side application interface mechanisms. For
 example, a BaaS could package 1) MongoDB with 2) a node.js application that
 offers access through 3) WebSockets. In the case of Usergrid, the trifecta
 is 1) Cassandra, 2) Java + Jersey and 3) a RESTful API.

 The Backend-as-a-Service approach has steadily gained popularity in the last
 few years with cloud providers such Parse.com, Stackmob.com and Kinvey.com,
 each operating tens of thousands of apps for tens of thousands of
 developers. The trend has already reached large organizations as well, with
 global companies such as Korea Telecom internally building a privately-run
 BaaS platform. But so far, there have been limited options for developers
 that want a non-proprietary, open option for hosting and providing these
 services themselves, or for enterprise and government users who want to
 provide these capabilities from their own data centers, especially on a very
 large scale.


 == Rationale ==

 The issue this proposal deals with is implicit in the name.
 Backend-as-a-Service platforms are usually offered solely as proprietary
 cloud services. They are typically closed sourced, hosted on public clouds,
 and require subscription payment. Usergrid opens the playing field, by
 making a fully-featured BaaS platform freely available to all. This includes
 developers that previously could not afford them, such as mobile
 enthusiasts, small boutiques, and cost-sensitive startups. This also
 includes large companies that benefit from a reference implementation they
 can deploy in trust, or extend to their needs without losing time writing
 less-vetted, less-performant boilerplate functionality.

 Usergrid has been open source since 2011 and has grown as an independent
 project, garnering 11 primary committers, 35 total contributors, 260+
 participants on its mailing list, with 3,700+ commits, 200+ external
 contributions, 350+ stars and 100+ forks on Github, not to mention several
 large scale production deployments at major global companies in the media,
 retail, telecommunication and government spaces.

 The Apache Software Foundation's Way, by putting community before the
 code, will help Usergrid 

Re: [PROPOSAL] Usergrid BaaS Stack for Apache Incubator

[Lieven Govaerts]

On Mon, Sep 16, 2013 at 3:39 PM, Jim Jagielski j...@jagunet.com wrote:
 I would like to propose Usergrid, a multi-tenant Backend-as-a-Service
 stack for web  mobile applications based on RESTful APIs, as an Apache
 Incubator podling.

 Here is a link to the proposal:
https://wiki.apache.org/incubator/UsergridProposal

 It is also pasted below:

 = Usergrid Proposal =

 == Abstract ==

 Usergrid is a multi-tenant Backend-as-a-Service stack for web  mobile
 applications, based on RESTful APIs.


 == Proposal ==

 Usergrid is an open-source Backend-as-a-Service (“BaaS” or “mBaaS”) composed
 of an integrated distributed NoSQL database, application layer and client
 tier with SDKs for developers looking to rapidly build web and/or mobile
 applications. It provides elementary services (user registration 
 management, data storage, file storage, queues) and retrieval features (full
 text search, geolocation search, joins) to power common app features.

 It is a multi-tenant system designed for deployment to public cloud
 environments (such as Amazon Web Services, Rackspace, etc.) or to run on
 traditional server infrastructures so that anyone can run their own private
 BaaS deployment.

 For architects and back-end teams, it aims to provide a distributed, easily
 extendable, operationally predictable and highly scalable solution. For
 front-end developers, it aims to simplify the development process by
 enabling them to rapidly build and operate mobile and web applications
 without requiring backend expertise.


 == Background ==

 Developing web or mobile applications obviously necessitates writing and
 maintaining more than just front-end code. Even simple applications can
 implicitly rely on server code being run to store users, perform database
 queries, serve images and video files, etc. Developing and maintaining such
 backend services requires skills not always available or expected of app
 development teams. Beyond that, the proliferation of apps inside of
 companies leads to the creation of many different, ad-hoc, unequally
 maintained backend solutions created by employees and contractors alike and
 hosted on a wide variety of environments. This is causing poor resource
 usage, operational issues, as well as security, privacy  compliance
 concerns.

 In response to this problem, companies have long tried to standardize their
 server-side stack or unify them behind an ESB or API strategy.
 Backends-as-a-Service follow a similar approach but their unique
 characteristic is strongly tying  1) a persistence tier (typically a
 database), 2) a server-side application tier delivering a set of common
 services and 3) a set of client-side application interface mechanisms. For
 example, a BaaS could package 1) MongoDB with 2) a node.js application that
 offers access through 3) WebSockets. In the case of Usergrid, the trifecta
 is 1) Cassandra, 2) Java + Jersey and 3) a RESTful API.

 The Backend-as-a-Service approach has steadily gained popularity in the last
 few years with cloud providers such Parse.com, Stackmob.com and Kinvey.com,
 each operating tens of thousands of apps for tens of thousands of
 developers. The trend has already reached large organizations as well, with
 global companies such as Korea Telecom internally building a privately-run
 BaaS platform. But so far, there have been limited options for developers
 that want a non-proprietary, open option for hosting and providing these
 services themselves, or for enterprise and government users who want to
 provide these capabilities from their own data centers, especially on a very
 large scale.


 == Rationale ==

 The issue this proposal deals with is implicit in the name.
 Backend-as-a-Service platforms are usually offered solely as proprietary
 cloud services. They are typically closed sourced, hosted on public clouds,
 and require subscription payment. Usergrid opens the playing field, by
 making a fully-featured BaaS platform freely available to all. This includes
 developers that previously could not afford them, such as mobile
 enthusiasts, small boutiques, and cost-sensitive startups. This also
 includes large companies that benefit from a reference implementation they
 can deploy in trust, or extend to their needs without losing time writing
 less-vetted, less-performant boilerplate functionality.

 Usergrid has been open source since 2011 and has grown as an independent
 project, garnering 11 primary committers, 35 total contributors, 260+
 participants on its mailing list, with 3,700+ commits, 200+ external
 contributions, 350+ stars and 100+ forks on Github, not to mention several
 large scale production deployments at major global companies in the media,
 retail, telecommunication and government spaces.

 The Apache Software Foundation's Way, by putting community before the
 code, will help Usergrid establish a vibrant, more diverse community to
 provide these features freely to downstream users. The incubation process
 will help 

Re: Is an android framework good candidate for Apache Incubation?

[Lieven Govaerts]

Hi Yigong,

On Mon, Jul 8, 2013 at 1:44 AM, yigong liu yigong.liu.apa...@gmail.com wrote:
 Sorry for the repost. My last email is messed up.

 Is an android framework good candidate for Apache Incubation?

 I have been working on an Android framework(library, service and app)
 for connecting android devices (phones and tablets) in a peer-to-peer
 fashion and enable communications among them. Some use cases are media
 sharing and multi-player games. Devices can be connected over WiFi,
 WiFi Direct or mobile hotspot; and the connecting process can be
 initiated through multicast, NFC tap or using camera scanning QR code.

 The design doc can be found here:
 http://www.peerdevicenet.net/arch.html

 The source code can be found here:
 https://github.com/yigongliu/PeerDeviceNet_Src

 Some API user guide can be found here:
 http://www.peerdevicenet.net/api.html

 Is such android framework good candidate to submit for Apache?

Skimming through the design doc I don't see anything that's Android specific.

Is it your goal to provide a general framework for multiple mobile
devices, with the android framework as first implementation? A
framework that can then be used by others in their applications?

Or do you want to keep it android only?

Lieven

 From incubation docs, i read advisors or champions will help
 bootstrapping candidate projects. Is there a list of champions who we
 can contact to see if they are interested?

 Thanks

 Yigong

 -
 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: Build machines: external or colocated?

[Lieven Govaerts]

On Sat, Jun 4, 2011 at 4:37 PM, Joe Schaefer joe_schae...@yahoo.com wrote:

 Most of Apache Infrastructure is based on shared resources, and our build
 environments are no exception.   We currently provide both jenkins and
 buildbot
 based build systems, and the slaves naturally run jobs for several
 projects.


While that used to be true, the Subversion project has dedicated buildbot
slaves running in a dedicated virtual machines, or machines set up but svn
folks. Once builds are taking too long to finish - thereby blocking other
builds from other projects - it doesn't make sense anymore to share slaves.

Also as for OOo a lot of libraries need to be installed to get it to build,
it'll be much easier (well, less difficult) to keep it separated from the
other projects.

Lieven


We provide access to Solaris, Linux, FreeBSD, OSX, and a few flavors of
 Windows.

 With OO I could see a situation where having dedicated resources for
 some/all
 of the OS's would make sense.  The ASF doesn't generally accept targetted
 donations
 and Infrastructure is long past the days of relying on hardware donations
 to
 survive.  We currently have a few machines in the queue that we might be
 able
 to purpose as OO build slaves, but if we need more I'm sure the board won't
 mind
 approving a budget increase for us to do so.

 In short, just tell us what you think you need resource-wise, and we'll
 work
 with you to sort out the details.  The Infrastructure Team is reachable at
 infrastructure@a.o, but I'm considering mentoring this podling to help
 bridge
 any gaps.

 HTH


 - Original Message 
  From: robert_w...@us.ibm.com robert_w...@us.ibm.com
  To: general@incubator.apache.org
  Sent: Sat, June 4, 2011 9:42:54 AM
  Subject: Build machines: external or colocated?
 
  I've heard some valid concerns about hardware resources needed to build
  OpenOffice.  Since I just happen to know a company that is in the
  hardware
  business, I might be able to get them to help out in this  department.
  But
  I wanted to first check on what the possibilities are  on the Apache
 side.
  In particular, does Apache have some way to accept  hardware donations
 and
  have them co-located in your data center, with Apache  taking care of
  physical infrastructure, back ups, bandwidth, etc.  Is  that possible at
  all?  Or should I be looking at some way these build  machines could be
  hosted externally?  How is this ordinarily done at  Apache?
 
  Regards,
 
 
  -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