Re: Incubator Information Terrakube

[Roman Shaposhnik]

On Sat, Dec 30, 2023 at 12:16 PM alfredo españa  wrote:
>
> Hello
>
> We have been working on an open source project called Terrakube that is an
> open source alternative to proprietary tools like Terraform Enterprise or
> Terraform Cloud. In the last couple of months we have noticed an increasing
> interest in a project like this that help to manage infrascture
>
> Project Links:
> - https://terrakube.org/
> - https://docs.terrakube.io/
> - https://github.com/AzBuilder/terrakube
>
> We would like to see if this project is a good candidate to be in the
> apache incubator program

While ASF may end up a really great home for your project, I can't
help but wonder whether you also considered approaching LF with all
the excitement around that they are building around
https://opentofu.org/ ?

Thanks,
Roman.

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

Re: [DISCUSS] HoraeDB proposal

[Roman Shaposhnik]

On Tue, Nov 28, 2023 at 12:12 PM Justin Mclean  wrote:
>
> Hi,
>
> We need to know the reasons for the name change and why the company is 
> willing to donate the code but not the name. The possibility of having them 
> forking the community later is a risk the Incubator needs to know about and 
> should be mentioned in the proposal. Having a brand closely associated with a 
> project and owned by a single corporate entity is a risk to the project. Why 
> a company would be unwilling to give up that brand or trademark just because 
> it may be convenient in the future is a concern.

While I agree that having a clear reason stated would be helpful, I
think I have a different take on the risks you are outlining here.

We have tons of examples here in the ASF of project Foo being used to
power commercial product Bar (Geode/Gemfire, Ignite/GridGain,
Kafka/Confluent, and many, many more). So this kind of dual branding
is nothing new -- there's no community fork involved per se.

It would be nice if the original name of the open source project (as
it existed on Github) was donated to ASF and the new name for a
commercially developed product was picked. But even if it is the other
way around -- I actually don't see any risks for the foundation in
this approach (as long as it is clearly understood that the branding
guidelines on both sides need to be honored).

Thanks,
Roman.

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

Re: Is llvm exception allowed for incubator projects?

[Roman Shaposhnik]

On Tue, Oct 24, 2023 at 10:25 AM Bertrand Delacretaz
 wrote:
>
> Hi Roman,
>
> On Tue, Oct 24, 2023 at 8:55 AM Roman Shaposhnik  wrote:
> > ...If you decide to distribute convenience binary artifact -- only then the 
> > LLVM exception
> > will apply and it will be OK...
>
> Shouldn't that exception be mentioned at
> https://www.apache.org/legal/resolved.html ?
>
> I searched for "llvm" there but found nothing.

It is a good point that we don't really talk about licensing
implications around binary convenience artifacts on that page
(although we do have a number of LEGAL JIRAs). It is not just llvm,
but we also don't really talk about class-path exceptions in detail,
nor do we talk about GNU's GCC Runtime Library Exception and there are
a few others that come to mind right away.

Part of me wants to propose we have a separate section of that page
dedicated to use-cases like that, but part of me feels that the page
is too long already.

Historically, we haven't really paid too much attention to the binary
convenience artifacts anyway -- so that perpetuates the status quo.

At any rate, Bertrand, if you feel strongly about this -- perhaps a
discussion on legal-discuss@ is warranted.

Thanks,
Roman.

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

Re: Is llvm exception allowed for incubator projects?

[Roman Shaposhnik]

On Tue, Oct 24, 2023 at 4:59 AM Ivan I  wrote:
>
> If my project uses “Apache License v2.0 with LLVM Exceptions”
> LLVM Exceptions being:
>  LLVM Exceptions to the Apache 2.0 License 
> As an exception, if, as a result of your compiling your source code,
> portions
> of this Software are embedded into an Object form of such source code, you
> may redistribute such embedded portions in such Object form without
> complying
> with the conditions of Sections 4(a), 4(b) and 4(d) of the License.
> In addition, if you combine or link compiled forms of this Software with
> software that is licensed under the GPLv2 ("Combined Software") and if a
> court of competent jurisdiction determines that the patent provision
> (Section
> 3), the indemnity provision (Section 9) or other Section of the License
> conflicts with the conditions of the GPLv2, you may retroactively and
> prospectively choose to deem waived or otherwise exclude such Section(s) of
> the License, but only in their entirety and only with respect to the
> Combined
> Software.
> Can my project go into incubator?

Yes you can.

> Will I need to change license at some point?

No. The source code in the incubator and later ASF will be licensed under ALv2.
The source code releases will be licensed under ALv2. If you decide to
distributed
convenience binary artifact -- only then the LLVM exception will apply
and it will be OK.

> I am asking to avoid future headache like llvm has with license
> change.
> I looked all over incubator web site but could not find an answer

You are unlikely to find anything like that on incubator websites.
This is generic
ASF licensing mechanics.

Thanks,
Roman.

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

Re: [VOTE] Accept ResilientDB Into The Apache Incubator

[Roman Shaposhnik]

On Mon, Oct 16, 2023 at 1:10 PM Atri Sharma  wrote:
>
> Following up the [DISCUSS] thread on ResilientDB,  I would like to call a
> VOTE to accept into the Apache Incubator.
>
>  Please cast your vote:
>
>  [ ] +1, bring into the Incubator
> [ ] +0, I don't care either way
> [ ] -1, do not bring ResilientDB into the Incubator, because...
>
> The vote will open at least for 72 hours and only votes from the
> Incubator PMC are binding, but votes from everyone are welcome.
>
>  Please check out the ResilientDB Proposal from the incubator wiki[1].
>
>  [1]https://cwiki.apache.org/confluence/display/INCUBATOR/ResilientDBProposal

+1 (binding)

Thanks,
Roman.

P.S. I literally started to compose that same email just now ;-)

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

Re: [DISCUSS] Incubating Proposal of ResilientDB

[Roman Shaposhnik]

gt; >>>>>
> > >>>
> > >>
> > https://cwiki.apache.org/confluence/display/INCUBATOR/ResilientDBProposal
> > >>>>>
> > >>>>> Willem Jiang
> > >>>>>
> > >>>>> Twitter: willemjiang
> > >>>>> Weibo: 姜宁willem
> > >>>>>
> > >>>>> On Sun, Oct 8, 2023 at 1:38 PM 俊平堵  wrote:
> > >>>>>>
> > >>>>>> +1.
> > >>>>>> btw, I assume we will have an official vote thread (start with
> > >>> [VOTE])
> > >>>>>> later?
> > >>>>>>
> > >>>>>> Thanks,
> > >>>>>>
> > >>>>>> JP
> > >>>>>>
> > >>>>>> Atri Sharma  于2023年10月3日周二 19:24写道：
> > >>>>>>
> > >>>>>>> We want to propose ResilientDB as a new Apache Incubator project.
> > >>>>>>>
> > >>>>>>> ResilientDB[1] is a distributed blockchain framework that is
> > >>> written
> > >>>>>>> in C++ and integrates with Byzantine Fault-Tolerant (BFT) and
> > >> Crash
> > >>>>>>> Fault-Tolerant (CFT) consensus protocols. Code is present at [2].
> > >>>>>>>
> > >>>>>>> Key features:
> > >>>>>>>
> > >>>>>>> Provides a scalable client-server architecture. Each developer
> > >> can
> > >>> use
> > >>>>>>> the ResilientDB framework to deploy a replicated service acting
> > >> as
> > >>> a
> > >>>>>>> service. The developer can choose the desired number of replicas
> > >>> and
> > >>>>>>> the number of clients its system should tolerate.
> > >>>>>>>
> > >>>>>>> Provides native integration with PBFT consensus protocol –
> > >> arguably
> > >>>>>>> the most popular BFT consensus protocol. PBFT helps replicas
> > >> reach
> > >>> an
> > >>>>>>> agreement for ordering the client's requests.
> > >>>>>>>
> > >>>>>>> Provides a mechanism to simulate the failure of different
> > >> replicas
> > >>>>>>> (including the leader).
> > >>>>>>>
> > >>>>>>> Provides a correct implementation of the view-change protocol
> > >> that
> > >>>>>>> replaces a faulty (or malicious) leader and moves all replicas to
> > >>> the
> > >>>>>>> new view.
> > >>>>>>>
> > >>>>>>> Provides checkpoint and recovery protocols to facilitate garbage
> > >>>>>>> collection, recovery of failed replicas, and durably logging of
> > >> the
> > >>>>>>> blockchain state.
> > >>>>>>>
> > >>>>>>> Eases development and testing of newer and optimized BFT and CFT
> > >>>>>>> consensus protocols.
> > >>>>>>> Provides clients with support for three different application
> > >>>>> interfaces:
> > >>>>>>>
> > >>>>>>> Key-Value Stores - where client transactions include key-value
> > >>> pairs.
> > >>>>>>>
> > >>>>>>> Smart Contracts - where clients issue smart contracts in Solidity
> > >>> for
> > >>>>>>> processing.
> > >>>>>>>
> > >>>>>>> UTXO - where clients issue unspent transactions similar to ones
> > >> in
> > >>>>> Bitcoin.
> > >>>>>>>
> > >>>>>>> Facilitates benchmarking system/protocol performance with the
> > >> help
> > >>> of
> > >>>>>>> existing benchmarks, such as YCSB [SoCC’10] and Diablo
> > >>> [EuroSys’23].
> > >>>>>>>
> > >>>>>>> Stores non-volatile ledger (blockchain) in memory and for further
> > >>>>>>> durability, provides APIs to store both client data and
> > >> blockchain
> > >>> in
> > >>>>>>> LevelDB and RocksDB.
> > >>>>>>>
> > >>>>>>>
> > >>>>>>> The serving mentors would be:
> > >>>>>>>
> > >>>>>>> Junping Du 
> > >>>>>>>
> > >>>>>>> Calvin Kirs 
> > >>>>>>>
> > >>>>>>> Kevin Ratnasekera 
> > >>>>>>>
> > >>>>>>> Roman Shaposhnik 
> > >>>>>>>
> > >>>>>>> Christian Grobmeier 
> > >>>>>>>
> > >>>>>>> and I shall be serving as the Champion.
> > >>>>>>>
> > >>>>>>> We have not done a trademark check yet for the name but that can
> > >> be
> > >>>>>>> pursued independently.
> > >>>>>>>
> > >>>>>>> [1]
> > >>>>>>>
> > >>>>>
> > >>>
> > >>
> > https://cwiki.apache.org/confluence/display/INCUBATOR/ResilientDBProposal
> > >>>>>>> [2] https://github.com/resilientdb/resilientdb
> > >>>>>>>
> > >>>>>>> Atri
> > >>>>>>>
> > >>>>>>>
> > >>> -
> > >>>>>>> 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
> > >>>
> > >>>
> > >>
> > >
> > >
> > > --
> > > *- Regards*
> > >
> > > *Suyash Gupta, PhD *
> > > *SkyLab*
> > > *Dept. of Computer Science*
> > > *University of California Berkeley*
> >
> > -
> > 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] Incubating Proposal of ResilientDB

[Roman Shaposhnik]

On Tue, Oct 3, 2023 at 2:24 PM Atri Sharma  wrote:
>
> We want to propose ResilientDB as a new Apache Incubator project.
>
> ResilientDB[1] is a distributed blockchain framework that is written
> in C++ and integrates with Byzantine Fault-Tolerant (BFT) and Crash
> Fault-Tolerant (CFT) consensus protocols. Code is present at [2].
>
> Key features:
>
> Provides a scalable client-server architecture. Each developer can use
> the ResilientDB framework to deploy a replicated service acting as a
> service. The developer can choose the desired number of replicas and
> the number of clients its system should tolerate.
>
> Provides native integration with PBFT consensus protocol – arguably
> the most popular BFT consensus protocol. PBFT helps replicas reach an
> agreement for ordering the client's requests.
>
> Provides a mechanism to simulate the failure of different replicas
> (including the leader).
>
> Provides a correct implementation of the view-change protocol that
> replaces a faulty (or malicious) leader and moves all replicas to the
> new view.
>
> Provides checkpoint and recovery protocols to facilitate garbage
> collection, recovery of failed replicas, and durably logging of the
> blockchain state.
>
> Eases development and testing of newer and optimized BFT and CFT
> consensus protocols.
> Provides clients with support for three different application interfaces:
>
> Key-Value Stores - where client transactions include key-value pairs.
>
> Smart Contracts - where clients issue smart contracts in Solidity for
> processing.
>
> UTXO - where clients issue unspent transactions similar to ones in Bitcoin.
>
> Facilitates benchmarking system/protocol performance with the help of
> existing benchmarks, such as YCSB [SoCC’10] and Diablo [EuroSys’23].
>
> Stores non-volatile ledger (blockchain) in memory and for further
> durability, provides APIs to store both client data and blockchain in
> LevelDB and RocksDB.
>
>
> The serving mentors would be:
>
> Junping Du 
>
> Calvin Kirs 
>
> Kevin Ratnasekera 
>
> Roman Shaposhnik 
>
> Christian Grobmeier 
>
> and I shall be serving as the Champion.
>
> We have not done a trademark check yet for the name but that can be
> pursued independently.
>
> [1] https://cwiki.apache.org/confluence/display/INCUBATOR/ResilientDBProposal
> [2] https://github.com/resilientdb/resilientdb

+1 (binding)

Thanks,
Roman.

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

Re: Looking for a Champion / Mentors for ResilientDB Blockchain Platform

[Roman Shaposhnik]

On Thu, Sep 28, 2023 at 7:46 PM Atri Sharma  wrote:
>
> Sorry was away due to medical reasons.

And my time to apologise as well -- past few weeks were crazy, but I'm
now fully available to help with the project.

> I will start this tonight

Looking forward to it!

Thanks,
Roman.

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

Re: Looking for a Champion / Mentors for ResilientDB Blockchain Platform

[Roman Shaposhnik]

On Mon, Aug 21, 2023 at 12:48 AM Mo Sadoghi  wrote:

> Dear Roman
>
> Thank you for your kind support.
>
> Indeed our PoC is well fitting for the Apache foundation’s community.
>
> Would you be willing to kindly serve as one of our mentors? We currently
> have 3 formal mentors plus 2 informal mentors.
>

I would be delighted to help -- please count me in!

Thanks,
Roman.


>
> Best
> Mohamad Sadoghi
>
>
> On Sun, Aug 20, 2023 at 2:04 AM Roman Shaposhnik 
> wrote:
>
> > On Fri, Aug 18, 2023 at 12:55 AM Mo Sadoghi 
> > wrote:
> > >
> > > Dear Apache Members,
> > >
> > > Hope you are safe and well.
> > >
> > > Over the past 6 years, we have been developing a distributed blockchain
> > > framework, called ResilientDB <https://resilientdb.com/>, which has
> been
> > > open-sourced <https://github.com/resilientdb/resilientdb> since 2019.
> > > ResilientDB is a lightweight and highly performant framework (written
> in
> > > C++) that has been extensively evaluated and refined resulting in over
> 20
> > > publications and 2 books. It allows for easy integration with various
> > > Byzantine Fault-Tolerant (BFT) and Crash Fault-Tolerant (CFT) consensus
> > > protocols. ResilientDB has been a key educational tool, thus far, 1
> > > postdoc, 3 Ph.D., and 13 MSc students have graduated while working on
> it.
> > > Furthermore, it has been used in the classroom for the past 5 years
> with
> > > several hundred students utilizing it for their course projects. The
> > > current core team of ResilientDB consists of 1 Postdoc, 2 PhD, 8 MSc,
> > and 6
> > > BSc.  In addition to academic success, it has been utilized by our
> > industry
> > > partners (e.g., Radix Ltd <https://www.radixdlt.com/> and Mysten Labs
> > > <https://mystenlabs.com/>) for analysis and as an industrial-strength
> > > framework to implement their consensus protocols. The broader team of
> > > active contributors currently included UCB, UCI, UPenn, and McMaster U.
> > >
> > > Our ResilientDB platform has now reached a stable point in its product
> > > life-cycle, and we believe it is now an excellent candidate to be
> > > considered for the Apache Incubation program to further expand its
> reach
> > > and development by building a larger community and ecosystem around it.
> > > Furthermore, considering the thriving field of blockchain / distributed
> > > ledger, Apache does not have any core blockchain software in its
> > portfolio.
> > >
> > > We are looking for champions and mentors for our project. Your kind
> > support
> > > is greatly appreciated. We look forward to growing and expanding our
> > > product as part of the Apache community.
> > >
> > > Here is the live / latest draft of the proposal.
> > >
> >
> https://docs.google.com/document/d/12WPvs1A7tqH8VjkMrgXTGQ_z4fiL6f6oi32e7bxSjXc/edit?usp=sharing
> > >
> > > Currently, we have *Anh Dinh*, Apache SINGA’s PMC, as our Apache mentor
> > > (cc'ed).
> >
> > It is extremely exciting to see a project like this seeking the ASF's
> > governance! Somehow I find it particularly fitting that one of the
> > innovations in your technology is PoC -- Proof Of Collaboration -- it
> > seems to me that this is somehow very on-brand for the ASF ;-)
> >
> > Best of luck!
> >
> > Oh, and on the mentors side -- I always advise projects to have at
> > least 3 mentors. If nothing else -- that tends to make voting on your
> > releases a much smoother experience.
> >
> > Thanks,
> > Roman.
> >
> > -
> > To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
> > For additional commands, e-mail: general-h...@incubator.apache.org
> >
> > --
> Best Regards,
> Mohammad Sadoghi, PhD
> Associate Professor
> Exploratory Systems Lab (ExpoLab)
> Department of Computer Science
> University of California, Davis
>

Re: Looking for a Champion / Mentors for ResilientDB Blockchain Platform

[Roman Shaposhnik]

On Fri, Aug 18, 2023 at 12:55 AM Mo Sadoghi  wrote:
>
> Dear Apache Members,
>
> Hope you are safe and well.
>
> Over the past 6 years, we have been developing a distributed blockchain
> framework, called ResilientDB , which has been
> open-sourced  since 2019.
> ResilientDB is a lightweight and highly performant framework (written in
> C++) that has been extensively evaluated and refined resulting in over 20
> publications and 2 books. It allows for easy integration with various
> Byzantine Fault-Tolerant (BFT) and Crash Fault-Tolerant (CFT) consensus
> protocols. ResilientDB has been a key educational tool, thus far, 1
> postdoc, 3 Ph.D., and 13 MSc students have graduated while working on it.
> Furthermore, it has been used in the classroom for the past 5 years with
> several hundred students utilizing it for their course projects. The
> current core team of ResilientDB consists of 1 Postdoc, 2 PhD, 8 MSc, and 6
> BSc.  In addition to academic success, it has been utilized by our industry
> partners (e.g., Radix Ltd  and Mysten Labs
> ) for analysis and as an industrial-strength
> framework to implement their consensus protocols. The broader team of
> active contributors currently included UCB, UCI, UPenn, and McMaster U.
>
> Our ResilientDB platform has now reached a stable point in its product
> life-cycle, and we believe it is now an excellent candidate to be
> considered for the Apache Incubation program to further expand its reach
> and development by building a larger community and ecosystem around it.
> Furthermore, considering the thriving field of blockchain / distributed
> ledger, Apache does not have any core blockchain software in its portfolio.
>
> We are looking for champions and mentors for our project. Your kind support
> is greatly appreciated. We look forward to growing and expanding our
> product as part of the Apache community.
>
> Here is the live / latest draft of the proposal.
> https://docs.google.com/document/d/12WPvs1A7tqH8VjkMrgXTGQ_z4fiL6f6oi32e7bxSjXc/edit?usp=sharing
>
> Currently, we have *Anh Dinh*, Apache SINGA’s PMC, as our Apache mentor
> (cc'ed).

It is extremely exciting to see a project like this seeking the ASF's
governance! Somehow I find it particularly fitting that one of the
innovations in your technology is PoC -- Proof Of Collaboration -- it
seems to me that this is somehow very on-brand for the ASF ;-)

Best of luck!

Oh, and on the mentors side -- I always advise projects to have at
least 3 mentors. If nothing else -- that tends to make voting on your
releases a much smoother experience.

Thanks,
Roman.

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

Re: A little incubator game

[Roman Shaposhnik]

This is amazeballs!

Thanks,
Roman.

P.S. Also "You have been incubating for 2.9004 months." LOL!

On Tue, Apr 4, 2023 at 5:26 AM Justin Mclean  wrote:
>
> A hint: Working on the code may not attract contribitors as quickly as some
> other activities.
>
> On Tue, 4 Apr 2023, 11:51 am Josh Fischer,  wrote:
>
> > I haven’t gone through the game in detail yet, but I think it’s an
> > interesting approach to getting people to understand the ways of the Apache
> > foundation and incubator.
> >
> > My favorite part of the game is when you keep clicking on “work on the
> > code” and the months pass by with no releases or new committers.
> >
> > Good thinking and +1 to you, Justin.
> >
> > On Mon, Apr 3, 2023 at 5:07 PM Justin Mclean 
> > wrote:
> >
> > > Hi,
> > >
> > > A work in progress, so there may be spelling errors and bugs. Just like
> > in
> > > real life, the game ends when you stop playing it but things can happen
> > to
> > > you along the way.
> > >
> > > http://incubator-game.s3-website-us-east-1.amazonaws.com
> > >
> > > Made using an open source engine https://twinery.org, the output is
> > > compatible with the Apache license if anyone was wondering.
> > >
> > > Feedback welcome.
> > >
> > > Kind Regards,
> > > Justin
> > > -
> > > To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
> > > For additional commands, e-mail: general-h...@incubator.apache.org
> > >
> > > --
> > Sent from A Mobile Device
> >

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

Re: Seeking ASF Champion for a New ASF “podling”

[Roman Shaposhnik]

Hi!

quick question from the peanut gallery (or somebody who maybe
interested to be a mentor).
I'm confused as to whether there's a GitHub repo I can take a look at
to provide additional
advice?

Thanks,
Roman.

On Mon, Apr 3, 2023 at 7:18 PM Kevin Ratnasekera
 wrote:
>
> Hi Hao,
>
> From the description, it is not fully clear to me which project you are
> proposing for the Apache Incubator. Do you already have a proposed project
> formed or is the project still in its inception phase where you
> are looking for  new ideas? Do you have a link to the project you are
> proposing?
> We prefer projects which are open sourced for a while and at least have a
> functioning community ( few members ) around it.
> As next steps, basically you need to create an Incubator project proposal,
> maybe a champion and few mentors will help you out creating the proposal.
> Then the project proposal needs to be discussed and voted @general list on
> whether it is accepted as an Incubator project or not.
>
> Regards
> Kevin
>
> On Wed, Mar 29, 2023 at 2:22 AM Hao Xu  wrote:
>
> > Hi Calvin,
> > haven't heard back from you. What would be the next step to start
> > the project? thanks!
> >
> > Best,
> > Hao
> >
> > On Tue, Mar 21, 2023 at 7:23 PM Calvin Kirs  wrote:
> >
> > > But I have a question, Are these new podlings based on your previous
> > > project[1]?
> > > or other?
> > > Does it have specific projects?
> > >
> > >
> > > [1] https://github.com/feast-dev/feast
> > >
> > > On Wed, Mar 22, 2023 at 10:11 AM Calvin Kirs  wrote:
> > > >
> > > > Hi Hao,
> > > >
> > > > I am interested in this project, if you need a champion or mentor, I
> > can
> > > help.
> > > >
> > > > On Wed, Mar 22, 2023 at 3:24 AM Hao Xu  wrote:
> > > > >
> > > > > Dear ASF Community,
> > > > >
> > > > > I’m writing to propose a new project at Apache Software Foundation. A
> > > little bit about myself, I’m currently a senior software engineer in the
> > > Affirm ML Platform team (possibly switching soon), and have around 5
> > years
> > > experience in a couple startups, all working in the Data and Machine
> > > Learning infrastructure.
> > > > > Over the past few years I’ve seen a general pattern arising in many
> > > companies to build the ML infrastructure, especially on the feature
> > store <
> > > https://www.featurestore.org/>. And I have built similar products across
> > > all my previous and current companies, including in-house solutions,
> > using
> > > the 3rd-party vendor: https://www.tecton.ai/ ,
> > > open source project: https://github.com/feast-dev/feast <
> > > https://github.com/feast-dev/feast> and
> > > https://github.com/feathr-ai/feathr  > >.
> > > > > But still those products are not able to well resolve the most
> > > important part of a feature store: transformation, or we can call it
> > > featurization.
> > > > > So I’m proposing a new podling project - Featurizer (name can change)
> > > to build an open source feature platform - aims to address the challenges
> > > of feature engineering in machine learning by developing a software
> > > framework that can automatically extract relevant features from raw
> > data.It
> > > will provide a wide range of featurization algorithms that can be
> > > customized and combined to fit the specific needs of different
> > > applications. And by leveraging three types of features: request based
> > real
> > > time feature, stream feature, and batch feature, the framework is
> > supposed
> > > to run on different processor engines such as apache spark, Flink, Beam,
> > or
> > > microservices etc.
> > > > > I’m still new to podling here, I did few contributions before but
> > it’s
> > > the first time proposing a project. So I’m looking for suggestions,
> > > feedbacks, champions and mentors to help on starting the project.
> > > > >
> > > > > Thanks
> > > > >
> > > >
> > > >
> > > > --
> > > > Best wishes！
> > > > CalvinKirs
> > >
> > >
> > >
> > > --
> > > Best wishes！
> > > CalvinKirs
> > >
> >

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

Re: Are programming languages suitable for Apache?

[Roman Shaposhnik]

On Mon, Jan 9, 2023 at 12:22 AM Rupert Smith
 wrote:
>
> On Sun, 8 Jan 2023 at 08:08, Vladimir Sitnikov 
> wrote:
>
> > > You are right about that, and I think that ultimately could prevent it
> > from
> > > happening
> >
> > Can you elaborate?
> >
> > Suppose Apache Bicycle project takes the current Elm code in a source
> > form and evolves it.
> > It should be pretty much possible.
> >
> > BSD-3 code may be included in Apache projects.
> > BSD-3 does not forbid modifications.
> > Eventually, the newly added files (and completely rewritten ones)
> > would be licensed under Apache-2.
> >
>
> To elaborate, I was under the impression that copyright ownership of code
> had to be transferred to Apache, so thinking that is unlikely to happen so
> would be a deal breaker. But your comments on BSD-3 compatability are
> illuminating, thanks for the explanation.

FWIW: Apache HAWQ went through exactly the same exercise -- a lot of
existing code was from Postgres (under BSD-like license) but the new
code created when the project joined ASF was all under ALv2.

Thanks,
Roman.

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

Re: [VOTE] Graduate Apache StreamPieps to a TLP

[Roman Shaposhnik]

+1 (binding)

and yes -- best of luck!

On Tue, Nov 8, 2022 at 6:13 PM Lars Francke  wrote:
>
> +1 (binding)
>
> On Sun, Nov 6, 2022 at 10:32 PM Dominik Riemer  wrote:
>
> > Hi everyone,
> >
> > following the [DISCUSS] thread at [0], I'd like to call a vote to graduate
> > StreamPipes to a TLP.
> >
> > Please vote accordingly:
> >
> > [ ] +1 Apache StreamPipes (incubating) is ready to graduate from the
> > Apache Incubator to a TLP.
> >
> > [ ] +0 No opinion.
> >
> > [ ] -1 Apache StreamPipes (Incubating) is not ready to graduate (please
> > state reasons)
> >
> > Thank you for participating in the vote!
> >
> > Cheers
> > Dominik
> >
> >
> > ---
> > Project highlights
> > ---
> >
> > * Incubating since 2019-11-11
> > * 5 releases (0.66.0, 0.67.0, 0.68.0, 0.69.0, 0.70.0)
> > * 3 different release managers
> > * 13 PPMC members (almost all from different organizations), including 5
> > mentors
> > * 8 additional committers
> > * active community with all discussions happening on the mailing list and
> > dedicated user mailing list as support channel
> > * community building & talks at ACNA19, 20, 21, 22 + Asia, SF Big Data
> > Analytics and many other webinars
> > * over 9.000 commits
> > * 52 subscribers on the dev list, 57 subscribers on the users list
> > * Articles about StreamPipes in the US Linux Magazine [4], and StreamPipes
> > was named one of the
> > top 5 open source tools for IoT Analytics by OpenSourceForU [5]
> > * Number of Github stars has increased to currently 350
> > * Website [6], extensive documentation [7] and a developer wiki [8]
> > * Strong connection and integration with other projects in the Apache IoT
> > space (e.g., PLC4X)
> > * Completed maturity self-assessment [9]
> >
> >
> > ---
> > Draft resolution
> > ---
> >
> > Establish the Apache StreamPipes Project
> >
> > WHEREAS, the Board of Directors deems it to be in the best interests of
> > the Foundation and consistent with the Foundation's purpose to establish
> > a Project Management Committee charged with the creation and maintenance
> > of open-source software, for distribution at no charge to the public,
> > related to a self-service Industrial IoT toolbox which enables
> > non-technical users to connect, analyze and explore IoT
> > data streams.
> >
> > NOW, THEREFORE, BE IT RESOLVED, that a Project Management Committee
> > (PMC), to be known as the "Apache StreamPipes Project", be and hereby is
> > established pursuant to Bylaws of the Foundation; and be it further
> >
> > RESOLVED, that the Apache StreamPipes Project be and hereby is
> > responsible for the creation and maintenance of software related to a
> > self-service Industrial IoT toolbox which enables non-technical users to
> > connect, analyze and explore IoT data streams; and be it
> > further
> >
> > RESOLVED, that the office of "Vice President, Apache StreamPipes" be and
> > hereby is created, the person holding such office to serve at the
> > direction of the Board of Directors as the chair of the Apache
> > StreamPipes Project, and to have primary responsibility for management
> > of the projects within the scope of responsibility of the Apache
> > StreamPipes Project; and be it further
> >
> > RESOLVED, that the persons listed immediately below be and hereby are
> > appointed to serve as the initial members of the Apache StreamPipes
> > Project:
> >
> > * Christofer Dutz 
> > * Dominik Riemer 
> > * Grainier Perera 
> > * Jean-Baptiste Onofré 
> > * Johannes Tex 
> > * Julian Feinauer 
> > * Justin Mclean 
> > * Kenneth Knowles 
> > * Marco Heyden 
> > * Patrick Wiener 
> > * Philipp Zehnder 
> > * Stefan Obermeier 
> > * Tim Bossenmaier 
> >
> > NOW, THEREFORE, BE IT FURTHER RESOLVED, that Philipp Zehnder be
> > appointed to the office of Vice President, Apache StreamPipes, to serve
> > in accordance with and subject to the direction of the Board of
> > Directors and the Bylaws of the Foundation until death, resignation,
> > retirement, removal or disqualification, or until a successor is
> > appointed; and be it further
> >
> > RESOLVED, that the Apache StreamPipes Project be and hereby is tasked
> > with the migration and rationalization of the Apache Incubator
> > StreamPipes podling; and be it further
> >
> > RESOLVED, that all responsibilities pertaining to the Apache Incubator
> > StreamPipes podling encumbered upon the Apache Incubator PMC are
> > hereafter discharged.
> >
> > ---
> >
> > [0] https://lists.apache.org/thread/dg3z175h2szcg3wgz9tmq770krvscvp8
> >
> > [1] https://lists.apache.org/thread/18vgpw0jq93rwh9mj9bb27nj7gjhmldg
> >
> > [2] https://lists.apache.org/thread/q6n11kfmmj1vgo6vq19nq1km5p1vow28
> >
> > [3] https://lists.apache.org/thread/5ybqmx8z768ksdymz2h2gjsx91p1drpp
> >
> > [4] https://www.linux-magazine.com/Issues/2021/244/Apache-StreamPipes
> >
> > [5]
> > https://www.opensourceforu.com/2020/12/top-5-open-source-tools-for-iot-analytics/
> >
> > [6] 

Re: Apache license in source files (pekko)

[Roman Shaposhnik]

On Tue, Oct 25, 2022 at 8:39 AM Justin Mclean  wrote:
>
> Hi,
>
> I would perhaps change the headers to be the 3rd party ASF header with the 
> copyright line to make it clear each file is under the Apache license.

What Justin said ;-)

Thanks,
Roman.

P.S. Of course, all the new files we start creating should have a
standard ASF header.

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

Re: [VOTE] Accept Pekko into the Apache Incubator

[Roman Shaposhnik]

own a specific interest in keeping this project open
> source and we expect that future developers will join for the same reasons.
>
> *Relationships with Other Apache Products:*
>
> As noted above Akka is used by Apache Flink though Flink is planning to
> migrate away. We anticipate that they will transition to Pekko when it
> becomes available. We expect that other projects may find the library of
> use.
>
> *An Excessive Fascination with the Apache Brand:*
>
> We understand the need to protect the Apache brand. We also understand that
> the Apache brand brings a licensing guarantee. While we are desirous of the
> licensing guarantee, we believe that the project we are bringing is viable
> and important. We think that it will provide support for at least two
> existing Apache projects and contribute to the strength of the Apache brand
> world wide.
>
> *Documentation*
>
> The current documentation can be found at https://akka.io/docs Other
> documentation is available as .md files within the source tree of the
> project.
>
> *Initial Source*
>
> The original source comes from the Lightbend Akka github repository before
> they transitioned to the Business Source License. The code base to be
> imported resides in several repositories under the control of Matthew
> Benedict de Detrich, the base one being
> https://github.com/mdedetrich/akka-apache-project
>
> *Source and Intellectual Property Submission Plan*
>
> Since Pekko is forked from an already existing Akka codebase there is a
> high chance that there may be existing IP/trademarks in the codebase that
> needs to be screened. The Akka name itself needs to be changed/removed
> entirely from the codebase.
>
> In addition there are already existing github triggers and other mechanisms
> that build and test the system. We will need to review the triggers to
> determine how to implement the same or similar functionality on the Apache
> infrastructure.
>
> Our high level plan is to:
>
>
>1. A lift and shift of the existing github core repository into the
>Apache repository.
>2. Modification of the build and test process to run on the Apache build
>infrastructure.
>3. Emphasis on the dev and user mailing lists for help requests and
>discussions.
>4. Development and modification of project documentation.
>5. Create a “release” 0.1.0.
>6. Verify release
>7. Functionality
>8. Documentation
>9. Meets Apache standards
>10. Continue using the above process to migrate additional libraries to
>the Apache libraries with each one being a release “0.x.0”
>11. Upon completion of the migration of all pertinent libraries release
>1.0.0
>12. This strategy gives us the opportunity of learning the Apache way
>and the Apache infrastructure with small modules before we move into the
>more complex systems, building up layer by layer until we have a complete
>first release.
>
>
> *External Dependencies:*
>
> The initial code was licensed under Apache Source License v2. As such we
> believe that it meets all the requirements for external dependencies.
> However, as part of the incubation process we will verify that all
> dependencies have appropriate licences. Any dependencies that do not meet
> the requirements will be removed and alternative libraries or code used
> instead.
>
> *Cryptography:*
>
> We believe that there is no cryptographic code in the code base. However,
> as part of the incubation process we will verify that this is true.
>
>
> *Required ResourcesMailing lists:*
>
> priv...@pekko.incubator.apache.org
> d...@pekko.incubator.apache.org
> us...@pekko.incubator.apache.org
> comm...@pekko.incubator.apache.org
> Subversion Directory:
> We do not intend to use subversion.
>
> *Git Repositories:*
>
> https://gitbox.apache.org/repos/asf/incubator-pekko.git
>
> *Issue Tracking:*
> JIRA Pekko (PEKKO)
>
> *Initial Committers*
> Matthew de Detrich mdedetr...@gmail.com (CLA submitted)
> Josep Prat jo...@prat.tech (CLA submitted)
> He Pin hepin1...@gmail.com (CLA submitted)
> Andrea Zito zito.and...@gmail.com
> Andrea Peruffo andrea.peruffo1...@gmail.com
> Alexandru Nedelcu m...@alexn.org
> Joe Brockmeier j...@apache.org
> Sean Glover s...@seanglover.com
> Greg Methvin g...@methvin.net (play framework)
> Nicolas Vollmar nicolas.voll...@altoo.io
> PJ Fanning fannin...@yahoo.com
> Daniel Schröter d...@theone.ch
> Michael Kohout mwkoh...@gmail.com
> jxnu-liguobin dreamyl...@outlook.com
> Salar Rahmanian sa...@softinio.com
> Jonas Chapuis m...@jonaschapuis.com
> Andreas Gabor acc_apa...@beezle.de
> Johannes Rudolph johannes.rudo...@gmail.com
>
> There has been a lot of interest in being an initial committer, and we've
> tried to pick a fair representation of interested developers from the
> requests. We want to be clear that we welcome all contributions and expect
> that the incubation period is the right time for this list to grow and
> evolve.
>
> *Sponsors*
> No company has committed to providing dedicated developers for the project
> but Aiven and Altoo have committed to supporting development as needed by
> their respective organisations.
>
> *Champion*:
> Claude Warren cla...@apache.org
>
> *Nominated Mentors:*
> Claude Warren cla...@apache.org
> Justin McLean jmcl...@apache.org
> Ryan Skraba rskr...@apache.org
> PJ Fanning fannin...@yahoo.com
> Roman Shaposhnik r...@apache.org
> Wu Sheng wush...@apache.org
> JB Onofré jbono...@apache.org
>
> *Sponsoring Entity:*
> The Incubator

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

Re: [DISCUSS] Incubating Proposal for Celeborn (was: [DISCUSS] Incubating Proposal for Datark)

[Roman Shaposhnik]

At the risk of drawing the ire of the top-post police -- I have to top-post ;-)

Kudos on a really cool name!

Thanks,
Roman.

On Fri, Sep 30, 2022 at 6:10 PM keyong zhou  wrote:
>
> Hi Yu,
>
>  Yeah the name is from 《The Silmarillion》 and Celeborn is a seedling of the
> tree Galathilion, which in turn had been made in image of Telperion[1].
>
>  We're glad that you like it :)
>
> Thanks.
>
> Best Regards,
> Keyong
>
> [1] https://tolkiengateway.net/wiki/Celeborn_(White_Tree)
>
> Yu Xiao  于2022年9月30日周五 18:13写道：
>
> > Hi，
> >
> >  Very happy to see the name ,
> >
> >  BTW, It refers to Telperion（silver tree）in Two Trees of Valinor?
> >
> > 《The Silmarillion》is my favorite stories. And now the TV of 《The Rings
> > of Power》in theaters.
> >
> >   The name is really great,
> >
> >  I think it's cool to introduce this fantasy tree to the Apache world.
> >
> >   > Celeborn is the name of the White Tree in J. R. R. Tolkien's fantasy
> >  stories. "Celeb" is the sindarin for "silver"
> >
> > Best wishes!
> >
> > Yu Xiao
> > Apache ShenYu
> >
> > Yu Li  于2022年9月30日周五 17:39写道：
> > >
> > > Hi All,
> > >
> > > After more careful searching and legal consultation, we found the name
> > > "Datark" may have some trademark conflicts and (after some community
> > > discussion) decided to rename the project to "Celeborn", and have updated
> > > the proposal document accordingly [1].
> > >
> > > Celeborn is the name of the White Tree in J. R. R. Tolkien's fantasy
> > > stories. "Celeb" is the sindarin for "silver", while "orn" is that for
> > > "tree", and we think it's cool to introduce this fantasy tree to the
> > Apache
> > > world. Hopefully people also like this new name.
> > >
> > > And we'd like to continue the discussion and look forward to more
> > feedback
> > > (and thanks for the existing ones).
> > >
> > > Thanks.
> > >
> > > Best Regards,
> > > Yu
> > >
> > > [1]
> > https://cwiki.apache.org/confluence/display/INCUBATOR/CelebornProposal
> > >
> > > On Tue, 27 Sept 2022 at 17:07, Kaijie Chen  wrote:
> > >
> > > > Hi Yu,
> > > >
> > > > Thanks for your explanation. Yes it makes sense.
> > > > It's nice we can see the migration process in the community.
> > > > And it will probably help create better docs for the project.
> > > >
> > > > Best,
> > > > Kaijie
> > > >
> > > > On 2022/09/27 06:05:10 Yu Li wrote:
> > > > > Hi BLAST and Kaijie,
> > > > >
> > > > > Yes, we've done quite some work on merging the two rss projects (or
> > more
> > > > > accurately, try to extract the high-level architecture and
> > interfaces to
> > > > > form a more general framework) but still not fully completed.
> > However, on
> > > > > second thought, we feel incubating the project first and involving
> > more
> > > > > community forces to discuss and complete the work together might be a
> > > > > better idea. I believe more information on this topic will be shared
> > in
> > > > the
> > > > > community, and further discussion and the incubation process won't
> > block
> > > > > each other. Wdyt?
> > > > >
> > > > > @Gon
> > > > > Apache Nemo is an interesting project and we will further
> > investigate and
> > > > > search for the cooperation between the two projects (smile).
> > > > >
> > > > > Best Regards,
> > > > > Yu
> > > > >
> > > > >
> > > > > On Tue, 27 Sept 2022 at 10:45, Kaijie Chen  wrote:
> > > > >
> > > > > > Hi Yu,
> > > > > >
> > > > > > You mentioned you will merge RemoteShuffleService and
> > > > flink-remote-shuffle
> > > > > > previously in this thread:
> > > > > >
> > > > > > https://lists.apache.org/thread/1w74z5f0pb7bhslhzcl5x7rdj9s9objz
> > > > > >
> > > > > > > Our proposal is still not fully prepared because the merge of
> > the two
> > > > > > projects
> > > > > > > is still in progress
> > > > > >
> > > > > > Have you done the merge? Or is there a plan to merge them later?
> > > > > > I just checked the github repositories, seems there is no mention
> > of
> > > > the
> > > > > > merge
> > > > > > and both project are still being actively developed.
> > > > > >
> > > > > > Best,
> > > > > > Kaijie
> > > > > >
> > > > > >
> > -
> > > > > > 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 

Re: possible interest in forming a community fork of akka

[Roman Shaposhnik]

Hi PJ! Thanks for moving the discussion to this list! For
completeness' sake -- let me repeat the comments I made on the legal
one:

On Mon, Sep 26, 2022 at 9:12 PM PJ Fanning  wrote:
>
> Hi everyone,
>
> Apologies if this is not the right mailing list. If it is not, please
> let me know and I'll switch the thread to the right list.
>
> Lighbend [1], the company that maintains the popular open source
> framework, Akka [2], recently announced they are moving Akka to a
> non-OSS commercial license [3].
>
> There is interest in the OSS community in forking Akka under a new
> name and maintaining it as an ASF project [4].
>
> It is early days yet but there is some discussion online [5].

I would absolutely agree that there's clearly a need for a community
supported, neutrally governed version of Akka under the Apache License.
The real question is how can we make sure we've exhausted all the options
to work with the original maintainers to achieve that goal.

As you probably know, ASF doesn't look kindly on "hostile forks", but the
key word in that phrase is *hostile*. So let's try to avoid that (if we can).

So my question to you and everyone else on this list is: do you think we
can somehow steer the disussion (on the GitHub) to gauge the level of
interest of Lightbend (or individuals employed by it) to actually work *with*
ASF to try and see whether a win-win here is possible?

> Reading the incubator cookbook, a new podling would need to have
> champions and mentors from within the Incubator PMC [6].
>
> I would like to put my name forward for such a role, as an existing
> ASF member [7].

Same here! (*)

> If anyone else in the Incubator PMC would like to get involved, that
> would be great.

Count me in. I'd like to be involved all the way in this effort (regardless
of whether we build some win-win combo with existing Lightbend folks
or decide to do it with a new community).

Thanks,
Roman.

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

Rebooting Ambari PMC via board resolution

[Roman Shaposhnik]

Hi!

after a few discussion with interested community members it
now seems that a board resolution for rebooting Apache Ambari
PMC may be the quickest and most convenient option. Since
the initial PMC are all (more or less) ex-Ambari folks AND
they all happen to be ASF members -- I don't see any issue
with it. Unless there are any major objections here's what I'm
going to submit.


 A. Establish the Apache Ambari Project

   WHEREAS, the Board of Directors deems it to be in the best
   interests of the Foundation and consistent with the
   Foundation's purpose to establish a Project Management
   Committee charged with the creation and maintenance of
   open-source software, for distribution at no charge to
   the public, related to Hadoop cluster management.

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

   RESOLVED, that the Apache Ambari Project be and hereby is
   responsible for the creation and maintenance of software
   related to Hadoop cluster management;
   and be it further

   RESOLVED, that the office of "Vice President, Apache Ambari" be
   and hereby is created, the person holding such office to
   serve at the direction of the Board of Directors as the chair
   of the Apache Ambari Project, and to have primary responsibility
   for management of the projects within the scope of
   responsibility of the Apache Ambari Project; and be it further

   RESOLVED, that the persons listed immediately below be and
   hereby are appointed to serve as the initial members of the
   Apache Ambari Project:
 Atri Sharma (atri)
 Devaraj Das (ddas)
 Evans Ye (evansye)
 Uma Maheswara Rao G (umamahesh)
 Roman Shaposhnik (rvs)

   NOW, THEREFORE, BE IT FURTHER RESOLVED, that Roman Shaposhnik
   be appointed to the office of Vice President, Apache Ambari, to
   serve in accordance with and subject to the direction of the
   Board of Directors and the Bylaws of the Foundation until
   death, resignation, retirement, removal or disqualification,
   or until a successor is appointed; and be it further

   RESOLVED, that the Apache Ambari Project be and hereby
   is tasked with the migration and rationalization of the Apache
   Ambari from the Apache Attic; and be it further

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

Thanks,
Roman.

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

Re: Any incubation proposal template for projects which leaving the attic.

[Roman Shaposhnik]

On Sat, Jun 4, 2022 at 12:04 PM Justin Mclean  wrote:
>
> HI,
>
> Depending on who is involved in the project, it may not even require to go 
> through the incubator again. Having more details would help with this.

What Justin said!

Honestly, I think if we can find 3 ative ASF members to be on the PMC
(which seems to be the case -- myself very much interested!) we can
just bring it back and bootstrap the rest of the community
organically.

Thanks,
Roman.

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

Re: BlockID champion

[Roman Shaposhnik]

On Tue, May 25, 2021 at 5:39 PM Matthew Sacks 
wrote:

> Would anyone champion BlockID once a formal specification is submitted
> here?


URL, plz?

Thanks,
Roman.

Re: Re: [VOTE] Distribution guidelines for platforms

[Roman Shaposhnik]

With my IPMC hat on (and explicitly NOT with my ASF VP Legal one on) +1

Btw I'd suggest replacing "This would expose our users and the ASF to
the risk of lawsuit." with "This would expose our users and the ASF to
the risk of legal actions." -- the rationale here being that C maybe
as annoying and damaging as a legal suit.

Thanks,
Roman.

On Mon, Sep 21, 2020 at 8:18 AM Liu Ted  wrote:
>
> +1 (binding).
> Ted Liu
>
>
>在 2020 年 9月 月 21 日週一，時間：20:38 ， Kevin Ratnasekera 
>  寫道：   +1 ( binding )
>
> On Mon, Sep 21, 2020 at 6:06 PM Furkan KAMACI 
> wrote:
>
> > Hi,
> >
> > +1 (binding)
> >
> > Kind Regards,
> > Furkan KAMACI
> >
> > On Mon, Sep 21, 2020 at 4:50 AM Paul King  wrote:
> >
> > > +1
> > >
> > > On Mon, Jul 6, 2020 at 11:23 AM Justin Mclean 
> > > wrote:
> > >
> > > > Hi,
> > > >
> > > > This vote is to make this official [1] and move the guidelines to the
> > > > website. The guidelines will be placed under the podling guides menu
> > and
> > > > linked to from the release section in the Incubator policy page [2]
> > > >
> > > > The last sentence in that section will be changed to say this (where
> > > > "here" links to the web version of the guidelines):
> > > >
> > > > "Also, the Podling MAY choose to distribute approved releases through
> > > > other channels by following the guidelines here."
> > > >
> > > > This vote will be open for 72 hours or as long as is needed and IPMC
> > > votes
> > > > are binding.
> > > >
> > > > Please vote:
> > > > +1 [ ] Let's make this official
> > > > +0 [ ] Not sure this is needed
> > > > -1 [ ] No way because...
> > > >
> > > > Thanks,
> > > > Justin
> > > >
> > > > 1.
> > > >
> > >
> > https://cwiki.apache.org/confluence/display/INCUBATOR/Distribution+Guidelines
> > > > 2. https://incubator.apache.org/policy/incubation.html#releases
> > > >
> > > >
> > > > -
> > > > 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] Distribution guidelines for platforms

[Roman Shaposhnik]

On Tue, Jul 14, 2020 at 4:23 PM Justin Mclean  wrote:
>
> Hi,
>
> So technically this votes passes with 2 +1 votes and a single -1 vote. A -1 
> vote on procedural matters is not a veto [1], but given the small number of 
> votes I’m hesitant to post a result. Does anyone else want to vote?

I suggest let it simmer for a little while (personally I need a day or
two to catch up with all the threads).

Thanks,
Roman.

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

Re: [VOTE] Accept NLPCraft into Apache Incubator

[Roman Shaposhnik]

On Sun, Feb 9, 2020 at 1:54 PM Konstantin Boudnik  wrote:
>
> Hello.
>
> As the discussion of NLPCraft proposal [1] has been wrapped up [2] I would 
> like
> to call a VOTE to accept this project into the Apache Incubator.
>
> Please cast your vote:
>
>   [ ] +1, bring NLPCraft into Incubator
>   [ ] +0, I don't care either way
>   [ ] -1, do not bring NLPCraft into Incubator, because...

+1 (binding)

Thanks,
Roman.

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

Re: [VOTE] Apache Hudi (incubating) 0.5.1 RC1

[Roman Shaposhnik]

+1 (binding)

Thanks,
Roman.

On Wed, Jan 29, 2020 at 7:11 AM Luciano Resende  wrote:
>
> +1 (binding)
>
> On Sat, Jan 25, 2020 at 6:27 PM leesf  wrote:
> >
> > Dear IPMC,
> >
> > Apache Hudi (incubating) (pronounced Hoodie) stands for Hadoop Upserts anD
> > Incrementals. Apache Hudi (incubating) manages storage of large analytical
> > datasets on DFS (Cloud stores, HDFS or any Hadoop FileSystem compatible
> > storage) and provide ability to query them.
> >
> > The Apache Hudi (incubating) community has voted on the release candidate
> > and approved. The new source release candidate version is
> > 0.5.1-incubating-rc1
> >
> > Results: 3 binding +1 votes
> >
> > Here is the voting thread:
> > https://lists.apache.org/thread.html/r8af8fb482991c6f8ab1c54069bab129fc76f97f3a2244bc809d9b914%40%3Cdev.hudi.apache.org%3E
> >
> >
> > Here is the voting result email:
> > https://lists.apache.org/thread.html/r75c603201701b5cd6697ddb6b69bf4d940c089a1e61ddfa8e68e07b1%40%3Cdev.hudi.apache.org%3E
> >
> >
> > The Apache Hudi community had verified the following aspects of release:
> > - verified checksums and signatures [SUCCESS]
> > - license header check [SUCCESS]
> > - No binaries in source release [SUCCESS]
> > - verified RAT check [SUCCESS]
> > - built from source release (mvn clean install -DskipTests) [SUCCESS]
> > - mvn test from source release [SUCCESS]
> >
> > I'd like to call a vote in general to approve the release of Apache Hudi
> > (incubating). Please review and vote on the release candidate #1 for the
> > version 0.5.1, as follows:
> > [ ] +1,  Approve the release
> > [ ]  0,  I don't feel strongly about it, but I'm okay with the release
> > [ ] -1,  Do not approve the release (please provide specific comments)
> >
> >
> > The complete staging area is available for your review, which includes:
> >
> >   - JIRA release notes [1]
> >   - The official Apache source release and binary convenience releases to
> > be deployed to dist.apache.org [2], which are signed with the key with
> > fingerprint 623E08E06DB376684FB9599A3F5953147903948A   [3],
> >   - all artifacts to be deployed to the Maven Central Repository [4]
> >   - source code tag "release-0.5.1-incubating-rc1" [5]
> >
> > [1]
> > https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12322822=12346183
> > [2]
> > https://dist.apache.org/repos/dist/dev/incubator/hudi/hudi-0.5.1-incubating-rc1/
> > [3] https://dist.apache.org/repos/dist/dev/incubator/hudi//KEYS
> > [4] https://repository.apache.org/content/repositories/orgapachehudi-1014
> > [5]
> > https://github.com/apache/incubator-hudi/tree/release-0.5.1-incubating-rc1
> >
> > A release validation script is available in master for running usual
> > checks. To run this
> >
> >   - git clone g...@github.com:apache/incubator-hudi.git
> >   - cd incubator-hudi/scripts
> >   - ./release/validate_staged_release.sh --release=0.5.1 --rc_num=1
> >
> > The vote will be open for at least 72 hours. Please cast your votes before
> > *Jan. 29th 2020, 23:59 UTC*(End on Wednesday). The vote will pass if a
> > majority of at least three +1 IPMC votes are cast.
> >
> > Thanks,
> > Leesf
>
>
>
> --
> Luciano Resende
> http://twitter.com/lresende1975
> http://lresende.blogspot.com/
>
> -
> To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
> For additional commands, e-mail: general-h...@incubator.apache.org
>

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

Present your project at Podling's Shark Tank in Berlin

[Roman Shaposhnik]

Hi!

if you happen to be at ApacheCON in Berlin and would
like to promote your project -- you've got a perfect opportunity

We have one slot open at  Podling's Shark Tank on
 Wednesday, 23 October, 17:20 - 18:10
You can find more details on what Podling's Shark Tank is
on this wikipage:
 
https://cwiki.apache.org/confluence/display/APACHECON/ACEU19PodlingSharkTank

First come -- first serve -- we only have one slot left!

Thanks,
Roman.

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

Podling's Shark Tank at ApacheCON Las Vegas

[Roman Shaposhnik]

Hi!

just wanted to let you all know that we're all set
to go ahead with this year's Podling's Shark Tank
at ApacheCON Las Vegas. We've got 5 amazing
podlings presenting and this is going to be a LOT
of fun:
https://cwiki.apache.org/confluence/display/APACHECON/ACNA19PodlingSharkTank

Please consider promoting it within your communities.

Even if you don't present -- Podling's Shark Tank
is typically jam-packed with useful nuggets of
information on how to grow your community within
the incubator.

Thanks,
Roman.

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

Podling's Shark Tank update

[Roman Shaposhnik]

Hi!

with 10 days until ApacheCON in Vegas I wanted
to share an update on Podling's Shark Tank:
 
https://cwiki.apache.org/confluence/display/APACHECON/ACNA19PodlingSharkTank

Feel free to ask any questions. Also, it would be
great if you could help promote this via social
media, etc.

See you in Vegas soon!

Thanks,
Roman.

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

Re: Showcase your project at ApacheCON at a Podling's Shark Tank

[Roman Shaposhnik]

On Thu, Aug 15, 2019 at 8:06 AM Supun Kamburugamuve  wrote:
>
> We are thinking about proposing a project to the incubator. Would this be
> open to such a project?

Given that we're already oversubscribed -- we can only allow existing
podlings at this point.

Thanks,
Roman.

>
> Best,
> Supun..
>
> On Thu, Aug 15, 2019 at 10:05 AM Antoine Toulme  wrote:
>
> > Hello Roman,
> >
> > The Tuweni podling is interested. I am attending ApacheCon EU and would
> > like a chance to present.
> >
> > Cheers,
> >
> > Antoine
> >
> > > On Aug 14, 2019, at 1:45 PM, Roman Shaposhnik  wrote:
> > >
> > > Hi Podlings!
> > >
> > > in less than a month we're going to have our first
> > > ApacheCON this year -- the one in Las Vegas. In
> > > about two month there will be one more in Berlin.
> > >
> > > These are not your regular ApacheCONs -- these are
> > > 20th Anniversary of ASF ApacehCONs! In other words,
> > > these are not to be missed!
> > >
> > > And even if your talk didn't get accepted -- you still
> > > get an opportunity to highlight your project to, what's
> > > likely going to be the biggest audience attending.
> > >
> > > Here's how: if you (or any community member who's
> > > passionate about your project) are going to be at either
> > > of those ApacheCONs consider signing up for
> > >Podling's Shark Tank
> > > events:
> > >https://www.apachecon.com/acna19/s/#/scheduledEvent/1038
> > >https://aceu19.apachecon.com/session/podlings-shark-tank
> > >
> > > Each project presenting will get ~10 min for the pitch and ~5 min
> > > of panel grilling them on all sorts of things. Kind of like this ;-)
> > > https://www.youtube.com/watch?v=wmenN7NEdBc
> > >
> > > You've got nothing to lose (in fact, the opposite: you're likely to get
> > > a prize!) and you will get a chance to receive feedback that might
> > > actually help you grow your community and ultimately graduate to the
> > > TLP status. And! Given our awesome panel of judges:
> > > * Myrle Krantz
> > > * Justin Mclean
> > > * Craig Russel
> > > * Shane Curcuru
> > > We guarantee this to be a fun and useful event for your community!
> > >
> > > We will be tracking signups over here:
> > > https://wiki.apache.org/apachecon/ACNA19PodlingSharkTank
> > > https://wiki.apache.org/apachecon/ACEU19PodlingSharkTank
> > > but for now:
> > >
> > > SIMPLY REPLY TO THIS EMAIL if you're interested.
> > >
> > > It is first come, first serve -- so don't delay -- sign up today!
> > >
> > > Thanks,
> > > Roman.
> > >
> > > -
> > > To unsubscribe, e-mail: dev-unsubscr...@tuweni.apache.org
> > > For additional commands, e-mail: dev-h...@tuweni.apache.org
> > >
> >
> >
> > -
> > To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
> > For additional commands, e-mail: general-h...@incubator.apache.org
> >
> >
>
> --
> Supun Kamburugamuve, PhD
> Digital Science Center, Indiana University
> Member, Apache Software Foundation; http://www.apache.org
> E-mail: supun@apache.o rg;  Mobile: +1 812 219 2563

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

Re: Showcase your project at ApacheCON at a Podling's Shark Tank

[Roman Shaposhnik]

Hi All!

thanks a million for this tremendous interest in Podling's Shark Tank.

We now have:

ApacheCON NA in Las Vegas:
Daffodil
ShardingSphere
Heron
DLab
IoTDB
Daffodil
Ratis
DataSketches

ApacheCON EU in Berlin:
 MorphL
 ShardingSphere
 DLab
 IoTDB
 Tuweni

We now have full schedule of podlings for both events and I will
be following up with individuals (and individual communities) who
volunteered for both.

Thanks,
Roman.

On Wed, Aug 14, 2019 at 1:45 PM Roman Shaposhnik  wrote:
>
> Hi Podlings!
>
> in less than a month we're going to have our first
> ApacheCON this year -- the one in Las Vegas. In
> about two month there will be one more in Berlin.
>
> These are not your regular ApacheCONs -- these are
> 20th Anniversary of ASF ApacehCONs! In other words,
> these are not to be missed!
>
> And even if your talk didn't get accepted -- you still
> get an opportunity to highlight your project to, what's
> likely going to be the biggest audience attending.
>
> Here's how: if you (or any community member who's
> passionate about your project) are going to be at either
> of those ApacheCONs consider signing up for
> Podling's Shark Tank
> events:
> https://www.apachecon.com/acna19/s/#/scheduledEvent/1038
> https://aceu19.apachecon.com/session/podlings-shark-tank
>
> Each project presenting will get ~10 min for the pitch and ~5 min
> of panel grilling them on all sorts of things. Kind of like this ;-)
>  https://www.youtube.com/watch?v=wmenN7NEdBc
>
> You've got nothing to lose (in fact, the opposite: you're likely to get
> a prize!) and you will get a chance to receive feedback that might
> actually help you grow your community and ultimately graduate to the
> TLP status. And! Given our awesome panel of judges:
>  * Myrle Krantz
>  * Justin Mclean
>  * Craig Russel
>  * Shane Curcuru
> We guarantee this to be a fun and useful event for your community!
>
> We will be tracking signups over here:
>  https://wiki.apache.org/apachecon/ACNA19PodlingSharkTank
>  https://wiki.apache.org/apachecon/ACEU19PodlingSharkTank
> but for now:
>
> SIMPLY REPLY TO THIS EMAIL if you're interested.

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

Showcase your project at ApacheCON at a Podling's Shark Tank

[Roman Shaposhnik]

Hi Podlings!

in less than a month we're going to have our first
ApacheCON this year -- the one in Las Vegas. In
about two month there will be one more in Berlin.

These are not your regular ApacheCONs -- these are
20th Anniversary of ASF ApacehCONs! In other words,
these are not to be missed!

And even if your talk didn't get accepted -- you still
get an opportunity to highlight your project to, what's
likely going to be the biggest audience attending.

Here's how: if you (or any community member who's
passionate about your project) are going to be at either
of those ApacheCONs consider signing up for
Podling's Shark Tank
events:
https://www.apachecon.com/acna19/s/#/scheduledEvent/1038
https://aceu19.apachecon.com/session/podlings-shark-tank

Each project presenting will get ~10 min for the pitch and ~5 min
of panel grilling them on all sorts of things. Kind of like this ;-)
 https://www.youtube.com/watch?v=wmenN7NEdBc

You've got nothing to lose (in fact, the opposite: you're likely to get
a prize!) and you will get a chance to receive feedback that might
actually help you grow your community and ultimately graduate to the
TLP status. And! Given our awesome panel of judges:
 * Myrle Krantz
 * Justin Mclean
 * Craig Russel
 * Shane Curcuru
We guarantee this to be a fun and useful event for your community!

We will be tracking signups over here:
 https://wiki.apache.org/apachecon/ACNA19PodlingSharkTank
 https://wiki.apache.org/apachecon/ACEU19PodlingSharkTank
but for now:

SIMPLY REPLY TO THIS EMAIL if you're interested.

It is first come, first serve -- so don't delay -- sign up today!

Thanks,
Roman.

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

Re: New disclaimer text

[Roman Shaposhnik]

Big +1!

On Fri, Jul 12, 2019 at 4:08 PM Matt Sicker  wrote:
>
> Agreed, this sounds like a great way to do this. As IPMC members reviewing
> releases, you now have better guidelines on how to go about reviewing a
> podling release.
>
> On Fri, Jul 12, 2019 at 17:59, Jim Jagielski  wrote:
>
> > This is a great idea... +1
> >
> > > On Jul 12, 2019, at 6:31 PM, Craig Russell  wrote:
> > >
> > > Hi,
> > >
> > > I understand I'm a bit late to this particular discussion, but perhaps
> > we can consider two different disclaimers that podlings can choose:
> > >
> > > The standard disclaimer that does not disclaim licensing issues; or,
> > >
> > > The proposed new disclaimer to be used by podlings' first releases until
> > they sort their licensing issues
> > >
> > > This "split roll" allows "mature" podlings the ability to assuage their
> > downstream that they have their licensing issues in hand.
> > >
> > > Use of the current disclaimer means that any licensing issues found
> > during release voting would cancel the release and require a respin.
> > >
> > > Use of the proposed new disclaimer would allow new-ish podlings to get
> > on with releasing while they sort any licensing issues.
> > >
> > > And we can add to the Maturity Model a section that discusses that the
> > podling has had at least one release with the standard disclaimer.
> > >
> > > Regards,
> > >
> > > Craig
> > >
> > >> On Jul 10, 2019, at 2:44 PM, Justin Mclean 
> > wrote:
> > >>
> > >> Hi,
> > >>
> > >>> Speaking as a member of a currently-incubating project (Apache Druid)
> > where
> > >>> we have always strived to do releases with no known licensing issues,
> > the
> > >>> text sounds needlessly scary to downstream consumers.
> > >>
> > >> And that may be the problem with a one solution fits all process. It
> > has been suggested before we let podlings choose which release process they
> > want.  However that may get too complex and make voting on releases
> > inconsistent.
> > >>
> > >>> IMO this disclaims too much, and would chill adoption of incubating
> > >>> software by people that care about having clean licensing. PPMCs
> > should be
> > >>> able to say "we believe this release is clean and have vetted it using
> > a
> > >>> normal Apache vetting process" or maybe even "we have vetted this
> > release
> > >>> and it is clean other than the following list of known issues". If they
> > >>> can't say one of those two statements, then maybe it's not time to do
> > their
> > >>> first release yet.
> > >>
> > >> The idea is to allow podlings to make releases that may not comply with
> > policy. Have a hard switch from your releases doesn’t comply to everything
> > must comply is too difficult for some podlings.
> > >>
> > >>> And yeah, as a few others have mentioned, I believe that a more
> > streamlined
> > >>> voting process
> > >>
> > >> That I think is a different issue, ands may be best to start another
> > thread on that. The main issue here is that IPMC members votes are binding,
> > and not all mentors (who are IPMC members) vote on releases, so podlings
> > need votes from the wider IPMC members to make releases (in about 90%+ of
> > cases). There been a few ideas on how to improve this, including one
> > approved method (but no podlings have take that up yet).
> > >>
> > >> Thanks,
> > >> Justin
> > >> -
> > >> To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
> > >> For additional commands, e-mail: general-h...@incubator.apache.org
> > >>
> > >
> > > Craig L Russell
> > > c...@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
> >
> > --
> Matt Sicker 

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

Re: New disclaimer text

[Roman Shaposhnik]

On Wed, Jul 3, 2019 at 2:52 PM Greg Stein  wrote:
>
> On Wed, Jul 3, 2019 at 4:35 PM Alex Harui  wrote:
>
> > Suggestion:  The DISCLAIMER references a detached copy of the DISCLAIMER
> > at dist.a.o/releases/incubator/project and that detached copy is the one
> > that gets updated with late breaking stuff.
> >
> > Re-rolling required re-GPG-signing, new hashes, etc.
> >
>
> Which is made worse by the two-step/vote process of podling then IPMC.

Perhaps that should be addressed first?

Thanks,
Roman.

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

Re: Podlings, the Incubator, relationships and Apache

[Roman Shaposhnik]

On Wed, Jul 3, 2019 at 2:13 PM Jim Jagielski  wrote:
>
>
>
> > On Jul 3, 2019, at 5:06 PM, Roman Shaposhnik  wrote:
> >
> >>
> >>  1.  Podlings, and PPMC members, to enjoy the legal protection of the 
> >> foundation when they do a release
> >
> > Let's be pedantic and define those in this particular case, shall we?
> > What exactly are the expectations for PPMC members?
>
> Do you mean what does the ASF expect from PPMC members (ie: "What will the 
> PPMC members do for the ASF")? Or do you mean what do PPMC members expect by 
> the ASF ("What will the ASF do for PPMC members")?

No. The other way around. What are the expectation of protections that
a legal shield is offering to PPMC *today*.

IOW, what do folks expect ASF to provide.

Thanks,
Roman.

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

Re: Podlings, the Incubator, relationships and Apache

[Roman Shaposhnik]

On Wed, Jul 3, 2019 at 1:59 PM Jim Jagielski  wrote:
> > On Jul 3, 2019, at 2:37 PM, Roman Shaposhnik  wrote:
> >
> >
> > This is correct. Provided we *do* explicitly acknowledge that special
> > status of the Incubator.
> >
> > This acknowledgement will basically put podling source code releases
> > at the same level we have convenience binary releases. Which is: they
> > are NOT acts of the foundation.
> >
>
> IMO, we want 2 things:
>
>   1.  Podlings, and PPMC members, to enjoy the legal protection of the 
> foundation when they do a release

Let's be pedantic and define those in this particular case, shall we?
What exactly are the expectations for PPMC members?

>   2. The outside world, and esp downstream end-users, to know that podling 
> releases should be expected to not be fully compliant with the normal 
> expectations associated w/ PMC releases.
>
> #1 requires them to be acts of the foundation; #2 requires easily visible and 
> discoverable disclaimers.
>
> Anything else just seems excessive and somewhat unwarranted, I think. Let's 
> make it as easy as possible, and as painless as possible, for podlings to 
> learn; Heck, at the start of The Apache Group and the ASF, we didn't do 
> everything right; we tried some things and some failed. It's in the nature of 
> education and mentoring. Making mistakes is not a problem; not learning from 
> them is.
>
> After we resolve this, I *really* would like to switch the convo around to a 
> discussion as deep, and as involved, but related to the other (IMO, more 
> important) side of the Incubator coin: education in the Apache Way. So much 
> derives from that... even the legal considerations of releases ultimately can 
> be found there, IMO. And I still maintain that we do a Not-So-Good job here.

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

Re: New disclaimer text

[Roman Shaposhnik]

On Wed, Jul 3, 2019 at 12:29 PM Dave Fisher  wrote:
>
>
>
> > On Jul 3, 2019, at 12:24 PM, Roman Shaposhnik  wrote:
> >
> > On Wed, Jul 3, 2019 at 12:17 PM Dave Fisher  wrote:
> >>> On Jul 3, 2019, at 11:50 AM, Roman Shaposhnik  
> >>> wrote:
> >>>
> >>> On Tue, Jul 2, 2019 at 10:28 AM Dave Fisher  wrote:
> >>>>
> >>>> Hi -
> >>>>
> >>>>> On Jul 1, 2019, at 1:30 AM, Bertrand Delacretaz 
> >>>>>  wrote:
> >>>>>
> >>>>> Hi,
> >>>>>
> >>>>> On Sun, Jun 30, 2019 at 1:39 AM Justin Mclean 
> >>>>>  wrote:
> >>>>>> ...I put up suggested text changes for an incubator disclaimer here 
> >>>>>> [1]...
> >>>>>
> >>>>> Basically just adding this, right?
> >>>>>
> >>>>>> Some of the project releases may not follow ASF policy or have
> >>>>>> incomplete or unknown licensing conditions
> >>>>>
> >>>>> It works for me but I'd say "incubating project" to be clearer.
> >>>>
> >>>> How is this?
> >>>>
> >>>> “Some of the incubating project’s releases may not be fully compliant 
> >>>> with ASF policy. For example, releases may have incomplete or unreviewed 
> >>>> licensing conditions. Known issues will be described on the project’s 
> >>>> status page."
> >>>
> >>> I would suggest we have a policy where known issues are actually
> >>> listed in the DISCLAIMER itself. Along the lines of:
> >>>
> >>> "Some of the incubating project’s releases may not be fully compliant
> >>> with ASF policy. For example, releases may have incomplete or
> >>> unreviewed licensing conditions. What follows is a list of known
> >>> issues the project is currently aware of (note that this list, by
> >>> definition, is likely to be incomplete):”
> >>
> >> -1.
> >>
> >> This only works for issues known before a release is cut. It does NOT WORK 
> >> if the issue is discovered during the release vote. Why? Because we are 
> >> trying to allow the release to go through without redoing it and this 
> >> would require reworking the release.
> >>
> >> I would rather do it outside of the release. Policing the actual 
> >> DISCLAIMER is not easily feasible and decreases the burden.
> >>
> >> If this is the decision then it leads to a choice that is worse than the 
> >> status quo.
> >
> > Nobody is suggesting the policing bit. What I'm suggesting is a
> > central place for that information to be collated. Whether that
> > becomes a showstopper for a release gets decided by the VOTE. But what
> > I'm saying is that we shouldn't be in a position where we have to hunt
> > for *known* and *acknowledged* issues all over the place (JIRA,
> > mailing lists, wiki, website, etc.). Lets at least make sure we make
> > our downstream consumer's life a bit easier.
>
> My suggestion is that we put these onto our neglected status pages. I’m also 
> willing to work on enhancing the status page and process to make this easy 
> for Podlings to do.

Sure, that's a reasonable place too, but the problem is -- it doesn't
help our downstream consumers.

What I'm trying to say is this, I'd like:
   1. this information to be available in one centralized location (per project)
   2. be easily discoverable by downstream consumers

If we all agree that #1 is desired (and sounds like we are). Then #2
can simply contain a link to #1 -- that'd be fine.

Makes sense?

Thanks,
Roman.

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

Re: New disclaimer text

[Roman Shaposhnik]

On Wed, Jul 3, 2019 at 12:17 PM Dave Fisher  wrote:
> > On Jul 3, 2019, at 11:50 AM, Roman Shaposhnik  wrote:
> >
> > On Tue, Jul 2, 2019 at 10:28 AM Dave Fisher  wrote:
> >>
> >> Hi -
> >>
> >>> On Jul 1, 2019, at 1:30 AM, Bertrand Delacretaz 
> >>>  wrote:
> >>>
> >>> Hi,
> >>>
> >>> On Sun, Jun 30, 2019 at 1:39 AM Justin Mclean  
> >>> wrote:
> >>>> ...I put up suggested text changes for an incubator disclaimer here 
> >>>> [1]...
> >>>
> >>> Basically just adding this, right?
> >>>
> >>>> Some of the project releases may not follow ASF policy or have
> >>>> incomplete or unknown licensing conditions
> >>>
> >>> It works for me but I'd say "incubating project" to be clearer.
> >>
> >> How is this?
> >>
> >> “Some of the incubating project’s releases may not be fully compliant with 
> >> ASF policy. For example, releases may have incomplete or unreviewed 
> >> licensing conditions. Known issues will be described on the project’s 
> >> status page."
> >
> > I would suggest we have a policy where known issues are actually
> > listed in the DISCLAIMER itself. Along the lines of:
> >
> > "Some of the incubating project’s releases may not be fully compliant
> > with ASF policy. For example, releases may have incomplete or
> > unreviewed licensing conditions. What follows is a list of known
> > issues the project is currently aware of (note that this list, by
> > definition, is likely to be incomplete):”
>
> -1.
>
> This only works for issues known before a release is cut. It does NOT WORK if 
> the issue is discovered during the release vote. Why? Because we are trying 
> to allow the release to go through without redoing it and this would require 
> reworking the release.
>
> I would rather do it outside of the release. Policing the actual DISCLAIMER 
> is not easily feasible and decreases the burden.
>
> If this is the decision then it leads to a choice that is worse than the 
> status quo.

Nobody is suggesting the policing bit. What I'm suggesting is a
central place for that information to be collated. Whether that
becomes a showstopper for a release gets decided by the VOTE. But what
I'm saying is that we shouldn't be in a position where we have to hunt
for *known* and *acknowledged* issues all over the place (JIRA,
mailing lists, wiki, website, etc.). Lets at least make sure we make
our downstream consumer's life a bit easier.

Thanks,
Roman.

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

Re: New disclaimer text

[Roman Shaposhnik]

On Tue, Jul 2, 2019 at 10:28 AM Dave Fisher  wrote:
>
> Hi -
>
> > On Jul 1, 2019, at 1:30 AM, Bertrand Delacretaz 
> >  wrote:
> >
> > Hi,
> >
> > On Sun, Jun 30, 2019 at 1:39 AM Justin Mclean  
> > wrote:
> >> ...I put up suggested text changes for an incubator disclaimer here [1]...
> >
> > Basically just adding this, right?
> >
> >> Some of the project releases may not follow ASF policy or have
> >> incomplete or unknown licensing conditions
> >
> > It works for me but I'd say "incubating project" to be clearer.
>
> How is this?
>
> “Some of the incubating project’s releases may not be fully compliant with 
> ASF policy. For example, releases may have incomplete or unreviewed licensing 
> conditions. Known issues will be described on the project’s status page."

I would suggest we have a policy where known issues are actually
listed in the DISCLAIMER itself. Along the lines of:

"Some of the incubating project’s releases may not be fully compliant
with ASF policy. For example, releases may have incomplete or
unreviewed licensing conditions. What follows is a list of known
issues the project is currently aware of (note that this list, by
definition, is likely to be incomplete):"

I would also suggest we add an explicit note warning our downstream consumers:

"If you are planning to incorporate this work into your
product/project, please be aware that you will need to conduct a
thorough licensing review to determine the overall implications of
including this work"

> >> ...It also been suggested than any known issues be listed in the 
> >> disclaimer...
> >
> > I don't think that works as modifying the disclaimer to list issues
> > will change the digests of the archive that's being voted on - and
> > those shouldn't change IMO.
> >
> > As Paul suggests in a different thread I'd go for easy to find tickets
> > to describe those changes. The disclaimer might point to
> > http://incubator.apache.org/release-issues which in turn points to
> > those tickets, keyed by release name and version number. Or something
> > like that - a permalink that points to the details.
>
> I would suggest that in a revamping of podling status pages that the podling 
> can list current issues with each release.
>
> The link to that page is easy: http://incubator.apache.org/projects/
>
> BTW - I’ve changed my thoughts on a Whimsical version of the status data and 
> am planning to put these in as AsciiDoc pages / YML into the Incubator’s Git.
>
> Regards,
> Dave
>
> >
> > -Bertrand
> >
> > -
> > 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: Podlings, the Incubator, relationships and Apache

[Roman Shaposhnik]

On Wed, Jul 3, 2019 at 4:48 AM Greg Stein  wrote:
> > > IMO, stop being pessimistic. Move forward with change to stop the gating,
> > > and let podlings do their releases without all the IPMC burden.
> >
> > We want to be at “D” or “E” , we’re currently at “A”  and there's a few
> > steps that need to be taken. I don’t believe the IPMC can just say “make it
> > so” and move from “A" to “E”. We also need consensus which I don’t believe
> > we have yet, so we might end up at “F” or “G”. Also if we make this
> > position “offical”, it will stop the same issue from reoccurring in the
> > future. It has occurred every few years since the incubator has existed as
> > far as I can tell. Well that’s the way I see it anyway, you and others may
> > see it differently.
> >
>
> I have zero confidence that you will move the pin here. You have shown zero
> willingness. I'd like to see a new VP Incubator.

And I would HATE to see a new VP Incubator (and I think a lot of podlings would
agree with that). As a former VP Incubator I just wanted to acknowledge that
Justin has probably done more than any other VP around here. He's pedantic
at times and not of the "move fast and break things" mentality (like Greg) but
he's the reason I'm still willing to be on the IPMC (I don't have any
active podling
to mentor).

Greg, you've been very helpful on this thread -- but this email ain't so.

Thanks,
Roman.

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

Re: Podlings, the Incubator, relationships and Apache

[Roman Shaposhnik]

On Tue, Jul 2, 2019 at 10:27 PM Greg Stein  wrote:
>
> On Wed, Jul 3, 2019 at 12:10 AM Justin Mclean 
> wrote:
> >...
>
> > Hi,
> >
> > > Although not a "real" PMC, we do need to provide legal protection for
> > each PPMC and distributing releases is the time that most legal
> > considerations "kick in" as it were. So we need a
>
>
> Or we *don't* provide legal protections. That *is* what the disclaimer is
> there for.

That's exactly the direction I personally would like this to go into.

> > Which while I don’t disagree with, again I ask how can a PMC (i.e the
> > incubator) make releases that are not in line with policy? Current advice
> > seems that the board would not grant a blanket exception like to the IPMC
>
>
> I don't recall that advice. In fact, Roman seemed to indicate Legal would
> be just fine with that.

This is correct. Provided we *do* explicitly acknowledge that special
status of the Incubator.

This acknowledgement will basically put podling source code releases
at the same level we have convenience binary releases. Which is: they
are NOT acts of the foundation.

> IMO, stop being pessimistic. Move forward with change to stop the gating,
> and let podlings do their releases without all the IPMC burden.
>
> >...
>
> > > Let's also recall that the origin genesis of the Incubator was NOT to
> > provide legal oversight
> >
> > That may be the original thought, but historical threads bring up legal
> > oversight very very early on. (I posted one from 2004 the other day).
> > Hopefully someone can explain this history?
> >
>
> Who cares? Red herring. We are where we are. Move forward from here.

+1000!

Thanks,
Roman.

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

Re: Podlings, the Incubator, relationships and Apache

[Roman Shaposhnik]

On Tue, Jun 25, 2019 at 8:07 PM Sam Ruby  wrote:
>
> On Mon, Jun 24, 2019 at 12:12 PM Roman Shaposhnik  
> wrote:
> >
> > On Sun, Jun 23, 2019 at 11:03 PM Alex Harui  
> > wrote:
> > >
> > > But, IMO, the reason the question went to VP Legal is that it doesn't 
> > > really matter what the IPMC thinks if their "business decision" will have 
> > > an impact on the "Legal Shield" and the insurance premiums that go with 
> > > it.  So I think the question got lost on legal-discuss.  The "space of 
> > > options" should probably be constrained by the "Legal Shield".
> >
> > Nope. That's not how any of the legal works. Legal never makes policy
> > -- legal always evaluates risk profiles of the policy that business
> > stakeholders make.
> >
> > In fact, and thin may come as a shock, legal never *blocks* anything.
> > Legal doesn't have veto power simply because the business decision
> > always trupms legal.
>
> Please interpret the following statement extremely narrowly: the Legal
> Affairs committee is a board committee.  Read section 5.9 of the ASF
> bylaws.
>
> I believe that the correct way to interpret this is that the Legal
> Committee (and therefore, VP, Legal) is empowered to make business
> decisions on behalf of the ASF.  This would include pulling a release
> or disbanding a committee.
>
> Now I'm not suggesting that you start vetoing anything.  I'm just
> saying that should you find yourself in a position where a veto is
> necessary, don't question whether or not you have that authority.

No disagreement there and good clarification.

Thanks,
Roman.

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

Re: Podlings, the Incubator, relationships and Apache

[Roman Shaposhnik]

On Sun, Jun 23, 2019 at 11:03 PM Alex Harui  wrote:
>
> But, IMO, the reason the question went to VP Legal is that it doesn't really 
> matter what the IPMC thinks if their "business decision" will have an impact 
> on the "Legal Shield" and the insurance premiums that go with it.  So I think 
> the question got lost on legal-discuss.  The "space of options" should 
> probably be constrained by the "Legal Shield".

Nope. That's not how any of the legal works. Legal never makes policy
-- legal always evaluates risk profiles of the policy that business
stakeholders make.

In fact, and thin may come as a shock, legal never *blocks* anything.
Legal doesn't have veto power simply because the business decision
always trupms legal.

You *may* get sued is a statement that is always true -- regardless of
what you do.

> What kinds of policy violations truly affect the legal shield if the 
> non-compliance:

You're asking the wrong question. You're still asking the TLP question.

> 1) is actually released
> 2) released but noted in RELEASE_NOTES or DISCLAIMER
> 3) released but not corrected in the next release
>
> Ted, Roy, Hen, seem to say that only "no rights to distribute" and "CatX" 
> should not be released by TLPs but "CatX" should be ok for podlings.  My 
> takeaway from Roman is that all policy non-compliance issues are release 
> breakers and Incubator should either be granted special status or not.  But 
> I'd like to see the first question be answered so we can understand how 
> special the Incubator status would have to be.  How different would it be 
> from TLP releases and what risks to the foundation would that pose and could 
> a DISCLAIMER or other means mitigate that risk?  Without knowing how the 
> Legal Shield works, it is hard to know what the options truly are.
>
> HTH,
> -Alex
>
> On 6/23/19, 10:43 PM, "Davor Bonaci"  wrote:
>
> On Sun, Jun 23, 2019 at 10:04 PM Greg Stein  wrote:
>
> > I disagree. I see a number of people who think that podling releases are
> > TLP-level releases from the Incubator itself. I see people wanting
> > structure/policy/rules to ensure these TLP releases are done properly. 
> And
> > that some want to "fix a few things" to make it easier for podlings to 
> make
> > these releases.
> >
>
> Perhaps you are right, but it is not necessary to debate it. (The
> 'disagreement' is about what other people think; we can let them speak up
> and/or measure consensus or lack thereof in the usual ways.)
>
> The balls rolls forward by understanding the space of options, and then
> discussing it. (... the first part of which is happening on other 
> threads.)
>
>

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

Re: Podlings, the Incubator, relationships and Apache

[Roman Shaposhnik]

On Sat, Jun 22, 2019 at 3:31 PM Rich Bowen  wrote:
>
> A couple of thoughts:

And a couple of thoughts on top of that.

> Podlings are not permitted to call themselves "Apache Foo" because they are
> not yet full Apache projects.

Correct. The I way I see this thread is this: *when it comes to
releases*, there's
always been two camps in Incubator. One thinks that Incubator is a TLP just
like Apache Commons that happens to produce release artifacts that have
nothing in common (just like Apache Commons'  JXPath has very little to do
with Compress and). A second camp thinks that Incubator is actually a special
construct within a foundation (after all, if it was just like Apache Commons why
would we make them put DISCLAIMER into release tarballs?).

It seems that David is closer to the 1st camp, and Rich and I are
closer to the 2nd.

Looking at the community benefits, I really think we should acknowledge that
Incubator is a special construct and optimize that special construct
for a particular
outcome: which is effectiveness of the graduation process.

> While in the incubator we should expect podlibgs to fail at the rules.
> They're new to them and many of them feel arbitrary, even capricious, to
> those coming in from outside. We should make it safe to fail until they are
> ready to graduate. We should nurture them as long as they are moving
> towards that goal.

Yup.

> I cannot disagree with your reading of our resolutions. But I wonder if
> that reality is producing good citizen projects or a bunch of resentful
> people following rules they don't understand or embrace because they know
> they have to.
>
> Zipkin is only the latest project which clearly didn't get it and has left
> angry. I would rather a project realize that they don't fit and be able to
> leave with their dignity without having also to leave hating what we stand
> for.
>
> I want our new graduates to love and understand the ASF not merely tolerate
> it.
>
> I want the incubator to respond to failure with gentle correction rather
> than scoldings.
>
> Specifically I think podlings should be able to produce releases that are
> not asf complient and have them clearly labeled as such. Because they are
> not TLPs yet and so cannot be held to the same standard. This must be
> accompanied by a movement towards being a TLP, not some eternal incubation.

With my IPMC member hat on -- huge +1 to the above.

With my VP Legal hat on: I have no dog in this race. The IPMC needs to make
a *business* (well, community in this case) decision and then we can work
with a risk profile of that decision.

Like I said -- the decision to make is: 1st vs. 2nd camp.

Thanks,
Roman.

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

Re: LGPL dependency

[Roman Shaposhnik]

Lets continue this discussion on
https://issues.apache.org/jira/browse/LEGAL-464 please

On Sat, Jun 22, 2019 at 2:18 PM Matt Sicker  wrote:
>
> WebKit dates back to KHTML, an LGPL web engine from KDE. It sounds like
> it’s some WebKit specific files that are BSD licensed. I haven’t inspected
> the individual files, but I suspect that the header files are BSD licensed
> to make linking less of a legal headache.
>
> On Sat, Jun 22, 2019 at 07:11, Craig Russell  wrote:
>
> > The Webkit license page https://webkit.org/licensing-webkit/ says
> > portions licensed under LGPL and BSD licenses.
> >
> > Usually this means it's the user's choice which license to use.
> >
> > We would choose the BSD License for the components that we use.
> >
> > Can you find anywhere a statement that the Webkit.so is licensed only
> > under LGPL?
> >
> > Craig
> >
> > > On Jun 14, 2019, at 1:40 AM, 申远  wrote:
> > >
> > > As mentioned above, Webkit is under dual License(BSD and LPGL) and it's
> > > almost impossible for us to figure out which function is a pure BSD
> > > function. I don't know
> > > Weex.apiA->Webkit.BSD.apiB->Webkit.BSD.apiC->Webkit.LGPL will happen or
> > > not. Perhaps pure BSD header file will lead to pure BSD implementation.
> > > Perhaps?
> > >
> > > As for alternative dependency, it's possible if we make some major
> > changes
> > > to Weex. But convenience binary of each Weex release includes Webkit.so,
> > > how to solve that problem? Maybe publish two convenience binary, one
> > named
> > > Weex_WebKit.aar and the other named Weex_BSDKit.aar ? Not sounds like a
> > > good idea to me.
> > >
> > > Best Regards,
> > > YorkShen
> > >
> > > 申远
> > >
> > >
> > > Sheng Wu  于2019年6月14日周五 下午4:23写道：
> > >
> > >> Hi York
> > >>
> > >> I am not a C/C++ coder, so I could be wrong.
> > >>
> > >> But from I saw, Catalog X dependency required is not right. Like Hen
> > said,
> > >> alternative is an option.
> > >>
> > >> Such as
> > >> Today’s another incubating project, ShardingSphere.
> > >> When user wants to MySQL sharing, then they needs to accept MySQL Driver
> > >> license first(or already accepted).
> > >> But user could use ShardingSphere with PostgreSQL JDBC Driver.
> > >>
> > >>
> > >> Sheng Wu
> > >> Apache Skywalking, ShardingSphere, Zipkin
> > >>
> > >>
> > >>
> > >>> 在 2019年6月14日，下午4:15，Hen  写道：
> > >>>
> > >>> Assuming Weex requires Webkit and is unable to work with an
> > alternative,
> > >>> the issue here is that users of Weex would seem to have to permit
> > reverse
> > >>> engineering in their legal terms. Our position has been that that goes
> > >>> beyond the scope of the Apache 2.0 license and would be an unpleasant
> > >>> surprise for users.
> > >>>
> > >>> (seem to have to  =>  this is how we've discussed the license; an
> > actual
> > >>> court may decide something completely different)
> > >>>
> > >>> Looking at Weex's website's description, it does not seem to be that a
> > >> user
> > >>> of Weex will already have agreed to the terms of Webkit; thus I believe
> > >>> they would be unpleasantly surprised.
> > >>>
> > >>> Hen
> > >>>
> > >>> On Fri, Jun 14, 2019 at 12:49 AM 申远  wrote:
> > >>>
> >  Hi,
> > 
> >  I am a PPMC member of Apache Weex. After serious reviewing of our
> >  dependencies, I found there some of the source code we copied from
> > >> Webkit
> >  is actually under LGPL license(Category X) and our license format
> > tools
> >  changed the license header of these files to Apache v2 incorrectly.
> > I'd
> >  like to hear advice from incubator that whether our actions below
> > would
> > >> fix
> >  the Category X issue.
> > 
> >  First of all, License for Webkit is complicated, as it's said that
> > >> "WebKit
> >  is open source software with portions licensed under the LGPL and BSD
> >  licenses available here." [1].
> > 
> >  Now, Weex includes 1500 header files( .h files) from Webkit at
> > compiling
> >  stage and around 150 of the are under BSD License. At runtime, Weex
> > will
> >  dynamic links to the shared library of Webkit.
> > 
> >  After some major change, Weex could just include around 50 headers(.h
> >  files) at compiling stage and all of them are under BSD license. At
> >  runtime, Weex still needs to dynamic links to the shared library of
> > >> Webkit
> >  as before.
> > 
> >  As Webkit is under dual license, and it's almost impossible for us to
> >  figure out whether there is an function call chain like
> >  Weex.apiA->Webkit.BSD.apiB->Webkit.BSD.apiC->Webkit.LGPL.apiD. I'd
> > like
> > >> to
> >  know our proposed change is enough to fix the Category X dependency.
> > 
> >  [1] https://webkit.org/licensing-webkit/
> > 
> >  Best Regards,
> >  YorkShen
> > 
> >  申远
> > 
> > >>
> > >>
> > >> -
> > >> To unsubscribe, e-mail: 

Re: Incubation Pain Points

[Roman Shaposhnik]

On Mon, Jun 17, 2019 at 8:51 AM Geertjan Wielenga  wrote:
>
> It’s not really totally OK. People leaving back to their old place feeling
> unhappy and frustrated, how is that totally OK?

I'll stick with Christofer's analogy -- if you come to a new country
thinking that
the roads are paved with gold -- all you're going to get is
frustration and unhappiness.
Not a single place is a paradise on earth.

If, however, you come to the new country with the intent to learn and
see if this
place can *gradually* become your new home -- now you're talking.

Obviously, this doesn't apply to refugees (I guess in our world it
would be corporate
refugees) but it applies extremely well to everyone else.

> How positive is that departing community going to be about Apache? Is that 
> really totally OK?

I'm not sure if you fully realize this, but Apache is a TERRIBLE place
for a whole
bunch of communities (I could totally see this being misquoted -- but
I'm doing it on purpose).

ASF is a HORRIBLE place to run Linux Kernel community. ASF is a
HORRIBLE place to
run any of the corporate-centric ASF communities, the list goes on.

What we should aspire to is that, on balance, we're an excellent place
for the kinds of
communities that have an affinity to our governance model (and
license) but that's
about it.

> I think it’s a sign that there was something wrong in the pre-incubation
> discussions, certainly some misconceptions. Sure, it’s not the end of the
> world to go back to the old place, but certainly not the ideal either.

There's as much wrong about pre-incubation as it is with trying to guess whether
you'd feel at home in a country by looking at travel shows on TV.

Thanks,
Roman.


> On Mon, 17 Jun 2019 at 17:36, Roman Shaposhnik  wrote:
>
> > On Mon, Jun 17, 2019 at 1:24 AM Christofer Dutz
> >  wrote:
> > >
> > > Hi Geertjan,
> > >
> > > not quite sure how to read this ... what are you referring to as "new
> > culture".
> > > The existing project coming to the ASF? And this project should adopt
> > the tradition of the ASF.
> > > Or that the ASF should adopt the culture and tradition of the project
> > joining?
> > > (Probably then meant more as: Allowing them to continue than the ASF to
> > change)
> > >
> > > I think projects coming to the ASF have to be educated prior to entering
> > incubation that
> > > there will almost always be things we are expecting them to change when
> > they come to Apache
> > > and that there's no discussion on if they have to follow them.
> >
> > This! Also, I think we should stop being so uptight about communities
> > trying incubation
> > and deciding that ASF is not for them. It is a two-ways street when it
> > comes to education.
> >
> > > We have to make them understand that the ASF is more than a GIT repo, CI
> > Server and Mailing lists.
> > > That the ASF has great things to provide (Legal Shield, Marketing,
> > Infra, ...) but that this only works
> > > If you play along with some rules we have. Also should we explain WHY
> > these rules are there.
> > >
> > > I would say it's sort of like emigrating to another country: You
> > probably move for some reasons.
> > > But also probably the rules are a little different at the country you
> > are moving. There will be things
> > > You will be allowed to do the same way you always did it, but there will
> > be things expected of you
> > > to simply follow and not ignore, because you think otherwise.
> >
> > And sometimes you'd return back to your old place after all -- and
> > that's totally OK.
> >
> > Thanks,
> > Roman.
> >
> > > We have to find a way to state the rules and what we expect before
> > podlings enter incubation.
> > >
> > > Still we will have podlings that sort of remind me of small children
> > simply not willing to do something simple,
> > > Just cause a parent told them to: "No, I will not say thank you".
> > >
> > > Or converted to our world: "No, I will not add anything to any Notice",
> > or "No, I will not credit stuff I
> > > obviously borrowed somewhere" ... but this way we can always refer to
> > the rules being clearly
> > > communicated prior to entering incubation and not have to listen to
> > complaints all the time.
> > >
> > > And for my point of view: If there are projects, that join the ASF, but
> > don't want to play according to the
> > > Rules - we're off way better without them. At least I don't want to
> > invest my time (which is already
> > &

Re: Incubation Pain Points

[Roman Shaposhnik]

On Mon, Jun 17, 2019 at 1:24 AM Christofer Dutz
 wrote:
>
> Hi Geertjan,
>
> not quite sure how to read this ... what are you referring to as "new 
> culture".
> The existing project coming to the ASF? And this project should adopt the 
> tradition of the ASF.
> Or that the ASF should adopt the culture and tradition of the project joining?
> (Probably then meant more as: Allowing them to continue than the ASF to 
> change)
>
> I think projects coming to the ASF have to be educated prior to entering 
> incubation that
> there will almost always be things we are expecting them to change when they 
> come to Apache
> and that there's no discussion on if they have to follow them.

This! Also, I think we should stop being so uptight about communities
trying incubation
and deciding that ASF is not for them. It is a two-ways street when it
comes to education.

> We have to make them understand that the ASF is more than a GIT repo, CI 
> Server and Mailing lists.
> That the ASF has great things to provide (Legal Shield, Marketing, Infra, 
> ...) but that this only works
> If you play along with some rules we have. Also should we explain WHY these 
> rules are there.
>
> I would say it's sort of like emigrating to another country: You probably 
> move for some reasons.
> But also probably the rules are a little different at the country you are 
> moving. There will be things
> You will be allowed to do the same way you always did it, but there will be 
> things expected of you
> to simply follow and not ignore, because you think otherwise.

And sometimes you'd return back to your old place after all -- and
that's totally OK.

Thanks,
Roman.

> We have to find a way to state the rules and what we expect before podlings 
> enter incubation.
>
> Still we will have podlings that sort of remind me of small children simply 
> not willing to do something simple,
> Just cause a parent told them to: "No, I will not say thank you".
>
> Or converted to our world: "No, I will not add anything to any Notice", or 
> "No, I will not credit stuff I
> obviously borrowed somewhere" ... but this way we can always refer to the 
> rules being clearly
> communicated prior to entering incubation and not have to listen to 
> complaints all the time.
>
> And for my point of view: If there are projects, that join the ASF, but don't 
> want to play according to the
> Rules - we're off way better without them. At least I don't want to invest my 
> time (which is already
> Spread out pretty thin with all the things I do for the ASF) to deal with 
> rebellious podlings.
>
> Chris
>
>
>
>
> Perhaps creating a training session as part of the training podling
>
> Am 13.06.19, 22:29 schrieb "Geertjan Wielenga" :
>
> Speaking on behalf of myself only, though note I am PMC chair of NetBeans,
> which went through a protracted (nice way of saying ‘complex’) incubation
> because of its size (‘very large’) and history (20+ years) — the key to 
> any
> new culture is to adopt its traditions and to fight them as little as
> possible. And one can’t really understand the culture until one is in it.
> It’s hard to really prepare — other than to admire projects like Maven or
> TomEE and to want and aim to be like them, regardless of the contortions
> required to get there.
>
> Gj
>
>
> On Thu, 13 Jun 2019 at 21:10, Dave Fisher  wrote:
>
> > Hi -
> >
> > Here are some thoughts I have to improving Incubation. These are not
> > really new, but I think we should discuss where and how best to apply 
> these.
> >
> > (1) Champions need to very clear that the ASF expects Community 
> decisions
> > not BDFLs. Burnout is one factor to highlight why community is 
> important.
> > Vendor independence is important and part of why BDFLs don’t fly. In the
> > last few years we have deemphasized the role of Champion and I think we
> > need to list out some of the duties a Champion has to both the 
> prospective
> > podling community and the Incubator.
> >
> > (2) We should help existing communities plan their entry into Incubation
> > with their proposals. Currently TVM is moving their community over 
> before
> > repositories. That might be a better approach for many communities as it
> > will assure that (a) the existing community keeps its current velocity 
> and
> > (b) they are making community decisions on list before actual 
> development
> > is moved over.
> >
> > (3) Having a lower impedance to release and code changes would really
> > help. We are already having this discussion. A very radical idea might 
> be
> > to move a lot of the License, Notice and Dependency work away from the
> > Release Vote and instead do periodic and potentially automated audits of
> > repositories. This would follow the REVIEW suggestion, but make it more
> > automated and based on tooling.
> >
> > (4) Relinquishing control of admin rights 

Re: [IMPORTANT] Board proposal on podling releases

[Roman Shaposhnik]

On Sun, Jun 9, 2019 at 8:20 PM Justin Mclean  wrote:
>
> Hi,
>
> > Big +1 to the above. I would strongly suggest trying to resolve
> > this first between IPMC and ASF Legal Committee
>
> JFYI - I’ve tried to do this before and was told (by aboard member) it was 
> the boards policy not the Legal Committer.

All policy is ultimately a board policy (well, you know ;-)) so what I
was suggesting is that a draft is worked on the legal committee side
and then submitted to the board if needed.

Thanks,
Roman.

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

Re: [IMPORTANT] Board proposal on podling releases

[Roman Shaposhnik]

A few comments based on various excellent previous posts:

On Sun, Jun 9, 2019 at 12:34 AM Hen  wrote:
> I don't see a need to go to the board on this :)

Big +1 to the above. I would strongly suggest trying to resolve
this first between IPMC and ASF Legal Committee

On Sun, Jun 9, 2019 at 6:33 PM Ted Dunning  wrote:
>
> There are three kinds of release constraints at Apache. Only one is
> critical for new podlings.
>
> 1. Legal constraints on whether Apache has the right to distribute the
> source code in question and link to any non-source dependencies. This
> mostly applies to projects coming out of commercial entities, but I would
> lump adversarial forks of open source projects into this category. Note
> that GPL inclusions are not a problem at this level, since they still allow
> us to make a source release legally.
>
> My feeling is that this is the only truly non-negotiable item for a podling
> release made at Apache.

Agreed 100%.

> 2. Downstream constraints on users. Mature projects at Apache provide good
> guarantees that using the release will not have limited allowable field of
> use or strange license terms. This is a MUST-DO for a top-level project
> release, but it is plausible to allow this for early podling releases with
> LOTs of disclaimers and warning signs. Examples of this are GPL inclusions,
> the JSON.org "don't be evil" license, non-commercial licenses and
> non-optional binary dependencies that are not open source. All of these
> could plausibly be allowable in an incubating release if the fact that the
> release doesn't have the normal safety of an Apache release.
>
> I would expect that any graduating podling has this under control before
> graduating and will not make any TLP releases with this kind of defect.

I would suggest we make it a policy to document those exceptions in
the DISCLAIMER file.

Later on, whether to allow graduation with non-trivial DISCLAIMER
file can be decided on a case-by-case basis.

> 3. Infrastructural impact on Apache itself. This means that a project can't
> require that infra rebuild their systems just to accommodate some
> idiosyncratic strangeness of the podling. This is typically a pretty strict
> constraint, but is reasonable to waive for early releases if, say, the
> podling uses non-Apache resources on an interim basis or if the project
> really does have some special needs and infra is willing to help.
>
> Again, this issue probably has to be dealt with one way or another before
> graduation.

Agreed.

Thanks,
Roman.

>
>
>
>
>
> On Sun, Jun 9, 2019 at 5:41 PM Greg Stein  wrote:
>
> > The entire note below sounds like "business as usual. we haven't learned
> > anything."
> >
> > Release offsite is not a solution, IMO. I believe it is Best(tm) to have a
> > DISCLAIMER.txt in the incubator/$podling/release/ directory, and "podling
> > releases" which do not meet our normal policies for TLPs. I think our goal
> > should be that a podling release has (say) two MUST items (add a
> > disclaimer, use Foundation dist system; I wouldn't even care about a
> > LICENSE file -- let users decide if that concerns them), and the rest is
> > forgiven as long as notes/fixes will be made before graduation.
> >
> > It takes a new mindset. What is the *bare* minimum MUST? Two items?
> > maaaybe three?
> >
> > And keep the IPMC out of it. No votes on releases. Stop second-guessing the
> > mentors and the podling communities.
> >
> > Cheers,
> > -g
> >
> >
> > On Sun, Jun 9, 2019 at 6:27 PM Justin Mclean  wrote:
> >
> > > Hi,
> > >
> > > > (2) We all know that for many incubating projects immediately requiring
> > > full Release Policy compliance is too steep a slope.
> > >
> > > This is solved by allowing them to make non Apache releases out side of
> > > the ASF. We currently do this. However branding and release policy also
> > > need to be followed there. i.e. A (P)PMC can’t release unreleased
> > materials
> > > outside the their development community, so they can’t be called Apache
> > > releases, and it’s not the (P)PMC who is releasing them.
> > >
> > > > (3) We should be willing to provide guidance to podlings about which
> > > requirements should be fully met first. We don’t need to define serious
> > for
> > > this.
> > >
> > > +1
> > >
> > > > (4) We already have tracking in place in the Podling Status XML/YAML
> > > about the dates where podlings have met various requirements with
> > licensing
> > > and copyright. If properly updated then we already providing for
> > additional
> > > DISCLAIMERs.
> > >
> > > I think those disclaimers would need to be in a more visible place, i.e.
> > > in the release artefacts, so end users can see them.
> > >
> > > > (5) We should work to modernize (3) and (4) to properly discuss the
> > > modern workflow using GitBox/GitHub. For example, at what point should a
> > > podling stop making releases in their pre-Apache process and switch to an
> > > Apache process and how should we handle repositories that are 

Re: [DISCUSS] Graduate Apache PLC4X (incubating) as a TLP

[Roman Shaposhnik]

+1 from my side. This looks like a small but very viable community to me.

Thanks,
Roman.

On Thu, Apr 4, 2019 at 6:38 PM Dave Fisher  wrote:
>
> Hi Chris,
>
> Thanks! My concern is that in the past the IPMC has graduated podlings with 5 
> PMC members that fairly quickly ended up in the Attic.
>
> With potential committers in view I’m less concerned!
>
> There are plenty of successful projects with 5-10 active PMC.
>
> +1
>
> Regards,
> Dave
>
> Sent from my iPhone
>
> > On Apr 4, 2019, at 6:08 PM, Christofer Dutz  
> > wrote:
> >
> > Hi Dave,
> >
> > The one addition you mention explicitly said, that due to changes at work 
> > he will not be able to participate and is not willing to invest his private 
> > time :-( ... But we are more than willing to re-invite past contributors 
> > later, if they decided not to be carried over now.
> >
> > And yes, there are potential candidates that we are keeping an eye on, 
> > which we will probably invite soon.
> >
> > We know there are way larger communities in the incubator but as far as I 
> > understand incubation, it's all about the projects learning to become good 
> > Apache communities and that they demonstrate their fitness to do correct 
> > releases. I guess we have proven that and continuing to grow community is 
> > and will remain the goal of every Apache project throughout it's existence.
> >
> > Chris
> >
> >
> > Outlook für Android herunterladen
> >
> > 
> > From: Dave Fisher 
> > Sent: Thursday, April 4, 2019 8:14:00 PM
> > To: general@incubator.apache.org
> > Subject: Re: [DISCUSS] Graduate Apache PLC4X (incubating) as a TLP
> >
> > Hi -
> >
> > I am for graduation. I appreciate the need to narrow the PMC to those who 
> > are active. I’ll note that one of your recent additions (noted on the Oct 
> > 2018 report) did not continue while the other did.
> >
> > Graduating with only 6 PMC is pretty narrow. Are there other developers 
> > active who look like you will want to add to the committer / PMC soon after 
> > graduation?
> >
> > Best Regards,
> > Dave
> >
> >> On Apr 4, 2019, at 6:59 AM, Christofer Dutz  
> >> wrote:
> >>
> >> Hi all,
> >>
> >> Since Apache PLC4X (incubating) entered the incubator in December 2017 we 
> >> have attracted quite a number of new PPMCs,
> >> committers and contributors that didn’t have any experience with Apache 
> >> and the Apache Way.
> >>
> >> However have we managed to educate these new individuals and have grown to 
> >> a community that operates nicely following
> >> the Apache Way. All issues reported have been addressed and our last 
> >> releases usually passed without any objections.
> >>
> >> We recently had a discussion on graduation [5] and just finished a 
> >> community vote [2] on the matter which resulted in 7 (binding) +1, 1 
> >> (non-binding) +1 and no 0 or -1 votes [1].
> >> In another discussion prior to the vote we decided to reduce the number of 
> >> PMCs/Committers to those existing who explicitly expressed the wish to be 
> >> included [3].
> >> This was due to the fact that when setting up the project outside of 
> >> Apache, a lot of my colleagues initially expressed the wish to participate 
> >> and we included them in the initial contributor list.
> >> However most of these never did anything and some didn’t even sign up for 
> >> our mailing lists.
> >> Some have expressed the wish to go emeritus and we used a vote [4] to 
> >> define the initial PMC for the TLP.
> >>
> >> We would like to continue the graduation process and hereby ask you all 
> >> for your opinion on this.
> >>
> >> Chris
> >>
> >> [1] 
> >> https://lists.apache.org/thread.html/d53c159c6e8973a6e763635c90bc0f52e0c4fa576da80f553bc4aa40@%3Cdev.plc4x.apache.org%3E
> >> [2] 
> >> https://lists.apache.org/thread.html/9a4cf5b1ad7b59e79ae33f3d09032e7942a7191a319335303e16d286@%3Cdev.plc4x.apache.org%3E
> >> [3] 
> >> https://lists.apache.org/thread.html/d14e972889dad4ca9cb72f2447edb422df2742f8d71bf140618ba021@%3Cdev.plc4x.apache.org%3E
> >> [4] 
> >> https://lists.apache.org/thread.html/7a979438fa050bc873a4df0da9b628edaa61d350a17364b837a059d3@%3Cdev.plc4x.apache.org%3E
> >> [5] 
> >> https://lists.apache.org/thread.html/0a590c8aabced1b46e1200aeface51e9fe34cdf01ed7753a6779ce55@%3Cdev.plc4x.apache.org%3E
> >>
> >>
> >> ---
> >>
> >> Establish the Apache PLC4X Project
> >>
> >> WHEREAS, the Board of Directors deems it to be in the best interests of
> >> the Foundation and consistent with the Foundation's purpose to establish
> >> a Project Management Committee charged with the creation and maintenance
> >> of open-source software, for distribution at no charge to the public,
> >> related to a set of libraries for communicating with industrial
> >> programmable logic controllers (PLCs) using a variety of protocols but
> >> with a shared API.
> >>
> >> NOW, THEREFORE, BE IT RESOLVED, that a Project Management Committee
> >> (PMC), to be known as 

Re: A smaller IPMC

[Roman Shaposhnik]

On Thu, Mar 7, 2019 at 3:33 PM Justin Mclean  wrote:
>
> Hi,
>
> It’s been suggested that the IPMC is too large, what do other IPMC members 
> think might be a way to address this?

Personally, I believe that "IPMC is too large" argument is only applicable to
how quickly/easily consensus can be built. That's literally the only situation
when the size of IPMC gets in the way (sometimes).

Is anyone aware of any other situations where "IPMC is too large" argument
is actually legit?

At any rate, the rest of my feedback will be from that single perspective:

> Please discuss and indicate +1 what you would think would help, you can vote 
> for more than one.
>
> Some suggestions:
> 1. Ask all inactive IPMC if they want to continue being on the IPMC and see 
> who steps down. Being inactive they are probably not following this list so 
> we need to identify and send each one email them personally.
> 2. There were some questions around merit raised, remove all IPMC members who 
> were not on the initial proposal and who were voted in. Those left on the 
> IPMC vote back in those who are currently active.
> 3. Get rid of all IPMC members, and vote (with ASF members vote being binding 
> - not sure how else it could be done?) currently active ones back in.
> 4. Do nothing as this is not actually a problem but instead address other 
> underlying issues. e.g. lack of mentor engagement.

I would like to suggest a 5th alternative (again this is from the
above's perspective):
   * Don't change anything, but for any situation that requires
consensus building just be a tad more formal with how we close loops
and track if we really get as many obstructionists as we thing that
the size of the IPMC allows. If not -- we don't have a problem.

> Also re point 2 do you think we should drop that ASF members can 
> automatically get IPMC membership and change it to requiring a vote by the 
> IPMC? It’s has always seem odd to me that this is the case. We’ve recently 
> voted more people in that we’ve had requests from ASF members.
>
> Any other sugestions?
>
> Options 2 and 3 may cause some issues around mentors, but if they were not 
> active then I guess it’s no big loss.
>
> And any suggestions on level of activity? Such as:
> - Emailed the list in the last year.
> - Reviewed at least one release in that time.
>
> It’s already been determined that some (about 15%) of the less than active 
> PMC members (out of the 100 odd that are not signed up to the IPMC private 
> list) do help out infrequently but that help is very useful. That may also 
> apply to other inactive IPMC members, so I would suggest the bar for what 
> consider active be kept low.

I honestly don't see how all of these options of getting people in and
out of IPMC can actually help with this consensus building thing. So
yeah -- I'd say #5.

Thanks,
Roman.

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

Re: [DISCUSS] Graduate Apache SkyWalking (incubating) as a TLP(take2)

[Roman Shaposhnik]

On Tue, Mar 5, 2019 at 5:09 PM sebb  wrote:
>
> On Wed, 6 Mar 2019 at 00:18, Dave Fisher  wrote:
> >
> > Hi -
> >
> > > On Mar 5, 2019, at 3:55 PM, 吴晟 Sheng Wu  wrote:
> > >
> > > Hi Roman
> > >
> > >
> > > In the discussion, I started about inviting committers to PMC when 
> > > graduation, shows the most PPMC members support this. We will wait 
> > > another 2 days, in case someone may say others.
> > >
> > >
> > > In case PPMC agree, I want to ask the process steps of this. From 
> > > committer to PMC, I think each one should be invited and accept to be 
> > > one. Then, when should the invitation happens?
> > > Do we need to send invitation and get confirmation before change the 
> > > graduation PMC list?
> > > Or we could change the PMC list first, after our graduation proposal is 
> > > accepted, we send the invitation.
> >
> > Just put them all on the graduation proposal (the IPMC and board’s approval 
> > is equal to NOTICE) and (unless Infra does it) add them to the PMC in 
> > Whimsy once you have graduated and infrastructure has moved the project 
> > LDAP.
>
> Huh?
> That does not sound right.
>
> The graduation proposal lists the initial PMC membership (committers
> are irrelevant here).
> Adding committers to the proposal (if that is what you meant) is the
> same as adding them to the (initial) PMC.
>
> That can only be done if the committers have agreed to becoming
> members,

That is correct, they need to be offered and they need to agree.

> in which case you might as well add them to the PPMC before
> graduation.

Since PPMC is an artificial construct that isn't recognized by the
foundation -- this part is moot. IOW, after these individuals agree
they may as well be put on the resolution straight away.

Thanks,
Roman.

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

Re: [DISCUSS] Graduate Apache SkyWalking (incubating) as a TLP(take2)

[Roman Shaposhnik]

On Mon, Mar 4, 2019 at 12:42 PM Craig Russell  wrote:
>
>
>
> > On Mar 4, 2019, at 3:12 AM, Mick Semb Wever  wrote:
> >> The cookies in the moderator mails expire after a few days.
> >
> > This example was all done today. Numerous attempts have been made.
> >> It also means that the person is aware that the private@ list is
> >> something they need to follow.
> >
> As noted else-thread, there is an alternate method to subscribing to the 
> email lists, by sending email to 
> private-subscribe-EMAIL.ADDRESS=domain@skywalking.apache.org
>
> > Not getting any response at all is not an indication of whether the list 
> > exist of not, unfortunately.
> >
> > Anyway… to the thread's discussion: every PPMC received an invitation (per 
> > Apache template) that requested subscription to both dev and private ML. 
> > Reading the ASF guidelines here: 
> > https://apache.org/foundation/governance/pmcs.html#communication ; I 
> > interpret it as they SHOULD be subscribed rather than MUST, and I'm curious 
> > as to whether how many of the TLPs are actually enforcing this among their 
> > pmc, if any. It's an interesting discussion… but I'm not entirely convinced 
> > it's an accurate shortcoming to whether the podling is ready for graduation 
> > or not.
>
> I think the question is not "Is SkyWalking ready to graduate" but "Is the 
> proposed PMC list accurate".
>
> The PMC members are responsible for governing the TLP and as such need to be 
> familiar with what is expected of them. Governance activities are conducted 
> on the PPMC private list. If a PPMC member has not participated in any 
> governance activities during incubation, it's unclear that they belong on the 
> PMC.
>
> Reviewing the last several months of private@skywalking list, most of the 
> discussion of new committers has had only four or five participants, who are 
> clearly involved in governance of the project.

>From a peanut gallery: has the podling considered PMC == committers at
the graduation point?
The two lists look very close to each other.

Thanks,
Roman.

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

Re: Binary jars in the source release which are only for testing

[Roman Shaposhnik]

On Mon, Feb 25, 2019 at 3:28 PM Mark Thomas  wrote:
>
> On 25/02/2019 14:15, Roman Shaposhnik wrote:
> > On Mon, Feb 25, 2019 at 11:35 AM Mark Thomas  wrote:
> >>
> >> On 23/02/2019 06:18, Willem Jiang wrote:
> >>> Hi,
> >>>
> >>> I just have a question about the Binary jars in the source release.
> >>> According the Apache release policy, I cannot find any rule about the
> >>> binary jars cannot be in the source release[1]. If we just have jars
> >>> for testing purposes and those jar won't be a part of convenience
> >>> binary release, I think it doesn't break the rule below:
> >>>
> >>> "In all such cases, the binary/bytecode package must have the same
> >>> version number as the source release and may only add binary/bytecode
> >>> files that are the result of compiling that version of the source code
> >>> release.".
> >>>
> >>> Is it OK to ship those test binary jars in the source release kit?
> >>
> >> It depends ;)
> >>
> >> Generally, source releases should contain exactly that - source code. So
> >> the aim should always be to not include compiled code - like JARs - in a
> >> source release.
> >>
> >> That said, I have always been a little more relaxed about test code.
> >> Sometimes you need to use class files and/or JARs in your testing. The
> >> minimum - in my view - is that:
> >> - it MUST be possible to produce a fully working binary from the source
> >>   distribution
> >
> > Big +1 to the above.
> >
> >> - the source for any compiled files included in the source MUST be
> >>   provided alongside the compiled files
> >
> > Is this really a MUST in all situations? Sometimes a JAR file truly is a 
> > test
> > artifact (like for negative testcases for example) and it may not even be
> > possible to "compile it" -- its purpose in fact, may be to test something 
> > like
> > a classloader for tripping up on "incorrect" JARs, etc.
> >
> > Or did I misunderstand your MUST?
>
> The view I was trying (and failing) to convey is that we don't want any
> binary "magic" files in the release.

By and large -- yes. IOW, for every magic binary there has to be a good reason.
Sometimes that reason actually exists (like my handcrafted JAR example
or an image file that was created in Gimp but its not like there's a
"source" for it).

> The "source" may be the source as
> in the input to a compiler.

Which is covered by your point #1 -- you disable tests -- you should be able
to build the release purely from source.

> It might be a more complex recipe. Either
> way it needs to carry sufficient information to enable other community
> members to understand how the binary file was created and what they
> would need to do if they wanted/needed to re-create the binary file at
> some point in the future.
>
> HTH,
>
> Mark
>
> >
> > Thanks,
> > Roman.
> >
> >> Ideally, class files, JAR files etc. would be constructed as required
> >> when the tests are run. However, there are cases when it makes sense to
> >> include the binary - e.g. the file needs to be compiled with a very
> >> specific version of the compiler because it is testing something that
> >> depends on a specific behaviour of that compiler version. It is arguably
> >> better for users to provide the compiled file rather than requiring them
> >> to obtain the specific compiler version required.
> >>
> >> For the record, Apache Tomcat has a small number of JAR and class files
> >> in its source distribution. All related to testing and the source is
> >> there for all of them. We could probably generate some of those at build
> >> time. But, given the very small number of files concerned and the
> >> complexity it adds to the build process, it isn't an itch any of the
> >> community has felt the need to scratch. Yet.
> >>
> >> I also recall an instance - I think in Apache Commons BCEL - where we
> >> needed to test with a faulty class file. From memory, we shipped the
> >> class file in the source along with instructions on how to recreate it.
> >> I don't recall exactly why but creating it at build time was problematic.
> >>
> >> In summary, I think you are fine as long as you meet the MUSTs I listed
> >> above. Whether the project should look to generate those files at
> >> build/testing time depends on circumstances. In most cases I 

Re: Binary jars in the source release which are only for testing

[Roman Shaposhnik]

On Mon, Feb 25, 2019 at 11:35 AM Mark Thomas  wrote:
>
> On 23/02/2019 06:18, Willem Jiang wrote:
> > Hi,
> >
> > I just have a question about the Binary jars in the source release.
> > According the Apache release policy, I cannot find any rule about the
> > binary jars cannot be in the source release[1]. If we just have jars
> > for testing purposes and those jar won't be a part of convenience
> > binary release, I think it doesn't break the rule below:
> >
> > "In all such cases, the binary/bytecode package must have the same
> > version number as the source release and may only add binary/bytecode
> > files that are the result of compiling that version of the source code
> > release.".
> >
> > Is it OK to ship those test binary jars in the source release kit?
>
> It depends ;)
>
> Generally, source releases should contain exactly that - source code. So
> the aim should always be to not include compiled code - like JARs - in a
> source release.
>
> That said, I have always been a little more relaxed about test code.
> Sometimes you need to use class files and/or JARs in your testing. The
> minimum - in my view - is that:
> - it MUST be possible to produce a fully working binary from the source
>   distribution

Big +1 to the above.

> - the source for any compiled files included in the source MUST be
>   provided alongside the compiled files

Is this really a MUST in all situations? Sometimes a JAR file truly is a test
artifact (like for negative testcases for example) and it may not even be
possible to "compile it" -- its purpose in fact, may be to test something like
a classloader for tripping up on "incorrect" JARs, etc.

Or did I misunderstand your MUST?

Thanks,
Roman.

> Ideally, class files, JAR files etc. would be constructed as required
> when the tests are run. However, there are cases when it makes sense to
> include the binary - e.g. the file needs to be compiled with a very
> specific version of the compiler because it is testing something that
> depends on a specific behaviour of that compiler version. It is arguably
> better for users to provide the compiled file rather than requiring them
> to obtain the specific compiler version required.
>
> For the record, Apache Tomcat has a small number of JAR and class files
> in its source distribution. All related to testing and the source is
> there for all of them. We could probably generate some of those at build
> time. But, given the very small number of files concerned and the
> complexity it adds to the build process, it isn't an itch any of the
> community has felt the need to scratch. Yet.
>
> I also recall an instance - I think in Apache Commons BCEL - where we
> needed to test with a faulty class file. From memory, we shipped the
> class file in the source along with instructions on how to recreate it.
> I don't recall exactly why but creating it at build time was problematic.
>
> In summary, I think you are fine as long as you meet the MUSTs I listed
> above. Whether the project should look to generate those files at
> build/testing time depends on circumstances. In most cases I would
> expect them to be generated during building/testing but there can be
> valid reasons for not doing so.
>
> Mark
>
>
>
>
> >
> > [1]http://www.apache.org/legal/release-policy.html#what
> >
> > Willem Jiang
> >
> > Twitter: willemjiang
> > Weibo: 姜宁willem
> >
> > -
> > 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] Guidelines for distribution of incubating artefacts on other platforms

[Roman Shaposhnik]

On Fri, Feb 8, 2019 at 12:27 PM Justin Mclean 
wrote:

> Hi,
>
> > This sentence is very confusing to me. If the release is "unofficial”
> then it can't be subject to ASF's policy, no?
>
> I used the word unofficial as some of these artefacts are connivance
> binaries. I and don’t want to open up the “we only release source" can of
> worms.
>

Then why not just call them what they are "convenience binary artifacts".
IOW, how about this edit:

- Convenience binary artifact releases need to be made from approved voted
on approved ASF releases.

?


>
> > I am actually not sure why we're including GitHub in this list.
>
> Because people are placing releases there as well. Github has a release
> page which can include release notes etc and shows a history of releases,
> users can download releases from here.
>

Wait, you mean binary releases, not just source code tags?


>
> > It is unclear whether  should include incubator- prefix. I
> > honestly thing it should.
>
> Good point. None of them I’ve seen have, I was thinking not and then you
> need to rename on graduation which would be a pain.
>
> > You don't have to had a Dockerfile to publish to Docker Hub. This
> sentence
> > makes it sound like it is a requirement.
>
> Right I’ll make that optional.
>
> Thanks for the feedback.
> Justin

Re: [DISCUSS] Guidelines for distribution of incubating artefacts on other platforms

[Roman Shaposhnik]

Great effort getting it all documented! Would really love to see this
converge ASAP.

On Thu, Feb 7, 2019 at 11:08 PM Justin Mclean 
wrote:

> Hi,
>
> Feedback welcome. If you think anything here is not in line with the ASF
> release and distribution policy please speak up. Currently it’s not clear
> to me if RCs, snapshots or nightlys would be allowed on these platforms so
> some changes may need to be made.
>
> If you want to add another platform please do so, but these are one we’ve
> recently had issues with that I’m aware of.
>
> Currently not many projects would be complying with this, for instance
> most likely missing the incubator disclaimer, which I think is importtant.
>
> Does the IPMC think we need to have a vote on approving this?
>
> I've added a harsh non-compliance to hopefully smart how important this is
> and to reduce the risk to the ASF. If you think it is too harsh or not
> needed speak up.
>
>
> --
> Guidelines to help you comply with the ASF release and distribution
> policies
>
> In addition to the Apache mirror system incubating projects may distribute
> artefacts on other platforms as long as they follow these general
> guidelines:
> - Unofficial releases need to be made from approved voted on approved ASF
> releases.
>

This sentence is very confusing to me. If the release is "unofficial" then
it can't be
subject to ASF's policy, no?


> - An incubating disclaimer must be clearly be displayed where the
> artefacts are made available.
> - Release candidates, nightlys and snapshots must not be advertised to the
> general public.

- Apache project branding and naming needs to be respected.
> - It should be clear that the artefact in under the ALv2 license.
> - Where possible these artefacts should not be referred to as releases.
>
> If any podling is found not to comply they will be asked to fix it, if a
> fix doesn’t happen with a week they will be asked to remove the offending
> artefact(s), if a podling commits serial offences or fails to remove
> artefacts when asked to within a week they will be banned from using that
> distribution mechanism altogether.
>

I would also ask that if after a certain period of time the podling doesn't
respond to criticism -- IPMC reserves the right to ask INFRA to remove the
artifact.


>
> GitHub
>

I am actually not sure why we're including GitHub in this list. For all
practical purposes,
GitHub is a mirror of ASF git repo and as such doesn't warrant a dedicated
policy.

I'd like to see it removed.


> Artifacts show up on https://github.com/apache/incubator-
> /releases
>
> To comply with ASF release and distributions please ensue the following:
> - Any releases need to include the text of the incubation disclaimer.
> - The release page must not contain release candidates, nightly or
> snapshots releases.
> - Any releases that exist before coming into incubation need to be clearly
> described and tagged as such on https://github.com/apache/incubator-
> /tags.
> - Release candidates, nightly or snapshots releases can be tagged and
> appear on https://github.com/apache/incubator-/tags.
>
> Docker
>
> Artefacts need to be placed in https://hub.docker.com/r/apache/
> or https://hub.docker.com/u/apache/
>

It is unclear whether  should include incubator- prefix. I
honestly thing it should.


> To comply with ASF release and distributions please ensue the following:
> - The overview should include the incubator disclaimer.
> - The docker file should include an ASF header.
>

You don't have to had a Dockerfile to publish to Docker Hub. This sentence
makes it sound like it is a requirement.


> - The docker file should include the incubator disclaimer.
> - "docker pull apache/" should not install an artefact containing
> unapproved code.
> - Release candidates, nightly or snapshots need to be clearly tagged.

- The latest tag should not point to an artefact containing unapproved code
> e.g. to master or dev branches or to a RC or snapshot.
>

This is a repeat of a "docker pull apache/" should not install an
artefact containing unapproved code. statement.

Thanks,
Roman.


> NPM
>
> Artefacts  show up on https://www.npmjs.com/package/apache
> version page
>
> To comply with ASF release and distributions please ensue the following:
> - The readme tab needs to include the text of the incubation disclaimer.
> - “npm install apache” should not install an artefact containing
> unapproved code.
> - The latest release should not point to an artefact containing unapproved
> code e.g. a release candidate or snapshot.
> - Release candidates, nightly or snapshots need to be clearly tagged.
> - The license field should display the ALv2 license.
>
> PiPy
>
> Artefacts need to be placed in https://pypi.org/project/apache/
>
> To comply with ASF release and distributions please ensue the following:
> - The project description should include the incubator 

Re: Tying Dockerhub into development and release management

[Roman Shaposhnik]

Hey Justin -- any chance you can take a look at the proposed policy for
*snapshot* Docker hub artifacts I proposed up-thread?

Thanks,
Roman.

On Thu, Feb 7, 2019 at 6:13 AM Justin Mclean 
wrote:

> Hi,
>
> > AFAIK everyone releasing binary convenience to dockerhub believed they
> were authorized.
>
> I didn't have a problem with them if they are based on actual released
> software, although it seem it’s now not clear that in line with policy or
> not, lets alone if a PPMC can  release tagged nightly or snapshots there.
>
> Thanks,
> Justin
>
>
> -
> To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
> For additional commands, e-mail: general-h...@incubator.apache.org
>
>

Re: Tying Dockerhub into development and release management

[Roman Shaposhnik]

On Wed, Feb 6, 2019 at 10:12 PM Hen  wrote:

> On Tue, Feb 5, 2019 at 6:45 AM Roman Shaposhnik 
> wrote:
>
> > On Tue, Feb 5, 2019 at 2:48 PM Dave  wrote:
> >
> > > I totally agree with you that Docker images should be built from
> official
> > > source releases, unless they are clearly marked as unofficial SNAPSHOT
> > > releases and intended for testing. I'm just repeating what I've heard
> > over
> > > and over again from various ASF members that the only official release
> is
> > > the source release; I'd don't agree with that point of view.
> > >
> > > I'm curious what "built from the official source releases". Does that
> > mean
> > > that you must create Docker images by downloading the official source
> > > release, verifying it's hash and then building image?  Or, are you
> > allowed
> > > to build your Docker images from the same SCM tag as was used to create
> > the
> > > source release?
> > >
> >
> > I think an acceptable solution could be:
> >* make sure that your :latest tag either points to a Docker scratch
> > container
> >  or a container that simply prints Incubator disclaimer and exists
> >* introduce a tagging scheme for nightly builds (personally I'm quite
> > fond
> >  of tagging nightly docker builds with SHAs from your git tree from
> > which
> >  you build the image)
> >* introduce :snapshot tag that points at the latest tag from previous
> > item
> >
> > I feel that this could be passable for IPMC.
> >
> >
> I remain confused on this topic.
>

We're not talking about "official" release binaries (whatever that means at
ASF).
We're talking about snapshot binaries that need to be available for
developers.
I don't think the rest of your reasoning applies *to this* particular
discussion.


>
> The legal-discuss thread leads me to think the current state is:
>
> 1. The PPMC release some source code. They may release convenience binaries
> on the Apache distribution urls, or in Maven Central (via Infra's support),
> and those binaries must be built from the release soruce.
> 2. The PPMC should not publish software outside of Apache controlled
> locations.
> 3. Third parties may publish software based on Apache's, but they must not
> cause user confusion (i.e. respect trademarks).
> 4. The PPMC may link to the software (including binaries) published by a
> third party, but they should flag that it does not come from Apache and
> should not treat it as the default user experience.
>
> All of which means PPMCs must not use PyPI, NuGet, NPM, DockerHub, etc.
> unless Infra actively support a mechanism of doing so (which they
> definitely do for Maven).
>
> (Though I'm confused as to whether #2 is a must not, should not, or can if
> they wish to)
>
> Hen
>

Re: Tying Dockerhub into development and release management

[Roman Shaposhnik]

On Tue, Feb 5, 2019 at 2:48 PM Dave  wrote:

> I totally agree with you that Docker images should be built from official
> source releases, unless they are clearly marked as unofficial SNAPSHOT
> releases and intended for testing. I'm just repeating what I've heard over
> and over again from various ASF members that the only official release is
> the source release; I'd don't agree with that point of view.
>
> I'm curious what "built from the official source releases". Does that mean
> that you must create Docker images by downloading the official source
> release, verifying it's hash and then building image?  Or, are you allowed
> to build your Docker images from the same SCM tag as was used to create the
> source release?
>

I think an acceptable solution could be:
   * make sure that your :latest tag either points to a Docker scratch
container
 or a container that simply prints Incubator disclaimer and exists
   * introduce a tagging scheme for nightly builds (personally I'm quite
fond
 of tagging nightly docker builds with SHAs from your git tree from
which
 you build the image)
   * introduce :snapshot tag that points at the latest tag from previous
item

I feel that this could be passable for IPMC.

Thanks,
Roman.

Re: Incubator exit interview

[Roman Shaposhnik]

On Mon, Jan 14, 2019 at 10:14 AM Kevin A. McGrail  wrote:
> On 1/14/2019 1:01 PM, Julian Hyde wrote:
> > I don’t think the “decisions should be made on-list” principle applies to 
> > all communication. (Otherwise why would we allow hallway conversations at 
> > conferences?) I’d rather that we make better decisions than be slave to 
> > principle.
> >
> It really does apply to everything.

As Mark Twain would say: all generalizations are false. Including this one ;-)

> Even if you have the best meeting
> in the world, you bring back minutes and decisions made off list for
> ratification.  That way there is then an archive of the decision and
> everyone can participate.

I think if you unpack this statement you will see that there's an implicit
assumption about "collaborative things". That's 90+% of what ASF does.
And the statement applies there 100% -- no disagreement there.

But there's also a small portion of things that have to do with humans,
personalities and personnel. That's where what - Julian mentioned really
starts making sense. At least in my book.

Thanks,
Roman.

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

Apache Quickstep (incubating) is now officially retired

[Roman Shaposhnik]

Hi!

with the last task of: https://issues.apache.org/jira/browse/INFRA-17392
now done, I believe that Apache Quickstep (incubating) is now officially
retired.

Since, believe it or not, this is the first time for me to retire a podling, I'd
appreciate if someone could double check.

Justin, you may want to include this in the Incubator report if it
isn't too late.

Thanks,
Roman.

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

Re: Incubator exit interview

[Roman Shaposhnik]

On Mon, Dec 10, 2018 at 7:51 PM Justin Mclean  wrote:
>
> Hi,
>
> > I like this idea a lot! In fact, I like it so much that I'd really
> > love to see it as an on-going feedback rather than a one-time deal.
>
> Were you thinking something like after 6 month, 1 year and 2 years (if 
> needed) in incubation? And also at graduation.

Yup. Basically ~6 months intervals.

Thanks,
Roman.

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

Re: Incubator exit interview

[Roman Shaposhnik]

On Fri, Dec 7, 2018 at 7:15 PM Justin Mclean  wrote:
>
> Hi,
>
> I was just wondering if it would be a good idea to ask projects a few 
> questions of committers/PPMC members once they leave the incubator to gauge 
> how we are doing and find out where there is room for improvement? It would 
> be simple to try as a proof of concept on a couple of graduating projects to 
> see to we get any valuable feedback that we don’t normally get on this list 
> or in the podling reports.
>
> Some suggested questions off the top of my head:
>
> Thinking about the project that you have just graduated as part of:
> - I am a X committer X PMC member X mentor X none of those X rather not say
> - How many times have you gone through the incubation process: X one X two X 
> three X more than three
> - Have you felt supported by the incubator? If not what could be improved?
> - Have you felt supported by the your mentors? If not what could be improved?
> - Did you run into any issues with any part of the incubating process? If so 
> what?
> - Was is clear what you needed to do to graduate?
> - What, if anything, could be done to make the graduation process smoother?
> - Is the time taken to graduate X too short? X just right? X too long?
> - Do you have a good understanding of the Apache Way? If not what areas are 
> you unclear on?
> - Anything else you want to add or comment on?
>
> Probably best if answers were anonymous. Anyone have any ideas for other 
> questions or improvement to the above? I’d like to keep it under a dozen 
> questions.

I like this idea a lot! In fact, I like it so much that I'd really
love to see it as an on-going feedback rather than a one-time deal.

That, however, can be the next step I suppose.

So yeah: +1!

Thanks,
Roman.

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

Re: December report - Mentor sign off due end of today

[Roman Shaposhnik]

Justin, I see my name attached to the Sharding Sphere as a mentor, but I only
agreed to help as a Champion (that's why my name wasn't listed as a Mentor
on the proposal).

I know we've had back-n-forth in the past on whether Champions automatically
become mentors (and I happen to be in the firm 'no they do NOT' camp) but
regardless -- do you want me to simply remove myself from podling.xml ?

Thanks,
Roman.On Mon, Dec 10, 2018 at 1:19 PM Justin Mclean
 wrote:
>
> Hi,
>
> It changes each month but here is Decembers link:
> https://wiki.apache.org/incubator/December2018
>
> Sing-off are also welcome :-)
>
> Thanks,
> Justin
>
> -
> 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

[RESULT] [VOTE] Retire Quickstep podling from Apache Incubator

[Roman Shaposhnik]

On Tue, Nov 27, 2018 at 4:03 PM Roman Shaposhnik  wrote:
>
> Hi!
>
> after a discussion with the Quickstep community:
>  
> https://lists.apache.org/thread.html/6c4998e6feaec2651511a0d461d45924847135b60aa00e084301bc59@%3Cdev.quickstep.apache.org%3E
> and a formal passing vote:
>  
> https://lists.apache.org/thread.html/e0e759c1ae95a46b00aad9a44ddaaf6a007039029bc0a3167381e328@%3Cprivate.quickstep.apache.org%3E
>
> I would like to call an IPMC VOTE on the following proposal:
>
> Given the lack of community participation in moving
> Apache Quickstep (incubating) towards graduation we
> are proposing to retire the project from the Apache Incubator.
>
> The project can continue existing on GitHub as an ALv2 licensed
> open source project but will stop being affiliated with an Apache
> Software Foundation.
>
> [ ] +1 Retire Quickstep from the Incubator.
> [ ] +0 Don't care.
> [ ] -1 Don't retire Quickstep from the Incubator because...
>
> The vote will be open for at least 72 hours.

With 7 binding +1 votes, 1 non-binding +1 vote and 0 votes of any other kind
this vote PASSES.

Thanks to everyone who voted. Here's a vote tally:

Binding +1s:
   Roman Shaposhnik
   Dave Fisher
   Julian Hyde
   Willem Jiang
   Sheng Wu
   Furkan Kamaci
   Jean-Baptiste Onofré

Non-binding +1:
   Liang Chen

Thanks,
Roman.

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

Re: [VOTE] Retire Quickstep podling from Apache Incubator

[Roman Shaposhnik]

On Tue, Nov 27, 2018 at 4:03 PM Roman Shaposhnik  wrote:
>
> Hi!
>
> after a discussion with the Quickstep community:
>  
> https://lists.apache.org/thread.html/6c4998e6feaec2651511a0d461d45924847135b60aa00e084301bc59@%3Cdev.quickstep.apache.org%3E
> and a formal passing vote:
>  
> https://lists.apache.org/thread.html/e0e759c1ae95a46b00aad9a44ddaaf6a007039029bc0a3167381e328@%3Cprivate.quickstep.apache.org%3E
>
> I would like to call an IPMC VOTE on the following proposal:
>
> Given the lack of community participation in moving
> Apache Quickstep (incubating) towards graduation we
> are proposing to retire the project from the Apache Incubator.
>
> The project can continue existing on GitHub as an ALv2 licensed
> open source project but will stop being affiliated with an Apache
> Software Foundation.
>
> [ ] +1 Retire Quickstep from the Incubator.
> [ ] +0 Don't care.
> [ ] -1 Don't retire Quickstep from the Incubator because...

+1 (binding)

Thanks,
Roman (mentor of Apache Quickstep [incubating]))

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

[VOTE] Retire Quickstep podling from Apache Incubator

[Roman Shaposhnik]

Hi!

after a discussion with the Quickstep community:
 
https://lists.apache.org/thread.html/6c4998e6feaec2651511a0d461d45924847135b60aa00e084301bc59@%3Cdev.quickstep.apache.org%3E
and a formal passing vote:
 
https://lists.apache.org/thread.html/e0e759c1ae95a46b00aad9a44ddaaf6a007039029bc0a3167381e328@%3Cprivate.quickstep.apache.org%3E

I would like to call an IPMC VOTE on the following proposal:

Given the lack of community participation in moving
Apache Quickstep (incubating) towards graduation we
are proposing to retire the project from the Apache Incubator.

The project can continue existing on GitHub as an ALv2 licensed
open source project but will stop being affiliated with an Apache
Software Foundation.

[ ] +1 Retire Quickstep from the Incubator.
[ ] +0 Don't care.
[ ] -1 Don't retire Quickstep from the Incubator because...

The vote will be open for at least 72 hours.

Thanks,
Roman.

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

Re: How to review so-called "binary releases"?

[Roman Shaposhnik]

On Fri, Nov 16, 2018 at 6:59 AM Jim Jagielski  wrote:
>
>
>
> > On Nov 15, 2018, at 2:41 AM, Bertrand Delacretaz 
> >  wrote:
> >
> >
> > I see this as a two-level thing:
> >
> > a) The source release is an Act of the Foundation, it is what the
> > foundation produces
> >
> > b) For the binaries, the PMC states that it thinks they are good and
> > declares that the published digests and signatures are the correct
> > ones. The Foundation does not state anything about them - use at your
> > own risk but in practice that risk is very low if the PMC members
> > collectively recommend using them.
> >
> > That's not very different from what other open source projects do - we
> > need a) for our legal shield but b) is exactly like random open source
> > projects operate.
> >
> > You have to trust an open source project when you use their binaries,
> > and you can use digests and signatures to verify that those binaries
> > are the same that everyone else uses - I don't think anyone provides
> > more guarantees than that, except when you pay for someone to state
> > that those binaries are good.
> >
> > If people agree with this view we might need to explain this better,
> > "unofficial" does not mean much, this two-level view might be more
> > useful.
>
> Agree 100%. Thx for very clearly and accurately describing all this.

+1 to this as well.

In fact, I love it so much that I'd like to have it published as part of our
official guide:
   http://www.apache.org/legal/release-policy.html#compiled-packages

Any objections?

Thanks,
Roman.

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

Re: How to review so-called "binary releases"?

[Roman Shaposhnik]

Personally, given the amount of binary releases that are distributed off of
our very own infrastructure (and I'm not even counting our namespace
on things like Docker hub -- I'm just talking about the INFRA we run) I don't
think that the argument "binary releases are NOT endorsed by ASF" will
fly very far.

I think the best defense for us is to, perhaps, position them as UGC, but
given the practices around existing PMC I don't think that would be easy to
do.

So the question really boils down to -- how much of a liability this could
potentially be for us?


Thanks,
Roman.
On Tue, Nov 6, 2018 at 4:55 PM Daniel Shahaf  wrote:
>
> CC += legal-discuss@ since this really isn't an incubator-specific topic any
> more.  The context is precompiled binary artifacts on
> https://www.apache.org/dist/.
>
> David Nalley wrote on Tue, Nov 06, 2018 at 17:06:50 -0500:
> > So let's assume a PMC (or PPMC) goes through the same process with
> > binaries in terms of reviewing, voting on, promoting, and publishing
> > to the world a binary release on behalf of the PMC and Foundation.
> > Binaries are published to the same location that source tar balls are
> > - are featured on download pages provided by the ASF. Perhaps even
> > with the situation being that people download the binary artifacts
> > from ASF resources tens of thousands, or maybe even millions of times
> > more frequently than the source tarballs.
> >
> > From that scenario I have some questions:
> >
> > 1. Would a reasonable person (or jury) suspend disbelief long enough
> > to consider our protestations that our 'releases' are source only, and
> > that as a Foundation we didn't release, propagate, promote, or
> > distribute the binaries in question? A rose by any other name.
> > 2. Should the Board be taking an active interest in projects (release
> > managers?) who promote and publish their binaries in this manner on
> > our hardware?
> > 3. Is lack of Board action tantamount to tacit approval of this
> > behavior? Can we really claim ignorance?
> > 4. Should Infrastructure be actively monitoring and removing binaries
> > which find their way to dist.a.o/archive.a.o - especially since our
> > header for dist.a.o says that the directories contain releases of
> > Apache software?
> > 5. Should we be alerting individual release managers that publishing
> > convenience binaries exposes them individually to liability?
>
> 6. What alternative can we offer to projects that want to distribute binaries?
> Can the RM upload precompiled binaries to his https://home.a.o/~availid/ 
> space?
> Can the project's download page link to them as the
> primary/canonical/recommended binaries?  Can the project's download page link
> to the RM's binaries as one alternative among many (compare
> https://subversion.apache.org/packages#windows)?
>
> -
> To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
> For additional commands, e-mail: general-h...@incubator.apache.org
>

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

Re: [PROPOSAL] Changing requirements for IPMC

[Roman Shaposhnik]

On Wed, Nov 7, 2018 at 1:28 AM Bertrand Delacretaz
 wrote:
>
> Hi,
>
> On Tue, Nov 6, 2018 at 9:20 AM Justin Mclean  wrote:
> > ...I propose this:
> >
> > If someone has done several of the following:
> > - has been involved in an incubating project from start to finish
> > - has been a release manager
> > - has assembled LICENSE and NOTICE files
> > - has reviewed and voted on releases
> > - has proposed or accepted committers/PPMC members
> >
> > Then they can ask the IPMC to join to IPMC by sending an email to private@ 
> > listing what they have been involved in...
>
> I like that, +1
>
> And maybe we should make sure each podling has at least one
> experienced mentor, that is one who has successfully brought other
> podlings to graduation, or a long-time ASF Member.

I like both the original idea (after all I, myself, was one such case -- an IPMC
member before an ASF member) and this idea of a mentor-in-training
for podlings.

+1 to both!

Thanks,
Roman.

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

[RESULT] [VOTE] Sharding-Sphere incubation proposal

[Roman Shaposhnik]

On Mon, Nov 5, 2018 at 10:41 PM Roman Shaposhnik  wrote:
>
> Hi!
>
> on behalf of Sharding-Sphere community, I'd like to call
> a VOTE to accept it into the Apache Incubator. The full
> proposal is available on the wiki:
> https://wiki.apache.org/incubator/ShardingSphereProposal
> and it is also attached below for your convenience.
>
> Please cast your vote:
>
>   [ ] +1, bring Sharding-Sphere into Incubator
>   [ ] +0, I don't care either way,
>   [ ] -1, do not bring Sharding-Sphere into Incubator, because...

With 7 +1 binding votes, 7 +1 non-binding votes and NO +/-0
or -1 votes, this VOTE passes. Thanks to everyone who voted!

Bellow is a voting tally:

Binding
  Craig Russell
  Justin Mclean
  Willem Jiang
  Matt Sicker
  Dave Fisher
  Benjamin Hindman
  Roman Shaposhnik

Non-binding
   Sheng Wu
   Xin Wang
   Von Gosling
   Bruno Mahé
   Zhang Liang
   XIAORUI Wang
   Raja Sundaram Ganesan

Thanks,
Roman.

> The vote will open at least for 72 hours.
>
> Thanks,
> Roman.
>
> = Abstract =
> Sharding-Sphere is an ecosystem of transparent distributed database
> middleware, focusing on data sharding, distributed transaction and
> database orchestration. It provides maximum compatibility for
> applications through Sharding-JDBC (a driver to implement JDBC) or
> Sharding-Proxy (a proxy to implement database protocol).
>
> = Proposal =
> With a large number of end users, Sharding-Sphere has a fairly huge
> community in China. It is also widely adopted by many
> [[http://shardingsphere.io/community/en/company/|companies and
> organizations]] as a solution to process their massive amounts of
> data.
>
> We believe that bringing Sharding-Sphere into Apache Software
> Foundation could advance development of a stronger and more diverse
> open source community.
>
> Dangdang submits this proposal to donate Sharding-Sphere's source
> codes and all related documentations to Apache Software Foundation.
> The codes are already under Apache License Version 2.0.
>
>   * Code base: https://github.com/sharding-sphere/sharding-sphere
>
>   * Web site: http://shardingsphere.io/
>
>   * Documentations: http://shardingsphere.io/document/current/
>
>   * Community: http://shardingsphere.io/community/
>
> = Background =
>
> Relational database hardly supports such huge amounts of data any more
> which has increased rapidly in recent years, but for reason of
> technique maturity, developers and DBAs still want to use it to
> persist core data.
>
> Sharding-Sphere was open sourced on Github in 2016. At the very
> beginning, Sharding-Sphere is just a JDBC driver for data sharding
> (name as Sharding-JDBC) at Dangdang internal framework; now it offers
> data sharding, distributed transaction and database orchestration.
> Besides JDBC, proxy to implement MySQL database protocol is also
> supported at present. Furthermore, our roadmap includes Proxy for
> PostgreSQL protocol, Sidecar model, data repica and elastic data
> scalability function as well.
>
> Due to the extension of project, we provide proxy model and sidecar
> model in addition to JDBC model. Therefore, we rename it to
> Sharding-Sphere by
> [[https://github.com/sharding-sphere/sharding-sphere/issues/788|a
> public vote]], which refers to a sharding ecosphere with
> Sharding-JDBC, Sharding-Proxy and Sharding Sidecar as its three
> sub-projects.
>
> Sharding-JDBC has won the
> [[http://www.oschina.net/project/top_cn_2016|TOP 20 most popular open
> source projects in China 2016]].
>
> = Rationale =
>
> Relational database still plays a very important role on current
> application system. The maturity of products and surrounding
> ecosystem, the friendliness of its data query and developers' and
> DBAs' mastery of it, cannot be completely replaced with other types of
> database in the near future. However, current relational database
> cannot support cloud native very well and it is not friendly to
> distributed system.
>
> It is the ultimate goal of Sharding-Sphere, which manages the
> databases scattering around the system, to make user use distributed
> databases as simply as using a single one.
>
> Without extra cost, Sharding-JDBC directly connects database with Java
> application to get the best performance.
>
> Sharding-Proxy is deployed as a stateless server and supports MySQL
> protocol at present. In the paper
> [[https://db.cs.cmu.edu/papers/2016/pavlo-newsql-sigmodrec2016.pdf|What’s
> Really New with NewSQL?]], three types of NewSQL are introduced, among
> which Sharding-Proxy is a Transparent Sharding Middleware.
>
> Sharding-Sidecar can be understood as a data panel in Service Mesh.
> The interaction between the application and the database provides a
>

Re: [VOTE] Sharding-Sphere incubation proposal

[Roman Shaposhnik]

On Mon, Nov 5, 2018 at 10:41 PM Roman Shaposhnik  wrote:
>
> Hi!
>
> on behalf of Sharding-Sphere community, I'd like to call
> a VOTE to accept it into the Apache Incubator. The full
> proposal is available on the wiki:
> https://wiki.apache.org/incubator/ShardingSphereProposal
> and it is also attached below for your convenience.
>
> Please cast your vote:
>
>   [ ] +1, bring Sharding-Sphere into Incubator
>   [ ] +0, I don't care either way,
>   [ ] -1, do not bring Sharding-Sphere into Incubator, because...

+1 (binding)

Thanks,
Roman.

> The vote will open at least for 72 hours.
>
> Thanks,
> Roman.
>
> = Abstract =
> Sharding-Sphere is an ecosystem of transparent distributed database
> middleware, focusing on data sharding, distributed transaction and
> database orchestration. It provides maximum compatibility for
> applications through Sharding-JDBC (a driver to implement JDBC) or
> Sharding-Proxy (a proxy to implement database protocol).
>
> = Proposal =
> With a large number of end users, Sharding-Sphere has a fairly huge
> community in China. It is also widely adopted by many
> [[http://shardingsphere.io/community/en/company/|companies and
> organizations]] as a solution to process their massive amounts of
> data.
>
> We believe that bringing Sharding-Sphere into Apache Software
> Foundation could advance development of a stronger and more diverse
> open source community.
>
> Dangdang submits this proposal to donate Sharding-Sphere's source
> codes and all related documentations to Apache Software Foundation.
> The codes are already under Apache License Version 2.0.
>
>   * Code base: https://github.com/sharding-sphere/sharding-sphere
>
>   * Web site: http://shardingsphere.io/
>
>   * Documentations: http://shardingsphere.io/document/current/
>
>   * Community: http://shardingsphere.io/community/
>
> = Background =
>
> Relational database hardly supports such huge amounts of data any more
> which has increased rapidly in recent years, but for reason of
> technique maturity, developers and DBAs still want to use it to
> persist core data.
>
> Sharding-Sphere was open sourced on Github in 2016. At the very
> beginning, Sharding-Sphere is just a JDBC driver for data sharding
> (name as Sharding-JDBC) at Dangdang internal framework; now it offers
> data sharding, distributed transaction and database orchestration.
> Besides JDBC, proxy to implement MySQL database protocol is also
> supported at present. Furthermore, our roadmap includes Proxy for
> PostgreSQL protocol, Sidecar model, data repica and elastic data
> scalability function as well.
>
> Due to the extension of project, we provide proxy model and sidecar
> model in addition to JDBC model. Therefore, we rename it to
> Sharding-Sphere by
> [[https://github.com/sharding-sphere/sharding-sphere/issues/788|a
> public vote]], which refers to a sharding ecosphere with
> Sharding-JDBC, Sharding-Proxy and Sharding Sidecar as its three
> sub-projects.
>
> Sharding-JDBC has won the
> [[http://www.oschina.net/project/top_cn_2016|TOP 20 most popular open
> source projects in China 2016]].
>
> = Rationale =
>
> Relational database still plays a very important role on current
> application system. The maturity of products and surrounding
> ecosystem, the friendliness of its data query and developers' and
> DBAs' mastery of it, cannot be completely replaced with other types of
> database in the near future. However, current relational database
> cannot support cloud native very well and it is not friendly to
> distributed system.
>
> It is the ultimate goal of Sharding-Sphere, which manages the
> databases scattering around the system, to make user use distributed
> databases as simply as using a single one.
>
> Without extra cost, Sharding-JDBC directly connects database with Java
> application to get the best performance.
>
> Sharding-Proxy is deployed as a stateless server and supports MySQL
> protocol at present. In the paper
> [[https://db.cs.cmu.edu/papers/2016/pavlo-newsql-sigmodrec2016.pdf|What’s
> Really New with NewSQL?]], three types of NewSQL are introduced, among
> which Sharding-Proxy is a Transparent Sharding Middleware.
>
> Sharding-Sidecar can be understood as a data panel in Service Mesh.
> The interaction between the application and the database provides a
> mesh layer. The concept of Database Mesh is similar to Service Mesh,
> and it focuses on how to connect data access applications to the
> database. Database Mesh will set up a huge grid system between
> applications and databases. Applications and databases need be placed
> in the grid system. They are all objects managed by the meshing layer.
>
> = 

Re: Champion Role is Only to Get a Podling Started

[Roman Shaposhnik]

On Mon, Nov 5, 2018 at 11:25 AM Dave Fisher  wrote:
>
> Hi Everyone, but especially mentors.
>
> I saw this email from a mentor on the Airflow dev list: [1]
>
> "The big list that *has* to be filled out and correct is here: 
> http://incubator.apache.org/projects/airflow.html 
>  This is usually done by 
> the Champion …"
>
> This is not correct. This work is to be done by Mentors maintaining the 
> podling status file.
>
> The PPMC should be handling the Maturity Model and Graduation Resolution with 
> Mentor’s help as needed.
>
> While the Champion may become a Mentor the Champion role finishes once the 
> podling is has been onboard to the Incubator.

+1. That's been my understanding as well.

Thanks,
Roman.

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

[VOTE] Sharding-Sphere incubation proposal

[Roman Shaposhnik]

-2.0
  * spring-boot-configuration-processor Apache-2.0
  * spring-boot-starter-test Apache-2.0
  * slf4j MIT
  * logback EPL-1.0
  * junit EPL-1.0
  * hamcrest BSD 3-clause
  * mockito MIT
  * h2 MPL-2.0/EPL-1.0
  * mysql GPL-2.0 Will remove before first apache release, use SPI instead of it
  * postgresql BSD
  * mssql-jdbc MIT
  * HikariCP Apache-2.0
  * ANTLR BSD
  * OpenTracing BSD

= Required Resources =
== Git Repositories ==
  * https://github.com/sharding-sphere/sharding-sphere.git
  * https://github.com/sharding-sphere/sharding-sphere-example.git
  * https://github.com/sharding-sphere/sharding-sphere-doc.git


== Issue Tracking ==

The community would like to continue using GitHub Issues.

== Continuous Integration tool ==
Travis

== Mailing Lists ==
  * Sharding-Sphere-dev: for development discussions
  * Sharding-Sphere-private: for PPMC discussions
  * Sharding-Sphere-notifications: for users notifications, and
notifications from GitHub

== Initial Committers ==
  * 张亮, Liang Zhang, zhangli...@apache.org
  * 曹昊, Hao Cao,
  * 吴晟, Sheng Wu, wush...@apache.org
  * 高洪涛, Hongtao Gao, hanahm...@apache.org
  * 张永伦, Yonglun Zhang
  * 潘娟, Juan Pan
  * 赵俊, Jun Zhao
  * 岳令, Ling Yue
  * 马晓光, Xiaoguang Ma
  * 陈清阳, QingYang Chen
  * 彭勇升, Yongsheng Peng, pen...@apache.org

== Affiliations ==
  * JD: Liang Zhang, Yonglun Zhang, Juan Pan, Jun Zhao
  * Dangdang: Hao Cao, Ling Yue
  * CHINA TELECOM Bestpay: QingYang Chen
  * Individuals: Sheng Wu, Hongtao Gao, Xiaoguang Ma

= Sponsors =
== Champion ==
  * Roman Shaposhnik (rvs at apache dot org)

== Mentors ==
  * Craig L Russell (clr at apache dot org)
  * Benjamin Hindman (benh at apache dot org)
  * Willem Ning Jiang (ningjiang at apache dot org)

== Sponsoring Entity ==
We are expecting the Apache Incubator could sponsor this project.

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

Re: [DISCUSS] Sharding-Sphere incubation proposal

[Roman Shaposhnik]

wn Risks =
> > > == Orphaned products ==
> > > Three development teams from JingDong, Dangdang and CHINA TELECOM Bestpay
> > > will spare no pains to work on Sharding-Sphere in the future with
> > > contributors from the growing community. Also, Sharding-Sphere is widely
> > > adopted in China by many [[
> > > http://shardingsphere.io/community/en/company/|companies and
> > > organizations]]. Thus, it is very unlikely that Sharding-Sphere becomes
> > > orphaned.
> > >
> > > == Inexperience with Open Source ==
> > >
> > > The current core developers all work for companies that have developed or
> > > contributed to many open source projects.
> > >
> > >  * Liang Zhang, PMC. He is the lead of two open source projects,
> > > Sharding-Sphere and Elastic-Job. Also Committer of Apache Dubbo
> > (Incubator).
> > >
> > >  * Sheng Wu, PMC. He is the PPMC and committer of Apache
> > > SkyWalking(Incubating), Apache Zipkin(Incubating) contributor, CNCF
> > > OpenTracing member. Also contributed a lot other open source projects.
> > >
> > >  * Hongtao Gao, PMC. He is the PPMC and committer of Apache
> > > SkyWalking(Incubating) too. Also contribute a lot of features of
> > > Elastic-Job.
> > >
> > > Therefore, we believe we have enough experience to deal with open source.
> > >
> > > == Homogenous Developers ==
> > > The current core developers work across a variety of organizations
> > > including Jingdong, Dangdang and CHINA TELECOM Bestpay; some individual
> > > developers are accepted as core developers of Sharding-Sphere as well.
> > > Considering that Sohu and Dataman have shown great interest in
> > > Sharding-Sphere, we plan to encourage them to contribute and invite them
> > as
> > > contributors to work together.
> > >
> > > == Reliance on Salaried Developers ==
> > > At present, three of the core developers are paid by their employer to
> > > contribute to Sharding-Sphere project. It is estimated that the
> > development
> > > of Sharding-Sphere will be continued with mainly salaried developers, and
> > > we will make efforts to attract more volunteers and grow the community.
> > >
> > > == Relationships with Other Apache Products ==
> > >
> > > An automatic prober of Sharding-Sphere is introduced into SkyWalking to
> > > send APM data, and SkyWalking also use Sharding-Sphere to persit tracing
> > > data. Saga provided by ServiceComb is adopted by Sharding-Sphere as one
> > of
> > > the distributed transaction processing engines. Sharding-Sphere
> > integrates
> > > Apache Zookeeper as one of the service registration/discovery mechanisms.
> > >
> > > == A Excessive Fascination with the Apache Brand ==
> > > We acknowledge the value and reputation that the Apache brand would bring
> > > to Sharding-Sphere. However, our primary interest is in the excellent
> > > community provided by Apache Software Foundation, in which all the
> > projects
> > > could gain stability for long-term development.
> > >
> > > = Documentation =
> > > A complete set of Sharding-Sphere documentations is provided on
> > > shardingsphere.io in both English and Simplified Chinese.
> > >
> > >  * [[http://shardingsphere.io/document/current/en/overview/|English]]
> > >  * [[http://shardingsphere.io/document/current/cn/overview/|Chinese]]
> > >
> > > = Initial Source =
> > > The project consists of three distinct codebases: core, example and
> > > document. The address of three existed git repositories are as follows:
> > >
> > >  * https://github.com/sharding-sphere/sharding-sphere
> > >  * https://github.com/sharding-sphere/sharding-sphere-example
> > >  * https://github.com/sharding-sphere/sharding-sphere-doc
> > >
> > > = Source and Intellectual Property Submission Plan =
> > > The codes are currently under Apache License Version 2.0 and have been
> > > verified to have no intellectual property or license issues before being
> > > released to open source by Dangdang in 2016. Dangdang will provide SGA
> > and
> > > all committers will sign ICLA after Sharding-Sphere is accepted into the
> > > Incubator.
> > >
> > > = External Dependencies =
> > >
> > > As all dependencies are managed using Apache Maven, none of the external
> > > libraries need to be packaged in a source distribution

Re: [VOTE] Accept Pinot into Apache Incubator

[Roman Shaposhnik]

Sorry for the belated reply -- was on a trip to China.

Yes, I'd love to be added as a mentor.

And, FWIW +1 on the proposal ;-)

Thanks,
Roman.
On Sun, Oct 14, 2018 at 11:23 PM kishore g  wrote:
>
> 72 hours have passed and the vote for accepting Pinot into Apache Incubator
> has passed with:
>
> 5 binding "+1" votes
> 2 non-binding "+1" votes
> No "0" or "-1" votes
>
> Binding Votes
>
>- Olivier Lamy
>- Carl Steinbach
>- Julian Hyde
>- William Jiang
>- Kevin A McGrail
>
>
> non-binding votes
>
>- Pierre Smits
>- Felix Cheung
>
>
> thanks,
> Kishore G
>
> On Sat, Oct 13, 2018 at 5:00 PM kishore g  wrote:
>
> > Thanks Justin. Would love to have Roman as the mentor. I will close the
> > vote and start the process.
> >
> > On Sat, Oct 13, 2018 at 3:31 PM Justin Mclean  wrote:
> >
> >> Hi,
> >>
> >> > Justin, I haven’t heard from anyone. We have Oliver and Jean so far. I
> >> can
> >> > sign up as a mentor if it’s must. I will be involved with the project
> >> > anyway.
> >>
> >> I spoke to Roman and he is interested in being a mentor, he is currently
> >> travelling so probably hasn’t had a chance to respond. He can be added
> >> after the vote, assuming you want him as a mentor  for your project.
> >>
> >> Thanks,
> >> Justin
> >> -
> >> 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: [Question] RE40 in Apache Maturity Model Assessment

[Roman Shaposhnik]

On Sun, Oct 7, 2018 at 6:23 AM 吴晟 Sheng Wu  wrote:
>
> Hi,
>
>
> I am doing Apache Maturity Model Assessment for SkyWalking, here is the 
> draft[1]. We have a question in our inside discussion[2].
>
>
>
> RE40
>
> Convenience binaries can be distributed alongside source code but they are 
> not Apache Releases -- they are just a convenience provided with no guarantee.
>
>
>
> Is this Convenience binaries means nightly release, or snapshot release? We 
> want to make sure the status we wrote is right.

First of all, an Apache Release means something that has undergone a PMC vote.
I doubt that you vote on everyone of your nightly or snapshot releases
at the PMC
level and hence they can NOT be considered a proper ASF release.

Coming back to your original question: convince binaries simply means
binaries that
PMC had a chance to vote on (just like they do for the source release). Once PMC
votes on a set of binary artifacts they are allowed to be distributed
as part of the
release and they are called "convenience binaries".

Thanks,
Roman.

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

[RESULT] [VOTE] Graduate Apache ServiceComb (incubating)

[Roman Shaposhnik]

On Tue, Sep 25, 2018 at 9:06 PM, Roman Shaposhnik  wrote:
> Hi!
>
> given that we've got only positive feedback on the DISCUSS
> thread I'd like to start an official VOTE thread now.
>
> Please vote on the resolution pasted below to graduate
> Apache ServiceComb from the incubator to the top level project.
>
> [ ] +1 Graduate Apache ServiceComb from the Incubator.
> [ ] +0 Don't care.
> [ ] -1 Don't graduate Apache ServiceComb from the Incubator because...
>
> This vote will be open for at least 72 hours.
>
> Many thanks to our mentors and everyone else for their support,
> Roman (on behalf of the Apache ServiceComb PPMC).
>
> ## Resolution to create a TLP from graduating Incubator podling
>
> X. Establish the Apache ServiceComb Project
>
> WHEREAS, the Board of Directors deems it to be in the best interests of
> the Foundation and consistent with the Foundation's purpose to establish
> a Project Management Committee charged with the creation and maintenance
> of open-source software, for distribution at no charge to the public,
> related to a microservice framework that provides a set of tools and
> components to make development and deployment of cloud applications
> easier.
>
> NOW, THEREFORE, BE IT RESOLVED, that a Project Management Committee
> (PMC), to be known as the "Apache ServiceComb Project", be and hereby is
> established pursuant to Bylaws of the Foundation; and be it further
>
> RESOLVED, that the Apache ServiceComb Project be and hereby is
> responsible for the creation and maintenance of software related to a
> microservice framework that provides a set of tools and components to
> make development and deployment of cloud applications easier; and be it
> further
>
> RESOLVED, that the office of "Vice President, Apache ServiceComb" be and
> hereby is created, the person holding such office to serve at the
> direction of the Board of Directors as the chair of the Apache
> ServiceComb Project, and to have primary responsibility for management
> of the projects within the scope of responsibility of the Apache
> ServiceComb Project; and be it further
>
> RESOLVED, that the persons listed immediately below be and hereby are
> appointed to serve as the initial members of the Apache ServiceComb
> Project:
>
> * Aray Chenchu Sukesh 
> * Bao Liu 
> * Eric Lee 
> * Jean-Baptiste Onofré 
> * Jimin Wu 
> * Linzhinan 
> * Mohammad Asif Siddiqui 
> * Qi Zhang 
> * Roman Shaposhnik 
> * Timothy Chen 
> * Willem Ning Jiang 
> * Yang Bo 
> * Yihua Cui 
> * Yin Xiang 
> * Zheng Feng 
> * zhengyangyong 
>
> NOW, THEREFORE, BE IT FURTHER RESOLVED, that Willem Ning Jiang be
> appointed to the office of Vice President, Apache ServiceComb, to serve
> in accordance with and subject to the direction of the Board of
> Directors and the Bylaws of the Foundation until death, resignation,
> retirement, removal or disqualification, or until a successor is
> appointed; and be it further
>
> RESOLVED, that the Apache ServiceComb Project be and hereby is tasked
> with the migration and rationalization of the Apache Incubator
> ServiceComb podling; and be it further
>
> RESOLVED, that all responsibilities pertaining to the Apache Incubator
> ServiceComb podling encumbered upon the Apache Incubator PMC are
> hereafter discharged.

With 16 +1 non-binding votes, 10 +1 binding votes and no -1 or +/-0 votes,
this vote PASSES. Thanks to everyone who voted. The vote tally is attached.

Non-binding:
Sheng Wu
Xin Wang
Liang Chen
Tan,Zhongyi
William Guo
Hao Chen
ShaoFeng Shi
Lionel Liu
Liu Guo
Zen Lin
Yang Bo
Li,De(BDG)
Mohammad Asif Siddiqui
Jimin Wu
Wjm Wjm
Huxing Zhang

Binding:
   Jean-Baptiste Onofré
   Willem Jiang
   Bertrand Delacretaz
   Timothy Chen
   Matt Sicker
   Dave Fisher
   Uma Gangumalla
   Luke Han
   Mick Semb Wever
   Roman Shaposhnik

Thanks,
Roman.

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

Re: [VOTE] Graduate Apache ServiceComb (incubating)

[Roman Shaposhnik]

On Tue, Sep 25, 2018 at 9:06 PM, Roman Shaposhnik  wrote:
> Hi!
>
> given that we've got only positive feedback on the DISCUSS
> thread I'd like to start an official VOTE thread now.
>
> Please vote on the resolution pasted below to graduate
> Apache ServiceComb from the incubator to the top level project.
>
> [ ] +1 Graduate Apache ServiceComb from the Incubator.
> [ ] +0 Don't care.
> [ ] -1 Don't graduate Apache ServiceComb from the Incubator because...

+1 (binding)

Thanks,
Roman.

>
> This vote will be open for at least 72 hours.
>
> Many thanks to our mentors and everyone else for their support,
> Roman (on behalf of the Apache ServiceComb PPMC).
>
> ## Resolution to create a TLP from graduating Incubator podling
>
> X. Establish the Apache ServiceComb Project
>
> WHEREAS, the Board of Directors deems it to be in the best interests of
> the Foundation and consistent with the Foundation's purpose to establish
> a Project Management Committee charged with the creation and maintenance
> of open-source software, for distribution at no charge to the public,
> related to a microservice framework that provides a set of tools and
> components to make development and deployment of cloud applications
> easier.
>
> NOW, THEREFORE, BE IT RESOLVED, that a Project Management Committee
> (PMC), to be known as the "Apache ServiceComb Project", be and hereby is
> established pursuant to Bylaws of the Foundation; and be it further
>
> RESOLVED, that the Apache ServiceComb Project be and hereby is
> responsible for the creation and maintenance of software related to a
> microservice framework that provides a set of tools and components to
> make development and deployment of cloud applications easier; and be it
> further
>
> RESOLVED, that the office of "Vice President, Apache ServiceComb" be and
> hereby is created, the person holding such office to serve at the
> direction of the Board of Directors as the chair of the Apache
> ServiceComb Project, and to have primary responsibility for management
> of the projects within the scope of responsibility of the Apache
> ServiceComb Project; and be it further
>
> RESOLVED, that the persons listed immediately below be and hereby are
> appointed to serve as the initial members of the Apache ServiceComb
> Project:
>
> * Aray Chenchu Sukesh 
> * Bao Liu 
> * Eric Lee 
> * Jean-Baptiste Onofré 
> * Jimin Wu 
> * Linzhinan 
> * Mohammad Asif Siddiqui 
> * Qi Zhang 
> * Roman Shaposhnik 
> * Timothy Chen 
> * Willem Ning Jiang 
> * Yang Bo 
> * Yihua Cui 
> * Yin Xiang 
> * Zheng Feng 
> * zhengyangyong 
>
> NOW, THEREFORE, BE IT FURTHER RESOLVED, that Willem Ning Jiang be
> appointed to the office of Vice President, Apache ServiceComb, to serve
> in accordance with and subject to the direction of the Board of
> Directors and the Bylaws of the Foundation until death, resignation,
> retirement, removal or disqualification, or until a successor is
> appointed; and be it further
>
> RESOLVED, that the Apache ServiceComb Project be and hereby is tasked
> with the migration and rationalization of the Apache Incubator
> ServiceComb podling; and be it further
>
> RESOLVED, that all responsibilities pertaining to the Apache Incubator
> ServiceComb podling encumbered upon the Apache Incubator PMC are
> hereafter discharged.

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

[VOTE] Graduate Apache ServiceComb (incubating)

[Roman Shaposhnik]

Hi!

given that we've got only positive feedback on the DISCUSS
thread I'd like to start an official VOTE thread now.

Please vote on the resolution pasted below to graduate
Apache ServiceComb from the incubator to the top level project.

[ ] +1 Graduate Apache ServiceComb from the Incubator.
[ ] +0 Don't care.
[ ] -1 Don't graduate Apache ServiceComb from the Incubator because...

This vote will be open for at least 72 hours.

Many thanks to our mentors and everyone else for their support,
Roman (on behalf of the Apache ServiceComb PPMC).

## Resolution to create a TLP from graduating Incubator podling

X. Establish the Apache ServiceComb Project

WHEREAS, the Board of Directors deems it to be in the best interests of
the Foundation and consistent with the Foundation's purpose to establish
a Project Management Committee charged with the creation and maintenance
of open-source software, for distribution at no charge to the public,
related to a microservice framework that provides a set of tools and
components to make development and deployment of cloud applications
easier.

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

RESOLVED, that the Apache ServiceComb Project be and hereby is
responsible for the creation and maintenance of software related to a
microservice framework that provides a set of tools and components to
make development and deployment of cloud applications easier; and be it
further

RESOLVED, that the office of "Vice President, Apache ServiceComb" be and
hereby is created, the person holding such office to serve at the
direction of the Board of Directors as the chair of the Apache
ServiceComb Project, and to have primary responsibility for management
of the projects within the scope of responsibility of the Apache
ServiceComb Project; and be it further

RESOLVED, that the persons listed immediately below be and hereby are
appointed to serve as the initial members of the Apache ServiceComb
Project:

* Aray Chenchu Sukesh 
* Bao Liu 
* Eric Lee 
* Jean-Baptiste Onofré 
* Jimin Wu 
* Linzhinan 
* Mohammad Asif Siddiqui 
* Qi Zhang 
* Roman Shaposhnik 
* Timothy Chen 
* Willem Ning Jiang 
* Yang Bo 
* Yihua Cui 
* Yin Xiang 
* Zheng Feng 
* zhengyangyong 

NOW, THEREFORE, BE IT FURTHER RESOLVED, that Willem Ning Jiang be
appointed to the office of Vice President, Apache ServiceComb, to serve
in accordance with and subject to the direction of the Board of
Directors and the Bylaws of the Foundation until death, resignation,
retirement, removal or disqualification, or until a successor is
appointed; and be it further

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

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

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

[DISCUSS] Graduate Apache Servicecomb (incubating) as a TLP

[Roman Shaposhnik]

Hi!

after an enthusiastic discussion with the community:
 
https://lists.apache.org/thread.html/3fe85fb22cd1fd2c4e4a2370c03a453448a1ea12735d1e136cae6e79@%3Cdev.servicecomb.apache.org%3E
culminating with a positive vote:
https://lists.apache.org/thread.html/53f73695f8b504d1ed52e837cff9b8877e98c8a9c88668fc25188aca@%3Cdev.servicecomb.apache.org%3E
we'd like to bring this to a discussing at the IPMC.

Please see the proposed resolution below and let us
know what do you think.

A few  stats to help with the discussion:

Now we have the developer team[3] from Huawei, Talend, Stealth,
Hyperpilot, RedHat, JingDong,Tencent, Syswin, PICC, Changhong,
Cainiao.

3300+ commits on development of three subproject.
1350+ PRs on the Github
171 contributors
800+ issues created
700+ issues resolved

dev has 113 subscribers
208 emails sent by 28 people, divided into 30 topics in last month

Please check out Apache Maturity Model Assessment for ServiceComb[4]
for more information.

[1]https://lists.apache.org/thread.html/8e59fef1a9eae9ee90808114b3abbdfdf8c6f24442d7575ee04f5100@%3Cdev.servicecomb.apache.org%3E
[2]https://lists.apache.org/thread.html/2d1e7f17f15fc8ec0d4d293798991e93127534be9cc13334336d228f@%3Cdev.servicecomb.apache.org%3E
[3]https://servicecomb.incubator.apache.org/developers/team/
[4]https://cwiki.apache.org/confluence/display/SERVICECOMB/Apache+Maturity+Model+Assessment+for+ServiceComb

Thanks,
Roman.

Establish the Apache ServiceComb Project

WHEREAS, the Board of Directors deems it to be in the best interests of
the Foundation and consistent with the Foundation's purpose to establish
a Project Management Committee charged with the creation and maintenance
of open-source software, for distribution at no charge to the public,
related to a microservice framework that provides a set of tools and
components to make development and deployment of cloud applications
easier.

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

RESOLVED, that the Apache ServiceComb Project be and hereby is
responsible for the creation and maintenance of software related to a
microservice framework that provides a set of tools and components to
make development and deployment of cloud applications easier; and be it
further

RESOLVED, that the office of "Vice President, Apache ServiceComb" be and
hereby is created, the person holding such office to serve at the
direction of the Board of Directors as the chair of the Apache
ServiceComb Project, and to have primary responsibility for management
of the projects within the scope of responsibility of the Apache
ServiceComb Project; and be it further

RESOLVED, that the persons listed immediately below be and hereby are
appointed to serve as the initial members of the Apache ServiceComb
Project:

* Aray Chenchu Sukesh 
* Bao Liu 
* Eric Lee 
* Jean-Baptiste Onofré 
* Jimin Wu 
* Linzhinan 
* Mohammad Asif Siddiqui 
* Qi Zhang 
* Roman Shaposhnik 
* Timothy Chen 
* Willem Ning Jiang 
* Yang Bo 
* Yihua Cui 
* Yin Xiang 
* Zheng Feng 
* zhengyangyong 

NOW, THEREFORE, BE IT FURTHER RESOLVED, that Willem Ning Jiang be
appointed to the office of Vice President, Apache ServiceComb, to serve
in accordance with and subject to the direction of the Board of
Directors and the Bylaws of the Foundation until death, resignation,
retirement, removal or disqualification, or until a successor is
appointed; and be it further

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

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

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

Re: Poddlings length of time in the incubator

[Roman Shaposhnik]

On Tue, Aug 28, 2018 at 10:22 PM, Greg Stein  wrote:
> On Tue, Aug 28, 2018 at 8:01 PM Roman Shaposhnik 
> wrote:
>>...
>
>> In the past we typically shied away from setting deadlines for certain
>> milestones in community development within podlings. This, in my view,
>> somewhat encouraged this phenomenon of an "eternal podling" (active
>> enough not to be in the attic, not active/ApacheWay'y enough to
>> graduate). I feel like Quickstep, for example, can exist in this state
>> indefinitely.
>
>
> I think there is/can/should be a different bar for TLPs "idle-ness", and
> that of a podling. A TLP has confirmed itself for operation/oversight, even
> when it may slow down. A podling hasn't had that confirmation, however.
>
> One of the more continual issues within the Incubator is the amount of
> mentor energy to "go around". It seems that if a podling has hit a dead
> end, then it is best for the Incubator (as a whole) to go ahead and retire
> it, and apply its energies to podlings that are making progress towards
> graduation.

True, but the other argument is that the process is self-throttling: the slower
the podling gets, the less energy it requires from the mentor
(although, I suppose
there's a "fixed energy cost" in chasing reports, etc. below which it
will never go).

Thanks,
Roman.

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

Re: Poddlings length of time in the incubator

[Roman Shaposhnik]

On Sun, Aug 26, 2018 at 1:40 PM, Julian Hyde  wrote:
> Regarding Quickstep. I am a mentor. (One mentor resigned earlier this
> year, but the other mentor, Roman, is sufficiently engaged.)
>
> I am concerned that Quickstep is not going to graduate. They are
> functioning well as an academic project, as evidenced by papers at top
> conferences[1], but all of their contributors are from the same
> university department. They have made a few efforts at community
> building, but do not seem to be building a user base, or attracting
> outside contributions.
>
> (Note that traffic for July and August is lower than usual, due to
> their contributors being in academia. Traffic on the dev list should
> pick up somewhat in September.)
>
> Embrace of Apache has been half-hearted. Note, for instance, that
> their twitter account [2] still references their pre-Apache home page
> [3] rather than their Apache page [4].
>
> Quickstep made their first release in March 2017 but have not made
> further releases. I am going encourage them to make a new release
> soon. That will stimulate some community activity. But I am dubious
> that this will attract outside contributors.

Basically, I'm +1 on every single point that Julian makes, but having
said this I'm unsure as to where can we go from here.

In the past we typically shied away from setting deadlines for certain
milestones in community development within podlings. This, in my view,
somewhat encouraged this phenomenon of an "eternal podling" (active
enough not to be in the attic, not active/ApacheWay'y enough to
graduate). I feel like Quickstep, for example, can exist in this state
indefinitely.


Thanks,
Roman.

> Julian
>
> [1] http://www.vldb.org/pvldb/vol11/p663-patel.pdf
>
> [2] https://twitter.com/ApacheQuickstep
>
> [3] http://quickstep.cs.wisc.edu/
>
> [4] http://quickstep.apache.org/
> On Sun, Aug 26, 2018 at 10:17 AM Mark Thomas  wrote:
>>
>> On 26/08/18 02:30, Justin Mclean wrote:
>> > Hi,
>> >
>> >> I’ve discussed this some on the ODF toolkit dev list. Development was 
>> >> recently moved to Git. The Incubator needs to decide if we will turnover 
>> >> the domains that were donated in 2011 by IBM(?) to the only consistent 
>> >> developer. If that is true then we can quickly let them retire, but 
>> >> survive on Github.
>> >
>> > I also saw you mentioned it in a previous incubator report for the 
>> > podling. What are the domain names in question? I think doing as you 
>> > suggested sounds like a good idea do you want to take that back to the 
>> > PPMC and discuss and/or vote on doing that.
>> >
>> > Any other IPMC members think differently?
>>
>> The podling PMC can make a recommendation but the decision to release a
>> domain name to a third party needs the approval of VP Brand Management.
>>
>> We also need to find the transfer agreements (if any) for those domains
>> to see what the ASF agreed to at the time of donation. It is not unheard
>> of for such agreements to include a clause that ownership reverts to the
>> donor if the podling does not graduate.
>>
>> Mark
>>
>> -
>> 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

[RESULT] [VOTE] Graduate Apache HAWQ (incubating)

[Roman Shaposhnik]

On Fri, Jul 27, 2018 at 7:13 PM, Roman Shaposhnik  wrote:
> Hi!
>
> after a very positive discussion in the HAWQ community
> and at the IPMC level:
>  
> https://lists.apache.org/thread.html/67a2d52ef29cbf9e93d8050ed0193cc110a919962dd92f8436b343b7@%3Cdev.hawq.apache.org%3E
>  
> https://lists.apache.org/thread.html/3a142d758ef5ae119e421071893615992ea5ee937b5d02007f5e@%3Cgeneral.incubator.apache.org%3E
>
> I'd like to bring the following resolution for a formal vote.
>
> Please vote on the resolution pasted below to graduate
> Apache HAWQ from the incubator to top level project.
>
> [ ] +1 Graduate Apache HAWQ from the Incubator.
> [ ] +0 Don't care.
> [ ] -1 Don't graduate Apache HAWQ from the Incubator because...
>
> This vote will be open for at least 72 hours.
>
> Many thanks to our mentors and everyone else for the support,
> Roman (on behalf of the Apache HAWQ PPMC).
>
> ## Resolution to create a TLP from graduating Incubator podling
>
> X. Establish the Apache HAWQ Project
>
>WHEREAS, the Board of Directors deems it to be in the best
>interests of the Foundation and consistent with the
>Foundation's purpose to establish a Project Management
>Committee charged with the creation and maintenance of
>open-source software, for distribution at no charge to
>the public, related to Hadoop native SQL query engine that
>combines the key technological advantages of MPP database
>with the scalability and convenience of Hadoop.
>
>NOW, THEREFORE, BE IT RESOLVED, that a Project Management
>Committee (PMC), to be known as the "Apache HAWQ Project",
>be and hereby is established pursuant to Bylaws of the
>Foundation; and be it further
>
>RESOLVED, that the Apache HAWQ Project be and hereby is
>responsible for the creation and maintenance of software
>related to Hadoop native SQL query engine that
>combines the key technological advantages of MPP database
>with the scalability and convenience of Hadoop;
>and be it further
>
>RESOLVED, that the office of "Vice President, Apache HAWQ" be
>and hereby is created, the person holding such office to
>serve at the direction of the Board of Directors as the chair
>of the Apache HAWQ Project, and to have primary responsibility
>for management of the projects within the scope of
>responsibility of the Apache HAWQ Project; and be it further
>
>RESOLVED, that the persons listed immediately below be and
>hereby are appointed to serve as the initial members of the
>Apache HAWQ Project:
>
> * Alan Gates   
> * Alexander Denissov   
> * Amy Bai  
> * Atri Sharma  
> * Bhuvnesh Chaudhary   
> * Bosco
> * Chunling Wang
> * David Yozie  
> * Ed Espino
> * Entong Shen  
> * Foyzur Rahman
> * Goden Yao
> * Gregory Chase
> * Hong Wu  
> * Hongxu Ma
> * Hubert Zhang 
> * Ivan Weng
> * Jesse Zhang  
> * Jiali Yao
> * Jun Aoki 
> * Kavinder Dhaliwal
> * Lav Jain 
> * Lei Chang
> * Lili Ma  
> * Lirong Jian  
> * Lisa Owen
> * Ming Li  
> * Mohamed Soliman  
> * Newton Alex  
> * Noa Horn 
> * Oleksandr Diachenko  
> * Paul Guo 
> * Radar Da Lei 
> * Roman Shaposhnik 
> * Ruilong Huo  
> * Shivram Mani 
> * Shubham Sharma   
> * Tushar Pednekar  
> * Venkatesh Raghavan   
> * Vineet Goel  
> * Wen Lin  
> * Xiang Sheng  
> * Yi Jin   
> * Zhanwei Wang 
> * Zhenglin Tao 
>
>NOW, THEREFORE, BE IT FURTHER RESOLVED, that Lei Chang
>be appointed to the office of Vice President, Apache HAWQ, to
>serve in accordance with and subject to the direction of the
>Board of Directors and the Bylaws of the Foundation until
>death, resignation, retirement, removal or disqualification,
>or until a successor is appointed; and be it further
>
>RESOLV

Re: [VOTE] Graduate Apache HAWQ (incubating)

[Roman Shaposhnik]

On Fri, Jul 27, 2018 at 7:13 PM, Roman Shaposhnik  wrote:
> Hi!
>
> after a very positive discussion in the HAWQ community
> and at the IPMC level:
>  
> https://lists.apache.org/thread.html/67a2d52ef29cbf9e93d8050ed0193cc110a919962dd92f8436b343b7@%3Cdev.hawq.apache.org%3E
>  
> https://lists.apache.org/thread.html/3a142d758ef5ae119e421071893615992ea5ee937b5d02007f5e@%3Cgeneral.incubator.apache.org%3E
>
> I'd like to bring the following resolution for a formal vote.
>
> Please vote on the resolution pasted below to graduate
> Apache HAWQ from the incubator to top level project.
>
> [ ] +1 Graduate Apache HAWQ from the Incubator.
> [ ] +0 Don't care.
> [ ] -1 Don't graduate Apache HAWQ from the Incubator because...

+1 (binding)

Thanks,
Roman.

>
> This vote will be open for at least 72 hours.
>
> Many thanks to our mentors and everyone else for the support,
> Roman (on behalf of the Apache HAWQ PPMC).
>
> ## Resolution to create a TLP from graduating Incubator podling
>
> X. Establish the Apache HAWQ Project
>
>WHEREAS, the Board of Directors deems it to be in the best
>interests of the Foundation and consistent with the
>Foundation's purpose to establish a Project Management
>Committee charged with the creation and maintenance of
>open-source software, for distribution at no charge to
>the public, related to Hadoop native SQL query engine that
>combines the key technological advantages of MPP database
>with the scalability and convenience of Hadoop.
>
>NOW, THEREFORE, BE IT RESOLVED, that a Project Management
>Committee (PMC), to be known as the "Apache HAWQ Project",
>be and hereby is established pursuant to Bylaws of the
>Foundation; and be it further
>
>RESOLVED, that the Apache HAWQ Project be and hereby is
>responsible for the creation and maintenance of software
>related to Hadoop native SQL query engine that
>combines the key technological advantages of MPP database
>with the scalability and convenience of Hadoop;
>and be it further
>
>RESOLVED, that the office of "Vice President, Apache HAWQ" be
>and hereby is created, the person holding such office to
>serve at the direction of the Board of Directors as the chair
>of the Apache HAWQ Project, and to have primary responsibility
>for management of the projects within the scope of
>responsibility of the Apache HAWQ Project; and be it further
>
>RESOLVED, that the persons listed immediately below be and
>hereby are appointed to serve as the initial members of the
>Apache HAWQ Project:
>
> * Alan Gates   
> * Alexander Denissov   
> * Amy Bai  
> * Atri Sharma  
> * Bhuvnesh Chaudhary   
> * Bosco
> * Chunling Wang
> * David Yozie  
> * Ed Espino
> * Entong Shen  
> * Foyzur Rahman
> * Goden Yao
> * Gregory Chase
> * Hong Wu  
> * Hongxu Ma
> * Hubert Zhang 
> * Ivan Weng
> * Jesse Zhang  
> * Jiali Yao
> * Jun Aoki 
> * Kavinder Dhaliwal
> * Lav Jain 
> * Lei Chang
> * Lili Ma  
> * Lirong Jian  
> * Lisa Owen
> * Ming Li  
> * Mohamed Soliman  
> * Newton Alex  
> * Noa Horn 
> * Oleksandr Diachenko  
> * Paul Guo 
> * Radar Da Lei 
> * Roman Shaposhnik 
> * Ruilong Huo  
> * Shivram Mani 
> * Shubham Sharma   
> * Tushar Pednekar  
> * Venkatesh Raghavan   
> * Vineet Goel  
> * Wen Lin  
> * Xiang Sheng  
> * Yi Jin   
> * Zhanwei Wang 
> * Zhenglin Tao 
>
>NOW, THEREFORE, BE IT FURTHER RESOLVED, that Lei Chang
>be appointed to the office of Vice President, Apache HAWQ, to
>serve in accordance with and subject to the direction of the
>Board of Directors and the Bylaws of the Foundation until
>death, resignation, retirement, removal or disqualification,
>or until a successor is appointed; an

[VOTE] Graduate Apache HAWQ (incubating)

[Roman Shaposhnik]

Hi!

after a very positive discussion in the HAWQ community
and at the IPMC level:
 
https://lists.apache.org/thread.html/67a2d52ef29cbf9e93d8050ed0193cc110a919962dd92f8436b343b7@%3Cdev.hawq.apache.org%3E
 
https://lists.apache.org/thread.html/3a142d758ef5ae119e421071893615992ea5ee937b5d02007f5e@%3Cgeneral.incubator.apache.org%3E

I'd like to bring the following resolution for a formal vote.

Please vote on the resolution pasted below to graduate
Apache HAWQ from the incubator to top level project.

[ ] +1 Graduate Apache HAWQ from the Incubator.
[ ] +0 Don't care.
[ ] -1 Don't graduate Apache HAWQ from the Incubator because...

This vote will be open for at least 72 hours.

Many thanks to our mentors and everyone else for the support,
Roman (on behalf of the Apache HAWQ PPMC).

## Resolution to create a TLP from graduating Incubator podling

X. Establish the Apache HAWQ Project

   WHEREAS, the Board of Directors deems it to be in the best
   interests of the Foundation and consistent with the
   Foundation's purpose to establish a Project Management
   Committee charged with the creation and maintenance of
   open-source software, for distribution at no charge to
   the public, related to Hadoop native SQL query engine that
   combines the key technological advantages of MPP database
   with the scalability and convenience of Hadoop.

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

   RESOLVED, that the Apache HAWQ Project be and hereby is
   responsible for the creation and maintenance of software
   related to Hadoop native SQL query engine that
   combines the key technological advantages of MPP database
   with the scalability and convenience of Hadoop;
   and be it further

   RESOLVED, that the office of "Vice President, Apache HAWQ" be
   and hereby is created, the person holding such office to
   serve at the direction of the Board of Directors as the chair
   of the Apache HAWQ Project, and to have primary responsibility
   for management of the projects within the scope of
   responsibility of the Apache HAWQ Project; and be it further

   RESOLVED, that the persons listed immediately below be and
   hereby are appointed to serve as the initial members of the
   Apache HAWQ Project:

* Alan Gates   
* Alexander Denissov   
* Amy Bai  
* Atri Sharma  
* Bhuvnesh Chaudhary   
* Bosco
* Chunling Wang
* David Yozie  
* Ed Espino
* Entong Shen  
* Foyzur Rahman
* Goden Yao
* Gregory Chase
* Hong Wu  
* Hongxu Ma
* Hubert Zhang 
* Ivan Weng
* Jesse Zhang  
* Jiali Yao
* Jun Aoki 
* Kavinder Dhaliwal
* Lav Jain 
* Lei Chang
* Lili Ma  
* Lirong Jian  
* Lisa Owen
* Ming Li  
* Mohamed Soliman  
* Newton Alex  
* Noa Horn 
* Oleksandr Diachenko  
* Paul Guo 
* Radar Da Lei     
    * Roman Shaposhnik 
* Ruilong Huo  
* Shivram Mani 
* Shubham Sharma   
* Tushar Pednekar  
* Venkatesh Raghavan   
* Vineet Goel  
* Wen Lin  
* Xiang Sheng  
* Yi Jin   
* Zhanwei Wang 
* Zhenglin Tao 

   NOW, THEREFORE, BE IT FURTHER RESOLVED, that Lei Chang
   be appointed to the office of Vice President, Apache HAWQ, to
   serve in accordance with and subject to the direction of the
   Board of Directors and the Bylaws of the Foundation until
   death, resignation, retirement, removal or disqualification,
   or until a successor is appointed; and be it further

   RESOLVED, that the initial Apache HAWQ PMC be and hereby is
   tasked with the creation of a set of bylaws intended to
   encourage open development and increased participation in the
   Apache HAWQ Project; and be it further

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

   RESOLVED, that all responsibilities pertaining to the Apache
   Incubator HAWQ podling encumbered upon the Apache Incubator
   Project are 

Re: [DISCUSS] Graduate Apache HAWQ (incubating) as a TLP

[Roman Shaposhnik]

It seems that the concerned raised around commercialization of HAWQ by
Oushu Inc have been fully addressed and no additional concerns have
been raised.

With that in mind, I plan to start an official vote over the weekend.

Thanks,
Roman.

On Fri, Jul 13, 2018 at 2:01 AM, Willem Jiang  wrote:
> Hi Radar,
>
> OK, I think I got the answer.
>
>
> Willem Jiang
>
> Twitter: willemjiang
> Weibo: 姜宁willem
>
> On Fri, Jul 13, 2018 at 2:14 PM, Radar Lei  wrote:
>
>> Hi Willem,
>>
>> I did a check but didn't find the '12 PPMC member' is mentioned, would you
>> specify which report it is in? The only similar one I found is we mentioned
>> 'HAWQ New Committers (12)' in ASF Maturity Evaluation
>> <https://cwiki.apache.org/confluence/display/HAWQ/ASF+Maturity+Evaluation
>> >.
>>
>> For the PMC size 45, we make the proposal because of the total committer
>> number 45 is pretty close with current PPMC member number 38, so we chose
>> to make the PMC=Committers as the graduation resolution.
>>
>> Hope this answers your question. Thanks.
>>
>>
>> Regards,
>> Radar
>>
>> On Thu, Jul 12, 2018 at 9:22 AM, Willem Jiang 
>> wrote:
>>
>> > Just a quick question for the PMC size 45.
>> > From the report, I can see there are 12 PPMC member, but the PMC size is
>> > same with the Committer size.
>> > I guess that could be a typo, am I right?
>> >
>> >
>> >
>> >
>> > Willem Jiang
>> >
>> > Twitter: willemjiang
>> > Weibo: 姜宁willem
>> >
>> > On Fri, Jul 6, 2018 at 9:54 AM, Roman Shaposhnik  wrote:
>> >
>> > > Hi!
>> > >
>> > > HAWQ community seems to be ready to graduate. What
>> > > do fellow IPMC members think?
>> > >
>> > > Details on the community are below and here's a link to
>> > > the DISCUSS thread:
>> > > https://lists.apache.org/thread.html/
>> 67a2d52ef29cbf9e93d8050ed0193c
>> > > c110a919962dd92f8436b343b7@%3Cdev.hawq.apache.org%3E
>> > >
>> > > Thanks,
>> > > Roman.
>> > >
>> > > -- Forwarded message --
>> > > From: Radar Lei 
>> > > Date: Tue, Jun 19, 2018 at 2:40 AM
>> > > Subject: [DISCUSS] Graduate Apache HAWQ (incubating) as a TLP
>> > > To: dev 
>> > >
>> > >
>> > > Hi All,
>> > >
>> > > With the 2.3.0.0-incubating release officially out, the Apache HAWQ
>> > > community and its mentors believe it is time to consider graduation to
>> > the
>> > > TLP:
>> > > https://lists.apache.org/thread.html/b4a0b5671ce377b3d51c9b7
>> > > ab00496a1eebfcbf1696ce8b67e078c64@%3Cdev.hawq.apache.org%3E
>> > >
>> > > Apache HAWQ entered incubation in September of 2015, since then, the
>> HAWQ
>> > > community learned a lot about how to do things in Apache ways. Now we
>> > have
>> > > a healthy and engaged community, ready to help with all questions from
>> > the
>> > > HAWQ community. We delivered four releases including two binary
>> releases,
>> > > now we can do self-driving releases in good cadence. The PPMC has
>> > > demonstrated a good understanding of growing the community by electing
>> 12
>> > > individuals as committers and PPMC members. The PPMC addressed the
>> > maturity
>> > > issues one by one followed by Apache Project Maturity Model, currently
>> > all
>> > > the License and IP issues are resolved. This demonstrated our
>> > understanding
>> > > of ASF's IP policies.
>> > >
>> > > All in all, I believe this project is qualified as a true TLP and we
>> > should
>> > > recognize this fact by formally awarding it such a status. This thread
>> > > means to open up the very same discussion that we had among the mentors
>> > and
>> > > HAWQ community to the rest of the IPMC. It is a DISCUSS thread so feel
>> > free
>> > > to ask questions.
>> > >
>> > > To get you all going, here are a few data points which may help:
>> > >
>> > > Project status:
>> > >  http://incubator.apache.org/projects/hawq.html
>> > >
>> > > Project website:
>> > >   http://hawq.incubator.apache.org/
>> > >
>> > > Project documentation:
>> > >http://hawq.incubator.apache.or

[DISCUSS] Graduate Apache HAWQ (incubating) as a TLP

[Roman Shaposhnik]

hereby are appointed to serve as the initial members of the
   Apache HAWQ Project:

* Alan Gates   
* Alexander Denissov   
* Amy Bai  
* Atri Sharma  
* Bhuvnesh Chaudhary   
* Bosco
* Chunling Wang
* David Yozie  
* Ed Espino
* Entong Shen  
* Foyzur Rahman
* Goden Yao
* Gregory Chase
* Hong Wu  
* Hongxu Ma
* Hubert Zhang 
* Ivan Weng
* Jesse Zhang  
* Jiali Yao
* Jun Aoki 
* Kavinder Dhaliwal
* Lav Jain 
* Lei Chang
* Lili Ma  
* Lirong Jian  
* Lisa Owen
* Ming Li  
* Mohamed Soliman  
* Newton Alex  
* Noa Horn 
* Oleksandr Diachenko  
* Paul Guo 
* Radar Da Lei     
    * Roman Shaposhnik 
* Ruilong Huo  
* Shivram Mani 
* Shubham Sharma   
* Tushar Pednekar  
* Venkatesh Raghavan   
* Vineet Goel  
* Wen Lin  
* Xiang Sheng  
* Yi Jin   
* Zhanwei Wang 
* Zhenglin Tao 

   NOW, THEREFORE, BE IT FURTHER RESOLVED, that Lei Chang
   be appointed to the office of Vice President, Apache HAWQ, to
   serve in accordance with and subject to the direction of the
   Board of Directors and the Bylaws of the Foundation until
   death, resignation, retirement, removal or disqualification,
   or until a successor is appointed; and be it further

   RESOLVED, that the initial Apache HAWQ PMC be and hereby is
   tasked with the creation of a set of bylaws intended to
   encourage open development and increased participation in the
   Apache HAWQ Project; and be it further

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

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

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

Re: Publishing Maven artifacts under third-party coordinates (was: Set up Nexus staging profile for Dubbo ...)

[Roman Shaposhnik]

On Thu, May 10, 2018 at 9:50 AM, Julian Hyde  wrote:
> In other words, there are several ways to prove that a binary release is 
> WRONG but (to Greg’s point) there is no way to prove it RIGHT.

That's actually a great way to put it.

> As a mentor, I strongly advise against podlings making binary releases, 
> especially for the first release.
> It’s difficult enough to get L correct for source releases, and when a 
> binary release is being make
> at the same time with necessarily different L, the PPMC tend to get 
> hopelessly confused.

Big +1 here. This is exactly what I advise my podlings as well.

Thanks,
Roman.

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

Re: Publishing Maven artifacts under third-party coordinates (was: Set up Nexus staging profile for Dubbo ...)

[Roman Shaposhnik]

On Thu, May 10, 2018 at 4:17 AM, sebb  wrote:
> On 10 May 2018 at 11:37, Greg Stein  wrote:
>> On Thu, May 10, 2018 at 3:31 AM, Huxing Zhang  wrote:
>>
>>> Hi,
>>>
>>> On Thu, May 10, 2018 at 3:59 PM, Willem Jiang 
>>> wrote:
>>> > Is there any plan for going through the vote process of Binary file?
>>>
>>> Yes, binaries will also go through the vote process.
>>
>>
>> No. It makes no sense.
>>
>> There is NO WAY to verify a binary. Even compiling from source to binary on
>> your machine, and trying to compare against a target binary will generally
>> fail since timestamps are embedded. Or maybe there are different compilers
>> being used.
>>
>> The Foundation *never* votes on binaries, because the Foundation DOES NOT
>> RELEASE BINARIES. The Foundation only votes/authorizes/releases source
>> code. REPEAT: only source code.
>>
>> Only source. Which is verifiable. Which has provenance.
>
> The LICENCE and NOTICE files that accompany the binary artifact are
> text, and IMO should be checked against the contents of the binary
> artifact.
> For example, if the binary bundles jars from other projects, the L
> need to agree with the bundled contents.

+1000! That has been a well established practice in the Incubator and
as such I see no reason not to keep following it.

In addition to that, a reasonable effort should be put into making sure
that the binary bundle doesn't drag in bits with incompatible licenses
(such as GPL). That's why verifying LICENSE in the binary bundle
is NOT a simple exersize of comparing it to the source bundle.

Thanks,
Roman.

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

Re: Inviting new committers to a podling

[Roman Shaposhnik]

On Mon, Apr 30, 2018 at 4:50 PM, Craig Russell  wrote:
> I would respectfully suggest that the PPMC guide section that describes how 
> to invite new committers and PPMC members is not adequate to the task.
>
> This is what I think is the relevant section of 
> https://incubator.apache.org/guides/ppmc.html :
>
> There are no ASF wide rules on how to decide when to make someone a 
> committer, podlings need to agree an approach that works for them. Some ASF 
> projects have a high bar requiring significant contributions before someone 
> is considered, other projects grant it more freely to anyone who shows 
> interest in contributing. Some projects use formal [DISCUSS] and [VOTE] 
> threads on the private mailing list, others use a more lazy consensus 
> approach. For more information see, commit access and the ASF How it Works 
> document, which explains meritocracy and roles.
>
> Once the decision has been made the proposer offers committership to the 
> nominee. If the nominee accepts the responsibility of being a committer for 
> the project, the nominee formally becomes an Apache committer.
>
> The proposer then asks an Incubator PMC member (typically one of the mentors) 
> to follow the documented procedures 
> http://www.apache.org/dev/pmc.html#newcommitter to complete the process. If 
> the nominee is already an Apache committer on another project, the Incubator 
> PMC member simply updates the SVN authorization settings to include the 
> nominee as a committer on the podling.

To me the biggest problem with the above is that it actually fails
to communicate the point that establishing these types of basic
principles of how to self-govern is, in fact, part of a succesful
incubation process.

As a community you may very well arrive at a process that's
very different from the rest of the ASF's TLPs, but it has to
be well understood. Worst possible thing for a community
is to keep changing these types of goal posts.

In addition to that -- it is a job of mentors to actually make
sure that a podling community converges on a reasonable process.

Now a few comments:

> I suggest that we look again at this section for these aspects:
>
> 1. We should document how we expect podlings to discuss, vote, and invite 
> committers and PPMC members. The paragraph describing how to decide on new 
> committers should be non-prescriptive with regard to the criteria, but 
> prescribe the process. If a podling doesn't want to follow the process of 
> discussing, voting, and inviting, it should explicitly document what it wants 
> to do so that its unique process can be incorporated into the project's 
> unique Project By-Laws. But most podlings will want to follow the processes 
> of most TLPs:
>
> a: discuss in private the desire to invite a new committer/PPMC member
> b: hold a vote in private, with +1, -1, +0 and -0
> c: end the vote when all PPMC members have voted, or at least 72 hours have 
> passed; with at least three binding (IPMC members) votes in favor, and no -1 
> votes

I agree in principle, but it all depends on how this is worded. Like I said
above -- I think it would be totally fine to tell the podling -- look how
the rest of the PMCs are functioning. At the same time -- I've had a
series of unfortunate experiences where anything that we write on
that page gets quoted back to you as immutable dogma. We should
avoid that.

Once again -- we really should make sure that mentors understand
that this is their responsibility to make sure these types of things
are understood by a PPMC (but, of course, something like this is
much easier said than done :-().

> 2. We should document the process in the guide and *not* refer to the page 
> that describes how PMCs invite new committers. The processes are different in 
> the case of podlings and it is simply confusing to mix them. Podlings 
> especially could use help with "standard" emails similar to those found here: 
> http://community.apache.org/newcommitter.html#new-committer-process

Big +1 here!

> 3. It is not obvious what the policy is for a podling to invite new 
> committers and PPMC members. I don't believe it should be the responsibility 
> of the podling to decide in isolation the process to invite new committers, 
> just as it is not the podlings' decision how to invite new PPMC members.

I actually don't quite understand this point. Care to elaborate?

Thanks,
Roman.

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

Re: Default webpages for new podlings

[Roman Shaposhnik]

On Tue, Apr 17, 2018 at 11:51 AM, sebb  wrote:
> On 17 April 2018 at 19:47, Greg Stein  wrote:
>> On Mon, Apr 16, 2018 at 8:57 PM, Dave Fisher  wrote:
>>>...
>>
>>> Greg - You know which project I’m thinking about - OpenOffice.org. (1) I
>>> can see a way to make Jekyll or something similar function for site
>>> generation. Since I did the migration in I ought to be able to migrate out.
>>> (2) The main challenge is that the CMS provides good in site patching by
>>> new contributors on page. Replacing that method of getting new contributors
>>> to easily provide patches is the hurdle AFAICT. Has Infra thought about a
>>> solution for this?
>>>
>>
>> The easiest solution is to place your site source into Git, specifically as
>> part of our "gitbox" program. That will allow for direct editing on
>> github.com. When the edits are saved, then buildbot or jenkins can pick up
>> the change, generate/save the site, and pubsub will pick up the
>> newly-generated change(s) to the site.
>
> How about creating a dummy podling site using this feature?

That, frankly, is an awesome idea!

Thanks,
Roman.

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

Re: Question about IP CLEARANCE

[Roman Shaposhnik]

On Mon, Apr 16, 2018 at 4:18 PM, Christopher  wrote:
> Two questions about IP CLEARANCE:
>
> There is a line item in the template for making sure that files are updated
> to reflect ASF copyright. Must this be done before the files are actually
> transferred to the receiving PMC, while still being hosted in the donating
> party's repository?

There's no requirement like that. You can transfer files into a branch and
do the clean up on ASF infrastructure. You will NOT be able to do releases
off of that branch, of course.

Thanks,
Roman.

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

Re: [DISCUSS] Absent mentors

[Roman Shaposhnik]

On Wed, Mar 28, 2018 at 4:15 PM, Ted Dunning  wrote:
> I think the problem is serious. I also think that signoff rate is a better
> metric in practice than it seems it would be.

That problem is indeed pretty serious and also pretty chronic.

As for the metric -- I really think that using mentor turnout on release
voting threads will serve us well.

> Adding the additional metric seems like a small step that could help.
>
> Being aggressive about removing non-mentors is a very good idea. It is best
> if mentors remove themselves, but it is imperative that the incubator has a
> realistic idea about how many mentors there really are.

Big +1 on the above. Perhaps if we:
   1. get a clear indication on release vote turnout (as part of
Incubator report)
   2. add to it the sign-off turnout

We can start at least nagging unresponsive mentors to begin
with and if behaviour doesn't improve -- suggest that podlings
start looking for a replacement.

Thanks,
Roman.

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

Re: [VOTE] Release Apache ServiceComb Service-Center (incubating) version 1.0.0-m1 - Second Attempt

[Roman Shaposhnik]

On Mon, Mar 19, 2018 at 9:24 PM, Mohammad Asif Siddiqui
 wrote:
> Hello All,
>
> This is a call for vote to release Apache ServiceComb Service-Center 
> (Incubating) version 1.0.0-m1
> Apache ServiceComb (Incubating) Community has voted and approved the release.
>
> Vote Thread : 
> https://lists.apache.org/thread.html/a69ff6228a961ea920a6189845d6d54fa3764acd0ab5e99c59ac18f1@%3Cdev.servicecomb.apache.org%3E
>
> Result Thread : 
> https://lists.apache.org/thread.html/9b2b6bdb5984dd721016eb673dee2df3a7dd5cf9c7470c1de5c76a02@%3Cdev.servicecomb.apache.org%3E
>
> Release Notes : 
> https://github.com/apache/incubator-servicecomb-service-center/blob/master/docs/release/releaseNotes.md
>
> Release Candidate : 
> https://dist.apache.org/repos/dist/dev/incubator/servicecomb/incubator-servicecomb-service-center/1.0.0-m1/
>
> Release Tag : 
> https://github.com/apache/incubator-servicecomb-service-center/releases/tag/1.0.0-m1
>
> Release CommitID : 94cea25ba55e763dbe23d0cd4a8da73e37a50539
>
> Keys to verify the Release Candidate : 
> https://dist.apache.org/repos/dist/dev/incubator/servicecomb/KEYS
>
> Guide to build the release from source : 
> https://github.com/apache/incubator-servicecomb-service-center/tree/master/scripts/release
>
> Voting will start now(Tuesday, March 20, 2018) and will remain open for next 
> 72 hours, Request all IPMC members to give their vote.
>
> [ ] +1 Release this package as 1.0.0-m1.
> [ ] +0 No Opinion.
> [ ] -1 Do not release this package because...

+1 (binding)

* checked hashes
* checked signatures
* checked binary artifacts
* compared release tarball to the tag
* checked LICENSE, NOTICE and DISCLAIMER

Thanks,
Roman.

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

Re: [VOTE] Release Apache ServiceComb Saga (incubating) version 0.1.0

[Roman Shaposhnik]

On Mon, Mar 19, 2018 at 9:41 PM, Mohammad Asif Siddiqui
 wrote:
> Hello All,
>
> This is a call for vote to release Apache ServiceComb Saga (Incubating) 
> version 0.1.0
>
> Apache ServiceComb (Incubating) Community has voted and approved the release.
>
> Vote Thread : 
> https://lists.apache.org/thread.html/46b2a639306ed5260f1aec5a3749eeb9112cc666069842e8aad1862d@%3Cdev.servicecomb.apache.org%3E
>
> Result Thread : 
> https://lists.apache.org/thread.html/1b60c2a2542b9a3358e16b8960c4f925fc7b3c25bc382771b97c5567@%3Cdev.servicecomb.apache.org%3E
>
> Release Notes : 
> https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12321626=12342353
>
> Release Candidate : 
> https://dist.apache.org/repos/dist/dev/incubator/servicecomb/incubator-servicecomb-saga/0.1.0/
>
> Staging Repo : 
> https://repository.apache.org/content/repositories/orgapacheservicecomb-1166
>
> Release Tag : 
> https://github.com/apache/incubator-servicecomb-saga/releases/tag/0.1.0
>
> Release CommitID : 708eec092988dfd4a5960ca5f232fb7421d5fbdd
>
> Keys to verify the Release Candidate : 
> https://dist.apache.org/repos/dist/dev/incubator/servicecomb/KEYS
>
> Voting will start now ( Tuesday, 20th March, 2018) and will remain open for 
> next 72 hours, We request all IPMC members to give their vote.
>
> [ ] +1 Release this package as 0.1.0
> [ ] +0 No Opinion
> [ ] -1 Do not release this package because

+1 (binding)

* checked hashes
* checked signatures
* compared tag to the tarball
* checked NOTICE, LICENSE and DISCLAIMER
* RAT plugin enabled

Thanks,
Roman.

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

Re: [VOTE]: Apache HAWQ 2.3.0.0-incubating Release

[Roman Shaposhnik]

+1 (binding)

* checked sigs and checksums
* checked licenses
* checked for archive matching git tag

Thanks,
Roman.


On Mon, Mar 12, 2018 at 12:21 PM, Konstantin Boudnik  wrote:
> +1 [biding]
>
> - signature check [ok]
> - checksum check [ok]
> - licenses check (RAT) [ok]
>
> I haven't tried to build it because of the complexity of the build
> process and multiplicity of the environment configurations. To lower
> the entry barrier, I would recommend the community to think how to
> wrap these steps into the build system. You can go as far as to
> provide an "official" toolchain for the project. In Bigtop, we even
> provide official Docker containers were people can start working with
> the project in under 2 minutes and without any need for additional
> error prone configuration steps.
> --
>   With regards,
> Konstantin (Cos) Boudnik
> 2CAC 8312 4870 D885 8616  6115 220F 6980 1F27 E622
>
> Disclaimer: Opinions expressed in this email are those of the author,
> and do not necessarily represent the views of any company the author
> might be affiliated with at the moment of writing.
>
>
> On Tue, Mar 6, 2018 at 6:56 PM, Yi JIN  wrote:
>> Hi IPMC members,
>>
>> The PPMC vote for the Apache HAWQ 2.3.0.0-incubating release has passed.
>> So I request IPMC now to vote on this release candidate. Thank you!
>>
>> The release page is here:
>> https://cwiki.apache.org/confluence/display/HAWQ/Apache+HAWQ+2.3.0.0-incubating+Release
>>
>> The PPMC vote thread is located here:
>> https://lists.apache.org/thread.html/fa5b41cd7461bd729146e10d8f7a54156c818f93e5a1160c42e76c79@%3Cdev.hawq.apache.org%3E
>>
>> The artifacts can be downloaded here:
>> https://dist.apache.org/repos/dist/dev/incubator/hawq/2.3.0.0-incubating.RC2/
>> The artifacts have been signed with Key : CE60F90D1333092A
>>
>> All JIRAs completed for this release are tagged with 'FixVersion
>> =2.3.0.0-incubating'
>> https://issues.apache.org/jira/secure/ReleaseNote.jspa?version=12340262=Html=12318826
>>
>> Please vote accordingly:
>> [ ] +1, accept as the official Apache HAWQ 2.3.0.0-incubating release
>> [ ] -1, do not accept as the official Apache HAWQ 2.3.0.0-incubating release
>> because...
>>
>> The vote will run for at least 72 hours.
>>
>> Best regards,
>> Yi Jin (yjin)
>
> -
> 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: Write access to incubator wiki

[Roman Shaposhnik]

Done!

On Tue, Mar 6, 2018 at 3:58 PM, Mark Thomas  wrote:
> Hi,
>
> Please grant 'markt' write access to the incubator wiki.
>
> Thanks,
>
> Mark
>
> -
> 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] Dr. Elephant Incubator Proposal

[Roman Shaposhnik]

On Tue, Mar 6, 2018 at 3:17 PM, Mike Drob  wrote:
> Why does Dr. Elephant make sense as a separate project instead of
> contributing to Hadoop directly?
>
> What is the relationship between Dr. Elephant and the (now seemingly
> defunct) Hadoop Vaidya?

A different way to ask the same question would be: how closely is it tied
to YARN as a scheduler? Does it support other schedulers (as in running
Spark on Mesos for example)?

Thanks,
Roman.

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

Re: [VOTE] Apache DataFu podling graduation

[Roman Shaposhnik]

On Wed, Feb 14, 2018 at 9:36 AM, Matthew Hayes  wrote:
> Hi all,
>
> I would like to open a vote for Apache DataFu's graduation from incubator.  
> The
> DataFu community previously voted on this back in July, 2017 and the vote
>  passed
> .
> Following this there was a discussion
> 
> on
> this list about graduation.  There were several pieces of feedback.  To
> summarize, there were:
>
> * Comments about the number of committers vs. proposed PMC size (here
> 
>  and here
> 
> )
> * Comments about the process for removing committers (here
> 
>  and here
> 
> )
> * Comments about the website, sha-512 extension, etc. (here
> 
> ).  DATAFU-131  was filed
> to address these.
>
> All of that feedback should now be addressed (see the bottom of this email
> for a more detailed summary than what follows).  The list of proposed PMC
> members has been updated in the graduation resolution to include 11
> individuals, which includes 10 of the current 14 committers.  The remaining
> committers declined to remain committers and join the PMC and upon
> graduation these individuals will no longer be committers.  However given
> their past contributions they would be welcomed back if they wished to
> become committers again in the future and contribute.  Following these
> updates another community vote was held in February 2018 to reaffirm
> graduation and this vote passed as well
> 
> .
>
> Given this, I would like to open a vote for Apache DataFu's graduation from
> incubator and becoming a top-level project.  The proposed graduation
> resolution can be found at https://cwiki.apache.org/confluence/display/
> DATAFU/Graduation+Resolution as well as at the bottom of this email.
>
> The vote will be open for 72 hours.
>
> [ ] +1 graduate DataFu to a TLP
> [ ] +0 no opinion
> [ ] -1 disapprove (and reason why)

+1 (binding)

Thanks,
Roman.

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