Re: [VOTE] Graduate Apache Ranger Project from the Incubator - Resending with additional mail distro

[Niclas Hedhman]

+1 (binding)

On Sat, Jan 7, 2017 at 6:29 AM, Owen O'Malley  wrote:

> +1 (binding)
>
> On Wed, Jan 4, 2017 at 5:15 PM, Balaji Ganesan  >
> wrote:
>
> > +1 Great to see the progress from the Ranger community.
> >
> > On Wed, Jan 4, 2017 at 4:54 PM, Suneel Marthi 
> wrote:
> >
> > > +1 binding
> > >
> > > On Wed, Jan 4, 2017 at 5:48 PM, Ramesh Mani 
> > wrote:
> > >
> > > > Dear Incubator members,
> > > >
> > > > Apache Ranger Project community has successfully released 0.6.2
> version
> > > > and with it there had been a lot of discussion within Apache Ranger
> > > > community to consider graduation to TLP. Apache Ranger entered into
> > > > incubation on 24th July 2014 and from this welcoming community had
> > done a
> > > > tremendous job in resolving various technical hurdles like
> refactoring
> > > the
> > > > project core model to  be service based, adding more Apache Hadoop
> > > > components like Apache YARN, Apache Storm, Apache Kafka, Apache Nifi,
> > > > Apache Ranger KMS into Ranger Authorizing  model for security and
> > making
> > > it
> > > > into a core product in the Apache Hadoop security space. PPMC has
> > > exhibited
> > > > a clear understanding of this growing apache community by electing  4
> > > > individuals as committers  and  inculding 22 individuals as
> > contributors
> > > to
> > > > the Apache Ranger project. PPMC also has done 8 successful releases
> > under
> > > > the guidance of mentors demonstrating their mastery over AFS’s IP
> > > policies.
> > > >
> > > > An voting was conducted within Apache Ranger Community to graduate
> > Apache
> > > > Ranger Project to Top Level Project. Vote passed with 16 +1 votes ,
> no
> > 0
> > > or
> > > > –1 votes.
> > > > http://mail-archives.apache.org/mod_mbox/incubator-ranger-
> > > > dev/201612.mbox/%3CD479D4C8.11E4E%25rmani%40hortonworks.com%3E
> > > >
> > > > Apache Ranger Project has shown a great perspective to become a true
> > TLP.
> > > > Following summary on the project reflects its accomplishment.
> > > >
> > > > Please vote on the Project resolution that is found in bottom to
> > graduate
> > > > Apache Ranger Project from Incubator to Top Level Project.
> > > >
> > > > [ ] +1 Graduate Apache Ranger from the Incubator.
> > > > [ ] +0 No opinion
> > > > [ ] -1 Don't graduate Apache Ranger from the Incubator ( please
> provide
> > > > the reason)
> > > >
> > > > This VOTE will be opened for next 72 hours.
> > > >
> > > > Thanks all Mentors and Apache Ranger Project members for their
> support
> > > and
> > > > contributions.
> > > >
> > > > Here is my vote +1 (binding)
> > > >
> > > > Project Summary:
> > > > =
> > > >
> > > > http://incubator.apache.org/projects/ranger.html
> > > >
> > > > Project website:
> > > > =
> > > >
> > > > http://ranger.incubator.apache.org incubator.apache.org/
> > >
> > > >
> > > > Project Documentation:
> > > > ===
> > > >
> > > > http://ranger.incubator.apache.org/index.html
> > > > http://ranger.incubator.apache.org/quick_start_guide.html
> > > > https://cwiki.apache.org/confluence/display/RANGER/Release+Folders
> > > >
> > > > Project maturity Assessment:
> > > > ===
> > > >
> > > > https://cwiki.apache.org/confluence/display/RANGER/
> > > > Apache+Ranger+Project+Ma
> > > > turity+Model
> > > >
> > > > Proposed PMC size: 17
> > > >
> > > > Total number of committers   : 14 members
> > > > Total number of contributors : 22 members
> > > >
> > > > PMC affiliation (* indicated chair)
> > > >
> > > > * Hortonworks (9)
> > > >Privacera (2)
> > > >BlueTalon (1)
> > > >Others(1)
> > > >
> > > > 1802 commits on develop
> > > > 22 contributors across all branches
> > > > Dev list averaged ~50 msgs/month in 2016
> > > > User list averaged ~40 msgs/month in 2016
> > > > 1208 issues created
> > > > 997 issues resolved
> > > >
> > > > Committer’s affiliation:
> > > > ===
> > > > Active:
> > > > Hortonworks
> > > > Talend
> > > > Freestone infotech
> > > > BlueTalon
> > > > eBay
> > > > Others
> > > >
> > > >
> > > > Apache Ranger Top Level Project Resolution:
> > > > 
> > > >
> > > > Establish the Apache Ranger 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 data management platform That provides real-time, consistent
> > access
> > > > to data-intensive applications throughout widely distributed cloud
> > > > architectures.
> > > >
> > > > NOW, THEREFORE, BE IT RESOLVED, that a Project Management Committee
> > > > (PMC), to 

Re: [VOTE] Drop incubating requirement of Maven artifacts

[Niclas Hedhman]

Pierre,
Where can I download or "consume" a project community? I would like to have
a local copy of it, right here. ;-)

Communities are living things, people, and not an immutable release
artifact. Incubation is not a release process, it is effectively an
education program for inexperienced people by experienced people, passing
the baton of collective knowledge. Sorry, but I simply fail to equate this
with the release process of "open source software for the public good", I
think the analogy is too thin.

Cheers

On Sat, Jan 7, 2017 at 4:42 AM, Pierre Smits  wrote:

> Nicolas, all,
>
> Despite your believes, you do release communities. Because the community is
> the incubating project. Only after the community meets the criteria of
> graduation a proposal is submitted, seconded by the IPMC and reviewed by
> the board. The community works the code during incubation until it
> consistently meets just one (small set) of the graduation criteria
> (compliance to ASF rules). But all the other aspects (community size,
> diversity and interaction) are far more important for the success, given
> the principle Community over Code.
>
> Otherwise, your suggestion to use the same standards for releasing as tlp
> (released communities) and the examples brought forward look very sound and
> acceptable.
>
> Best regards,
>
> Pierre Smits
>
> ORRTIZ.COM 
> OFBiz based solutions & services
>
> OFBiz Extensions Marketplace
> http://oem.ofbizci.net/oci-2/
>
> On Fri, Jan 6, 2017 at 1:37 AM, Niclas Hedhman  wrote:
>
> > Coming late to the party...
> >
> > This has been discussed, and contentious, since "forever". A long time
> ago,
> > there was a notion that a podling release was not an ASF release (which
> was
> > the main reason for the "incubating" marker in all release and support
> > artifacts. But that pendulum has swung in the opposite direction, and
> > podling releases are now expected to be at ASF TLP levels.
> >
> > Pierre pointed out that "incubating" refers to community and not code,
> but
> > we don't release a community, we release code. I think this is an
> important
> > fact.
> >
> > So, instead of tying the "incubating" marker to "incubating", I would
> favor
> > a system of marker(s) indicating the code maturity (incl legal). So, for
> a
> > podling release to be 1.2.3 (a la Groovy), the same release standard as
> > TLPs are applied, but allow "alpha", "rc" or similar markers for podlings
> > to "practice" releases. Probably not pushing those to mirrors, but
> > otherwise identical in "process" for podling to get their grips on the
> > release process.
> >
> > So, I am +1 with John's "something is broken" observation, although I
> also
> > agree with the many "-1"s that think there is value to the public here.
> >
> >
> > Cheers
> >
> > On Wed, Jan 4, 2017 at 7:47 PM, John D. Ament 
> > wrote:
> >
> > > I'll point out that this is a cancel thread..., I'm fine if people want
> > to
> > > continue chatting in here, but I started a new discussion on
> > > https://lists.apache.org/thread.html/15550f5bf622ae3070b558505c8a0f
> > > d0ce3b23df3012d57de8b6d9f3@%3Cgeneral.incubator.apache.org%3E
> > >
> > > I'll try to answer questions I saw pop up
> > >
> > > Mark Struberg: No, ignoring commons/log4j for a minute, other projects
> > > continue to work under legacy maven coordinates.  Includes one i
> already
> > > linked to - groovy, also freemarker, zest/polygene (a project that went
> > > straight to TLP).  There's neither foundation policy nor legal impact
> by
> > > using other very similar marks, especially when the project's name
> hasn't
> > > changed.  Publishing under "com.oracle.someProduct" would probably be
> bad
> > > from a marks standpoint since it shows as property of some other
> company,
> > > whereas former foundations or completely independent projects.  Plus,
> the
> > > way maven central works you own the entire tld, except for cases where
> > its
> > > a known third party publisher.  For instance, I own (personally) the
> > domain
> > > name ament.ws and have access to publish under maven coordinates
> > > ws.ament.*.  Github users have to request io.github.themselves
> > manually.  I
> > > assume that something similar exists between the ASF and Sonatype to
> > enable
> > > publishing under org.apache, and ensure that no one else can use
> > > org.apache.
> > >
> > > Pierre Smits: This is something I expected to be a hot topic.  So while
> > > 100% consensus isn't expected, a clear path forward is something to
> > expect,
> > > even if not everyone is happy about the outcome.  FWIW, there seem to
> be
> > 3
> > > different POVs (that I could identify) on those who were against the
> > idea:
> > >
> > > - Those who thought this was dropping -incubating from the Apache
> release
> > > archive.
> > > - Those who acknowledged that this was maven specific and felt it
> should
> > > continue as is.
> > > - 

Re: [DISCUSS] Proposing MXNet for the Apache Incubator

[Henri Yandell]

Thanks Joe - I've added you to the commiter list :)

On Fri, Jan 6, 2017 at 12:31 PM, Joe Spisak  wrote:

> Awesome!  Please sign me up as a committer - I've been working with Mu on
> MXNet (Amazon) and would love to get more involved with project!
>
> GitHub ID: jspisak
>
>
>
> Sent from Joe's iPhone
> -
> To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
> For additional commands, e-mail: general-h...@incubator.apache.org
>
>

Re: [DISCUSS] Proposing MXNet for the Apache Incubator

[Henri Yandell]

Thanks Markus - I've added you to the proposal :)

On Fri, Jan 6, 2017 at 9:20 AM, Markus Weimer  wrote:

> On 2017-01-05 9:12 PM, Henri Yandell wrote:
>
>> I'd like to propose a new incubator Apache MXNet podling.
>>
>
> Awesome! If you still need a mentor, feel free to sign me up!
>
> Markus
>
>
> -
> To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
> For additional commands, e-mail: general-h...@incubator.apache.org
>
>

Re: [DISCUSS] Proposing MXNet for the Apache Incubator

[Joe Spisak]

Awesome!  Please sign me up as a committer - I've been working with Mu on MXNet 
(Amazon) and would love to get more involved with project!

GitHub ID: jspisak 

Sent from Joe's iPhone

On 2017-01-06 08:44 (-0800), Henri Yandell wrote: 
> Understood. I saw that Greg had recently approved another podling to do> 
> this. Though, assuming approved, there will still need to be some infra> 
> headscratching on the 3,000 issues currently on the main dmlc/mxnet repo> 
> and how imports are best done :) The simplest would be to transfer the> 
> current repo as is over at GitHub - not sure if that's been done before.> 
> 
> On Thu, Jan 5, 2017 at 11:32 PM, Henry Saputra > 
> wrote:> 
> 
> > This is great news and I am looking forward to it =)> 
> >> 
> > According to proposal, the community want to stick with Github issues for> 
> > tracking issues and bugs?> 
> > I suppose this needs a nod by Greg Stein as rep from Apache Infra to> 
> > confirm that this is ok for incubation and how would it impact during> 
> > graduation.> 
> >> 
> > - Henry> 
> >> 
> > On Thu, Jan 5, 2017 at 9:12 PM, Henri Yandell  wrote:> 
> >> 
> > > Hello Incubator,> 
> > >> 
> > > I'd like to propose a new incubator Apache MXNet podling.> 
> > >> 
> > > The existing MXNet project (http://mxnet.io - 1.5 years old, 15> 
> > > committers,> 
> > > 200 contributors) is very interested in joining Apache. MXNet is an> 
> > > open-source deep learning framework that allows you to define, train, 
> > > and> 
> > > deploy deep neural networks on a wide array of devices, from cloud> 
> > > infrastructure to mobile devices.> 
> > >> 
> > > The wiki proposal page is located here:> 
> > >> 
> > > https://wiki.apache.org/incubator/MXNetProposal> 
> > >> 
> > > I've included the text below in case anyone wants to focus on parts of 
> > > it> 
> > > in a reply.> 
> > >> 
> > > Looking forward to your thoughts, and for lots of interested Apache> 
> > members> 
> > > to volunteer to mentor the project in addition to Sebastian and myself.> 
> > >> 
> > > Currently the list of committers is based on the current active coders,> 
> > so> 
> > > we're also very interested in hearing from anyone else who is interested> 
> > in> 
> > > working on the project, be they current or future contributor!> 
> > >> 
> > > Thanks,> 
> > >> 
> > > Hen> 
> > > On behalf of the MXNet project> 
> > >> 
> > > -> 
> > >> 
> > > = MXNet: Apache Incubator Proposal => 
> > >> 
> > > == Abstract ==> 
> > >> 
> > > MXNet is a Flexible and Efficient Library for Deep Learning> 
> > >> 
> > > == Proposal ==> 
> > >> 
> > > MXNet is an open-source deep learning framework that allows you to> 
> > define,> 
> > > train, and deploy deep neural networks on a wide array of devices, from> 
> > > cloud infrastructure to mobile devices. It is highly scalable, allowing> 
> > for> 
> > > fast model training, and supports a flexible programming model and> 
> > multiple> 
> > > languages. MXNet allows you to mix symbolic and imperative programming> 
> > > flavors to maximize both efficiency and productivity. MXNet is built on 
> > > a> 
> > > dynamic dependency scheduler that automatically parallelizes both> 
> > symbolic> 
> > > and imperative operations on the fly. A graph optimization layer on top> 
> > of> 
> > > that makes symbolic execution fast and memory efficient. The MXNet> 
> > library> 
> > > is portable and lightweight, and it scales to multiple GPUs and multiple> 
> > > machines.> 
> > >> 
> > > == Background ==> 
> > >> 
> > > Deep learning is a subset of Machine learning and refers to a class of> 
> > > algorithms that use a hierarchical approach with non-linearities to> 
> > > discover and learn representations within data. Deep Learning has> 
> > recently> 
> > > become very popular due to its applicability and advancement of domains> 
> > > such as Computer Vision, Speech Recognition, Natural Language> 
> > Understanding> 
> > > and Recommender Systems. With pervasive and cost effective cloud> 
> > computing,> 
> > > large labeled datasets and continued algorithmic innovation, Deep> 
> > Learning> 
> > > has become the one of the most popular classes of algorithms for machine> 
> > > learning practitioners in recent years.> 
> > >> 
> > > == Rational ==> 
> > >> 
> > > The adoption of deep learning is quickly expanding from initial deep> 
> > domain> 
> > > experts rooted in academia to data scientists and developers working to> 
> > > deploy intelligent services and products. Deep learning however has many> 
> > > challenges. These include model training time (which can take days to> 
> > > weeks), programmability (not everyone writes Python or C++ and like> 
> > > symbolic programming) and balancing production readiness (support for> 
> > > things like failover) with development flexibility (ability to program> 
> > > different ways, support for new operators and model types) and speed of> 
> > > execution (fast and scalable model training).  Other frameworks excel on> 
> > 

Re: [VOTE] Drop incubating requirement of Maven artifacts

[John D. Ament]

Jochen,


On Fri, Jan 6, 2017 at 3:56 PM Jochen Wiedmann 
wrote:

> -1
>
> Because I fail to see a problem with the current policy.
>

I'll point out this has already been canceled.  I'd ask you to bring your
questions to the related discuss thread.

https://lists.apache.org/thread.html/15550f5bf622ae3070b558505c8a0fd0ce3b23df3012d57de8b6d9f3@%3Cgeneral.incubator.apache.org%3E

John


>
>
> On Mon, Jan 2, 2017 at 6:22 PM, John D. Ament 
> wrote:
> > All,
> >
> > I'm calling to vote on a proposed policy change.  Current guide at [1]
> > indicates that maven artifacts should include incubator (or incubating)
> in
> > the version string of maven artifacts.  Its labeled as a best practice,
> not
> > a requirement and is not a policy followed on other repository management
> > tools (e.g. PyPi).
> >
> > I therefore push forward that the incubator will cease expecting
> java-based
> > projects to publish artifacts with "-incubating" in the version string,
> > with the understanding that:
> >
> > - Incubating is a term used to refer to a project's stability, not a
> > release's stability.  It is generally understood that incubating projects
> > are not necessarily immature, but may have a potential of failing to
> become
> > a TLP.
> > - Podling releases are endorsed, the podling itself is not endorsed.  We
> > will not approve releases that are blatantly against ASF policies.
> >
> >
> > [ ] +1 Drop the -incubator/-incubating expectation of maven projects
> > [ ] +/0
> > [ ] -1 Don't drop because
> >
> >
> > [1]:
> > http://incubator.apache.org/guides/release-java.html#best-practice-maven
>
>
>
> --
> The next time you hear: "Don't reinvent the wheel!"
>
>
> http://www.keystonedevelopment.co.uk/wp-content/uploads/2014/10/evolution-of-the-wheel-300x85.jpg
>
> -
> To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
> For additional commands, e-mail: general-h...@incubator.apache.org
>
>

Re: Write access to January report page

[John D. Ament]

Added, happy editing!

On Fri, Jan 6, 2017 at 3:16 PM Matt Rutkowski  wrote:

> Thanks Marvin,
>
> It appears my Incubator Wiki ID is already "MattRutkowski" (read-only
> access) if this is the one we can add to the ACLs for:
> https://wiki.apache.org/incubator/MattRutkowski
>
> Carlos is on vacation today and will ask him to send his ID hen he
> returns.
>
> Kind regards,
> Matt
>
>
>
> From:   Marvin Humphrey 
> To: "general@incubator.apache.org" 
> Date:   01/06/2017 12:00 PM
> Subject:Re: Write access to January report page
>
>
>
> On Fri, Jan 6, 2017 at 9:46 AM, Matt Rutkowski 
> wrote:
> > The OpenWhisk moderators would like to begin submitting status on behalf
> > of OpenWhisk, but have also found we do not have write access to the
> Wiki.
> >  Previously, our mentor Felix Meschberger provided this for our
> > first/initial report, but would like to help him to not be the sole
> > persons responsible.
> >
> > If you could please add myself, Matt Rutkowski, along with Carlos
> Santana
> > to the ContributorsGroup similarly (below) we would like to accept that
> > responsibility going forward on behalf of the podling.
>
> Happy to. What usernames do the two of you use to log into
> wiki.apache.org/incubator ? Are your usernames actually `Matt
> Rutkowski` and `Carlos Santana` (with the space in the middle)? That's
> possible but unusual, so please confirm.
>
> Marvin Humphrey
>
> -
> To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
> For additional commands, e-mail: general-h...@incubator.apache.org
>
>
>
>
>
>

Re: [VOTE] Graduate Apache Ranger Project from the Incubator - Resending with additional mail distro

[Owen O'Malley]

+1 (binding)

On Wed, Jan 4, 2017 at 5:15 PM, Balaji Ganesan 
wrote:

> +1 Great to see the progress from the Ranger community.
>
> On Wed, Jan 4, 2017 at 4:54 PM, Suneel Marthi  wrote:
>
> > +1 binding
> >
> > On Wed, Jan 4, 2017 at 5:48 PM, Ramesh Mani 
> wrote:
> >
> > > Dear Incubator members,
> > >
> > > Apache Ranger Project community has successfully released 0.6.2 version
> > > and with it there had been a lot of discussion within Apache Ranger
> > > community to consider graduation to TLP. Apache Ranger entered into
> > > incubation on 24th July 2014 and from this welcoming community had
> done a
> > > tremendous job in resolving various technical hurdles like refactoring
> > the
> > > project core model to  be service based, adding more Apache Hadoop
> > > components like Apache YARN, Apache Storm, Apache Kafka, Apache Nifi,
> > > Apache Ranger KMS into Ranger Authorizing  model for security and
> making
> > it
> > > into a core product in the Apache Hadoop security space. PPMC has
> > exhibited
> > > a clear understanding of this growing apache community by electing  4
> > > individuals as committers  and  inculding 22 individuals as
> contributors
> > to
> > > the Apache Ranger project. PPMC also has done 8 successful releases
> under
> > > the guidance of mentors demonstrating their mastery over AFS’s IP
> > policies.
> > >
> > > An voting was conducted within Apache Ranger Community to graduate
> Apache
> > > Ranger Project to Top Level Project. Vote passed with 16 +1 votes , no
> 0
> > or
> > > –1 votes.
> > > http://mail-archives.apache.org/mod_mbox/incubator-ranger-
> > > dev/201612.mbox/%3CD479D4C8.11E4E%25rmani%40hortonworks.com%3E
> > >
> > > Apache Ranger Project has shown a great perspective to become a true
> TLP.
> > > Following summary on the project reflects its accomplishment.
> > >
> > > Please vote on the Project resolution that is found in bottom to
> graduate
> > > Apache Ranger Project from Incubator to Top Level Project.
> > >
> > > [ ] +1 Graduate Apache Ranger from the Incubator.
> > > [ ] +0 No opinion
> > > [ ] -1 Don't graduate Apache Ranger from the Incubator ( please provide
> > > the reason)
> > >
> > > This VOTE will be opened for next 72 hours.
> > >
> > > Thanks all Mentors and Apache Ranger Project members for their support
> > and
> > > contributions.
> > >
> > > Here is my vote +1 (binding)
> > >
> > > Project Summary:
> > > =
> > >
> > > http://incubator.apache.org/projects/ranger.html
> > >
> > > Project website:
> > > =
> > >
> > > http://ranger.incubator.apache.org >
> > >
> > > Project Documentation:
> > > ===
> > >
> > > http://ranger.incubator.apache.org/index.html
> > > http://ranger.incubator.apache.org/quick_start_guide.html
> > > https://cwiki.apache.org/confluence/display/RANGER/Release+Folders
> > >
> > > Project maturity Assessment:
> > > ===
> > >
> > > https://cwiki.apache.org/confluence/display/RANGER/
> > > Apache+Ranger+Project+Ma
> > > turity+Model
> > >
> > > Proposed PMC size: 17
> > >
> > > Total number of committers   : 14 members
> > > Total number of contributors : 22 members
> > >
> > > PMC affiliation (* indicated chair)
> > >
> > > * Hortonworks (9)
> > >Privacera (2)
> > >BlueTalon (1)
> > >Others(1)
> > >
> > > 1802 commits on develop
> > > 22 contributors across all branches
> > > Dev list averaged ~50 msgs/month in 2016
> > > User list averaged ~40 msgs/month in 2016
> > > 1208 issues created
> > > 997 issues resolved
> > >
> > > Committer’s affiliation:
> > > ===
> > > Active:
> > > Hortonworks
> > > Talend
> > > Freestone infotech
> > > BlueTalon
> > > eBay
> > > Others
> > >
> > >
> > > Apache Ranger Top Level Project Resolution:
> > > 
> > >
> > > Establish the Apache Ranger 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 data management platform That provides real-time, consistent
> access
> > > to data-intensive applications throughout widely distributed cloud
> > > architectures.
> > >
> > > NOW, THEREFORE, BE IT RESOLVED, that a Project Management Committee
> > > (PMC), to be known as the "Apache Ranger Project", be and hereby is
> > > established pursuant to Bylaws of the Foundation; and be it further
> > >
> > > RESOLVED,that the Apache Ranger Project be and hereby is responsible
> for
> > > the creation and maintenance of software related to a data management
> > > platform that provides real-time, consistent access to data-intensive
> > > applications 

Re: [VOTE] Drop incubating requirement of Maven artifacts

[Jochen Wiedmann]

-1

Because I fail to see a problem with the current policy.


On Mon, Jan 2, 2017 at 6:22 PM, John D. Ament  wrote:
> All,
>
> I'm calling to vote on a proposed policy change.  Current guide at [1]
> indicates that maven artifacts should include incubator (or incubating) in
> the version string of maven artifacts.  Its labeled as a best practice, not
> a requirement and is not a policy followed on other repository management
> tools (e.g. PyPi).
>
> I therefore push forward that the incubator will cease expecting java-based
> projects to publish artifacts with "-incubating" in the version string,
> with the understanding that:
>
> - Incubating is a term used to refer to a project's stability, not a
> release's stability.  It is generally understood that incubating projects
> are not necessarily immature, but may have a potential of failing to become
> a TLP.
> - Podling releases are endorsed, the podling itself is not endorsed.  We
> will not approve releases that are blatantly against ASF policies.
>
>
> [ ] +1 Drop the -incubator/-incubating expectation of maven projects
> [ ] +/0
> [ ] -1 Don't drop because
>
>
> [1]:
> http://incubator.apache.org/guides/release-java.html#best-practice-maven



-- 
The next time you hear: "Don't reinvent the wheel!"

http://www.keystonedevelopment.co.uk/wp-content/uploads/2014/10/evolution-of-the-wheel-300x85.jpg

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

Re: [VOTE] Drop incubating requirement of Maven artifacts

[Pierre Smits]

Nicolas, all,

Despite your believes, you do release communities. Because the community is
the incubating project. Only after the community meets the criteria of
graduation a proposal is submitted, seconded by the IPMC and reviewed by
the board. The community works the code during incubation until it
consistently meets just one (small set) of the graduation criteria
(compliance to ASF rules). But all the other aspects (community size,
diversity and interaction) are far more important for the success, given
the principle Community over Code.

Otherwise, your suggestion to use the same standards for releasing as tlp
(released communities) and the examples brought forward look very sound and
acceptable.

Best regards,

Pierre Smits

ORRTIZ.COM 
OFBiz based solutions & services

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

On Fri, Jan 6, 2017 at 1:37 AM, Niclas Hedhman  wrote:

> Coming late to the party...
>
> This has been discussed, and contentious, since "forever". A long time ago,
> there was a notion that a podling release was not an ASF release (which was
> the main reason for the "incubating" marker in all release and support
> artifacts. But that pendulum has swung in the opposite direction, and
> podling releases are now expected to be at ASF TLP levels.
>
> Pierre pointed out that "incubating" refers to community and not code, but
> we don't release a community, we release code. I think this is an important
> fact.
>
> So, instead of tying the "incubating" marker to "incubating", I would favor
> a system of marker(s) indicating the code maturity (incl legal). So, for a
> podling release to be 1.2.3 (a la Groovy), the same release standard as
> TLPs are applied, but allow "alpha", "rc" or similar markers for podlings
> to "practice" releases. Probably not pushing those to mirrors, but
> otherwise identical in "process" for podling to get their grips on the
> release process.
>
> So, I am +1 with John's "something is broken" observation, although I also
> agree with the many "-1"s that think there is value to the public here.
>
>
> Cheers
>
> On Wed, Jan 4, 2017 at 7:47 PM, John D. Ament 
> wrote:
>
> > I'll point out that this is a cancel thread..., I'm fine if people want
> to
> > continue chatting in here, but I started a new discussion on
> > https://lists.apache.org/thread.html/15550f5bf622ae3070b558505c8a0f
> > d0ce3b23df3012d57de8b6d9f3@%3Cgeneral.incubator.apache.org%3E
> >
> > I'll try to answer questions I saw pop up
> >
> > Mark Struberg: No, ignoring commons/log4j for a minute, other projects
> > continue to work under legacy maven coordinates.  Includes one i already
> > linked to - groovy, also freemarker, zest/polygene (a project that went
> > straight to TLP).  There's neither foundation policy nor legal impact by
> > using other very similar marks, especially when the project's name hasn't
> > changed.  Publishing under "com.oracle.someProduct" would probably be bad
> > from a marks standpoint since it shows as property of some other company,
> > whereas former foundations or completely independent projects.  Plus, the
> > way maven central works you own the entire tld, except for cases where
> its
> > a known third party publisher.  For instance, I own (personally) the
> domain
> > name ament.ws and have access to publish under maven coordinates
> > ws.ament.*.  Github users have to request io.github.themselves
> manually.  I
> > assume that something similar exists between the ASF and Sonatype to
> enable
> > publishing under org.apache, and ensure that no one else can use
> > org.apache.
> >
> > Pierre Smits: This is something I expected to be a hot topic.  So while
> > 100% consensus isn't expected, a clear path forward is something to
> expect,
> > even if not everyone is happy about the outcome.  FWIW, there seem to be
> 3
> > different POVs (that I could identify) on those who were against the
> idea:
> >
> > - Those who thought this was dropping -incubating from the Apache release
> > archive.
> > - Those who acknowledged that this was maven specific and felt it should
> > continue as is.
> > - Those who acknowledged that this was currently maven specific and
> should
> > be made broader.
> >
> > John
> >
> >
> > On Wed, Jan 4, 2017 at 4:49 AM Martijn Dashorst <
> > martijn.dasho...@gmail.com>
> > wrote:
> >
> > > Late to the party, but having a long think about this is sometimes
> > > beneficial.
> > >
> > > +1 to drop the -incubator/-incubating version attachment for any
> > > artifacts (not just Maven).
> > >
> > > My reasoning is the following:
> > >
> > > Source code lives longer than any community. Long after a podling has
> > > gone through the incubator, the code remains. The releases remain. How
> > > a community conducts itself doesn't reflect on the released code. Code
> > > just exists.
> > >
> > > While it is important for current users coming to a project to know
> > > the status of 

Re: [DISCUSS] Proposing MXNet for the Apache Incubator

[Joe Spisak]

Awesome!  Please sign me up as a committer - I've been working with Mu on MXNet 
(Amazon) and would love to get more involved with project!

GitHub ID: jspisak 



Sent from Joe's iPhone
-
To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
For additional commands, e-mail: general-h...@incubator.apache.org

Re: Write access to January report page

[Matt Rutkowski]

Thanks Marvin,

It appears my Incubator Wiki ID is already "MattRutkowski" (read-only 
access) if this is the one we can add to the ACLs for:
https://wiki.apache.org/incubator/MattRutkowski

Carlos is on vacation today and will ask him to send his ID hen he 
returns.

Kind regards,
Matt 



From:   Marvin Humphrey 
To: "general@incubator.apache.org" 
Date:   01/06/2017 12:00 PM
Subject:Re: Write access to January report page



On Fri, Jan 6, 2017 at 9:46 AM, Matt Rutkowski  
wrote:
> The OpenWhisk moderators would like to begin submitting status on behalf
> of OpenWhisk, but have also found we do not have write access to the 
Wiki.
>  Previously, our mentor Felix Meschberger provided this for our
> first/initial report, but would like to help him to not be the sole
> persons responsible.
>
> If you could please add myself, Matt Rutkowski, along with Carlos 
Santana
> to the ContributorsGroup similarly (below) we would like to accept that
> responsibility going forward on behalf of the podling.

Happy to. What usernames do the two of you use to log into
wiki.apache.org/incubator ? Are your usernames actually `Matt
Rutkowski` and `Carlos Santana` (with the space in the middle)? That's
possible but unusual, so please confirm.

Marvin Humphrey

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

Re: [VOTE] Drop incubating requirement of Maven artifacts

[Jochen Theodorou]

On 06.01.2017 17:32, Wade Chandler wrote:
[]

It's not a big deal YET, but http://codehaus.org is not reachable anymore.


yes, Ben told me he does not want to give the domain away right now. 
When the time comes, he will think about donating it to the ASF. when 
this will be I do not know


[...]

Too many projects based off of
it. The domain is being donated to Apache though AFAIK, but still, end
users shouldn't have to change so many sources or break other dependencies,
which may not be using the new package names, just because the package
names are org.netbeans and someone thinks they should be
org.apache.netbeans unless there is a true legal reason, and that would be
rare, but a different email thread I imagine, but way more complicated than
just changing the package name in the case of Groovy or NetBeans because we
are talking about whole ecosystems and dependency graphs.


oh, it is not only the package name for Groovy, it is the maven group-id 
as well.


bye Jochen


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

Re: Write access to January report page

[Marvin Humphrey]

On Fri, Jan 6, 2017 at 9:46 AM, Matt Rutkowski  wrote:
> The OpenWhisk moderators would like to begin submitting status on behalf
> of OpenWhisk, but have also found we do not have write access to the Wiki.
>  Previously, our mentor Felix Meschberger provided this for our
> first/initial report, but would like to help him to not be the sole
> persons responsible.
>
> If you could please add myself, Matt Rutkowski, along with Carlos Santana
> to the ContributorsGroup similarly (below) we would like to accept that
> responsibility going forward on behalf of the podling.

Happy to. What usernames do the two of you use to log into
wiki.apache.org/incubator ? Are your usernames actually `Matt
Rutkowski` and `Carlos Santana` (with the space in the middle)? That's
possible but unusual, so please confirm.

Marvin Humphrey

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

Re: Write access to January report page

[Matt Rutkowski]

The OpenWhisk moderators would like to begin submitting status on behalf 
of OpenWhisk, but have also found we do not have write access to the Wiki. 
 Previously, our mentor Felix Meschberger provided this for our 
first/initial report, but would like to help him to not be the sole 
persons responsible.

If you could please add myself, Matt Rutkowski, along with Carlos Santana 
to the ContributorsGroup similarly (below) we would like to accept that 
responsibility going forward on behalf of the podling. 

Kind regards,
Matt Rutkowski





From:   Marvin Humphrey 
To: "general@incubator.apache.org" 
Date:   01/05/2017 02:12 PM
Subject:Re: Write access to January report page



On Thu, Jan 5, 2017 at 9:41 AM, jean-frederic clere  
wrote:
> On 01/05/2017 01:51 AM, Niclas Hedhman wrote:
>> Hi,
>> Isn't the https://wiki.apache.org/incubator/January2017 supposed to be
>> editable by Mentors/IPMC members?
>
> So I probably have a problem... JeanFredericClere my user can't edit it
> or is it too late?

I have added JeanFredericClere to ContributorsGroup, and you should
now be able to edit the wiki report page.

Marvin Humphrey

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

Re: [VOTE] Drop incubating requirement of Maven artifacts

[Cédric Champeau]

@wade it would be better to continue the discussion in the discuss vote,
rather than this vote which has been cancelled.

See
https://lists.apache.org/thread.html/15550f5bf622ae3070b558505c8a0fd0ce3b23df3012d57de8b6d9f3@%3Cgeneral.incubator.apache.org%3E

2017-01-06 17:32 GMT+01:00 Wade Chandler :

> On Jan 4, 2017 4:46 AM, "Jochen Theodorou"  wrote:
>
> On 04.01.2017 07:28, Mark Struberg wrote:
> [...]
>
> I'm a bit surprised that groovy still uses the org.codehaus groupId, but I
> > guess they have a deal with Ben (the former owner and thus (former?)
> > copyright holder of 'Codehaus').
> > So while this will work for now I guess that even groovy will move to
> > org.apache.groovy in the long term (maybe with a new major version).
> >
>
> A new major version is a big thing for Groovy, but yes. In our view it is
> the only realistic way, since people can expect breaking changes between
> major versions and that includes in our view package names as well as group
> ids.
>
>
> It's not a big deal YET, but http://codehaus.org is not reachable anymore.
> > And if anyone buys this domain he will have a much better position
> > regarding trademarks than we do.
> > What if someone buys the codehaus.org domain and publishes own artifacts
> > under org.codehaus.groovy? Can we even prevent someone else to e.g
> publish
> > org.codehaus.groovyng artifacts?
> >
>
> Assume we change and 2 months later somebody does that? How is the
> situation then any better?
>
> Actually I wonder if Ben would donate the domain to the ASF...
>
>
> This would be a huge deal for NetBeans too. Too many projects based off of
> it. The domain is being donated to Apache though AFAIK, but still, end
> users shouldn't have to change so many sources or break other dependencies,
> which may not be using the new package names, just because the package
> names are org.netbeans and someone thinks they should be
> org.apache.netbeans unless there is a true legal reason, and that would be
> rare, but a different email thread I imagine, but way more complicated than
> just changing the package name in the case of Groovy or NetBeans because we
> are talking about whole ecosystems and dependency graphs.
>
> Thanks
>
> Wade
>

Re: [DISCUSS] Proposing MXNet for the Apache Incubator

[Markus Weimer]

On 2017-01-05 9:12 PM, Henri Yandell wrote:

I'd like to propose a new incubator Apache MXNet podling.


Awesome! If you still need a mentor, feel free to sign me up!

Markus

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

Request to join IPMC

[Markus Weimer]

Hi,

I'm an Apache member and am already helping the Hivemall project as a 
mentor. It is about time I join the IPMC :)


Thanks,

Markus

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

Re: [DISCUSS] Proposing MXNet for the Apache Incubator

[Henri Yandell]

Understood. I saw that Greg had recently approved another podling to do
this. Though, assuming approved, there will still need to be some infra
headscratching on the 3,000 issues currently on the main dmlc/mxnet repo
and how imports are best done :) The simplest would be to transfer the
current repo as is over at GitHub - not sure if that's been done before.

On Thu, Jan 5, 2017 at 11:32 PM, Henry Saputra 
wrote:

> This is great news and I am looking forward to it =)
>
> According to proposal, the community want to stick with Github issues for
> tracking issues and bugs?
> I suppose this needs a nod by Greg Stein as rep from Apache Infra to
> confirm that this is ok for incubation and how would it impact during
> graduation.
>
> - Henry
>
> On Thu, Jan 5, 2017 at 9:12 PM, Henri Yandell  wrote:
>
> > Hello Incubator,
> >
> > I'd like to propose a new incubator Apache MXNet podling.
> >
> > The existing MXNet project (http://mxnet.io - 1.5 years old, 15
> > committers,
> > 200 contributors) is very interested in joining Apache. MXNet is an
> > open-source deep learning framework that allows you to define, train, and
> > deploy deep neural networks on a wide array of devices, from cloud
> > infrastructure to mobile devices.
> >
> > The wiki proposal page is located here:
> >
> >   https://wiki.apache.org/incubator/MXNetProposal
> >
> > I've included the text below in case anyone wants to focus on parts of it
> > in a reply.
> >
> > Looking forward to your thoughts, and for lots of interested Apache
> members
> > to volunteer to mentor the project in addition to Sebastian and myself.
> >
> > Currently the list of committers is based on the current active coders,
> so
> > we're also very interested in hearing from anyone else who is interested
> in
> > working on the project, be they current or future contributor!
> >
> > Thanks,
> >
> > Hen
> > On behalf of the MXNet project
> >
> > -
> >
> > = MXNet: Apache Incubator Proposal =
> >
> > == Abstract ==
> >
> > MXNet is a Flexible and Efficient Library for Deep Learning
> >
> > == Proposal ==
> >
> > MXNet is an open-source deep learning framework that allows you to
> define,
> > train, and deploy deep neural networks on a wide array of devices, from
> > cloud infrastructure to mobile devices. It is highly scalable, allowing
> for
> > fast model training, and supports a flexible programming model and
> multiple
> > languages. MXNet allows you to mix symbolic and imperative programming
> > flavors to maximize both efficiency and productivity. MXNet is built on a
> > dynamic dependency scheduler that automatically parallelizes both
> symbolic
> > and imperative operations on the fly. A graph optimization layer on top
> of
> > that makes symbolic execution fast and memory efficient. The MXNet
> library
> > is portable and lightweight, and it scales to multiple GPUs and multiple
> > machines.
> >
> > == Background ==
> >
> > Deep learning is a subset of Machine learning and refers to a class of
> > algorithms that use a hierarchical approach with non-linearities to
> > discover and learn representations within data. Deep Learning has
> recently
> > become very popular due to its applicability and advancement of domains
> > such as Computer Vision, Speech Recognition, Natural Language
> Understanding
> > and Recommender Systems. With pervasive and cost effective cloud
> computing,
> > large labeled datasets and continued algorithmic innovation, Deep
> Learning
> > has become the one of the most popular classes of algorithms for machine
> > learning practitioners in recent years.
> >
> > == Rational ==
> >
> > The adoption of deep learning is quickly expanding from initial deep
> domain
> > experts rooted in academia to data scientists and developers working to
> > deploy intelligent services and products. Deep learning however has many
> > challenges.  These include model training time (which can take days to
> > weeks), programmability (not everyone writes Python or C++ and like
> > symbolic programming) and balancing production readiness (support for
> > things like failover) with development flexibility (ability to program
> > different ways, support for new operators and model types) and speed of
> > execution (fast and scalable model training).  Other frameworks excel on
> > some but not all of these aspects.
> >
> >
> > == Initial Goals ==
> >
> > MXNet is a fairly established project on GitHub with its first code
> > contribution in April 2015 and roughly 200 contributors. It is used by
> > several large companies and some of the top research institutions on the
> > planet. Initial goals would be the following:
> >
> >  1. Move the existing codebase(s) to Apache
> >  1. Integrate with the Apache development process/sign CLAs
> >  1. Ensure all dependencies are compliant with Apache License version 2.0
> >  1. Incremental development and releases per Apache guidelines
> >  1. Establish engineering discipline 

Re: [DISCUSS] Proposing MXNet for the Apache Incubator

[Henri Yandell]

On Fri, Jan 6, 2017 at 3:52 AM, John D. Ament  wrote:

> There seem to be some discrepancies in the proposal vs what they currently
> have.  That and some comments in line.
>
> On Fri, Jan 6, 2017 at 12:12 AM Henri Yandell  wrote:
>
> > Hello Incubator,
> >
> > I'd like to propose a new incubator Apache MXNet podling.
> >
> > The existing MXNet project (http://mxnet.io - 1.5 years old, 15
> > committers,
> > 200 contributors) is very interested in joining Apache. MXNet is an
> > open-source deep learning framework that allows you to define, train, and
> > deploy deep neural networks on a wide array of devices, from cloud
> > infrastructure to mobile devices.
> >
>
> This seems to be a broad gap between committers and contributors.  Of the
> remaining 220 not included as committer, are they being considered?
>

Mu's contacting (and has been contacting) contributors to invite them; for
the proposal I went with the notion of the current active folk with write
access and having others introduce themselves. I suspect some are already
awaiting general@ moderators to pass their email through :)

>
> > The wiki proposal page is located here:
> >
> >   https://wiki.apache.org/incubator/MXNetProposal
> >
> >
> I've added it to the project proposals page.
>
>
*doh* Thank you :)


>
> > I've included the text below in case anyone wants to focus on parts of it
> > in a reply.
> >
> > Looking forward to your thoughts, and for lots of interested Apache
> members
> > to volunteer to mentor the project in addition to Sebastian and myself.
> >
> > Currently the list of committers is based on the current active coders,
> so
> > we're also very interested in hearing from anyone else who is interested
> in
> > working on the project, be they current or future contributor!
> >
> > Thanks,
> >
> > Hen
> > On behalf of the MXNet project
> >
> > -
> >
> > = MXNet: Apache Incubator Proposal =
> >
>
>



> >
> > === Core Developers ===
> >
> > (with GitHub logins)
> >
> >  * Tianqi Chen (@tqchen)
> >  * Mu Li (@mli)
> >  * Junyuan Xie (@piiswrong)
> >  * Bing Xu (@antinucleon)
> >  * Chiyuan Zhang (@pluskid)
> >  * Minjie Wang (@jermainewang)
> >  * Naiyan Wang (@winstywang)
> >  * Yizhi Liu (@javelinjs)
> >  * Tong He (@hetong007)
> >  * Qiang Kou (@thirdwing)
> >  * Xingjian Shi (@sxjscience)
> >
> >
> AFAIK, we still expect email addresses, not github accounts.
>
>
The GitHubs were just as an FYI :)


>
> >
> > == Initial Source ==
> >
> > We currently use Github to maintain our source code,
> > https://github.com/MXNet
>
>
> This doesn't look right.  This github organization has a single repo that
> contains a mobile app that appears to been 4 years old.  The website points
> to https://github.com/dmlc/mxnet which looks more correct.  Which is it?
> I'll also note that if it is the latter, there are git submodules in the
> codebase.  Please include references to those modules as well.  Please also
> include the website source code, if available.
>

*DOH* thank you :)

There will be more than dmlc/mxnet as some of the other dmlc repos relate
to mxnet too.


>
> I'll point out that since the github name is taken, it may be cause to say
> that MXNet isn't a viable name.  But that can be worked out later.
>

Yup. I did a preliminary name search of the various TESSA type places and
didn't see any blocking concerns.


>
> >
> > == External Dependencies ==
> >
> >  * required by the core code base: GCC or CLOM, Clang, any BLAS library
> > (ATLAS, OpenBLAS, MKL), dmlc-core, mshadow, ps-lite (which requires
> > lib-zeromq), TBB
> >  * required for GPU usage: cudnn, cuda
> >  * required for python usage: Python 2/3
> >  * required for R module: R, Rcpp (GPLv2 licensing)
> >  * optional for image preparation and preprocessing: opencv
> >  * optional dependencies for additional features: torch7, numba, cython
> (in
> > NNVM branch)
> >
>
> Before we go any further, I think we need to address the incompatible
> licenses.  Knowing that R is a core component of MXNet, how will you
> replace it?
>

I don't expect R itself to be an issue. Rcpp I expect to be an issue and
there are options here - either hosting the R module separately or
switching to using Rcpp11 (MIT license).

ZeroMQ is perhaps a larger issue given it's a transitive dependency of the
core codebase. That community has a licensing exception in addition to its
LGPL which can be discussed, it has expressed a desire to move to MPL and
is so prevalent in the ecosystem that I feel it's something to be figured
out rather than avoided. Solutions would involve either approval for the
exception text, rewriting to not use ps-lite, or rewriting ps-lite to not
use zmq (given ps-lite is a dmlc project).


> >
> > == Committers and Affiliations ==
> >
> >  * Tianqi Chen (UW)
> >  * Mu Li (AWS)
> >  * Junyuan Xie (AWS)
> >  * Bing Xu (Apple)
> >  * Chiyuan Zhang (MIT)
> >  * Minjie Wang (UYU)
> >  * Naiyan Wang (Tusimple)
> >  * Yizhi Liu 

Re: [VOTE] Drop incubating requirement of Maven artifacts

[Wade Chandler]

On Jan 4, 2017 4:46 AM, "Jochen Theodorou"  wrote:

On 04.01.2017 07:28, Mark Struberg wrote:
[...]

I'm a bit surprised that groovy still uses the org.codehaus groupId, but I
> guess they have a deal with Ben (the former owner and thus (former?)
> copyright holder of 'Codehaus').
> So while this will work for now I guess that even groovy will move to
> org.apache.groovy in the long term (maybe with a new major version).
>

A new major version is a big thing for Groovy, but yes. In our view it is
the only realistic way, since people can expect breaking changes between
major versions and that includes in our view package names as well as group
ids.


It's not a big deal YET, but http://codehaus.org is not reachable anymore.
> And if anyone buys this domain he will have a much better position
> regarding trademarks than we do.
> What if someone buys the codehaus.org domain and publishes own artifacts
> under org.codehaus.groovy? Can we even prevent someone else to e.g publish
> org.codehaus.groovyng artifacts?
>

Assume we change and 2 months later somebody does that? How is the
situation then any better?

Actually I wonder if Ben would donate the domain to the ASF...


This would be a huge deal for NetBeans too. Too many projects based off of
it. The domain is being donated to Apache though AFAIK, but still, end
users shouldn't have to change so many sources or break other dependencies,
which may not be using the new package names, just because the package
names are org.netbeans and someone thinks they should be
org.apache.netbeans unless there is a true legal reason, and that would be
rare, but a different email thread I imagine, but way more complicated than
just changing the package name in the case of Groovy or NetBeans because we
are talking about whole ecosystems and dependency graphs.

Thanks

Wade

Re: [VOTE] Drop incubating requirement of Maven artifacts

[Wade Chandler]

On Jan 3, 2017 7:06 AM, "Guillaume Laforge"  wrote:

When you say "it denotes a lack of maturity which is exactly the purpose
AFAIK", what do you mean my maturity?
Maturity in terms of how well it follows Apache processes and principles?
Or in terms of "the project is not ready for prime time"?

For example, for Apache Groovy, the project was very mature, and was
already 11 years old when it joined the ASF.
It was very stable, very mature, very solid.
And it was a bit weird to append "-incubating", as people thought it meant
"not ready for prime time" rather that "going through ASF incubation".
Furthermore it forced users to also change the appId although they usually
change only the version number, which might be in some property file
externally. It's not such a big big deal, but it's still something they had
to do, which is a bit unconvenient.


Agreed, and something NetBeans will face. But, surely users of a projects
artifacts use more information than the artifact versions to decide to use
a project. Though without specific reasoning on the project site about
versioning, I have seen, even within my company, 0.x versions have a bad
connotation; Dropwizard and Nodejs.

Too this is a new classifier that the tooling will have to know about in
its RCP and plugin developer support in the case of NetBeans, which will
only be relevant during the incubation phase. Without it, the tooling would
create invalid project files, so it has impacts outside of just the build
system for projects; some code changes on relevant to incubation.



I also second the idea that such a rule should apply to all kind of
artifacts or none, but not be an exception of Maven artifacts.
It doesn't make sense to enforce a rule for just one... and hence the idea
of lifting that rule altogether for everybody.


Also agreed. If it is important for the reasons noted, then it should be
just as important every where. If the tooling of various things cannot
support it, then perhaps it isn't something worth caring about broadly, but
then is it worth it at all if that is the case?

But too, isn't this is exactly what Maven SNAPSHOTS are about? A release is
a final thing whether it has some warts or not. So, if I have a mature
project going to Apache, its released artifacts should be something I can
depend on as well as the previous released artifacts if I trusted them
regardless if the project may not make another release. If I am using that
artifact from Central, it isn't magically going away.

As the project was donated to Apache, was the same risk not already in
existence or present before? This is an inherent risk with 3rd party
dependency whether COTS or OSS which often seems lost on the industry, and
adding an extra bit to the binary artifact isn't changing that.

Wade

Re: [VOTE] Drop incubating requirement of Maven artifacts

[Guillaume Laforge]

+1

On Fri, Jan 6, 2017 at 4:05 PM, Wade Chandler 
wrote:

> On Jan 2, 2017 7:53 PM, "Pierre Smits"  wrote:
>
>
> +1 Drop the -incubator/-incubating expectation of maven projects
>
> It is not the code that is incubating.
>
> Whether a project of the ASF has a status (podling, tlp, attic, etc.) is
> irrelevant for the code. The code is donated/owned by the ASF, and tasks to
> ensure that the code released is in conformance of the standards of the ASF
> is delegated to the project. In the case of podlings, that responsibility
> is delegated to the IPMC.
> That a new project is going through the incubation phase is to ensure that
> the community works in accordance with the principles and regulations of
> the ASF (community over code, and such), and that the code is reworked to
> something that can be released as code of the ASF.
>
> For some open source is like a red flag. An addition like 'incubating'
> could be regarded as worse. Is that what the ASF wants? This kind of
> addition doesn't instil trust. It may influence potential adopters to stay
> away of the code until the project has successfully gone through
> incubation, It may influence potential contributors to not contribute until
> graduation.
>
>
> I agree with the sentiment expressed here. Projects which already have a
> long history coming to ASF have valid releases, and the word "incubating"
> has important meaning to policy and the ASF for Podlings, but for produced
> artifacts it is about like 0.x releases. One shouldn't have to understand
> ASF policy beyond the license to feel comfortable using ASF wares IMO, but
> just an opinion.
>
> Thanks
>
> Wade
>



-- 
Guillaume Laforge
Apache Groovy committer & PMC Vice-President
Developer Advocate @ Google Cloud Platform

Blog: http://glaforge.appspot.com/
Social: @glaforge  / Google+

Re: [VOTE] Drop incubating requirement of Maven artifacts

[Apache]

-1

Ralph

> On Jan 2, 2017, at 10:22 AM, John D. Ament  wrote:
> 
> All,
> 
> I'm calling to vote on a proposed policy change.  Current guide at [1]
> indicates that maven artifacts should include incubator (or incubating) in
> the version string of maven artifacts.  Its labeled as a best practice, not
> a requirement and is not a policy followed on other repository management
> tools (e.g. PyPi).
> 
> I therefore push forward that the incubator will cease expecting java-based
> projects to publish artifacts with "-incubating" in the version string,
> with the understanding that:
> 
> - Incubating is a term used to refer to a project's stability, not a
> release's stability.  It is generally understood that incubating projects
> are not necessarily immature, but may have a potential of failing to become
> a TLP.
> - Podling releases are endorsed, the podling itself is not endorsed.  We
> will not approve releases that are blatantly against ASF policies.
> 
> 
> [ ] +1 Drop the -incubator/-incubating expectation of maven projects
> [ ] +/0
> [ ] -1 Don't drop because
> 
> 
> [1]:
> http://incubator.apache.org/guides/release-java.html#best-practice-maven



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

Re: [DISCUSS] Proposing MXNet for the Apache Incubator

[Tsuyoshi Ozawa]

Apache SystemML(incubating) is also a flexible, scalable machine
learning system[4].

> Apache SystemML provides an optimal workplace for machine learning using big 
> data. It can be run on top of Apache Spark, where it automatically scales 
> your data, line by line, determining whether your code should be run on the 
> driver or an Apache Spark cluster.

[4] https://systemml.apache.org/

Thanks,
- Tsuyoshi

On Fri, Jan 6, 2017 at 6:11 PM, Tsuyoshi Ozawa  wrote:
> Hi Henri,
>
> It's a great news! Looking forwarding to MXNet's coming to Apache Incubator 
> :-)
>
> Two minor comments:
>
>> We currently use Github to maintain our source code,
>> https://github.com/MXNet
>
> In my understanding, the following url is correct one.
> https://github.com/dmlc/mxnet
>
>> === Relationship with Other Apache Products ===
>
> As far as I know, there are 2 additional machine learning libraries in
> addition to the projects you mentioned.
> Apache MADlib(incubating)[1] is a machine learning library, which can
> run on SQL system(Greenplum/Apache HAWQ(incubating)/PostgreSQL).
> Apache Hivemall(incubating)[2] are also machine learning library,
> which can run on Hadoop ecosystem: Apache Spark/Apache Hive/Apache
> Pig. Especially for Hivemall project, it has MIX server, one kind of
> parameter server to exchange parameters between mappers[3].
>
> This is just a sharing, and I don't mean you should add these projects
> to your comment.
>
> [1] http://madlib.incubator.apache.org/
> [2] https://hivemall.incubator.apache.org/
> [3] https://hivemall.incubator.apache.org/userguide/tips/mixserver.html
>
> Thanks,
> - Tsuyoshi
>
> On Fri, Jan 6, 2017 at 4:32 PM, Henry Saputra  wrote:
>> This is great news and I am looking forward to it =)
>>
>> According to proposal, the community want to stick with Github issues for
>> tracking issues and bugs?
>> I suppose this needs a nod by Greg Stein as rep from Apache Infra to
>> confirm that this is ok for incubation and how would it impact during
>> graduation.
>>
>> - Henry
>>
>> On Thu, Jan 5, 2017 at 9:12 PM, Henri Yandell  wrote:
>>
>>> Hello Incubator,
>>>
>>> I'd like to propose a new incubator Apache MXNet podling.
>>>
>>> The existing MXNet project (http://mxnet.io - 1.5 years old, 15
>>> committers,
>>> 200 contributors) is very interested in joining Apache. MXNet is an
>>> open-source deep learning framework that allows you to define, train, and
>>> deploy deep neural networks on a wide array of devices, from cloud
>>> infrastructure to mobile devices.
>>>
>>> The wiki proposal page is located here:
>>>
>>>   https://wiki.apache.org/incubator/MXNetProposal
>>>
>>> I've included the text below in case anyone wants to focus on parts of it
>>> in a reply.
>>>
>>> Looking forward to your thoughts, and for lots of interested Apache members
>>> to volunteer to mentor the project in addition to Sebastian and myself.
>>>
>>> Currently the list of committers is based on the current active coders, so
>>> we're also very interested in hearing from anyone else who is interested in
>>> working on the project, be they current or future contributor!
>>>
>>> Thanks,
>>>
>>> Hen
>>> On behalf of the MXNet project
>>>
>>> -
>>>
>>> = MXNet: Apache Incubator Proposal =
>>>
>>> == Abstract ==
>>>
>>> MXNet is a Flexible and Efficient Library for Deep Learning
>>>
>>> == Proposal ==
>>>
>>> MXNet is an open-source deep learning framework that allows you to define,
>>> train, and deploy deep neural networks on a wide array of devices, from
>>> cloud infrastructure to mobile devices. It is highly scalable, allowing for
>>> fast model training, and supports a flexible programming model and multiple
>>> languages. MXNet allows you to mix symbolic and imperative programming
>>> flavors to maximize both efficiency and productivity. MXNet is built on a
>>> dynamic dependency scheduler that automatically parallelizes both symbolic
>>> and imperative operations on the fly. A graph optimization layer on top of
>>> that makes symbolic execution fast and memory efficient. The MXNet library
>>> is portable and lightweight, and it scales to multiple GPUs and multiple
>>> machines.
>>>
>>> == Background ==
>>>
>>> Deep learning is a subset of Machine learning and refers to a class of
>>> algorithms that use a hierarchical approach with non-linearities to
>>> discover and learn representations within data. Deep Learning has recently
>>> become very popular due to its applicability and advancement of domains
>>> such as Computer Vision, Speech Recognition, Natural Language Understanding
>>> and Recommender Systems. With pervasive and cost effective cloud computing,
>>> large labeled datasets and continued algorithmic innovation, Deep Learning
>>> has become the one of the most popular classes of algorithms for machine
>>> learning practitioners in recent years.
>>>
>>> == Rational ==
>>>
>>> The adoption of deep learning is quickly expanding from 

Re: [DISCUSS] Proposing MXNet for the Apache Incubator

[Tsuyoshi Ozawa]

Hi Henri,

It's a great news! Looking forwarding to MXNet's coming to Apache Incubator :-)

Two minor comments:

> We currently use Github to maintain our source code,
> https://github.com/MXNet

In my understanding, the following url is correct one.
https://github.com/dmlc/mxnet

> === Relationship with Other Apache Products ===

As far as I know, there are 2 additional machine learning libraries in
addition to the projects you mentioned.
Apache MADlib(incubating)[1] is a machine learning library, which can
run on SQL system(Greenplum/Apache HAWQ(incubating)/PostgreSQL).
Apache Hivemall(incubating)[2] are also machine learning library,
which can run on Hadoop ecosystem: Apache Spark/Apache Hive/Apache
Pig. Especially for Hivemall project, it has MIX server, one kind of
parameter server to exchange parameters between mappers[3].

This is just a sharing, and I don't mean you should add these projects
to your comment.

[1] http://madlib.incubator.apache.org/
[2] https://hivemall.incubator.apache.org/
[3] https://hivemall.incubator.apache.org/userguide/tips/mixserver.html

Thanks,
- Tsuyoshi

On Fri, Jan 6, 2017 at 4:32 PM, Henry Saputra  wrote:
> This is great news and I am looking forward to it =)
>
> According to proposal, the community want to stick with Github issues for
> tracking issues and bugs?
> I suppose this needs a nod by Greg Stein as rep from Apache Infra to
> confirm that this is ok for incubation and how would it impact during
> graduation.
>
> - Henry
>
> On Thu, Jan 5, 2017 at 9:12 PM, Henri Yandell  wrote:
>
>> Hello Incubator,
>>
>> I'd like to propose a new incubator Apache MXNet podling.
>>
>> The existing MXNet project (http://mxnet.io - 1.5 years old, 15
>> committers,
>> 200 contributors) is very interested in joining Apache. MXNet is an
>> open-source deep learning framework that allows you to define, train, and
>> deploy deep neural networks on a wide array of devices, from cloud
>> infrastructure to mobile devices.
>>
>> The wiki proposal page is located here:
>>
>>   https://wiki.apache.org/incubator/MXNetProposal
>>
>> I've included the text below in case anyone wants to focus on parts of it
>> in a reply.
>>
>> Looking forward to your thoughts, and for lots of interested Apache members
>> to volunteer to mentor the project in addition to Sebastian and myself.
>>
>> Currently the list of committers is based on the current active coders, so
>> we're also very interested in hearing from anyone else who is interested in
>> working on the project, be they current or future contributor!
>>
>> Thanks,
>>
>> Hen
>> On behalf of the MXNet project
>>
>> -
>>
>> = MXNet: Apache Incubator Proposal =
>>
>> == Abstract ==
>>
>> MXNet is a Flexible and Efficient Library for Deep Learning
>>
>> == Proposal ==
>>
>> MXNet is an open-source deep learning framework that allows you to define,
>> train, and deploy deep neural networks on a wide array of devices, from
>> cloud infrastructure to mobile devices. It is highly scalable, allowing for
>> fast model training, and supports a flexible programming model and multiple
>> languages. MXNet allows you to mix symbolic and imperative programming
>> flavors to maximize both efficiency and productivity. MXNet is built on a
>> dynamic dependency scheduler that automatically parallelizes both symbolic
>> and imperative operations on the fly. A graph optimization layer on top of
>> that makes symbolic execution fast and memory efficient. The MXNet library
>> is portable and lightweight, and it scales to multiple GPUs and multiple
>> machines.
>>
>> == Background ==
>>
>> Deep learning is a subset of Machine learning and refers to a class of
>> algorithms that use a hierarchical approach with non-linearities to
>> discover and learn representations within data. Deep Learning has recently
>> become very popular due to its applicability and advancement of domains
>> such as Computer Vision, Speech Recognition, Natural Language Understanding
>> and Recommender Systems. With pervasive and cost effective cloud computing,
>> large labeled datasets and continued algorithmic innovation, Deep Learning
>> has become the one of the most popular classes of algorithms for machine
>> learning practitioners in recent years.
>>
>> == Rational ==
>>
>> The adoption of deep learning is quickly expanding from initial deep domain
>> experts rooted in academia to data scientists and developers working to
>> deploy intelligent services and products. Deep learning however has many
>> challenges.  These include model training time (which can take days to
>> weeks), programmability (not everyone writes Python or C++ and like
>> symbolic programming) and balancing production readiness (support for
>> things like failover) with development flexibility (ability to program
>> different ways, support for new operators and model types) and speed of
>> execution (fast and scalable model training).  Other frameworks excel on
>> some 

Re: [DISCUSS] publishing docker image for podling

[Myrle Krantz]

On Thu, Jan 5, 2017 at 8:13 PM, Roman Shaposhnik 
wrote:

> On Thu, Jan 5, 2017 at 1:32 AM, Greg Stein  wrote:
> > Taking off my Infrastructure hat from within that issue, and speaking to
> > this from a Foundation policy standpoint ... I think this is probably
> okay,
> > if the docker image is named (say) u/apache/incubator-singa. We allow
> > incubator projects in our github namespace as
> > github.com/apache/incubator-singa.
>
> This is orthogonal to the podling discussion, but have we settled the issue
> of any Docker container being full of not only GPLed binaries, but also,
> interesting potential trademark implications along the lines of:
> https://mjg59.dreamwidth.org/36312.html
>
> The reason I'm raising this is because we're now talking about an official
> ASF account on DockerHub which means ramifications are Foundation-level
> (not PMC level).
>
> Apologies if it was settled and I missed it.
>

I assume based on the discussion you linked to that by the GPLed binaries
you mean the OS.  But if you look at image file specification, you'll
notice that it does not contain the OS itself, but rather a reference to an
OS:
https://github.com/docker/docker/blob/master/image/spec/v1.md

Actually, if you think about it, all binaries are dependent on one or more
OS's, and that dependency is almost always documented.What a docker
image does differently than other forms of binary distribution is that it
documents the OS dependency explicitly and in a machine-readable form.  It
does not distribute the OS itself however -- docker itself takes care of
that.

Whether those technical truths are enough to comfort the ASF's legal
department, or the legal department of any company which wishes to use a
docker image is a question I cannot answer.  Probably, the distributors of
at least one linux distro would have to put it in writing before anyone
will feel very comfortable with it.


> > But then we also get into an area of "what happens around graduation?"
> ...
> > do we then offer both u/incubator-singa *and* u/singa ? ... If that's
> > acceptable, then this may be a simple decision. But for downstream
> > stability/continuity reasons would a podling want to *start* at
> > docker/u/singa ? ... and that is where I ask if the IPMC is willing to
> give
> > up the incubator- signal within our namespace on docker.
> >
> > And yes, I recognize the similarity to the concurrent discussion about
> > Maven Central artifacts. There are costs/benefits around continuity and
> > impacts on downstream users.
>
> I just want to point out that just like with Maven -- you can achieve
> -incubator
> tagging with versions/tags of Docker containers which will solve the naming
> issue.
>
>
And actually -incubator tagging of a docker image is a little less hairy
than it is with a maven artifact, because you don't have the issues with
transitive dependencies on version ranges and multiple routes to the same
dependency.  Docker dependency specifications are always... specific, and
you can only specify one of them per docker image.

Still, while I think the ASF is within its rights to request that a
description contain an incubation disclaimer, making requirements on tag
names is micromanaging.

Greets,
Myrle