Re: [VOTE] Accept Concerted into the Apache Incubator

[Sergio Fernández]

+0 (binding)

As we discussed in a previous thread, I have concerns about the current
status of the project, both regarding implementation and community, and if
incubating it now is the best for the goals of the project.

On Fri, Oct 9, 2015 at 5:55 PM, Atri Sharma  wrote:

> Hi all,
>
> Following the discussion about Concerted I would like to call a vote for
> accepting Concerted as a new incubator project.
>
> The proposal text is included below, and available on the wiki:
>
> https://wiki.apache.org/incubator/ConcertedProposal
>
> The vote is open for 72 hours:
>
> [ ] +1 accept Concerted in the Incubator
> [ ] ±0
> [ ] -1 (please give reason)
>
> Regards,
>
> Atri
>
> = Abstract =
>
> Concerted is an in memory write less read more engine aimed to provide
> extreme read performance with very high degree of concurrency and
> scalability and focus on minimizing own resource footprint.
>
> = Proposal =
> Concerted is built on the principal that a new type of workload is
> dominating the scene and is now needed to be supported. These are the large
> data set analytical workloads being analyzed or used on large clusters or
> high power machines. Large analytical workloads depend on the ability to
> query large data sets efficiently and in high concurrency while maintaining
> semantics such as immediate consistency. An in memory engine designed to
> support extreme read queries while providing support for aggregation
> through various features (such as multidimensional representation of
> tuples) will accelerate many usecases around large scale analytics.
>
> Concerted believes that best understanding of user application lies with
> user application developer. The need for massive read scaling should be on
> demand and should be flexible to the level that user can decide as to which
> representation and access of data suits his/her current requirements.
> Hence, Concerted is not built in a traditional client/server model.
> Concerted provides users with an API which can be used to load, read,
> update and delete data. User chooses which data structure has to be used
> for his current requirements. All API access is covered by Concerted's
> internal systems like lock manager, transaction manager and cache manager
> which ensure that reads scale to high level in every API call.
>
> Concerted is a Do It Yourself in memory platform for making in memory
> supporting engines. The use case we think of is supporting big data
> warehouses like Hive, but there are endless use cases for a custom, highly
> scalable in memory platform.
>
> The goal of this proposal is to leverage an existing code base available on
> Github and licensed under the Apache License 2.0 to build a community
> around the project. Currently the community consists of existing hackers of
> Concerted as well as people who have been following and associated with the
> project since a while as well as database experts who are excited about
> building a project like this. We are hoping that entering into Apache would
> help us attract more contributors as well as connect with existing big data
> projects like Apache Hive, Apache HAWQ, Apache Storm, Apache Tajo, Apache
> Spark, Apache Geode to leverage their community base while assisting in
> their use cases with Concerted. We had a discussion with founders of Apache
> Tajo and they showed interest in using Concerted for some of their use
> cases.
> = Background =
> Relational databases were built with the cost of physical memory in mind.
> The cost is no longer very relevant and physical memory is now available on
> demand. Another driving factor behind Concerted is that there is a paradigm
> shift with big data coming into picture. Disk IO speeds are more of a
> bottleneck than ever before. Combining the read dominance of analytical
> workload with the speed of in memory structures, Concerted fits the current
> scene. Also, supporting OLAP workloads with in memory support for faster
> read constant queries and joins will be useful.
>
> = Rationale =
> As explained above, large analytical workloads need an in memory
> lightweight engine which supports massive read concurrency, ground level
> support for aggregations and analytics, extreme scalability and high read
> performance, along with the engine being very light itself. Concerted aims
> to solve these needs. Concerted is designed and built with three goals as
> objectives:
>
>
> Performance
> To provide high performance access to data from a large number of rows,
> Concerted uses efficient representation and in memory indexing of data
> coupled with high performance transactions, custom transactions and
> lightweight locking and lockless techniques and an intelligent locking
> manager.
>
> Scalability
> Concerted is built with extreme concurrency and scalability in mind.
>
> Efficiency
> Concerted aims to give expected performance under vast variety of
> workloads and aims to have as low footprint as possible.
>
> = 

Re: Require projects to have solid API docs

[Greg Stein]

On Sun, Oct 11, 2015 at 11:20 PM, Julian Hyde  wrote:

> On Sun, Oct 11, 2015 at 1:11 PM, Alan D. Cabrera 
> wrote:
> > Should != Must
>
> Yes, I know. But I didn't want to have everyone leap into yet another
> long-winded debate with no one even having mentioned that there is
> existing policy on this matter.
>

Euh... no. ComDev does *not* set/create policy for the ASF. The page you
cited is not Foundation policy.

Cheers,
-g

[VOTE] Release Apache REEF 0.13.0-incubating (rc1)

[Mariia Mykhailova]

The Apache REEF PPMC has voted to release Apache REEF 0.13.0-incubating
based on the release candidate described below. Now it is the IPMC's turn
to vote.

The PPMC vote passed with 5 +1 votes:
http://mail-archives.apache.org/mod_mbox/incubator-reef-dev/201510.mbox/%3CBL2PR03MB2900A370B6F6894F8E08EA8D2370%40BL2PR03MB290.namprd03.prod.outlook.com%3E


The source tar ball, including signatures, digests, etc can be found at:
https://dist.apache.org/repos/dist/dev/incubator/reef/0.13.0-incubating-rc1/

The Git tag is release-0.13.0-incubating-rc1

The Git commit ID is e1d42e8008d97714a0f7bc303dae37239a10a029


Checksums of apache-reef-0.13.0-incubating-rc1.tar.gz:

MD5: 8e0a1cd6c7e17a86abbd32366c8cccac
SHA512: 
8f542aeaf2dc3b241bdcd0d343c607355e1f09e1ca89bbc3431b0cc1f0908479511f60900a91a6731051ffef8af30488eb85df567c32bc2db9d3d91014c4fed7

Release artifacts are signed with a key found in the KEYS file available here:

https://dist.apache.org/repos/dist/release/incubator/reef/KEYS



Issues Resolved in the release
https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12315820=12332972


The vote will be open for 72 hours. Please download the release
candidate, check the hashes/signature, build it and test it, and then
please vote:

[ ] +1 Release this package as Apache REEF 0.13.0-incubating
[ ] +0 no opinion
[ ] -1 Do not release this package because ...

Thanks!

Re: [VOTE] Accept Concerted into the Apache Incubator

[Bertrand Delacretaz]

On Fri, Oct 9, 2015 at 5:55 PM, Atri Sharma  wrote:
> ...Following the discussion about Concerted I would like to call a vote for
> accepting Concerted as a new incubator project...

+1

-Bertrand

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

Mentor disengagement - a suggestion

[Rich Bowen]

Fellow mentors,

There was a conversation at ApacheCon about the Incubator. I'll leave it 
to the other participants to champion the particular parts that they are 
passionate about, but I was particularly concerned with mentor 
disengagement, and suggestions for improving it.


A mentor's role is to help a project learn the ropes at the ASF, and 
that mentor might not necessarily be deeply versed in the particular 
technology that the podling works with. As such, it can frequently be 
the case that the mentor becomes disengaged from the daily conversation 
of the lists, and eventually with the entire process.


As a means of refocusing the mentors' efforts, and keeping them engaged, 
I'd like to encourage each mentor (or group of mentors) to consider 
writing a running report (ie, evolving, updated every quarter) based on 
https://community.apache.org/apache-way/apache-project-maturity-model.html 
where they evaluate each point on the maturity model, as a path towards 
graduation. This gives a concrete target, and a lens through which to 
view the podling's progress towards that target.


This could be kept in the incubator wiki, and linked from the official 
project report, or it could be maintained just for your own benefit. I 
think it would be particularly useful to attach to a graduation 
recommendation, as a sign that the recommendation is more than just 
checking the various boxes, but is a glowing endorsement of the 
project's readiness to be TLP.


As a side-note, I'd also encourage mentors who are mentors in name only, 
and not reality, to consider cleaning up the paperwork by removing 
themselves from the roster. It doesn't look great when a podling can't 
get mentor signoff on their reports.


--
Rich Bowen - rbo...@rcbowen.com - @rbowen
http://apachecon.com/ - @apachecon

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

Re: [VOTE] Release Apache REEF 0.13.0-incubating (rc1)

[Daniel Gruno]

Did the usual checks;
- Sigs, hash etc checks
- unpacks fine
- license, notice present
- Things are apache licensed :)

There are a few C# files missing license headers, see
http://compliance.rocks/result.html?23410ea9 - but that's nothing that
can't be fixed. I also saw a BSD license but no BSD license headers -
I'm assuming that's just a third party lib that's not as aggressively
marking its files as we do.

On the whole, it looks good. I have not tested whether the programs
actually _work_ - I'll leave that to people who know what REEF is and
does :)

+1

With regards,
Daniel.

On 10/10/2015 04:02 AM, Mariia Mykhailova wrote:
> The Apache REEF PPMC has voted to release Apache REEF 0.13.0-incubating
> based on the release candidate described below. Now it is the IPMC's turn
> to vote.
> 
> The PPMC vote passed with 5 +1 votes:
> http://mail-archives.apache.org/mod_mbox/incubator-reef-dev/201510.mbox/%3CBL2PR03MB2900A370B6F6894F8E08EA8D2370%40BL2PR03MB290.namprd03.prod.outlook.com%3E
> 
> 
> The source tar ball, including signatures, digests, etc can be found at:
> https://dist.apache.org/repos/dist/dev/incubator/reef/0.13.0-incubating-rc1/
> 
> The Git tag is release-0.13.0-incubating-rc1
> 
> The Git commit ID is e1d42e8008d97714a0f7bc303dae37239a10a029
> 
> 
> Checksums of apache-reef-0.13.0-incubating-rc1.tar.gz:
> 
> MD5: 8e0a1cd6c7e17a86abbd32366c8cccac
> SHA512: 
> 8f542aeaf2dc3b241bdcd0d343c607355e1f09e1ca89bbc3431b0cc1f0908479511f60900a91a6731051ffef8af30488eb85df567c32bc2db9d3d91014c4fed7
> 
> Release artifacts are signed with a key found in the KEYS file available here:
> 
> https://dist.apache.org/repos/dist/release/incubator/reef/KEYS
> 
> 
> 
> Issues Resolved in the release
> https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12315820=12332972
> 
> 
> The vote will be open for 72 hours. Please download the release
> candidate, check the hashes/signature, build it and test it, and then
> please vote:
> 
> [ ] +1 Release this package as Apache REEF 0.13.0-incubating
> [ ] +0 no opinion
> [ ] -1 Do not release this package because ...
> 
> Thanks!
> 


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

A suggestion: podling post-mortems

[Andrew Bayer]

I'd like to make a suggestion - after a podling graduates or is terminated,
the podling's mentors should be responsible for putting together a post
mortem report, or an exit interview, or whatever you want to call it. This
would cover the pain points in onboarding the podling, particular issues
hit during incubation, what made the podling easier or harder to get to
graduation, and ideally a self assessment of what the mentors think they
could have done better.

I think this would be very valuable - it'd help shine a light on
inefficiencies in getting into the ASF's infrastructure, show things to
watch for/discuss in podling cultural integration, and provide more
information and self-support for future mentors.

Thoughts?

A.

Re: A suggestion: podling post-mortems

[Rich Bowen]

On 10/12/2015 10:49 AM, Bertrand Delacretaz wrote:

Hi,

On Mon, Oct 12, 2015 at 1:18 PM, Andrew Bayer  wrote:

...I'd like to make a suggestion - after a podling graduates or is terminated,
the podling's mentors should be responsible for putting together a post
mortem report, or an exit interview, or whatever you want to call it...


I like the idea, not sure how that would look but I'd welcome an
experiment at least.



It would be very welcome to have this attached to a graduation 
resolution, so that we could have some background beyond just a 
boilerplate "time to graduate" message. That may delay the actual time 
to graduate, but would allow us to be more than a rubber stamp, but 
actually offer some oversight.


--
Rich Bowen - rbo...@rcbowen.com - @rbowen
http://apachecon.com/ - @apachecon

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

Re: A suggestion: podling post-mortems

[Pierre Smits]

Since when is the incubation process a race that must be completed in the
least amount of time? If it is, it would surely validate (for some) cutting
corners and push-through actions (and associated tactics). Is that what the
ASF wants or needs?

Best regards,

Pierre Smits

*OFBiz Extensions Marketplace*
http://oem.ofbizci.net/oci-2/

On Mon, Oct 12, 2015 at 5:39 PM, Sam Ruby  wrote:

> On Mon, Oct 12, 2015 at 11:14 AM, Bertrand Delacretaz
>  wrote:
> > On Mon, Oct 12, 2015 at 5:10 PM, Rich Bowen  wrote:
> >> ...It would be very welcome to have this attached to a
> graduation
> >> resolution, so that we could have some background beyond just a
> boilerplate
> >> "time to graduate" message
> >
> > I agree, and IMO our maturity model [1] would provide a good framework
> > for such a report.
>
> +1 to both of the above.
>
> > -Bertrand
> >
> > [1]
> https://community.apache.org/apache-way/apache-project-maturity-model.html
>
> - Sam Ruby
>
> -
> To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
> For additional commands, e-mail: general-h...@incubator.apache.org
>
>

Re: A suggestion: podling post-mortems

[Sam Ruby]

On Mon, Oct 12, 2015 at 11:14 AM, Bertrand Delacretaz
 wrote:
> On Mon, Oct 12, 2015 at 5:10 PM, Rich Bowen  wrote:
>> ...It would be very welcome to have this attached to a graduation
>> resolution, so that we could have some background beyond just a boilerplate
>> "time to graduate" message
>
> I agree, and IMO our maturity model [1] would provide a good framework
> for such a report.

+1 to both of the above.

> -Bertrand
>
> [1] https://community.apache.org/apache-way/apache-project-maturity-model.html

- Sam Ruby

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

[VOTE] Accept Mynewt into the Apache Incubator

[Sterling Hughes]

Hi All,

As mentioned in the DISCUSS thread, all feedback has been positive on
the Mynewt proposal, so I'd like to call a VOTE to accept Mynewt as a
new ASF incubator project.

The full text of the proposal is available on the incubator wiki at
the following URL:

https://wiki.apache.org/incubator/MynewtProposal?action=recall=20

I have also included the full text below.

Vote is open until Thurs, 16th October 2015, 23:59:00 PST.

[   ] +1 to accept Mynewt into the Apache Incubator
[   ] +0
[   ] -1 because...

Thank you,

Sterling


/!\ '''FINAL''' /!\

This proposal is now complete and has been submitted for a VOTE.


= Mynewt Proposal =

== Abstract ==

Mynewt is a real-time operating system for constrained embedded systems
like wearables, lightbulbs, locks and doorbells. It works on a variety of
32-bit MCUs (microcontrollers), including ARM Cortex-M and MIPS
architectures.

== Proposal ==

The goal of this proposal is to bring the Mynewt codebase (developed by
Runtime, Inc.) into the Apache Software Foundation. Mynewt is designed to
run constrained Internet of Things devices, where a small, real-time
operating system is required.

It includes the following components:

 * Real-time operating system kernel (Scheduler, Mutexes, Semaphores, etc.)

 * Command line package management and build system

 * Hardware Abstraction Layer unifying common MCU features (e.g. GPIOs,
 High Resolution Timers, PWM interfaces, UARTs, ADCs, etc.)

 * Board Support Infrastructure, that defines the framework for building
 software for various board architectures.

Should this project be accepted into the incubator, Runtime, Inc. will
assign the ASF a license to all source code developed to date and begin
the development of an open source community around the project.

== Background ==

Mynewt has been developed solely by Runtime to date. We are a team of 5
software engineers, that really love writing embedded systems.

== Rationale ==

With the momentum behind the Internet of Things, there is an increasing
need for standard open source software to help developers create connected
devices. One area where there is a large need is an open-source, liberally
licensed, community-driven RTOS (real-time operating system.)

Today, there are many RTOSes, the majority of which are provided by
proprietary vendors and many of which are not permissively licensed or
controlled by a single company. These restrictions create fragmentation,
because either not everyone can afford to purchase the operating system or
restrictions put on the OS's use (e.g. restricted to vendor-specific
platforms), means that people using other processors cannot adopt it.

The lack of a standardized operating system creates fragmentation around
everything above it. Because there is not a well adopted community driven
operating system, people don't have a place to contribute back new
drivers, or networking stacks. Additionally, there is constant work to
port and maintain software across a myriad of different operating systems,
all with slightly different APIs and interfaces.

In order for the industry to accelerate and keep up with the increasing
complexity in these devices, it's important that an open-source community
form and provide a RTOS effort that:

 * Accepts community contributions and encourages code reuse
 * Natively supports source package management, to allow for efficient
 redistribution and reuse of software across a broad swath of use cases (from
 wearables to industrial equipment)
 * Supports all of the "new" protocol stacks required for IoT (e.g.
Bluetooth, IPv6,
 etc.)
 * Has drivers for all new chipsets, sensors, and other devices

The core of Mynewt has been designed to accommodate these requirements. It
contains a small, pre-emptive RTOS core, that works on native (OS X,
Linux) and Cortex platforms (and is easily portable to others), and
standardized HAL and BSP interfaces.

It also provides a build and package management tool that allows
developers to install, develop, and redistribute source packages. This
tool allows developers to start with the core of the OS and its
interfaces, and then download only the source packages that are needed to
run their embedded project. This will allow the community to grow beyond
just porting the core of the Mynewt system and extend to all of the
necessary protocol stacks, drivers and sensor interfaces that a modern
embedded developer will need.

In addition to the Mynewt core, there is active development around a set
of commonly needed functionality when developing small embedded systems,
including:

 * A Flash Filesystem designed for small flashes, with large block sizes
 (very common in single chip designs)
 * An Open Bluetooth stack with native support for prevalent modules

== Initial Goals ==

The core of the Mynewt Operating System is functional.

The goal is to have an initial release February, 2016. Between now and
then, a number of things need to be finished:

 * Improved HAL 

Re: A suggestion: podling post-mortems

[Rich Bowen]

On 10/12/2015 11:55 AM, Pierre Smits wrote:

Since when is the incubation process a race that must be completed in the
least amount of time? If it is, it would surely validate (for some) cutting
corners and push-through actions (and associated tactics). Is that what the
ASF wants or needs?




Help us understand how you jumped from this email thread to that 
conclusion, because I'm not seeing it.


--Rich





Best regards,

Pierre Smits

*OFBiz Extensions Marketplace*
http://oem.ofbizci.net/oci-2/

On Mon, Oct 12, 2015 at 5:39 PM, Sam Ruby  wrote:


On Mon, Oct 12, 2015 at 11:14 AM, Bertrand Delacretaz
 wrote:

On Mon, Oct 12, 2015 at 5:10 PM, Rich Bowen  wrote:

...It would be very welcome to have this attached to a

graduation

resolution, so that we could have some background beyond just a

boilerplate

"time to graduate" message


I agree, and IMO our maturity model [1] would provide a good framework
for such a report.


+1 to both of the above.


-Bertrand

[1]

https://community.apache.org/apache-way/apache-project-maturity-model.html

- Sam Ruby

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







--
Rich Bowen - rbo...@rcbowen.com - @rbowen
http://apachecon.com/ - @apachecon

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

Johnzon Graduation

[Hendrik Dev]

On behalf of the Johnzon PPMC i would like to let you know that that
we currently discussing about graduating Johnzon out of the Incubator.

http://mail-archives.apache.org/mod_mbox/incubator-johnzon-dev/201510.mbox/%3CCAPm%3DoFDF6guVNc6HS%3D2TA5iBrx2X45JvFfaFpGiT%3DHg%2BnE7s_w%40mail.gmail.com%3E

Thanks
Hendrik

-- 
Hendrik Saly (salyh, hendrikdev22)
@hendrikdev22
PGP: 0x22D7F6EC

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

Re: A suggestion: podling post-mortems

[Tommaso Teofili]

I like this idea, +1.

Tommaso

2015-10-12 13:18 GMT+02:00 Andrew Bayer :

> I'd like to make a suggestion - after a podling graduates or is terminated,
> the podling's mentors should be responsible for putting together a post
> mortem report, or an exit interview, or whatever you want to call it. This
> would cover the pain points in onboarding the podling, particular issues
> hit during incubation, what made the podling easier or harder to get to
> graduation, and ideally a self assessment of what the mentors think they
> could have done better.
>
> I think this would be very valuable - it'd help shine a light on
> inefficiencies in getting into the ASF's infrastructure, show things to
> watch for/discuss in podling cultural integration, and provide more
> information and self-support for future mentors.
>
> Thoughts?
>
> A.
>

Re: [DISCUSS] Mentor neutrality policy

[Jim Jagielski]

I understand your concern but, at present, I don't see it
being an issue nor something that we need worry about.

We hope and trust mentors to wear their hats well.

> On Oct 9, 2015, at 11:07 AM, Daniel Gruno  wrote:
> 
> Hi Incubator folks,
> 
> I would like to propose we adopt a mentor neutrality policy for
> incubating podlings:
> 
> - A mentor must not be financially tied to the project or its incubation
> status.
> - A mentor must not have a vested interest in incubating, graduating or
> dismantling a podling that goes beyond the general Apache mission
> - A mentor must not be affiliated with the entity granting the code
> (company or original project community)
> 
> Furthermore, I would like to see this extended to votes on graduating or
> retiring podlings, so that only people with no organizational (aparty
> from the ASF) or financial ties to the project (or the companies behind
> it) can cast a binding vote on graduation or retirement.
> 
> This would essentially mean:
> 
> - If you work for a company (or are hired as consultant/advisor) that is
> entering a project into incubation, you cannot mentor it nor vote
> for/against its incubation, graduation or retirement.
> - If you are a in the original community behind the project, you cannot
> mentor it nor vote for/against it.
> 
> I believe this would create a neutral mentorship whose sole mission is
> to guide podlings with the interests of the ASF in mind.
> 
> 
> Please do discuss this. If there is (mostly) positive feedback, I would
> like to, at some point, have a vote on including this in the Incubator
> policy. I realize this would cut down on the number of potential
> mentors, and I would ask that more people step up to the challenge of
> mentoring if adopted.
> 
> With regards,
> Daniel
> 
> -
> To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
> For additional commands, e-mail: general-h...@incubator.apache.org
> 


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

Re: [DISCUSS] Mentor neutrality policy

[Reto Gmür]

That work under the assumption that all Jane has to deliver is a working
software. If the company is also interested in increasing its reputation by
allowing their marketing department to say thing like "We initiated the
Apache Foobar project", or "Apache OpenOffice natively supports our file
format" things become a bit more nuanced. Joining an existing community
might be more efficient code wise but less efficient marketing wise.

To bring a real example I was myself involved in: the incubation of Apache
Stanbol. Apache Stanbol comes out of a European Union funded research and
innovation project where multiple companies and research institutions where
involved. Graduating before the end of the funding period was clearly in
the interest of the project partners as this clearly was a success to
report at the final review meeting. On the other hand it might have been
better to wait till after the end of the funding period to decide on
graduation as this would have allowed to see which part of the code are
still maintained even without the funding. Without the financial/reputation
interest arising from the ongoing funded research the comparative
motivation of having the actually needed code in sustainable communities
would have been greater.

Cheers,
Reto



On Sun, Oct 11, 2015 at 10:29 PM, Ross Gardler 
wrote:

> I blogged on this topic some time ago - basically it is my opinion that if
> I am a good employee I would never try to contribute code to an Apache
> project that is not beneficial to the broader community. Such an action
> would be detrimental to her employers business. Consequently, there is no
> conflict between employer needs and community needs an ASF project.
>
> Here's a relevant excerpt:
>
> "Jane is paid to deliver results for her employer. If Jane finds that the
> best route to delivery is through community led open source she ought to
> fight for the survival of that community at all costs. It is in her
> interests to do so, both for her community reputation (employability beyond
> her current role) and for her employers satisfaction (employability in her
> current role). If Jane blows her community reputation she loses her ability
> to deliver for her employer as well as her ability to seek alternative
> employment relating to that community’s activities. A double whammy."
>
> Full blog at
> http://www.computerworlduk.com/blogs/apache-asserts/apache-openoffice-can-i-depend-on-software-built-by-volunteers--3570412/
>
> -Original Message-
> From: Reto Gmür [mailto:r...@apache.org]
> Sent: Sunday, October 11, 2015 9:53 AM
> To: general 
> Subject: Re: [DISCUSS] Mentor neutrality policy
>
> On Sat, Oct 10, 2015 at 11:40 AM, Roman Shaposhnik 
> wrote:
>
> > On Fri, Oct 9, 2015 at 6:07 PM, Daniel Gruno 
> wrote:
> > > Hi Incubator folks,
> > >
> > > I would like to propose we adopt a mentor neutrality policy for
> > > incubating podlings:
> > >
> > > - A mentor must not be financially tied to the project or its
> > > incubation status.
> >
> > I'm very strongly -1 on this for two reasons. One fundamental and one
> > operational. Fundamentally, this goes against a core ASF principle
> > that we all collaborate here as individuals by checking our corporate
> > affiliation at the door.
>
>
> I think it's naive to think that just because the members are individual
> and corporate affiliations don't formally play a role there is no influence
> by the employer. When I'm paid by a company or government agency to work on
> an apache project I don't have an effective protection against the
> directives of my employer. Maybe if I refuse to follow an employer's
> instruction to write some code for an Apache project of which I'm committer
> I could not be fired without notice, maybe I could write the patch and say
> on the list that I wrote this patch for my employer but that as an
> individual PMC member I vote against it (did something like this ever
> happen?), whichever way I'm likely to act against my financial interest.
>
> In medical journals the author's are also writing in their own name, yet
> they must declare all competing interests. Following your logic such as
> declaration would be unnecessary if the journal says somewhere that authors
> leave their affiliation at the door.
>
>
>
> > IOW, we are explicitly granting our members and committers the trust
> > required to make sure they do the right thing while they themselves
> > (or their employees) can significantly benefit (financially and
> > otherwise) from the projects.
> >
>
> Even if we trust our commiters that they do not commit a hidden back door
> on behalf of the spy agency they work for, the conflict of interest can be
> much more subtle. The company has a deadline and a release of an apache
> project before that deadline would come in very handy, will you scrutinize
> the notice files at the risk of finding something that 

Re: Mentor disengagement - a suggestion

[Emmanuel Lécharny]

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

Actually, when discussing a podling potential exit from incubation, a
[DISUSSION] thread is started on the podling mailing list, and the
mentors can express their opinion, which can be aggregated in a report
when the podling is proposed for exit, or on the opposite, when the
podling is seen as not ready, and send this report to the board (within
all the other podling reports).

Regarding inactive mentors, this is quite simple : we have a monthly
report that has to be signed off by mentors, if one mentor does not sign
it three time in a raw, shouldn't we consider that this mentor has
already stepped down ?

My 2cts...


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

Re: Mentor disengagement - a suggestion

[Rich Bowen]

On 10/12/2015 10:10 AM, Emmanuel Lécharny wrote:

Regarding inactive mentors, this is quite simple : we have a monthly
report that has to be signed off by mentors, if one mentor does not sign
it three time in a raw, shouldn't we consider that this mentor has
already stepped down ?



No, it's not simple. Actively removing people from volunteer roles is 
much more complicated than you might suppose. I'd rather focus on making 
myself a better mentor than any measures against other mentors which 
might be seen as punitive.



--
Rich Bowen - rbo...@rcbowen.com - @rbowen
http://apachecon.com/ - @apachecon

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

Incubation capacity

[Jukka Zitting]

Hi,

It sounds like ruminations about the Incubator are on the increase again,
so I figured I'd wake up from my slumber and share an insight of mine.

I believe the way the Incubator is organized sets an upper bound on the
number of podlings it can effectively manage. Based on experience and
historical data (http://incubator.apache.org/history/ *) I believe this
limit is somewhere around 30 podlings.

Assuming my theory is correct, proposed changes to the Incubator structure
should be primarily evaluated on whether they increase bandwidth (number of
podlings we can manage), decrease latency (time to graduation or
termination) or tighten the entry criteria (implicit or explicit).

Proposals that tighten exit criteria or add extra constraints (voting,
reporting, etc.) during incubation may solve some immediate issues, but
will likely not help with the big picture unless they come with termination
clauses for podlings that fail to meet the constraints.

*) That graph was one of the key metrics I looked at during my time as the
Incubator VP.

BR,

Jukka Zitting

Re: [DISCUSS] Mentor neutrality policy

[Jim Jagielski]

But it is basically *core* to who and what we are.

> On Oct 12, 2015, at 10:52 AM, Marko Rodriguez  wrote:
> 
> Hi,
> 
>> We hope and trust mentors to wear their hats well.
> 
> This quote from a colleague of mine has always stuck with me:
> 
>   "Hope is not a strategy."
> 
> Take care,
> Marko.
> 
> http://markorodriguez.com
> 
> 
>> 
>>> On Oct 9, 2015, at 11:07 AM, Daniel Gruno  wrote:
>>> 
>>> Hi Incubator folks,
>>> 
>>> I would like to propose we adopt a mentor neutrality policy for
>>> incubating podlings:
>>> 
>>> - A mentor must not be financially tied to the project or its incubation
>>> status.
>>> - A mentor must not have a vested interest in incubating, graduating or
>>> dismantling a podling that goes beyond the general Apache mission
>>> - A mentor must not be affiliated with the entity granting the code
>>> (company or original project community)
>>> 
>>> Furthermore, I would like to see this extended to votes on graduating or
>>> retiring podlings, so that only people with no organizational (aparty
>>> from the ASF) or financial ties to the project (or the companies behind
>>> it) can cast a binding vote on graduation or retirement.
>>> 
>>> This would essentially mean:
>>> 
>>> - If you work for a company (or are hired as consultant/advisor) that is
>>> entering a project into incubation, you cannot mentor it nor vote
>>> for/against its incubation, graduation or retirement.
>>> - If you are a in the original community behind the project, you cannot
>>> mentor it nor vote for/against it.
>>> 
>>> I believe this would create a neutral mentorship whose sole mission is
>>> to guide podlings with the interests of the ASF in mind.
>>> 
>>> 
>>> Please do discuss this. If there is (mostly) positive feedback, I would
>>> like to, at some point, have a vote on including this in the Incubator
>>> policy. I realize this would cut down on the number of potential
>>> mentors, and I would ask that more people step up to the challenge of
>>> mentoring if adopted.
>>> 
>>> With regards,
>>> Daniel
>>> 
>>> -
>>> To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
>>> For additional commands, e-mail: general-h...@incubator.apache.org
>>> 
>> 
>> 
>> -
>> To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
>> For additional commands, e-mail: general-h...@incubator.apache.org
>> 
> 
> 
> -
> 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] Mentor neutrality policy

[Marko Rodriguez]

Hi,

> We hope and trust mentors to wear their hats well.

This quote from a colleague of mine has always stuck with me:

"Hope is not a strategy."

Take care,
Marko.

http://markorodriguez.com


> 
>> On Oct 9, 2015, at 11:07 AM, Daniel Gruno  wrote:
>> 
>> Hi Incubator folks,
>> 
>> I would like to propose we adopt a mentor neutrality policy for
>> incubating podlings:
>> 
>> - A mentor must not be financially tied to the project or its incubation
>> status.
>> - A mentor must not have a vested interest in incubating, graduating or
>> dismantling a podling that goes beyond the general Apache mission
>> - A mentor must not be affiliated with the entity granting the code
>> (company or original project community)
>> 
>> Furthermore, I would like to see this extended to votes on graduating or
>> retiring podlings, so that only people with no organizational (aparty
>> from the ASF) or financial ties to the project (or the companies behind
>> it) can cast a binding vote on graduation or retirement.
>> 
>> This would essentially mean:
>> 
>> - If you work for a company (or are hired as consultant/advisor) that is
>> entering a project into incubation, you cannot mentor it nor vote
>> for/against its incubation, graduation or retirement.
>> - If you are a in the original community behind the project, you cannot
>> mentor it nor vote for/against it.
>> 
>> I believe this would create a neutral mentorship whose sole mission is
>> to guide podlings with the interests of the ASF in mind.
>> 
>> 
>> Please do discuss this. If there is (mostly) positive feedback, I would
>> like to, at some point, have a vote on including this in the Incubator
>> policy. I realize this would cut down on the number of potential
>> mentors, and I would ask that more people step up to the challenge of
>> mentoring if adopted.
>> 
>> With regards,
>> Daniel
>> 
>> -
>> To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
>> For additional commands, e-mail: general-h...@incubator.apache.org
>> 
> 
> 
> -
> To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
> For additional commands, e-mail: general-h...@incubator.apache.org
> 


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

Re: A suggestion: podling post-mortems

[Bertrand Delacretaz]

On Mon, Oct 12, 2015 at 5:10 PM, Rich Bowen  wrote:
> ...It would be very welcome to have this attached to a graduation
> resolution, so that we could have some background beyond just a boilerplate
> "time to graduate" message

I agree, and IMO our maturity model [1] would provide a good framework
for such a report.

-Bertrand

[1] https://community.apache.org/apache-way/apache-project-maturity-model.html

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

Re: Require projects to have solid API docs

[Emmanuel Lécharny]

Le 11/10/15 17:59, Andrew Pennebaker a écrit :
> In the future, could Apache Incubator require projects to maintain better
> API documentation before graduation? In particular, Kafka has rather sparse
> documentation in v0.8. The Javadocs appear to be randomly hosted on this or
> that professor webpage, and no Kafka javadoc has documentation for
> *both* Consumers
> and Producers.

I'm ok with this proposal, when we have checked that every TLP has a
decent API documentation...

Good luck with that ;-)

/me guilty as charged...


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

Re: A suggestion: podling post-mortems

[Bertrand Delacretaz]

Hi,

On Mon, Oct 12, 2015 at 1:18 PM, Andrew Bayer  wrote:
> ...I'd like to make a suggestion - after a podling graduates or is terminated,
> the podling's mentors should be responsible for putting together a post
> mortem report, or an exit interview, or whatever you want to call it...

I like the idea, not sure how that would look but I'd welcome an
experiment at least.

-Bertrand

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

Re: [VOTE] Accept Mynewt into the Apache Incubator

[Marvin Humphrey]

On Mon, Oct 12, 2015 at 9:04 AM, Sterling Hughes  wrote:
> Hi All,
>
> As mentioned in the DISCUSS thread, all feedback has been positive on
> the Mynewt proposal, so I'd like to call a VOTE to accept Mynewt as a
> new ASF incubator project.
>
> The full text of the proposal is available on the incubator wiki at
> the following URL:
>
> https://wiki.apache.org/incubator/MynewtProposal?action=recall=20
>
> I have also included the full text below.
>
> Vote is open until Thurs, 16th October 2015, 23:59:00 PST.
>
> [   ] +1 to accept Mynewt into the Apache Incubator
> [   ] +0
> [   ] -1 because...
>
> Thank you,
>
> Sterling
>
> 
> /!\ '''FINAL''' /!\
>
> This proposal is now complete and has been submitted for a VOTE.
> 
>
> = Mynewt Proposal =
>
> == Abstract ==
>
> Mynewt is a real-time operating system for constrained embedded systems
> like wearables, lightbulbs, locks and doorbells. It works on a variety of
> 32-bit MCUs (microcontrollers), including ARM Cortex-M and MIPS
> architectures.
>
> == Proposal ==
>
> The goal of this proposal is to bring the Mynewt codebase (developed by
> Runtime, Inc.) into the Apache Software Foundation. Mynewt is designed to
> run constrained Internet of Things devices, where a small, real-time
> operating system is required.
>
> It includes the following components:
>
>  * Real-time operating system kernel (Scheduler, Mutexes, Semaphores, etc.)
>
>  * Command line package management and build system
>
>  * Hardware Abstraction Layer unifying common MCU features (e.g. GPIOs,
>  High Resolution Timers, PWM interfaces, UARTs, ADCs, etc.)
>
>  * Board Support Infrastructure, that defines the framework for building
>  software for various board architectures.
>
> Should this project be accepted into the incubator, Runtime, Inc. will
> assign the ASF a license to all source code developed to date and begin
> the development of an open source community around the project.
>
> == Background ==
>
> Mynewt has been developed solely by Runtime to date. We are a team of 5
> software engineers, that really love writing embedded systems.
>
> == Rationale ==
>
> With the momentum behind the Internet of Things, there is an increasing
> need for standard open source software to help developers create connected
> devices. One area where there is a large need is an open-source, liberally
> licensed, community-driven RTOS (real-time operating system.)
>
> Today, there are many RTOSes, the majority of which are provided by
> proprietary vendors and many of which are not permissively licensed or
> controlled by a single company. These restrictions create fragmentation,
> because either not everyone can afford to purchase the operating system or
> restrictions put on the OS's use (e.g. restricted to vendor-specific
> platforms), means that people using other processors cannot adopt it.
>
> The lack of a standardized operating system creates fragmentation around
> everything above it. Because there is not a well adopted community driven
> operating system, people don't have a place to contribute back new
> drivers, or networking stacks. Additionally, there is constant work to
> port and maintain software across a myriad of different operating systems,
> all with slightly different APIs and interfaces.
>
> In order for the industry to accelerate and keep up with the increasing
> complexity in these devices, it's important that an open-source community
> form and provide a RTOS effort that:
>
>  * Accepts community contributions and encourages code reuse
>  * Natively supports source package management, to allow for efficient
>  redistribution and reuse of software across a broad swath of use cases (from
>  wearables to industrial equipment)
>  * Supports all of the "new" protocol stacks required for IoT (e.g.
> Bluetooth, IPv6,
>  etc.)
>  * Has drivers for all new chipsets, sensors, and other devices
>
> The core of Mynewt has been designed to accommodate these requirements. It
> contains a small, pre-emptive RTOS core, that works on native (OS X,
> Linux) and Cortex platforms (and is easily portable to others), and
> standardized HAL and BSP interfaces.
>
> It also provides a build and package management tool that allows
> developers to install, develop, and redistribute source packages. This
> tool allows developers to start with the core of the OS and its
> interfaces, and then download only the source packages that are needed to
> run their embedded project. This will allow the community to grow beyond
> just porting the core of the Mynewt system and extend to all of the
> necessary protocol stacks, drivers and sensor interfaces that a modern
> embedded developer will need.
>
> In addition to the Mynewt core, there is active development around a set
> of commonly needed functionality when developing small embedded systems,
> including:
>
>  * A Flash Filesystem designed for small flashes, with large block sizes
>  (very common in single chip 

Re: [VOTE] Accept Mynewt into the Apache Incubator

[Marvin Humphrey]

On Mon, Oct 12, 2015 at 9:04 AM, Sterling Hughes  wrote:

> As mentioned in the DISCUSS thread, all feedback has been positive on
> the Mynewt proposal, so I'd like to call a VOTE to accept Mynewt as a
> new ASF incubator project.
>
> The full text of the proposal is available on the incubator wiki at
> the following URL:
>
> https://wiki.apache.org/incubator/MynewtProposal?action=recall=20
>
> I have also included the full text below.
>
> Vote is open until Thurs, 16th October 2015, 23:59:00 PST.
>
> [   ] +1 to accept Mynewt into the Apache Incubator
> [   ] +0
> [   ] -1 because...

+1

> === Mentors ===
>
>  * Sterling Hughes
>  * Jim Jagielski
>  * Justin Mclean
>  * Greg Stein
>  * P. Taylor Goetz
>

Thanks very much to each of Mynewt's Mentors for volunteering!

Marvin Humphrey

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

Re: [DISCUSS] Mentor neutrality policy

[Ted Dunning]

The practical effect on me of this requirement would be that

a) I couldn't have mentored Drill

b) I couldn't have mentored Zookeeper (assuming it were to come along now)

c) I couldn't mentor Kylin (it affects Drill and MapR customers are
considering using it)

d) I couldn't mentor Calcite (same as Drill)

e) I couldn't mentor Storm (MapR distributes it)

f) I couldn't mentor Flink (I am co-writing a book that highlights it)

g) I couldn't help with Zeppelin (our SE's use it for demos)

h) I couldn't mentor Apex (MapR is a partner of DataTorrent)

In fact, I can't think of any project that I have helped out that would be
allowable under this policy.

Take Julian Hyde and Taylor Goetz as additional examples.  They wouldn't be
able to help on any of the projects they have been helping on.

So I *could* mentor Corinthia. Or some of the projects that I had never
heard of and couldn't care less about.

Well, that doesn't work because I don't care about those projects and I am
not going to waste my time.  I care about machine learning and big data and
streaming and query languages. That is what drives my choice of work and
what drives my choice of open source projects to contribute to. It also
leads me to advocate for adoption of those projects at work and for driving
some of the work I do into open source.



On Sat, Oct 10, 2015 at 7:49 AM, Mattmann, Chris A (3980) <
chris.a.mattm...@jpl.nasa.gov> wrote:

> So here’s my elaboration.
>
> The proposal below would have prevented me from ever helping
> projects to the ASF and convincing them that it may be a good
> home for them. I’ve always had financial ties to a project’s
> Incubation status. In many cases, projects being at the ASF,
> and my involvement in them has assisted my mission of doing
> scientific research and helping win proposals and so forth for
> NASA and other agencies.
>
> Further, I’ve many times been at the same institution in which
> the project has originated from before the ASF.
>
> I think I’ve done a good job on the projects I’ve helped to
> bring here and they have been successful too and have overall
> benefitted the ASF.
>
> This rings to me very similar to Roy’s email circa 2012 I believe
> in which in the Incubator we tried to force the diversity requirement
> as a graduation requirement, and Roy succinctly explained that we
> can’t punish e.g., a podling for having people all from the same
> institution. That would punish that institution for hiring folks
> for open source who work on code at the ASF. Diversity is always
> a strong property of a podling as I feel it makes it more resilient
> but it’s not a hard requirement. I feel the same thing in this thread.
>
> Cheers,
> Chris
>
> ++
> Chris Mattmann, Ph.D.
> Chief Architect
> Instrument Software and Science Data Systems Section (398)
> NASA Jet Propulsion Laboratory Pasadena, CA 91109 USA
> Office: 168-519, Mailstop: 168-527
> Email: chris.a.mattm...@nasa.gov
> WWW:  http://sunset.usc.edu/~mattmann/
> ++
> Adjunct Associate Professor, Computer Science Department
> University of Southern California, Los Angeles, CA 90089 USA
> ++
>
>
>
>
>
> -Original Message-
> From: jpluser 
> Reply-To: "general@incubator.apache.org" 
> Date: Friday, October 9, 2015 at 5:14 PM
> To: "general@incubator.apache.org" 
> Subject: Re: [DISCUSS] Mentor neutrality policy
>
> >I do not agree with this proposal I will elaborate more later
> >
> >Sent from my iPhone
> >
> >> On Oct 9, 2015, at 8:07 AM, Daniel Gruno  wrote:
> >>
> >> Hi Incubator folks,
> >>
> >> I would like to propose we adopt a mentor neutrality policy for
> >> incubating podlings:
> >>
> >> - A mentor must not be financially tied to the project or its incubation
> >> status.
> >> - A mentor must not have a vested interest in incubating, graduating or
> >> dismantling a podling that goes beyond the general Apache mission
> >> - A mentor must not be affiliated with the entity granting the code
> >> (company or original project community)
> >>
> >> Furthermore, I would like to see this extended to votes on graduating or
> >> retiring podlings, so that only people with no organizational (aparty
> >> from the ASF) or financial ties to the project (or the companies behind
> >> it) can cast a binding vote on graduation or retirement.
> >>
> >> This would essentially mean:
> >>
> >> - If you work for a company (or are hired as consultant/advisor) that is
> >> entering a project into incubation, you cannot mentor it nor vote
> >> for/against its incubation, graduation or retirement.
> >> - If you are a in the original community behind the project, you cannot
> >> mentor it nor vote for/against it.
> >>
> >> I believe this would 

Re: [VOTE] Accept Mynewt into the Apache Incubator

[Jim Jagielski]

> On Oct 12, 2015, at 12:04 PM, Sterling Hughes  wrote:
> 
> Hi All,
> 
> As mentioned in the DISCUSS thread, all feedback has been positive on
> the Mynewt proposal, so I'd like to call a VOTE to accept Mynewt as a
> new ASF incubator project.
> 
> The full text of the proposal is available on the incubator wiki at
> the following URL:
> 
> https://wiki.apache.org/incubator/MynewtProposal?action=recall=20
> 
> I have also included the full text below.
> 
> Vote is open until Thurs, 16th October 2015, 23:59:00 PST.
> 
>[x] +1 to accept Mynewt into the Apache Incubator
>

Make it so!

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

Re: [DISCUSS] Mentor neutrality policy

[Andrew Purtell]

I would not have been able to mentor Phoenix should it have come along now.
At the time I was not employed by the originator of the project. Later I
chose to join them in part because they contributed the results of their
labor to Apache. My evaluation of how well a podling might be
functioning would not have been in any way different before or after I took
the job.


On Mon, Oct 12, 2015 at 10:13 AM, Ted Dunning  wrote:

> The practical effect on me of this requirement would be that
>
> a) I couldn't have mentored Drill
>
> b) I couldn't have mentored Zookeeper (assuming it were to come along now)
>
> c) I couldn't mentor Kylin (it affects Drill and MapR customers are
> considering using it)
>
> d) I couldn't mentor Calcite (same as Drill)
>
> e) I couldn't mentor Storm (MapR distributes it)
>
> f) I couldn't mentor Flink (I am co-writing a book that highlights it)
>
> g) I couldn't help with Zeppelin (our SE's use it for demos)
>
> h) I couldn't mentor Apex (MapR is a partner of DataTorrent)
>
> In fact, I can't think of any project that I have helped out that would be
> allowable under this policy.
>
> Take Julian Hyde and Taylor Goetz as additional examples.  They wouldn't be
> able to help on any of the projects they have been helping on.
>
> So I *could* mentor Corinthia. Or some of the projects that I had never
> heard of and couldn't care less about.
>
> Well, that doesn't work because I don't care about those projects and I am
> not going to waste my time.  I care about machine learning and big data and
> streaming and query languages. That is what drives my choice of work and
> what drives my choice of open source projects to contribute to. It also
> leads me to advocate for adoption of those projects at work and for driving
> some of the work I do into open source.
>
>
>
> On Sat, Oct 10, 2015 at 7:49 AM, Mattmann, Chris A (3980) <
> chris.a.mattm...@jpl.nasa.gov> wrote:
>
> > So here’s my elaboration.
> >
> > The proposal below would have prevented me from ever helping
> > projects to the ASF and convincing them that it may be a good
> > home for them. I’ve always had financial ties to a project’s
> > Incubation status. In many cases, projects being at the ASF,
> > and my involvement in them has assisted my mission of doing
> > scientific research and helping win proposals and so forth for
> > NASA and other agencies.
> >
> > Further, I’ve many times been at the same institution in which
> > the project has originated from before the ASF.
> >
> > I think I’ve done a good job on the projects I’ve helped to
> > bring here and they have been successful too and have overall
> > benefitted the ASF.
> >
> > This rings to me very similar to Roy’s email circa 2012 I believe
> > in which in the Incubator we tried to force the diversity requirement
> > as a graduation requirement, and Roy succinctly explained that we
> > can’t punish e.g., a podling for having people all from the same
> > institution. That would punish that institution for hiring folks
> > for open source who work on code at the ASF. Diversity is always
> > a strong property of a podling as I feel it makes it more resilient
> > but it’s not a hard requirement. I feel the same thing in this thread.
> >
> > Cheers,
> > Chris
> >
> > ++
> > Chris Mattmann, Ph.D.
> > Chief Architect
> > Instrument Software and Science Data Systems Section (398)
> > NASA Jet Propulsion Laboratory Pasadena, CA 91109 USA
> > Office: 168-519, Mailstop: 168-527
> > Email: chris.a.mattm...@nasa.gov
> > WWW:  http://sunset.usc.edu/~mattmann/
> > ++
> > Adjunct Associate Professor, Computer Science Department
> > University of Southern California, Los Angeles, CA 90089 USA
> > ++
> >
> >
> >
> >
> >
> > -Original Message-
> > From: jpluser 
> > Reply-To: "general@incubator.apache.org" 
> > Date: Friday, October 9, 2015 at 5:14 PM
> > To: "general@incubator.apache.org" 
> > Subject: Re: [DISCUSS] Mentor neutrality policy
> >
> > >I do not agree with this proposal I will elaborate more later
> > >
> > >Sent from my iPhone
> > >
> > >> On Oct 9, 2015, at 8:07 AM, Daniel Gruno 
> wrote:
> > >>
> > >> Hi Incubator folks,
> > >>
> > >> I would like to propose we adopt a mentor neutrality policy for
> > >> incubating podlings:
> > >>
> > >> - A mentor must not be financially tied to the project or its
> incubation
> > >> status.
> > >> - A mentor must not have a vested interest in incubating, graduating
> or
> > >> dismantling a podling that goes beyond the general Apache mission
> > >> - A mentor must not be affiliated with the entity granting the code
> > >> (company or original project community)
> > >>
> > >> Furthermore, I would like to 

Re: [VOTE] Accept Mynewt into the Apache Incubator

[Jean-Baptiste Onofré]

+1 (binding)

Regards
JB

On 10/12/2015 06:04 PM, Sterling Hughes wrote:

Hi All,

As mentioned in the DISCUSS thread, all feedback has been positive on
the Mynewt proposal, so I'd like to call a VOTE to accept Mynewt as a
new ASF incubator project.

The full text of the proposal is available on the incubator wiki at
the following URL:

https://wiki.apache.org/incubator/MynewtProposal?action=recall=20

I have also included the full text below.

Vote is open until Thurs, 16th October 2015, 23:59:00 PST.

 [   ] +1 to accept Mynewt into the Apache Incubator
 [   ] +0
 [   ] -1 because...

Thank you,

Sterling


/!\ '''FINAL''' /!\

This proposal is now complete and has been submitted for a VOTE.


= Mynewt Proposal =

== Abstract ==

Mynewt is a real-time operating system for constrained embedded systems
like wearables, lightbulbs, locks and doorbells. It works on a variety of
32-bit MCUs (microcontrollers), including ARM Cortex-M and MIPS
architectures.

== Proposal ==

The goal of this proposal is to bring the Mynewt codebase (developed by
Runtime, Inc.) into the Apache Software Foundation. Mynewt is designed to
run constrained Internet of Things devices, where a small, real-time
operating system is required.

It includes the following components:

  * Real-time operating system kernel (Scheduler, Mutexes, Semaphores, etc.)

  * Command line package management and build system

  * Hardware Abstraction Layer unifying common MCU features (e.g. GPIOs,
  High Resolution Timers, PWM interfaces, UARTs, ADCs, etc.)

  * Board Support Infrastructure, that defines the framework for building
  software for various board architectures.

Should this project be accepted into the incubator, Runtime, Inc. will
assign the ASF a license to all source code developed to date and begin
the development of an open source community around the project.

== Background ==

Mynewt has been developed solely by Runtime to date. We are a team of 5
software engineers, that really love writing embedded systems.

== Rationale ==

With the momentum behind the Internet of Things, there is an increasing
need for standard open source software to help developers create connected
devices. One area where there is a large need is an open-source, liberally
licensed, community-driven RTOS (real-time operating system.)

Today, there are many RTOSes, the majority of which are provided by
proprietary vendors and many of which are not permissively licensed or
controlled by a single company. These restrictions create fragmentation,
because either not everyone can afford to purchase the operating system or
restrictions put on the OS's use (e.g. restricted to vendor-specific
platforms), means that people using other processors cannot adopt it.

The lack of a standardized operating system creates fragmentation around
everything above it. Because there is not a well adopted community driven
operating system, people don't have a place to contribute back new
drivers, or networking stacks. Additionally, there is constant work to
port and maintain software across a myriad of different operating systems,
all with slightly different APIs and interfaces.

In order for the industry to accelerate and keep up with the increasing
complexity in these devices, it's important that an open-source community
form and provide a RTOS effort that:

  * Accepts community contributions and encourages code reuse
  * Natively supports source package management, to allow for efficient
  redistribution and reuse of software across a broad swath of use cases (from
  wearables to industrial equipment)
  * Supports all of the "new" protocol stacks required for IoT (e.g.
Bluetooth, IPv6,
  etc.)
  * Has drivers for all new chipsets, sensors, and other devices

The core of Mynewt has been designed to accommodate these requirements. It
contains a small, pre-emptive RTOS core, that works on native (OS X,
Linux) and Cortex platforms (and is easily portable to others), and
standardized HAL and BSP interfaces.

It also provides a build and package management tool that allows
developers to install, develop, and redistribute source packages. This
tool allows developers to start with the core of the OS and its
interfaces, and then download only the source packages that are needed to
run their embedded project. This will allow the community to grow beyond
just porting the core of the Mynewt system and extend to all of the
necessary protocol stacks, drivers and sensor interfaces that a modern
embedded developer will need.

In addition to the Mynewt core, there is active development around a set
of commonly needed functionality when developing small embedded systems,
including:

  * A Flash Filesystem designed for small flashes, with large block sizes
  (very common in single chip designs)
  * An Open Bluetooth stack with native support for prevalent modules

== Initial Goals ==

The core of the Mynewt Operating System is functional.

The goal is to have an initial release 

Draft Report October 2015 - please review

[Marvin Humphrey]

Incubator PMC report for October 2015

The Apache Incubator is the entry path into the ASF for projects and
codebases wishing to become part of the Foundation's efforts.

There are 44 podlings currently undergoing incubation.

* Community

  New IPMC members:

  - Josh Elser
  - Sterling Hughes

* New Podlings

  - MADlib
  - Rya
  - Unomi

* Graduations

  The board has motions for the following:

  - Calcite

* Releases

  The following releases were made since the last Incubator report:

  - 2015-09-06 Apache Kylin 1.0-incubating
  - 2015-09-14 Apache Brooklyn 0.8.0-incubating
  - 2015-09-14 Apache HTrace-4.0.0-incubating
  - 2015-09-15 Apache TinkerPop 3.0.1-incubating
  - 2015-09-16 Apache Groovy 2.4.5-incubating
  - 2015-09-21 Apache Sentry-1.6.0-incubating
  - 2015-09-22 Apache AsterixDB Hyracks 0.2.16-incubating

* IP Clearance

  - Raytheon BBN Technologies Corp donated POI Visio, an extension module for
Apache POI. It adds support for the Microsoft Visio .vsdx xml-based file
format. (Current Apache POI Visio support only handled the older binary
.vsd format). Post-import, the component will be known as XDGF.

* Infrastructure

  - It seems that an incorrect date in the Board meeting calendar caused the
report reminders to fire a week early, requiring manual cleanup after the
correct date was established.  There was discussion of migrating the
reminders and other Incubator bookkeeping to Whimsy.

* Miscellaneous

  - At the height of Corinthia's crisis, several committers resigned.  The
mailing lists have since gone silent.  Some IPMC members followed up but
those efforts do not appear to have been successful.
  - A vote to retire the Droids podling is pending.
  - Various proposals to change the Incubator have been discussed on
general@incubator.  The one generating the most responses, mostly in
opposition, is a proposal which would lessen the role of Mentors with
business affiliations to podlings during Incubator entry and exit votes.
None of the other proposals have gotten any traction.
  - A proposal regarding the Incubator formulated during ApacheCon EU was
discussed on board@apache.

* Credits

  - Report Manager: Marvin Humphrey

 Summary of podling reports 

* Still getting started at the Incubator

  - HAWQ
  - MADlib

* Not yet ready to graduate

  No release:

  - Apex
  - FreeMarker
  - Geode
  - Myriad
  - OpenAZ

* Ready to graduate

  - Groovy

  The Board has motions for the following:

  - Calcite

* Did not report, expected next month

  - BatchEE
  - Climate Model Diagnostic Analyzer (2 months late)
  - Cotton (2 months late)
  - DataFu
  - HORN
  - ODF Toolkit
  - Ripple (4 months late)

* Report reviewed but not signed off by Mentors, expected next month

  - Wave

* Likely to retire

  - Droids

--
   Table of Contents
Apex
FreeMarker
Geode
Groovy
HAWQ
MADlib
Myriad
ODF Toolkit
OpenAz
Wave

--


Apex

Apex is an enterprise grade native YARN big data-in-motion platform that
unifies stream processing as well as batch processing.

Apex has been incubating since 2015-08-17.

Three most important issues to address in the move towards graduation:

  1. Release Apex-Core, and Apex-Malhar at least twice.
  2. Grow contributors beyond the initial set.

Any issues that the Incubator PMC (IPMC) or ASF Board wish/need to be
aware of?

  None. Thanks for continual support.

How has the community developed since the last report?

  The community is very engaged with the development of the project. There
  have been 485 messages on dev@.

  The community voted and selected the APEX logo which is put on the brand
  new project website at http://apex.incubator.apache.org/

How has the project developed since the last report?

  Various metrics are as follows:
  +---+
  |   Metric | Core  | Malhar |
  +---+
  | Non Merge Commits|  88   |   33   |
  | Contributors |  17   |9   |
  | Jira Issues  |  94   |   30   |
  | Resolved Issues  |  30   |4   |
  +---+

  The project is still using the Atlassian instance of JIRA. The migration to
  Apache JIRA is underway.

  The first release of the project under ASF banner (3.2.0) is targeted to be
  branched off at the end of September.

Date of last release:

  No release under ASF-Incubation code base as yet. Apex-Core, Apex-Malhar
  were last launched on July end in pre Apache days.

When were the last committers or PMC members elected?

  Committers and Mentors came about via incubation proposal.

Signed-off-by:

  [X](apex) Chris Nauroth
  [ 

Re: Mentor disengagement - a suggestion

[Sam Ruby]

On Mon, Oct 12, 2015 at 11:06 AM, Rich Bowen  wrote:
>
> On 10/12/2015 10:10 AM, Emmanuel Lécharny wrote:
>>
>> Regarding inactive mentors, this is quite simple : we have a monthly
>> report that has to be signed off by mentors, if one mentor does not sign
>> it three time in a raw, shouldn't we consider that this mentor has
>> already stepped down ?
>
> No, it's not simple. Actively removing people from volunteer roles is much
> more complicated than you might suppose. I'd rather focus on making myself a
> better mentor than any measures against other mentors which might be seen as
> punitive.

Getting some things out of the way:

I agree that it is not simple.  I agree that it is complicated.  I
disagree that it needs to be viewed as punitive.  I suggest it would
be worthwhile to do.  I respect that this may not be something you
personally would want to volunteer for.  I believe that you can't fix
what you don't measure.  I acknowledge that measuring may lead to
gaming, though in this case I think the rewards are so vanishingly
small that that is unlikely to be a major issue.

Whew!

Now on to the substance of my reply:

https://whimsy.apache.org/incubator/signoff

If we can get some volunteers to split this list up, perhaps we can
reach out to those that haven't been participating in signoffs and see
what changes need to be made.

Any takers?

- Sam Ruby

P.S.  Despite this being pulled from either public or soon to be
public data, I have limited access to IPMC members and ASF members.
At a minimum, this should keep the page out of search engine results.


> --
> Rich Bowen - rbo...@rcbowen.com - @rbowen
> http://apachecon.com/ - @apachecon
>
> -
> To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
> For additional commands, e-mail: general-h...@incubator.apache.org
>

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

Re: Incubation capacity

[Marvin Humphrey]

On Mon, Oct 12, 2015 at 8:08 AM, Jukka Zitting  wrote:

> It sounds like ruminations about the Incubator are on the increase again,

I hope that we can make use of some of this bursting energy and channel it
into incremental improvements.

The Incubator is a stable platform, and it has been functioning well by
historical terms, and with blessedly low drama compared to a few years ago.
My impression is that frustration with the institutional resistance of
Incubator to change is skewing impressions of how well it is doing its job of
incubating podlings.

> I believe the way the Incubator is organized sets an upper bound on the
> number of podlings it can effectively manage. Based on experience and
> historical data (http://incubator.apache.org/history/ *) I believe this
> limit is somewhere around 30 podlings.

I'm curious, Jukka.  Why 30?  What are the scarce resources?  And how is this
supposed degradation manifesting?

*   One single point of failure has been the Chair, especially with regards to
the report.  However, we have addressed that to some extent by having
other people produce the report while leaving the Chair with editorial
prerogative.
*   You could argue that we have a shortage of shepherds since participation
has been flagging, but I don't see that as a bad thing.  The critical
function of the shepherds -- keeping neglected podlings from falling
through the cracks -- is now handled by the Report Manager.  And the
expectation that it is the shepherd's role to provide review of podling
reports is harmful in that it discourages Mentors from commenting.
*   It used to be the case that we were perpetually short on IPMC votes for
releases, but since late 2013 we have been using that limited capacity
much more effectively -- thanks to improved understanding of release
policy and improved consensus about when leniency is appropriate, we now
cycle through fewer release candidates.

Additionally, I'll note that while we're at 43 or so podlings right now, we
have multiple podlings about to retire (Droids, Kalumet, likely Corinthia) and
others about to graduate (Kylin, Groovy).

It would probably be healthy to nudge some podlings here and there towards
graduation or retirement, but we're doing that.  Podlings which don't report
get put into the "monthly" reporting category, as are podlings whose reports
are not signed-off by their Mentors -- and they are not removed until they
provide a proper signed-off report.  Recently this has triggered action on
Droids, Kalumet, and Wave.  Before that, NPanday and others.

So... I can see an argument that some individual Mentors might sometimes
stretch themselves too thin by taking on multiple projects, but I don't yet
grok how the Incubator's central institutions are having capacity problems.

Marvin Humphrey

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

Re: Incubation capacity

[Jukka Zitting]

Hi,

On Mon, Oct 12, 2015 at 2:50 PM Marvin Humphrey  wrote:
> On Mon, Oct 12, 2015 at 8:08 AM, Jukka Zitting  wrote:
> > It sounds like ruminations about the Incubator are on the increase again,
>
> I hope that we can make use of some of this bursting energy and channel it
> into incremental improvements.
>
> The Incubator is a stable platform, and it has been functioning well by
> historical terms, and with blessedly low drama compared to a few years ago.
> My impression is that frustration with the institutional resistance of
> Incubator to change is skewing impressions of how well it is doing its job of
> incubating podlings.

Yes, we're far from the drama of 2011.

> > I believe the way the Incubator is organized sets an upper bound on the
> > number of podlings it can effectively manage. Based on experience and
> > historical data (http://incubator.apache.org/history/ *) I believe this
> > limit is somewhere around 30 podlings.
>
> I'm curious, Jukka.  Why 30?

I don't have a firm theory on why this is happening, only some key observations:

* The entry rate of new podlings has been amazingly constant
throughout the existence of the Incubator even though the total number
of open source projects has been growing exponentially for much of
this time.

* The "limit" was first reached in 2006 during which the board first
pushed back on Incubator reports and the current monthly 1/3 reporting
schedule was adopted and the process of retiring dormant podlings was
adopted.

* The Incubator stayed at or slightly above the 30 podlings limit
until around mid-2010 after which many podlings started getting stuck,
leading to the crisis of late 2011.

* We solved that problem with a concentrated effort in 2012 that
brought the Incubator back to around 30 active podlings, a level that
stayed mostly stable for the next two years.

* The number of current podlings is again growing, and some of the
issues that have shown up recently remind me of the problems seen five
years ago.

It could be that I'm just selectively interpreting history to match my
theory, but from a systems perspective it does look as if the
Incubator indeed has a structural bandwidth cap that probably feeds
into and limits the entry rate.

>  What are the scarce resources?

Some possible answers:

* Mailing list. There is only so much general@ traffic that a single
IPMC member can reasonably process without starting to skip
significant parts.

* Mentors. The growth rate of the IPMC is fairly constant and, with
most members becoming inactive over time, I believe the number of
active mentors has not grown too much over the years.

* Chair/Report Manager. Someone still needs to pay attention to
everything that's going around, which I believe you and all other
recent chairs agree is a daunting task.

One could run some numbers to better quantify the above possibilities.

> And how is this supposed degradation manifesting?

The noise got loud enough to wake me up. :-) I don't have hard
numbers, but we do have a couple of recent failures and it sounds like
some people are getting concerned, which does remind me of early 2011.
Of course the one thing you can learn from history is that things are
never quite the same.

> Additionally, I'll note that while we're at 43 or so podlings right now, we
> have multiple podlings about to retire (Droids, Kalumet, likely Corinthia) and
> others about to graduate (Kylin, Groovy).

Right, this might be just a fluke.

BR,

Jukka Zitting

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

Re: [DISCUSS] [REVISED] Mentor neutrality policy

[Konstantin Boudnik]

And still -1 on the revised proposal for the same reasons I stated before.

Cos

On Sun, Oct 11, 2015 at 11:39PM, Daniel Gruno wrote:
> First off: Can we *please* focus on the revised proposal and not get
> into a loop about the original email? I'll change the topic if that helps.
> 
> The revised edition, as partly suggested by Sam (and echoed by Bertrand)
> was:
> 
> - Binding votes on incubation, graduation and/or retirement are only
> valid when given by members of the IPMC who are independent from the
> podling in question. Mentors are free to recommend such actions, but
> cannot cast a vote themselves.
> 
> I don't believe I mentioned MIA mentors anywhere - is that something you
> wish to discuss as well?
> 
> With regards,
> Daniel.
> 
> On 10/11/2015 11:34 PM, Alan D. Cabrera wrote:
> > I’m -1 on on this.  The whole premise of the ASF is that it is a 
> > meritocracy and that volunteers at various “levels” of the organization 
> > have attained their status because they are trustworthy.  Without this 
> > premise, the ASF falls apart.
> > 
> > Finally, it’s not clear to me that this addresses the problem of MIA 
> > mentors.  If they were supposedly tied in some manner to the incubation and 
> > graduation of a podling,  then they are definitely active during its 
> > incubation; I have no problem with that because in my book, they are 
> > trustworthy.
> > 
> > I’ve made proposals to solve the problems listed below, the causes of which 
> > are, imo, volunteerism and a free ride into a project and its PMC.  My 
> > proposal was after 3 missed votes, the mentor is automatically removed with 
> > simple no-fuss reinstatement procedures should the mentor wish to redeem 
> > themselves.  Mentors cannot stay with the podling when it graduates.
> > 
> > 
> > Regards,
> > Alan
> > 
> >> On Oct 9, 2015, at 8:07 AM, Daniel Gruno  wrote:
> >>
> >> Hi Incubator folks,
> >>
> >> I would like to propose we adopt a mentor neutrality policy for
> >> incubating podlings:
> >>
> >> - A mentor must not be financially tied to the project or its incubation
> >> status.
> >> - A mentor must not have a vested interest in incubating, graduating or
> >> dismantling a podling that goes beyond the general Apache mission
> >> - A mentor must not be affiliated with the entity granting the code
> >> (company or original project community)
> >>
> >> Furthermore, I would like to see this extended to votes on graduating or
> >> retiring podlings, so that only people with no organizational (aparty
> >> from the ASF) or financial ties to the project (or the companies behind
> >> it) can cast a binding vote on graduation or retirement.
> >>
> >> This would essentially mean:
> >>
> >> - If you work for a company (or are hired as consultant/advisor) that is
> >> entering a project into incubation, you cannot mentor it nor vote
> >> for/against its incubation, graduation or retirement.
> >> - If you are a in the original community behind the project, you cannot
> >> mentor it nor vote for/against it.
> >>
> >> I believe this would create a neutral mentorship whose sole mission is
> >> to guide podlings with the interests of the ASF in mind.
> >>
> >>
> >> Please do discuss this. If there is (mostly) positive feedback, I would
> >> like to, at some point, have a vote on including this in the Incubator
> >> policy. I realize this would cut down on the number of potential
> >> mentors, and I would ask that more people step up to the challenge of
> >> mentoring if adopted.
> >>
> >> With regards,
> >> Daniel
> >>
> >> -
> >> To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
> >> For additional commands, e-mail: general-h...@incubator.apache.org
> >>
> > 
> > 
> 
> 
> -
> To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
> For additional commands, e-mail: general-h...@incubator.apache.org
> 


signature.asc
Description: Digital signature

Re: [DISCUSS] Mentor neutrality policy

[Konstantin Boudnik]

On Sun, Oct 11, 2015 at 06:52PM, Reto Gmür wrote:
> On Sat, Oct 10, 2015 at 11:40 AM, Roman Shaposhnik 
> wrote:
> 
> > On Fri, Oct 9, 2015 at 6:07 PM, Daniel Gruno  wrote:
> > > Hi Incubator folks,
> > >
> > > I would like to propose we adopt a mentor neutrality policy for
> > > incubating podlings:
> > >
> > > - A mentor must not be financially tied to the project or its incubation
> > > status.
> >
> > I'm very strongly -1 on this for two reasons. One fundamental
> > and one operational. Fundamentally, this goes against a core
> > ASF principle that we all collaborate here as individuals by
> > checking our corporate affiliation at the door.
> 
> 
> I think it's naive to think that just because the members are individual
> and corporate affiliations don't formally play a role there is no influence
> by the employer. When I'm paid by a company or government agency to work on
> an apache project I don't have an effective protection against the
> directives of my employer. Maybe if I refuse to follow an employer's
> instruction to write some code for an Apache project of which I'm committer
> I could not be fired without notice, maybe I could write the patch and say
> on the list that I wrote this patch for my employer but that as an
> individual PMC member I vote against it (did something like this ever
> happen?), whichever way I'm likely to act against my financial interest.
> 
> In medical journals the author's are also writing in their own name, yet
> they must declare all competing interests. Following your logic such as
> declaration would be unnecessary if the journal says somewhere that authors
> leave their affiliation at the door.

That's a straw-man argument.

Unlike people writing for the medical journals who're working for the, sadly,
the most regulated industry ever and making millions if their research happen
to be acknowledged as promising, even when harmful, Apache contributors are
_individual volunteers_ developing the software for public consumption. And
you _have_ to leave your affiliation elsewhere when you're wearing your Apache
hat. Hence your affiliation is of no relevance here.

Cos

> > IOW, we are explicitly granting our members and committers the trust
> > required to make sure they do the right thing while they themselves (or
> > their employees) can significantly benefit (financially and otherwise) from
> > the projects.
> >
> 
> Even if we trust our commiters that they do not commit a hidden back door
> on behalf of the spy agency they work for, the conflict of interest can be
> much more subtle. The company has a deadline and a release of an apache
> project before that deadline would come in very handy, will you scrutinize
> the notice files at the risk of finding something that delays the release?
> 
> If a main customer of my consulting firm is the main promoter of the XY
> file format, will I by neutral in choosing the best file format for the
> Apache Project I'm involved in? I probably really believe that XY is the
> way to go, but is should be an Apache rule that I declare that I have some
> financial ties to it.
> 
> 
> >
> > This is what makes ASF unique and anything that goes even slightly
> > in the direction of reducing this level of trust will have me up in arms
> > (regardless of whether it is related to Incubator or not).
> >
> > Operationally, this is extremely tricky to enforce. I speak here
> > from experience of somebody who has to be appreciative of the same
> > set of issues while consulting for companies and yet working for my
> > current employer. Even in a corporate world (where stakes are much
> > higher from legal perspective) this typically gets handled by trusting
> > the individual to do the right thing and disclose any potential conflict
> > of interest (financial or otherwise).
> >
> 
> We would not have to ask people for their tax declaration, a self
> declaration of any potentially competing interest would do.
> 
> Cheers,
> Reto


signature.asc
Description: Digital signature

Re: [VOTE] Accept Mynewt into the Apache Incubator

[Greg Stein]

+1 (binding)

On Mon, Oct 12, 2015 at 11:04 AM, Sterling Hughes 
wrote:

> Hi All,
>
> As mentioned in the DISCUSS thread, all feedback has been positive on
> the Mynewt proposal, so I'd like to call a VOTE to accept Mynewt as a
> new ASF incubator project.
>
> The full text of the proposal is available on the incubator wiki at
> the following URL:
>
> https://wiki.apache.org/incubator/MynewtProposal?action=recall=20
>
> I have also included the full text below.
>
> Vote is open until Thurs, 16th October 2015, 23:59:00 PST.
>
> [   ] +1 to accept Mynewt into the Apache Incubator
> [   ] +0
> [   ] -1 because...
>
> Thank you,
>
> Sterling
>
> 
> /!\ '''FINAL''' /!\
>
> This proposal is now complete and has been submitted for a VOTE.
> 
>
> = Mynewt Proposal =
>
> == Abstract ==
>
> Mynewt is a real-time operating system for constrained embedded systems
> like wearables, lightbulbs, locks and doorbells. It works on a variety of
> 32-bit MCUs (microcontrollers), including ARM Cortex-M and MIPS
> architectures.
>
> == Proposal ==
>
> The goal of this proposal is to bring the Mynewt codebase (developed by
> Runtime, Inc.) into the Apache Software Foundation. Mynewt is designed to
> run constrained Internet of Things devices, where a small, real-time
> operating system is required.
>
> It includes the following components:
>
>  * Real-time operating system kernel (Scheduler, Mutexes, Semaphores, etc.)
>
>  * Command line package management and build system
>
>  * Hardware Abstraction Layer unifying common MCU features (e.g. GPIOs,
>  High Resolution Timers, PWM interfaces, UARTs, ADCs, etc.)
>
>  * Board Support Infrastructure, that defines the framework for building
>  software for various board architectures.
>
> Should this project be accepted into the incubator, Runtime, Inc. will
> assign the ASF a license to all source code developed to date and begin
> the development of an open source community around the project.
>
> == Background ==
>
> Mynewt has been developed solely by Runtime to date. We are a team of 5
> software engineers, that really love writing embedded systems.
>
> == Rationale ==
>
> With the momentum behind the Internet of Things, there is an increasing
> need for standard open source software to help developers create connected
> devices. One area where there is a large need is an open-source, liberally
> licensed, community-driven RTOS (real-time operating system.)
>
> Today, there are many RTOSes, the majority of which are provided by
> proprietary vendors and many of which are not permissively licensed or
> controlled by a single company. These restrictions create fragmentation,
> because either not everyone can afford to purchase the operating system or
> restrictions put on the OS's use (e.g. restricted to vendor-specific
> platforms), means that people using other processors cannot adopt it.
>
> The lack of a standardized operating system creates fragmentation around
> everything above it. Because there is not a well adopted community driven
> operating system, people don't have a place to contribute back new
> drivers, or networking stacks. Additionally, there is constant work to
> port and maintain software across a myriad of different operating systems,
> all with slightly different APIs and interfaces.
>
> In order for the industry to accelerate and keep up with the increasing
> complexity in these devices, it's important that an open-source community
> form and provide a RTOS effort that:
>
>  * Accepts community contributions and encourages code reuse
>  * Natively supports source package management, to allow for efficient
>  redistribution and reuse of software across a broad swath of use cases
> (from
>  wearables to industrial equipment)
>  * Supports all of the "new" protocol stacks required for IoT (e.g.
> Bluetooth, IPv6,
>  etc.)
>  * Has drivers for all new chipsets, sensors, and other devices
>
> The core of Mynewt has been designed to accommodate these requirements. It
> contains a small, pre-emptive RTOS core, that works on native (OS X,
> Linux) and Cortex platforms (and is easily portable to others), and
> standardized HAL and BSP interfaces.
>
> It also provides a build and package management tool that allows
> developers to install, develop, and redistribute source packages. This
> tool allows developers to start with the core of the OS and its
> interfaces, and then download only the source packages that are needed to
> run their embedded project. This will allow the community to grow beyond
> just porting the core of the Mynewt system and extend to all of the
> necessary protocol stacks, drivers and sensor interfaces that a modern
> embedded developer will need.
>
> In addition to the Mynewt core, there is active development around a set
> of commonly needed functionality when developing small embedded systems,
> including:
>
>  * A Flash Filesystem designed for small flashes, with large block sizes
>  (very common in 

Re: [DISCUSS] Mentor neutrality policy

[Konstantin Boudnik]

Continuing this line of reasoning I won't be able to mentor _any_ of the
projects I've mentored or still mentoring because of different levels of
involvements either at my $dayjob or with the organizations that donated the
code initially. Is this really an intent of the original proposal to prevent
people from they care doing in the open-source? And based on what again?

Cos

On Mon, Oct 12, 2015 at 11:14AM, Andrew Purtell wrote:
> I would not have been able to mentor Phoenix should it have come along now.
> At the time I was not employed by the originator of the project. Later I
> chose to join them in part because they contributed the results of their
> labor to Apache. My evaluation of how well a podling might be
> functioning would not have been in any way different before or after I took
> the job.
> 
> 
> On Mon, Oct 12, 2015 at 10:13 AM, Ted Dunning  wrote:
> 
> > The practical effect on me of this requirement would be that
> >
> > a) I couldn't have mentored Drill
> >
> > b) I couldn't have mentored Zookeeper (assuming it were to come along now)
> >
> > c) I couldn't mentor Kylin (it affects Drill and MapR customers are
> > considering using it)
> >
> > d) I couldn't mentor Calcite (same as Drill)
> >
> > e) I couldn't mentor Storm (MapR distributes it)
> >
> > f) I couldn't mentor Flink (I am co-writing a book that highlights it)
> >
> > g) I couldn't help with Zeppelin (our SE's use it for demos)
> >
> > h) I couldn't mentor Apex (MapR is a partner of DataTorrent)
> >
> > In fact, I can't think of any project that I have helped out that would be
> > allowable under this policy.
> >
> > Take Julian Hyde and Taylor Goetz as additional examples.  They wouldn't be
> > able to help on any of the projects they have been helping on.
> >
> > So I *could* mentor Corinthia. Or some of the projects that I had never
> > heard of and couldn't care less about.
> >
> > Well, that doesn't work because I don't care about those projects and I am
> > not going to waste my time.  I care about machine learning and big data and
> > streaming and query languages. That is what drives my choice of work and
> > what drives my choice of open source projects to contribute to. It also
> > leads me to advocate for adoption of those projects at work and for driving
> > some of the work I do into open source.
> >
> >
> >
> > On Sat, Oct 10, 2015 at 7:49 AM, Mattmann, Chris A (3980) <
> > chris.a.mattm...@jpl.nasa.gov> wrote:
> >
> > > So here’s my elaboration.
> > >
> > > The proposal below would have prevented me from ever helping
> > > projects to the ASF and convincing them that it may be a good
> > > home for them. I’ve always had financial ties to a project’s
> > > Incubation status. In many cases, projects being at the ASF,
> > > and my involvement in them has assisted my mission of doing
> > > scientific research and helping win proposals and so forth for
> > > NASA and other agencies.
> > >
> > > Further, I’ve many times been at the same institution in which
> > > the project has originated from before the ASF.
> > >
> > > I think I’ve done a good job on the projects I’ve helped to
> > > bring here and they have been successful too and have overall
> > > benefitted the ASF.
> > >
> > > This rings to me very similar to Roy’s email circa 2012 I believe
> > > in which in the Incubator we tried to force the diversity requirement
> > > as a graduation requirement, and Roy succinctly explained that we
> > > can’t punish e.g., a podling for having people all from the same
> > > institution. That would punish that institution for hiring folks
> > > for open source who work on code at the ASF. Diversity is always
> > > a strong property of a podling as I feel it makes it more resilient
> > > but it’s not a hard requirement. I feel the same thing in this thread.
> > >
> > > Cheers,
> > > Chris
> > >
> > > ++
> > > Chris Mattmann, Ph.D.
> > > Chief Architect
> > > Instrument Software and Science Data Systems Section (398)
> > > NASA Jet Propulsion Laboratory Pasadena, CA 91109 USA
> > > Office: 168-519, Mailstop: 168-527
> > > Email: chris.a.mattm...@nasa.gov
> > > WWW:  http://sunset.usc.edu/~mattmann/
> > > ++
> > > Adjunct Associate Professor, Computer Science Department
> > > University of Southern California, Los Angeles, CA 90089 USA
> > > ++
> > >
> > >
> > >
> > >
> > >
> > > -Original Message-
> > > From: jpluser 
> > > Reply-To: "general@incubator.apache.org" 
> > > Date: Friday, October 9, 2015 at 5:14 PM
> > > To: "general@incubator.apache.org" 
> > > Subject: Re: [DISCUSS] Mentor neutrality policy
> > >
> > > >I do not agree with this proposal I will elaborate more later
> > > >
> > > >Sent from my iPhone
> > 

Re: A suggestion: podling post-mortems

[Greg Stein]

Pierre: by "time to graduate", Rich meant "ready to graduate". Not the
amount of time from entry until graduation.

On Mon, Oct 12, 2015 at 10:55 AM, Pierre Smits 
wrote:

> Since when is the incubation process a race that must be completed in the
> least amount of time? If it is, it would surely validate (for some) cutting
> corners and push-through actions (and associated tactics). Is that what the
> ASF wants or needs?
>
> Best regards,
>
> Pierre Smits
>
> *OFBiz Extensions Marketplace*
> http://oem.ofbizci.net/oci-2/
>
> On Mon, Oct 12, 2015 at 5:39 PM, Sam Ruby  wrote:
>
> > On Mon, Oct 12, 2015 at 11:14 AM, Bertrand Delacretaz
> >  wrote:
> > > On Mon, Oct 12, 2015 at 5:10 PM, Rich Bowen 
> wrote:
> > >> ...It would be very welcome to have this attached to a
> > graduation
> > >> resolution, so that we could have some background beyond just a
> > boilerplate
> > >> "time to graduate" message
> > >
> > > I agree, and IMO our maturity model [1] would provide a good framework
> > > for such a report.
> >
> > +1 to both of the above.
> >
> > > -Bertrand
> > >
> > > [1]
> >
> https://community.apache.org/apache-way/apache-project-maturity-model.html
> >
> > - Sam Ruby
> >
> > -
> > To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
> > For additional commands, e-mail: general-h...@incubator.apache.org
> >
> >
>

Re: Incubation capacity

[Mattmann, Chris A (3980)]

Fantastic analysis Jukka.

Fan-freaking-tastic.

Cheers,
Chris

++
Chris Mattmann, Ph.D.
Chief Architect
Instrument Software and Science Data Systems Section (398)
NASA Jet Propulsion Laboratory Pasadena, CA 91109 USA
Office: 168-519, Mailstop: 168-527
Email: chris.a.mattm...@nasa.gov
WWW:  http://sunset.usc.edu/~mattmann/
++
Adjunct Associate Professor, Computer Science Department
University of Southern California, Los Angeles, CA 90089 USA
++





-Original Message-
From: Jukka Zitting 
Reply-To: "general@incubator.apache.org" 
Date: Monday, October 12, 2015 at 2:13 PM
To: general 
Subject: Re: Incubation capacity

>Hi,
>
>On Mon, Oct 12, 2015 at 2:50 PM Marvin Humphrey 
>wrote:
>> On Mon, Oct 12, 2015 at 8:08 AM, Jukka Zitting 
>>wrote:
>> > It sounds like ruminations about the Incubator are on the increase
>>again,
>>
>> I hope that we can make use of some of this bursting energy and channel
>>it
>> into incremental improvements.
>>
>> The Incubator is a stable platform, and it has been functioning well by
>> historical terms, and with blessedly low drama compared to a few years
>>ago.
>> My impression is that frustration with the institutional resistance of
>> Incubator to change is skewing impressions of how well it is doing its
>>job of
>> incubating podlings.
>
>Yes, we're far from the drama of 2011.
>
>> > I believe the way the Incubator is organized sets an upper bound on
>>the
>> > number of podlings it can effectively manage. Based on experience and
>> > historical data (http://incubator.apache.org/history/ *) I believe
>>this
>> > limit is somewhere around 30 podlings.
>>
>> I'm curious, Jukka.  Why 30?
>
>I don't have a firm theory on why this is happening, only some key
>observations:
>
>* The entry rate of new podlings has been amazingly constant
>throughout the existence of the Incubator even though the total number
>of open source projects has been growing exponentially for much of
>this time.
>
>* The "limit" was first reached in 2006 during which the board first
>pushed back on Incubator reports and the current monthly 1/3 reporting
>schedule was adopted and the process of retiring dormant podlings was
>adopted.
>
>* The Incubator stayed at or slightly above the 30 podlings limit
>until around mid-2010 after which many podlings started getting stuck,
>leading to the crisis of late 2011.
>
>* We solved that problem with a concentrated effort in 2012 that
>brought the Incubator back to around 30 active podlings, a level that
>stayed mostly stable for the next two years.
>
>* The number of current podlings is again growing, and some of the
>issues that have shown up recently remind me of the problems seen five
>years ago.
>
>It could be that I'm just selectively interpreting history to match my
>theory, but from a systems perspective it does look as if the
>Incubator indeed has a structural bandwidth cap that probably feeds
>into and limits the entry rate.
>
>>  What are the scarce resources?
>
>Some possible answers:
>
>* Mailing list. There is only so much general@ traffic that a single
>IPMC member can reasonably process without starting to skip
>significant parts.
>
>* Mentors. The growth rate of the IPMC is fairly constant and, with
>most members becoming inactive over time, I believe the number of
>active mentors has not grown too much over the years.
>
>* Chair/Report Manager. Someone still needs to pay attention to
>everything that's going around, which I believe you and all other
>recent chairs agree is a daunting task.
>
>One could run some numbers to better quantify the above possibilities.
>
>> And how is this supposed degradation manifesting?
>
>The noise got loud enough to wake me up. :-) I don't have hard
>numbers, but we do have a couple of recent failures and it sounds like
>some people are getting concerned, which does remind me of early 2011.
>Of course the one thing you can learn from history is that things are
>never quite the same.
>
>> Additionally, I'll note that while we're at 43 or so podlings right
>>now, we
>> have multiple podlings about to retire (Droids, Kalumet, likely
>>Corinthia) and
>> others about to graduate (Kylin, Groovy).
>
>Right, this might be just a fluke.
>
>BR,
>
>Jukka Zitting
>
>-
>To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
>For additional commands, e-mail: general-h...@incubator.apache.org
>

Re: Draft Report October 2015 - please review

[Marvin Humphrey]

> 
> ODF Toolkit
>
> Java modules that allow programmatic creation, scanning and manipulation of
> OpenDocument Format (ISO/IEC 26300 == ODF) documents
>
> Shepherd/Mentor notes:
>
>   Rob Weir (robweir):
>
> No report submitted, though I did remind the PPMC.   I sense some "report
> fatigue" since they missed the July report deadline, submitted then in
> time for August, but lacked a mentor sign off, and then submitted again in
> September and did get sign off.
>
>   Drew Farris (drew):
>
> Kudos to robweir activity as a mentor, however this project could use
> another mentor. Generally little traffic or activity.

The following Mentor notes for ODF Toolkit have been added to the wiki:

  Nick Burch (nick):

Project has recently added a committer, which is good, but
otherwise the level
of activity remains too low. I've heard rumours of development happening
in private elsewhere, but unless that effort returns to the project and
activity improves, I think we're going to have to look at admitting defeat
and retiring the podling soon.

ODF Toolkit will remain in "monthly" reporting, so a report is expected next
month.  "Report fatigue", while understandable, is not an excuse.  The
Board expects all TLPs to turn in meaningful reports that adequately
communicate the state of the community, even when not much is happening.

> 
> Wave
>
> A wave is a hosted, live, concurrent data structure for rich communication.
> It can be used like email, chat, or a document.
>
> Wave has been incubating since 2010-12-04.
>
> Shepherd/Mentor notes:
>
>   Marvin Humphrey (marvin):
>
> Wave's report was deliberately not signed off by its Mentors.  Mentor
> Upayavira engaged the Wave community about the possibility of retiring.
> The community preferred to continue; a timeline for making an incubating
> release was discussed.

Upayavira signed off on the Wave report and added the following commentary:

  [x](wave) Upayavira
  [ ](wave) Christian Grobmeier

  Upayavira (upayavira):

As Marvin observed, I'm doubtful that Wave has the momentum to make
any significant change nor to progress towards graduation. The community
will need to meet some targets - the immediate one is to make a release
before the next board report is due.

I had previously deleted the report (which was pretty bare-bones) because it
was not signed off.

I plan to interpret Upayavira's signoff as fulfilling Wave's reporting
requirement for this cycle (even without the podling report text included in
the final) and will remove Wave from "monthly" reporting.

Marvin Humphrey

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

Re: [DISCUSS] Mentor neutrality policy

[P. Taylor Goetz]

Mentors are, by definition, either:

A) ASF Members
B) someone who has shown enough understanding of the Apache Way to be invited 
to the IPMC (and should at least be considered for membership, IMHO).

I would think that in either case, they should know how/when/why to check their 
corporate affiliation hat at the door.

If someone can't, or won't, then maybe they should not be an ASF/IPMC member.

I would likely not be able to mentor many projects under the proposed policy.

-1

-Taylor

> On Oct 9, 2015, at 11:07 AM, Daniel Gruno  wrote:
> 
> Hi Incubator folks,
> 
> I would like to propose we adopt a mentor neutrality policy for
> incubating podlings:
> 
> - A mentor must not be financially tied to the project or its incubation
> status.
> - A mentor must not have a vested interest in incubating, graduating or
> dismantling a podling that goes beyond the general Apache mission
> - A mentor must not be affiliated with the entity granting the code
> (company or original project community)
> 
> Furthermore, I would like to see this extended to votes on graduating or
> retiring podlings, so that only people with no organizational (aparty
> from the ASF) or financial ties to the project (or the companies behind
> it) can cast a binding vote on graduation or retirement.
> 
> This would essentially mean:
> 
> - If you work for a company (or are hired as consultant/advisor) that is
> entering a project into incubation, you cannot mentor it nor vote
> for/against its incubation, graduation or retirement.
> - If you are a in the original community behind the project, you cannot
> mentor it nor vote for/against it.
> 
> I believe this would create a neutral mentorship whose sole mission is
> to guide podlings with the interests of the ASF in mind.
> 
> 
> Please do discuss this. If there is (mostly) positive feedback, I would
> like to, at some point, have a vote on including this in the Incubator
> policy. I realize this would cut down on the number of potential
> mentors, and I would ask that more people step up to the challenge of
> mentoring if adopted.
> 
> With regards,
> Daniel
> 
> -
> To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
> For additional commands, e-mail: general-h...@incubator.apache.org
> 

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

Re: [VOTE] Accept Mynewt into the Apache Incubator

[Justin Mclean]

+1 (binding)

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

Re: [DISCUSS] Mentor neutrality policy

[Konstantin Boudnik]

On Sun, Oct 11, 2015 at 02:45PM, Pierre Smits wrote:
> Producing good code is a community effort. When it comes down to just the
> mentors fix that themselves, there is something wrong with the community of
> the podling.
> 
> This discussion is not about what participants do with their mentor hat on
> in the podling. I expect we all appreciate what mentors do within the
> podling and how they help out with explanation when a podling is discussed
> in this ML. The discussion is about people wearing two (or more) hats while
> mentoring a podling.
> 
> And yes, the ASF should be wary of mentors pushing their podling toward
> graduation beyond their mentor role. Do the mentors fear podling failure
> (not graduating) so much, that they need a control on both the internal
> process of the podling (e.g. regarding graduation) and the process at IPMC
> level?

At this point, this is all a hearsay. Supporters of the proposal are making an
assumption nearing the base-less accusation of someone putting their
employment or financial affiliation in front of that of Foundation.

It is suboptimal, lacking the implementation mechanism, and finally smells bad
to impose a blanket policy without real ground, but just because "not doing
something isn't a option".

Cos

> Was the whole evalution process not intended to ensure that eyes of others
> than those with a vested interest (and yes graduation success can be regard
> as such) look and decide on the aspects of community diversity/project
> independence/code risk of the podling?
> 
> 
> Best regards,
> 
> Pierre Smits
> 
> *OFBiz Extensions Marketplace*
> http://oem.ofbizci.net/oci-2/
> 
> On Sun, Oct 11, 2015 at 11:48 AM, Mark Struberg  wrote:
> 
> > -1
> >
> > Mentors who have no interest (financially or purely technical doesn’t
> > matter in the end) will not find enough time to _really_ look into the
> > projects health.
> >
> > Be honest with yourself: how much do you look into the code if you are not
> > working on it yourself? How could you then detect that code is
> > bulk-imported from another project (I‚ve even seen LGPLed code slip in).
> > And this doesn’t happen because people want us something bad. They often
> > simply don’t know how much the ASF cares about code provenance and legal
> > things. That’s an important part in the mentor work. And you cannot do this
> > if you are only somehow loosely checking the project every other month.
> >
> > Or do you fear a mentor will push through his own ‚baby‘ with knowingly
> > ignoring ASF rules?
> >
> >
> > LieGrue,
> > strub
> >
> >
> >
> > > Am 09.10.2015 um 17:07 schrieb Daniel Gruno :
> > >
> > > Hi Incubator folks,
> > >
> > > I would like to propose we adopt a mentor neutrality policy for
> > > incubating podlings:
> > >
> > > - A mentor must not be financially tied to the project or its incubation
> > > status.
> > > - A mentor must not have a vested interest in incubating, graduating or
> > > dismantling a podling that goes beyond the general Apache mission
> > > - A mentor must not be affiliated with the entity granting the code
> > > (company or original project community)
> > >
> > > Furthermore, I would like to see this extended to votes on graduating or
> > > retiring podlings, so that only people with no organizational (aparty
> > > from the ASF) or financial ties to the project (or the companies behind
> > > it) can cast a binding vote on graduation or retirement.
> > >
> > > This would essentially mean:
> > >
> > > - If you work for a company (or are hired as consultant/advisor) that is
> > > entering a project into incubation, you cannot mentor it nor vote
> > > for/against its incubation, graduation or retirement.
> > > - If you are a in the original community behind the project, you cannot
> > > mentor it nor vote for/against it.
> > >
> > > I believe this would create a neutral mentorship whose sole mission is
> > > to guide podlings with the interests of the ASF in mind.
> > >
> > >
> > > Please do discuss this. If there is (mostly) positive feedback, I would
> > > like to, at some point, have a vote on including this in the Incubator
> > > policy. I realize this would cut down on the number of potential
> > > mentors, and I would ask that more people step up to the challenge of
> > > mentoring if adopted.
> > >
> > > With regards,
> > > Daniel
> > >
> > > -
> > > To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
> > > For additional commands, e-mail: general-h...@incubator.apache.org
> > >
> >
> >
> > -
> > To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
> > For additional commands, e-mail: general-h...@incubator.apache.org
> >
> >


signature.asc
Description: Digital signature

Re: [DISCUSS] Mentor neutrality policy

[Ted Dunning]

On Mon, Oct 12, 2015 at 4:02 PM, P. Taylor Goetz  wrote:

> Mentors are, by definition, either:
>
> A) ASF Members
> B) someone who has shown enough understanding of the Apache Way to be
> invited to the IPMC (and should at least be considered for membership,
> IMHO).
>

In at least one case, a mentor has been BOTH of these.

(I'm looking at you Taylor)

Re: Mentor disengagement - a suggestion

[Ted Dunning]

On Mon, Oct 12, 2015 at 11:37 AM, Sam Ruby  wrote:

> Now on to the substance of my reply:
>
> https://whimsy.apache.org/incubator/signoff
>
> If we can get some volunteers to split this list up, perhaps we can
> reach out to those that haven't been participating in signoffs and see
> what changes need to be made.
>

Reaching out is a great idea.

(not volunteering yet)

Re: [VOTE] Accept Mynewt into the Apache Incubator

[P. Taylor Goetz]

+1 (binding)

-Taylor

> On Oct 12, 2015, at 12:04 PM, Sterling Hughes  wrote:
> 
> Hi All,
> 
> As mentioned in the DISCUSS thread, all feedback has been positive on
> the Mynewt proposal, so I'd like to call a VOTE to accept Mynewt as a
> new ASF incubator project.
> 
> The full text of the proposal is available on the incubator wiki at
> the following URL:
> 
> https://wiki.apache.org/incubator/MynewtProposal?action=recall=20
> 
> I have also included the full text below.
> 
> Vote is open until Thurs, 16th October 2015, 23:59:00 PST.
> 
>[   ] +1 to accept Mynewt into the Apache Incubator
>[   ] +0
>[   ] -1 because...
> 
> Thank you,
> 
> Sterling
> 
> 
> /!\ '''FINAL''' /!\
> 
> This proposal is now complete and has been submitted for a VOTE.
> 
> 
> = Mynewt Proposal =
> 
> == Abstract ==
> 
> Mynewt is a real-time operating system for constrained embedded systems
> like wearables, lightbulbs, locks and doorbells. It works on a variety of
> 32-bit MCUs (microcontrollers), including ARM Cortex-M and MIPS
> architectures.
> 
> == Proposal ==
> 
> The goal of this proposal is to bring the Mynewt codebase (developed by
> Runtime, Inc.) into the Apache Software Foundation. Mynewt is designed to
> run constrained Internet of Things devices, where a small, real-time
> operating system is required.
> 
> It includes the following components:
> 
> * Real-time operating system kernel (Scheduler, Mutexes, Semaphores, etc.)
> 
> * Command line package management and build system
> 
> * Hardware Abstraction Layer unifying common MCU features (e.g. GPIOs,
> High Resolution Timers, PWM interfaces, UARTs, ADCs, etc.)
> 
> * Board Support Infrastructure, that defines the framework for building
> software for various board architectures.
> 
> Should this project be accepted into the incubator, Runtime, Inc. will
> assign the ASF a license to all source code developed to date and begin
> the development of an open source community around the project.
> 
> == Background ==
> 
> Mynewt has been developed solely by Runtime to date. We are a team of 5
> software engineers, that really love writing embedded systems.
> 
> == Rationale ==
> 
> With the momentum behind the Internet of Things, there is an increasing
> need for standard open source software to help developers create connected
> devices. One area where there is a large need is an open-source, liberally
> licensed, community-driven RTOS (real-time operating system.)
> 
> Today, there are many RTOSes, the majority of which are provided by
> proprietary vendors and many of which are not permissively licensed or
> controlled by a single company. These restrictions create fragmentation,
> because either not everyone can afford to purchase the operating system or
> restrictions put on the OS's use (e.g. restricted to vendor-specific
> platforms), means that people using other processors cannot adopt it.
> 
> The lack of a standardized operating system creates fragmentation around
> everything above it. Because there is not a well adopted community driven
> operating system, people don't have a place to contribute back new
> drivers, or networking stacks. Additionally, there is constant work to
> port and maintain software across a myriad of different operating systems,
> all with slightly different APIs and interfaces.
> 
> In order for the industry to accelerate and keep up with the increasing
> complexity in these devices, it's important that an open-source community
> form and provide a RTOS effort that:
> 
> * Accepts community contributions and encourages code reuse
> * Natively supports source package management, to allow for efficient
> redistribution and reuse of software across a broad swath of use cases (from
> wearables to industrial equipment)
> * Supports all of the "new" protocol stacks required for IoT (e.g.
> Bluetooth, IPv6,
> etc.)
> * Has drivers for all new chipsets, sensors, and other devices
> 
> The core of Mynewt has been designed to accommodate these requirements. It
> contains a small, pre-emptive RTOS core, that works on native (OS X,
> Linux) and Cortex platforms (and is easily portable to others), and
> standardized HAL and BSP interfaces.
> 
> It also provides a build and package management tool that allows
> developers to install, develop, and redistribute source packages. This
> tool allows developers to start with the core of the OS and its
> interfaces, and then download only the source packages that are needed to
> run their embedded project. This will allow the community to grow beyond
> just porting the core of the Mynewt system and extend to all of the
> necessary protocol stacks, drivers and sensor interfaces that a modern
> embedded developer will need.
> 
> In addition to the Mynewt core, there is active development around a set
> of commonly needed functionality when developing small embedded systems,
> including:
> 
> * A Flash Filesystem designed for small flashes, with large block 

Re: Draft Report October 2015 - please review

[Ted Dunning]

On Mon, Oct 12, 2015 at 7:21 PM, Marvin Humphrey 
wrote:

> >   [ ](myriad) Benjamin Hindman
> >   [ ](myriad) Danese Cooper
> >   [ ](myriad) Ted Dunning
> >   [ ](myriad) Luciano Resende
>
> Can we get please get sign-off for Myriad?  They turned in a very thorough
> report this month.


Signed.  And I will heckle other mentors off-list.

Re: Incubation capacity

[Ted Dunning]

I think that this is an excellent analysis.

The (gut) feeling I have about scarce resources are:

1) me.  As Marvin noted, I am a failure mode as much as a contributor
lately.  This is largely due to my crazy travel schedule combined with lots
of short term deliverables. Marvin has lightened that load enormously with
the report group and I see that as a good way forward

2) mentors. As Zukka mentions, the number of mentors is roughly constant if
you subtract away those who are MiA


I worry that the lull that others have noted in drama level may be
increasing again. I hope that we can manage that a bit by pushing to
recognize common points of reference, move on to points difference and only
then start discussing solutions.




On Mon, Oct 12, 2015 at 2:13 PM, Jukka Zitting 
wrote:

> Hi,
>
> On Mon, Oct 12, 2015 at 2:50 PM Marvin Humphrey 
> wrote:
> > On Mon, Oct 12, 2015 at 8:08 AM, Jukka Zitting 
> wrote:
> > > It sounds like ruminations about the Incubator are on the increase
> again,
> >
> > I hope that we can make use of some of this bursting energy and channel
> it
> > into incremental improvements.
> >
> > The Incubator is a stable platform, and it has been functioning well by
> > historical terms, and with blessedly low drama compared to a few years
> ago.
> > My impression is that frustration with the institutional resistance of
> > Incubator to change is skewing impressions of how well it is doing its
> job of
> > incubating podlings.
>
> Yes, we're far from the drama of 2011.
>
> > > I believe the way the Incubator is organized sets an upper bound on the
> > > number of podlings it can effectively manage. Based on experience and
> > > historical data (http://incubator.apache.org/history/ *) I believe
> this
> > > limit is somewhere around 30 podlings.
> >
> > I'm curious, Jukka.  Why 30?
>
> I don't have a firm theory on why this is happening, only some key
> observations:
>
> * The entry rate of new podlings has been amazingly constant
> throughout the existence of the Incubator even though the total number
> of open source projects has been growing exponentially for much of
> this time.
>
> * The "limit" was first reached in 2006 during which the board first
> pushed back on Incubator reports and the current monthly 1/3 reporting
> schedule was adopted and the process of retiring dormant podlings was
> adopted.
>
> * The Incubator stayed at or slightly above the 30 podlings limit
> until around mid-2010 after which many podlings started getting stuck,
> leading to the crisis of late 2011.
>
> * We solved that problem with a concentrated effort in 2012 that
> brought the Incubator back to around 30 active podlings, a level that
> stayed mostly stable for the next two years.
>
> * The number of current podlings is again growing, and some of the
> issues that have shown up recently remind me of the problems seen five
> years ago.
>
> It could be that I'm just selectively interpreting history to match my
> theory, but from a systems perspective it does look as if the
> Incubator indeed has a structural bandwidth cap that probably feeds
> into and limits the entry rate.
>
> >  What are the scarce resources?
>
> Some possible answers:
>
> * Mailing list. There is only so much general@ traffic that a single
> IPMC member can reasonably process without starting to skip
> significant parts.
>
> * Mentors. The growth rate of the IPMC is fairly constant and, with
> most members becoming inactive over time, I believe the number of
> active mentors has not grown too much over the years.
>
> * Chair/Report Manager. Someone still needs to pay attention to
> everything that's going around, which I believe you and all other
> recent chairs agree is a daunting task.
>
> One could run some numbers to better quantify the above possibilities.
>
> > And how is this supposed degradation manifesting?
>
> The noise got loud enough to wake me up. :-) I don't have hard
> numbers, but we do have a couple of recent failures and it sounds like
> some people are getting concerned, which does remind me of early 2011.
> Of course the one thing you can learn from history is that things are
> never quite the same.
>
> > Additionally, I'll note that while we're at 43 or so podlings right now,
> we
> > have multiple podlings about to retire (Droids, Kalumet, likely
> Corinthia) and
> > others about to graduate (Kylin, Groovy).
>
> Right, this might be just a fluke.
>
> BR,
>
> Jukka Zitting
>
> -
> To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
> For additional commands, e-mail: general-h...@incubator.apache.org
>
>

RE: Incubation capacity

[Ross Gardler]

With respect to " I hope that we can manage that a bit by pushing to recognize 
common points of reference, move on to points difference and only then start 
discussing solutions." I remind everyone of a perfect starting point for this - 
perhaps we can focus on constructively updating 
http://wiki.apache.org/incubator/IncubatorIssues2013

-Original Message-
From: Ted Dunning [mailto:ted.dunn...@gmail.com] 
Sent: Monday, October 12, 2015 9:26 PM
To: general@incubator.apache.org
Subject: Re: Incubation capacity

I think that this is an excellent analysis.

The (gut) feeling I have about scarce resources are:

1) me.  As Marvin noted, I am a failure mode as much as a contributor lately.  
This is largely due to my crazy travel schedule combined with lots of short 
term deliverables. Marvin has lightened that load enormously with the report 
group and I see that as a good way forward

2) mentors. As Zukka mentions, the number of mentors is roughly constant if you 
subtract away those who are MiA


I worry that the lull that others have noted in drama level may be increasing 
again. I hope that we can manage that a bit by pushing to recognize common 
points of reference, move on to points difference and only then start 
discussing solutions.




On Mon, Oct 12, 2015 at 2:13 PM, Jukka Zitting 
wrote:

> Hi,
>
> On Mon, Oct 12, 2015 at 2:50 PM Marvin Humphrey 
> 
> wrote:
> > On Mon, Oct 12, 2015 at 8:08 AM, Jukka Zitting 
> wrote:
> > > It sounds like ruminations about the Incubator are on the increase
> again,
> >
> > I hope that we can make use of some of this bursting energy and 
> > channel
> it
> > into incremental improvements.
> >
> > The Incubator is a stable platform, and it has been functioning well 
> > by historical terms, and with blessedly low drama compared to a few 
> > years
> ago.
> > My impression is that frustration with the institutional resistance 
> > of Incubator to change is skewing impressions of how well it is 
> > doing its
> job of
> > incubating podlings.
>
> Yes, we're far from the drama of 2011.
>
> > > I believe the way the Incubator is organized sets an upper bound 
> > > on the number of podlings it can effectively manage. Based on 
> > > experience and historical data 
> > > (https://na01.safelinks.protection.outlook.com/?url=http%3a%2f%2fi
> > > ncubator.apache.org%2fhistory%2f=01%7c01%7cRoss.Gardler%40mic
> > > rosoft.com%7c16c58f0566a547707af408d2d3868e32%7c72f988bf86f141af91
> > > ab2d7cd011db47%7c1=6DkLFL2cvSI%2bi9cpO%2fbrzR6vmzQE4xKDInxbq
> > > %2b270bE%3d *) I believe
> this
> > > limit is somewhere around 30 podlings.
> >
> > I'm curious, Jukka.  Why 30?
>
> I don't have a firm theory on why this is happening, only some key
> observations:
>
> * The entry rate of new podlings has been amazingly constant 
> throughout the existence of the Incubator even though the total number 
> of open source projects has been growing exponentially for much of 
> this time.
>
> * The "limit" was first reached in 2006 during which the board first 
> pushed back on Incubator reports and the current monthly 1/3 reporting 
> schedule was adopted and the process of retiring dormant podlings was 
> adopted.
>
> * The Incubator stayed at or slightly above the 30 podlings limit 
> until around mid-2010 after which many podlings started getting stuck, 
> leading to the crisis of late 2011.
>
> * We solved that problem with a concentrated effort in 2012 that 
> brought the Incubator back to around 30 active podlings, a level that 
> stayed mostly stable for the next two years.
>
> * The number of current podlings is again growing, and some of the 
> issues that have shown up recently remind me of the problems seen five 
> years ago.
>
> It could be that I'm just selectively interpreting history to match my 
> theory, but from a systems perspective it does look as if the 
> Incubator indeed has a structural bandwidth cap that probably feeds 
> into and limits the entry rate.
>
> >  What are the scarce resources?
>
> Some possible answers:
>
> * Mailing list. There is only so much general@ traffic that a single 
> IPMC member can reasonably process without starting to skip 
> significant parts.
>
> * Mentors. The growth rate of the IPMC is fairly constant and, with 
> most members becoming inactive over time, I believe the number of 
> active mentors has not grown too much over the years.
>
> * Chair/Report Manager. Someone still needs to pay attention to 
> everything that's going around, which I believe you and all other 
> recent chairs agree is a daunting task.
>
> One could run some numbers to better quantify the above possibilities.
>
> > And how is this supposed degradation manifesting?
>
> The noise got loud enough to wake me up. :-) I don't have hard 
> numbers, but we do have a couple of recent failures and it sounds like 
> some people are getting concerned, which does remind me of early 2011.
> Of course 

Re: Mentor disengagement - a suggestion

[Ted Dunning]

On Mon, Oct 12, 2015 at 11:37 AM, Sam Ruby  wrote:

>
> Now on to the substance of my reply:
>
> https://whimsy.apache.org/incubator/signoff
>
> If we can get some volunteers to split this list up, perhaps we can
> reach out to those that haven't been participating in signoffs and see
> what changes need to be made.


Uh... Sam, I see you haven't been signing off on odftoolkit. Is this
something we should be concerned about?

Sounds like reaching out to the inactive mentors is a great idea and I
think we have a great example here of how complicated it can be.

Re: Draft Report October 2015 - please review

[Marvin Humphrey]

> * Did not report, expected next month
>
>   - BatchEE
>   - Climate Model Diagnostic Analyzer (2 months late)
>   - Cotton (2 months late)
>   - DataFu
>   - HORN
>   - ODF Toolkit
>   - Ripple (4 months late)

A disappointingly large number of podlings did not report this month.  It is
probably worth looking into what is up with CMDA, Cotton and Ripple.

> 
> Myriad

>   1. Determine the best way to take github pull requests or ReviewBoard patch
>  (chains) and apply/commit them to the Myriad git repo. We're looking at
>  Mesos' apply-review.sh script, but I wonder if there's something else
>  out there we should be considering. Is there a way to make github
>  'Merge' integration just work, even through the mirror?

I suggest that Myriad developers ask on infrastructure-dev@apache about this.

>   3. Prepare our first release under Apache. We'll update the code's
>  copyright/namespace and packaging, but we still need to learn the other
>  elements of the Apache release process. Is this "DRAFT" still the best
>  resource? https://incubator.apache.org/guides/releasemanagement.html

The releasemanagement.html page is bloated and outdated, but there is no
central resource which has supplanted it.

Efforts are underway to address the state of Apache's policy documentation.

> Signed-off-by:
>
>   [ ](myriad) Benjamin Hindman
>   [ ](myriad) Danese Cooper
>   [ ](myriad) Ted Dunning
>   [ ](myriad) Luciano Resende

Can we get please get sign-off for Myriad?  They turned in a very thorough
report this month.

> Signed-off-by:
>
>   [ ](openaz) Emmanuel Lecharny
>   [ ](openaz) Colm O Heigeartaigh
>   [ ](openaz) Hadrian Zbarcea
>
> Shepherd/Mentor notes:
>
>   P. Taylor Goetz (ptgoetz):
>
> The OpenAz report is pretty sparse and has not been signed off
> by any of the podling's mentors. dev@ mailing list activity is
> extremely low (15 messages in the past 3 months). I would recommend
> the top priority be for the project to expand the community.

The deadline for Mentor sign-off is Tuesday end of day.  If a report has no
sign-off it will be removed from the report.

I really hope that we can get OpenAZ and Myriad signed off.

Marvin Humphrey

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

Re: Draft Report October 2015 - please review

[Hadrian Zbarcea]

Please add Brooklyn to the Graduations section. It's already added to 
the Board agenda.


Thanks,
Hadrian

On 10/12/2015 03:11 PM, Marvin Humphrey wrote:

Incubator PMC report for October 2015

The Apache Incubator is the entry path into the ASF for projects and
codebases wishing to become part of the Foundation's efforts.

There are 44 podlings currently undergoing incubation.

* Community

   New IPMC members:

   - Josh Elser
   - Sterling Hughes

* New Podlings

   - MADlib
   - Rya
   - Unomi

* Graduations

   The board has motions for the following:


 - Brooklyn

   - Calcite

* Releases

   The following releases were made since the last Incubator report:

   - 2015-09-06 Apache Kylin 1.0-incubating
   - 2015-09-14 Apache Brooklyn 0.8.0-incubating
   - 2015-09-14 Apache HTrace-4.0.0-incubating
   - 2015-09-15 Apache TinkerPop 3.0.1-incubating
   - 2015-09-16 Apache Groovy 2.4.5-incubating
   - 2015-09-21 Apache Sentry-1.6.0-incubating
   - 2015-09-22 Apache AsterixDB Hyracks 0.2.16-incubating

* IP Clearance

   - Raytheon BBN Technologies Corp donated POI Visio, an extension module for
 Apache POI. It adds support for the Microsoft Visio .vsdx xml-based file
 format. (Current Apache POI Visio support only handled the older binary
 .vsd format). Post-import, the component will be known as XDGF.

* Infrastructure

   - It seems that an incorrect date in the Board meeting calendar caused the
 report reminders to fire a week early, requiring manual cleanup after the
 correct date was established.  There was discussion of migrating the
 reminders and other Incubator bookkeeping to Whimsy.

* Miscellaneous

   - At the height of Corinthia's crisis, several committers resigned.  The
 mailing lists have since gone silent.  Some IPMC members followed up but
 those efforts do not appear to have been successful.
   - A vote to retire the Droids podling is pending.
   - Various proposals to change the Incubator have been discussed on
 general@incubator.  The one generating the most responses, mostly in
 opposition, is a proposal which would lessen the role of Mentors with
 business affiliations to podlings during Incubator entry and exit votes.
 None of the other proposals have gotten any traction.
   - A proposal regarding the Incubator formulated during ApacheCon EU was
 discussed on board@apache.

* Credits

   - Report Manager: Marvin Humphrey

 Summary of podling reports 

* Still getting started at the Incubator

   - HAWQ
   - MADlib

* Not yet ready to graduate

   No release:

   - Apex
   - FreeMarker
   - Geode
   - Myriad
   - OpenAZ

* Ready to graduate

   - Groovy

   The Board has motions for the following:

   - Calcite

* Did not report, expected next month

   - BatchEE
   - Climate Model Diagnostic Analyzer (2 months late)
   - Cotton (2 months late)
   - DataFu
   - HORN
   - ODF Toolkit
   - Ripple (4 months late)

* Report reviewed but not signed off by Mentors, expected next month

   - Wave

* Likely to retire

   - Droids

--
Table of Contents
Apex
FreeMarker
Geode
Groovy
HAWQ
MADlib
Myriad
ODF Toolkit
OpenAz
Wave

--


Apex

Apex is an enterprise grade native YARN big data-in-motion platform that
unifies stream processing as well as batch processing.

Apex has been incubating since 2015-08-17.

Three most important issues to address in the move towards graduation:

   1. Release Apex-Core, and Apex-Malhar at least twice.
   2. Grow contributors beyond the initial set.

Any issues that the Incubator PMC (IPMC) or ASF Board wish/need to be
aware of?

   None. Thanks for continual support.

How has the community developed since the last report?

   The community is very engaged with the development of the project. There
   have been 485 messages on dev@.

   The community voted and selected the APEX logo which is put on the brand
   new project website at http://apex.incubator.apache.org/

How has the project developed since the last report?

   Various metrics are as follows:
   +---+
   |   Metric | Core  | Malhar |
   +---+
   | Non Merge Commits|  88   |   33   |
   | Contributors |  17   |9   |
   | Jira Issues  |  94   |   30   |
   | Resolved Issues  |  30   |4   |
   +---+

   The project is still using the Atlassian instance of JIRA. The migration to
   Apache JIRA is underway.

   The first release of the project under ASF banner (3.2.0) is targeted to be
   branched off at the end of September.

Date of last release:

   No release under ASF-Incubation code 

Re: Draft Report October 2015 - please review

[Marvin Humphrey]

On Mon, Oct 12, 2015 at 7:57 PM, Hadrian Zbarcea  wrote:
> Please add Brooklyn to the Graduations section. It's already added to the
> Board agenda.

Done -- thanks!

Marvin Humphrey

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