Re: The state of Sirona

[Niclas Hedhman]

The "wrong" part (from a project's PoV) is that ASF retains trademarks...

On Mon, Apr 17, 2017 at 10:56 AM, P. Taylor Goetz  wrote:

> +1 for retirement.
>
> There's absolutely nothing wrong with a podling returning to the place
> from whence it came. I'm encouraged that that sentiment seems to be
> proliferating among the IPMC.
>
> -Taylor
>
>
>
>
>
>
>
> > On Apr 16, 2017, at 11:33 AM, Ted Dunning  wrote:
> >
> > Sounds like consensus is coming together, then. Sound right?
> >
> >
> >> On Apr 16, 2017 06:03, "larry mccay"  wrote:
> >>
> >> H - interesting points about incubator vs github and overhead.
> >> I do think my statement was unclear though.
> >>
> >> I was saying exactly the same thing about struggling podlings.
> >> Much better to find out in the incubator than as a TLP that the apache
> way
> >> isn't really going to work for them at the moment.
> >>
> >>
> >> On Sun, Apr 16, 2017 at 7:21 AM, John D. Ament 
> >> wrote:
> >>
>  On Sat, Apr 15, 2017 at 3:04 PM larry mccay 
> wrote:
> 
>  Well said.
>  It is healthy to not have a podling graduate and subsequently struggle
> >>> as a
>  TLP.
>  This is actually a success of sorts.
> 
>  At least until a majority of podlings have trouble. :)
> 
> 
> >>> I may be reading Ted's email differently.  Or I might be reading your
> >>> response wrong.
> >>>
> >>> Retirement isn't a failure.  Podlings are meant to be experiments in
> some
> >>> cases.  Can I build a strong enough community, can we follow the apache
> >>> way.
> >>>
> >>> There's a notion that the incubator adds over head to smaller projects.
> >> If
> >>> you're a one-or-two developer group, who can commit one small change
> and
> >>> cut a release in an afternoon, coming to apache with our 3 day voting
> >>> periods seems crazy.
> >>>
> >>> For small projects like Sirona, they may benefit from rapid iterate,
> >>> release, feedback cycles. This is where tooling like GitHub becomes
> much
> >>> more useful.  Once you get wikis, websites going, you can iterate and
> >> seem
> >>> like a strong community.  Until you become a community of 100's of
> users.
> >>>
> >>> We don't want to see struggling podlings graduate.  This is why the
> >>> incubator has no time limit.  We do get worried when a podling's been
> >> here
> >>> for too long.
> >>>
> >>> Basically, Sirona may see some success retiring from Apache, moving
> >>> development to github, until they've been able to build a bigger
> >> community.
> >>>
> >>>
>  On Sat, Apr 15, 2017 at 2:55 PM, Ted Dunning 
>  wrote:
> 
> > I think that we need to get over thinking of this state of affairs
> >> is a
> > "failure".
> >
> > It is just one of the many different possible outcomes for
> >> incubation.
> >>> To
> > my mind, having multiple possible outcomes is a *feature*, not a bug.
> >
> > Obviously, we should not admit podlings that we aren't committed to
>  helping
> > become TLP's and we should help those podlings become TLP's. But
> >> there
>  are
> > lots of different possible outcomes and only the podling can really
> > determine which outcome it will have.
> >
> > It is a fact of nature that we cannot always know whether a new
> >> podling
> > really has the right intent and contributor mix to become a good TLP.
> > Sometimes it is apparent that the project will be a great fit and
>  sometimes
> > it is apparent that it won't be, but many times we won't exactly
> >> know.
> > There will be cases where a community will melt away and there will
> >> be
> > cases where a community really didn't get the point of the Apache
>  license.
> > In many cases, the world just changes and by the time it is time to
> > graduate, the project just isn't the right thing to do any more.
> >
> > As such, I think we need to (somewhat) over-admit podlings when there
> >>> is
> > doubt. That doesn't mean admit projects that just won't ever succeed,
> >>> but
> > it does mean we should be a little generous in terms of admission. We
> > should vote to admit in cases of some doubt.
> >
> > If that is true, then we have to expect that there will be a variety
> >> of
> > outcomes and we have to take that as a consequence of our initial
> > generosity. This is not a cause for tears. Frankly, every project
> >> that
> > becomes an obvious candidate for retirement means that there is
> >> another
> > successful project that we admitted even though there was doubt.
> >
> > IF it is time to retire Sirona, let's just do it.
> >
> >
> >
> > On Sat, Apr 15, 2017 at 10:09 AM, Pierre Smits <
> >> pierre.sm...@gmail.com
> 
> > wrote:
> >
> >> It is very sad to see a project failing at growing a community.
> >>> Looking

Re: [VOTE] Apache Gearpump (incubating) 0.8.3-RC1

[Jean-Baptiste Onofré]

+1 (binding)

Check:
- build
- signatures and headers
- checksums
- DISCLAIMER

Regards
JB

On 04/11/2017 11:33 AM, Karol Brejna wrote:

Hi IPMC Community,

The PPMC vote to release Apache Gearpump (incubating) 0.8.3-RC1 has passed.
We would like to now submit this release candidate to the IPMC.

The PPMC vote thread is here:
https://lists.apache.org/thread.html/0e1022d2f3b5b2a2b879e4c278d7fc44d094058550d47ae7e07702ec@%3Cdev.gearpump.apache.org%3E

The source and binary tarballs, including signatures, digests, etc.
can be found at:
https://dist.apache.org/repos/dist/dev/incubator/gearpump/0.8.3-incubating/RC1/

Release artifacts are signed with the key with fingerprint:
3F12 81A2 DB58 0842 5ABA  6962 D8A8 4FBC 0A83 B291

The KEYS file is available here:
https://dist.apache.org/repos/dist/dev/incubator/gearpump/KEYS

The tag to be voted upon is:
https://git-wip-us.apache.org/repos/asf?p=incubator-gearpump.git;a=shortlog;h=refs/tags/0.8.3-RC1

The release hash is:
https://git-wip-us.apache.org/repos/asf?p=incubator-gearpump.git;a=commit;h=80f49154428cd18b5a27d946b8c9536124849cc9

For information about the contents of this release see:
https://issues.apache.org/jira/browse/GEARPUMP-294?jql=project%20%3D%20GEARPUMP%20AND%20status%20in%20(Resolved%2C%20Closed)%20AND%20fixVersion%20%3D%200.8.3

This vote will be open for 72 hours (Thursday, April 13, 2017 at 3:00AM PST).

Please download the release candidate and evaluate the necessary items
including checking hashes, signatures, build from source, run the
binary artifacts in the binary release and test.
Please vote:

[ ] +1 Release this package as gearpump-0.8.3
[ ] +0 no opinion
[ ] -1 Do not release this package because because...

Thanks,
Karol



--
Jean-Baptiste Onofré
jbono...@apache.org
http://blog.nanthrax.net
Talend - http://www.talend.com

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

Re: The state of Sirona

[P. Taylor Goetz]

+1 for retirement.

There's absolutely nothing wrong with a podling returning to the place from 
whence it came. I'm encouraged that that sentiment seems to be proliferating 
among the IPMC.

-Taylor







> On Apr 16, 2017, at 11:33 AM, Ted Dunning  wrote:
> 
> Sounds like consensus is coming together, then. Sound right?
> 
> 
>> On Apr 16, 2017 06:03, "larry mccay"  wrote:
>> 
>> H - interesting points about incubator vs github and overhead.
>> I do think my statement was unclear though.
>> 
>> I was saying exactly the same thing about struggling podlings.
>> Much better to find out in the incubator than as a TLP that the apache way
>> isn't really going to work for them at the moment.
>> 
>> 
>> On Sun, Apr 16, 2017 at 7:21 AM, John D. Ament 
>> wrote:
>> 
 On Sat, Apr 15, 2017 at 3:04 PM larry mccay  wrote:
 
 Well said.
 It is healthy to not have a podling graduate and subsequently struggle
>>> as a
 TLP.
 This is actually a success of sorts.
 
 At least until a majority of podlings have trouble. :)
 
 
>>> I may be reading Ted's email differently.  Or I might be reading your
>>> response wrong.
>>> 
>>> Retirement isn't a failure.  Podlings are meant to be experiments in some
>>> cases.  Can I build a strong enough community, can we follow the apache
>>> way.
>>> 
>>> There's a notion that the incubator adds over head to smaller projects.
>> If
>>> you're a one-or-two developer group, who can commit one small change and
>>> cut a release in an afternoon, coming to apache with our 3 day voting
>>> periods seems crazy.
>>> 
>>> For small projects like Sirona, they may benefit from rapid iterate,
>>> release, feedback cycles. This is where tooling like GitHub becomes much
>>> more useful.  Once you get wikis, websites going, you can iterate and
>> seem
>>> like a strong community.  Until you become a community of 100's of users.
>>> 
>>> We don't want to see struggling podlings graduate.  This is why the
>>> incubator has no time limit.  We do get worried when a podling's been
>> here
>>> for too long.
>>> 
>>> Basically, Sirona may see some success retiring from Apache, moving
>>> development to github, until they've been able to build a bigger
>> community.
>>> 
>>> 
 On Sat, Apr 15, 2017 at 2:55 PM, Ted Dunning 
 wrote:
 
> I think that we need to get over thinking of this state of affairs
>> is a
> "failure".
> 
> It is just one of the many different possible outcomes for
>> incubation.
>>> To
> my mind, having multiple possible outcomes is a *feature*, not a bug.
> 
> Obviously, we should not admit podlings that we aren't committed to
 helping
> become TLP's and we should help those podlings become TLP's. But
>> there
 are
> lots of different possible outcomes and only the podling can really
> determine which outcome it will have.
> 
> It is a fact of nature that we cannot always know whether a new
>> podling
> really has the right intent and contributor mix to become a good TLP.
> Sometimes it is apparent that the project will be a great fit and
 sometimes
> it is apparent that it won't be, but many times we won't exactly
>> know.
> There will be cases where a community will melt away and there will
>> be
> cases where a community really didn't get the point of the Apache
 license.
> In many cases, the world just changes and by the time it is time to
> graduate, the project just isn't the right thing to do any more.
> 
> As such, I think we need to (somewhat) over-admit podlings when there
>>> is
> doubt. That doesn't mean admit projects that just won't ever succeed,
>>> but
> it does mean we should be a little generous in terms of admission. We
> should vote to admit in cases of some doubt.
> 
> If that is true, then we have to expect that there will be a variety
>> of
> outcomes and we have to take that as a consequence of our initial
> generosity. This is not a cause for tears. Frankly, every project
>> that
> becomes an obvious candidate for retirement means that there is
>> another
> successful project that we admitted even though there was doubt.
> 
> IF it is time to retire Sirona, let's just do it.
> 
> 
> 
> On Sat, Apr 15, 2017 at 10:09 AM, Pierre Smits <
>> pierre.sm...@gmail.com
 
> wrote:
> 
>> It is very sad to see a project failing at growing a community.
>>> Looking
> at
>> the various public sources, I see:
>> 
>>   - just 2 pull request since its start in incubation
>>   - no postings on the user ml since December 2015
>>   - only 3 committing contributors since start in incubation
>>   - No description (readme) in github
>>   - No mission statement/goal description of the project on the
> project's
>>   

Re: [VOTE] Release Apache PredictionIO 0.11.0 (incubating) RC2

[Donald Szeto]

Hi all,

This is a friendly reminder for the release voting of Apache PredictionIO
0.11.0-incubating-rc2. The voting will stay open until there are enough
votes for acceptance or rejection.

Regards,
Donald

On Thu, Apr 13, 2017 at 11:41 AM, Donald Szeto  wrote:

> Hi all,
>
> The PredictionIO community has voted that 0.11.0-incubating-rc2 to be good
> for a source-only release. This thread is to facilitate a voting for the
> IPMC before a final official source-only release.
>
> Vote result on dev@:
> https://lists.apache.org/thread.html/031ff6f98b3d5a54b716789bda5068
> 1a0c821f1054218843ac5fcc77@%3Cdev.predictionio.apache.org%3E
>
> The original vote thread on dev@:
> https://lists.apache.org/thread.html/d1bf205404bf4e16e12f17209f4f20
> 7722e554ee9e4139974812f8e4@%3Cdev.predictionio.apache.org%3E
>
> The release candidate Git commit is:
> e34a853d0e89baed09b3d3b0c25b244162a3bdea
>
> The release candidate Git tag is:
> v0.11.0-incubating-rc2
>
> The source-only release candidate artifacts can be downloaded here:
> https://dist.apache.org/repos/dist/dev/incubator/predictionio/0.11.0-
> incubating-rc2/
>
> Test results of RC2 can be found here:
> https://travis-ci.org/apache/incubator-predictionio/builds/220381611
>
> Build instructions of previous versions can be used on this RC:
> http://predictionio.incubator.apache.org/install/install-sourcecode/
>
> Maven artifacts are built from the release candidate artifacts above, and
> are provided as convenience for testing with PredictionIO engine templates.
> The Maven artifacts are provided at the Maven staging repo here:
> https://repository.apache.org/content/repositories/
> orgapachepredictionio-1016/
>
> All JIRAs completed for this release are tagged with 'FixVersion =
> 0.11.0-incubating'. You can view them here: https://issues.apache.org/
> jira/secure/ReleaseNote.jspa?projectId=12320420=12338381
>
> The artifacts have been signed with Key : 8BF4ABEB
>
> Please vote accordingly:
>
> [ ] +1, accept RC as the official 0.11.0 release
> [ ] 0, neutral because...
> [ ] -1, do not accept RC as the official 0.11.0 release because...
>
> The vote will be open for 72 hours and close at 12pm PDT 4/16/2016.
>
> Regards,
> Donald
>

Re: Podling Press Kit

[Sally Khudairi]

Hi everyone --regarding the standard Apache Incubator logo (rectangular)
vs. standalone "Powered By", there often are projects/podlings that do
not have logos.


This would be a good way to promote such projects. 



I suspect it won't be *widely* used, but the option is good to have.



Another way to use the standalone "Powered By" logo is in presentations,
etc. Folks often like to make stickers of their "Powered By" logos --we
can do the same with the Incubator.


Speaking of stickers, although we missed the deadline for the group
order ,I can have Incubator stickers if you'd like. Do let me know.


Hope this helps!



-Sally



- - -

Vice President Marketing & Publicity

The Apache Software Foundation



Tel +1 617 921 8656

Skype sallykhudairi





On Fri, Apr 14, 2017, at 22:47, John D. Ament wrote:

> 

> 

> On Fri, Apr 14, 2017 at 4:00 PM Deron Eriksson
>  wrote:
>> Hi,

>> 

>>  I noticed that in the Downloadable Graphics section (

>> http://incubator.apache.org/guides/press-kit.html#graphics-downloads),
>> the
>>  "EPS - RGB" and "EPS - CMYK" links appear to be broken.

>> 

> 

> Should be fixed shortly.  Glad someone was paying attention (more than
> me).  I forgot that EPS files were .eps not .svg.
>  

>> Deron

>> 

>> 

>>  On Fri, Apr 14, 2017 at 7:07 AM, Shane Curcuru
>>   wrote:
>> 

>>  > Good questions.  My thoughts:

>>  >

>>  > Daniel Dekany wrote on 4/14/17 5:32 AM:

>>  > > The page says that the "Official Incubator Logo" "is to be used
>>  > > on ALL
>>  > > podling pages during the incubation process". But I guess the
>>  > > intent
>>  > > was to allow using the "Red-On-White Version of Logo" or

>>  > > "Black-On-White Version of Logo" or "White-On-Black Version of
>>  > > Logo"
>>  > > instead as well.

>>  >

>>  > Yes, I'd think podlings should be able to choose the variant that
>>  > best
>>  > fits their own design.

>>  >

> 

> Agreed.  The reason for selection is exactly that - not every logo
> format will match every podling website.  We want some selection, but
> try to match contents as much as possible.
>  

>> > > Also I'm not sure what the intended usage of the ``Standalone
>> > > "Powered
>>  > > By" Apache Incubator Logo`` is. Since the rectangular official
>>  > > logo
>>  > > must be displayed (according the press kit), it sounds unlikely
>>  > > that
>>  > > someone will show the circular variation as well. So maybe the
>>  > > intent
>>  > > was to allow using that *instead* of the rectangular one?

>>  >

>>  > Good question, does Sally or anyone else working on Incubator
>>  > branding
>>  > overall have an opinion?  Personally I'd vote for using the
>>  > official
>>  > square logo in general for podling branding, but if someone
>>  > wants to
>>  > talk about the Incubator project as an overall process, the
>>  > circular
>>  > logo might make sense.

> 

> Which are you considering the "official" one?

> Sally can probably speak to it better (CCing her) but I believe the
> new "powered by" were supposed to be the sign off allegiance.  Is up
> to the podling which format they want to use as their allegiance.
>  

>> >

>>  > >

>>  > > The press kit doesn't tell where on the page the logo can be
>>  > > shown, so
>>  > > I assume even showing it in the page footer is fine.

>>  >

>>  > Since a number of current projects feature the incubator
>>  > disclaimer and
>>  > logo in the footer, yes, that should still be fine.

>>  >

>>  > > Also I'm not sure that by "used on ALL podling pages" you really
>>  > > mean
>>  > > all of them, like even JavaDoc generated pages. (It's doable

>>  > > technically, just asking.)

>>  >

>>  > No, javadoc pages don't need the branding, although it's nice.
>>  > Branding
>>  > MUST be applied on homepage, any major landing pages (i.e.
>>  > where you
>>  > send out links to answer questions from), and on download related
>>  > pages.
>>  >  Branding should be on all the main pages of the website; i.e.
>>  >  ones
>>  > where we are crafting the content (as opposed to purely generated
>>  > API or
>>  > similar docsets like javadoc).

> 

> You'll note that I removed the SHOULD.  The interpretation is that
> its an optional requirement.  I don't think that's quite right, and
> I considered adding the MUST, but ultimately left it equally
> ambiguous.  How strongly do you feel on the MUST?  I would rather
> see it than not see it.
>  

>> >

>>  > > Well, I guess these will be added to

>>  > > http://incubator.apache.org/incubation/Incubation_Policy.html

>>  > > eventually. Only if we are to implement this at certain podling
>>  > > now,
>>  > > it would be good to know what the options are.

>>  >

>>  > The high level goal is to have your project complying with the
>>  > Apache
>>  > TLP project branding policy by the time you graduate (modulo the

>>  > incubating disclaimer, etc..  It's supposed to be a process, so as
>>  > long
>>  > as a podling is making 

[VOTE] Accept Amaterasu into the Apache Incubator

[Jean-Baptiste Onofré]

Hi all,

following the discussion thread, I think we can start the vote on accepting 
Amaterasu into the Apache Incubator.


The ASF voting rules are described:

http://www.apache.org/foundation/voting.html

A vote for accepting a new Apache Incubator podling is a majority vote for which 
only Incubator PMC member votes are binding.


This vote will run for at least 72 hours. Please VOTE as follows
[] +1 Accept Amaterasu into the Apache Incubator
[] +0 Abstain.
[] -1 Do not accept Amaterasu into the Apache Incubator because ...

The proposal is listed below, but you can also access it on the wiki:

   https://wiki.apache.org/incubator/AmaterasuProposal

Note that we are looking for one more mentor on the proposal.
One concern has been raised about the "Amaterasu" name. We want to move forward 
with Amaterasu name but open to change if needed.


Thanks
Regards
--
Jean-Baptiste Onofré
jbono...@apache.org
http://blog.nanthrax.net
Talend - http://www.talend.com

= Apache Amaterasu =

== Abstract ==

Apache Amaterasu is a framework providing continuous deployment for Big Data 
pipelines.


It provides the following capabilities:

 * '''Continuous integration''' tools to '''package pipelines and run tests'''.
 * A repository to store those packaged applications: the '''applications 
repository'''.
 * A repository to store the pipelines, and engine configuration (for instance, 
location of the Spark master, etc.): per environment - the '''configuration 
repository'''.

 * A '''dashboard''' to monitor the pipelines.
 * A '''DSL and integration hooks''' allowing third parties to easily integrate.

== Proposal ==

Amaterasu is a simple and powerful framework to build and dispense pipelines. 
It aims to help data engineers and data scientists to compose, configure, test, 
package, deploy and execute data pipelines written using multiple tools, 
languages and frameworks. Amaterasu provides a standard repo structure to 
package big data pipelines, a YAML based Domain Specific Languages (DSL) for 
data engineers, data scientists and operations engineers to manage complex 
pipelines throughout their entire lifecycle (Dev, UAT, Prod, etc.).


== Background ==

Amaterasu is a relatively new project that was created to deal with some of the 
issues that as Consultants, we have seen recurring at different client sites. 
Mainly the need to continuously deploy complex pipelines built in multiple tools 
and languages.
Amaterasu started as a pet project and is currently being evaluated by a couple 
of organizations, supported by the contributors, on a personal time and 
voluntary bases.


== Rational ==

As software engineers working on big data projects we have straggled for a long 
time to apply the same CI/CD practices that have become the standard in the 
software industry for the last few years. While some of them are possible, for 
example Apache Spark is easy to unit test. However large scale pipelines are 
more complex and often use data, which might be un-structured as integration 
point, which requires heavy integration tests.


To automate such tests and complex deployments, we have found the need to often 
handcraft scripts and use a mixture tools, so we have decided to finally build a 
tool we can apply in a general way and not on a project by project basis.


Another issue Amaterasu is trying to tackle is the Integrating between the work 
of software engineers, data scientists, and sometimes operations engineers. The 
approach Amaterasu takes to integrate between those three schools of thought it 
to provide a simple YAML based DSL that provides a simple way to integrate 
different pipeline written in the native tools for each task (R, Spark in 
different languages, etc.).


== Initial Goals ==

Our initial goals are to bring Amaterasu into the ASF, transition internal 
engineering processes into the open, and foster a collaborative development 
model according to the "Apache Way".


In addition, we intend to continue the development of Amaterasu, add new 
features as well as  integrate better with other frameworks, including:


 * Apache Arrow
 * Apache Hive
 * Apache Drill
 * Apache Beam
 * Apache YARN
 * Farther and more complete integration with Apache Spark

Other frameworks will be evaluated after those initial goals are reached.

== Current Status ==

Amaterasu is preview state but provide a large set of features. We plan to 
stabilize and head to a first production ready release during the incubation 
process. The current license is already Apache 2.0.


=== Meritocracy ===

We intend to radically expand the initial developer and user community by 
running the project in accordance with the "Apache Way". Users and new 
contributors will be treated with respect and welcomed. By participating in the 
community and providing quality patches/support that move the project forward, 
they will earn merit. They also will be encouraged to provide non-code 
contributions (documentation, events, community 

Re: The state of Sirona

[Ted Dunning]

Sounds like consensus is coming together, then. Sound right?


On Apr 16, 2017 06:03, "larry mccay"  wrote:

> H - interesting points about incubator vs github and overhead.
> I do think my statement was unclear though.
>
> I was saying exactly the same thing about struggling podlings.
> Much better to find out in the incubator than as a TLP that the apache way
> isn't really going to work for them at the moment.
>
>
> On Sun, Apr 16, 2017 at 7:21 AM, John D. Ament 
> wrote:
>
> > On Sat, Apr 15, 2017 at 3:04 PM larry mccay  wrote:
> >
> > > Well said.
> > > It is healthy to not have a podling graduate and subsequently struggle
> > as a
> > > TLP.
> > > This is actually a success of sorts.
> > >
> > > At least until a majority of podlings have trouble. :)
> > >
> > >
> > I may be reading Ted's email differently.  Or I might be reading your
> > response wrong.
> >
> > Retirement isn't a failure.  Podlings are meant to be experiments in some
> > cases.  Can I build a strong enough community, can we follow the apache
> > way.
> >
> > There's a notion that the incubator adds over head to smaller projects.
> If
> > you're a one-or-two developer group, who can commit one small change and
> > cut a release in an afternoon, coming to apache with our 3 day voting
> > periods seems crazy.
> >
> > For small projects like Sirona, they may benefit from rapid iterate,
> > release, feedback cycles. This is where tooling like GitHub becomes much
> > more useful.  Once you get wikis, websites going, you can iterate and
> seem
> > like a strong community.  Until you become a community of 100's of users.
> >
> > We don't want to see struggling podlings graduate.  This is why the
> > incubator has no time limit.  We do get worried when a podling's been
> here
> > for too long.
> >
> > Basically, Sirona may see some success retiring from Apache, moving
> > development to github, until they've been able to build a bigger
> community.
> >
> >
> > > On Sat, Apr 15, 2017 at 2:55 PM, Ted Dunning 
> > > wrote:
> > >
> > > > I think that we need to get over thinking of this state of affairs
> is a
> > > > "failure".
> > > >
> > > > It is just one of the many different possible outcomes for
> incubation.
> > To
> > > > my mind, having multiple possible outcomes is a *feature*, not a bug.
> > > >
> > > > Obviously, we should not admit podlings that we aren't committed to
> > > helping
> > > > become TLP's and we should help those podlings become TLP's. But
> there
> > > are
> > > > lots of different possible outcomes and only the podling can really
> > > > determine which outcome it will have.
> > > >
> > > > It is a fact of nature that we cannot always know whether a new
> podling
> > > > really has the right intent and contributor mix to become a good TLP.
> > > > Sometimes it is apparent that the project will be a great fit and
> > > sometimes
> > > > it is apparent that it won't be, but many times we won't exactly
> know.
> > > > There will be cases where a community will melt away and there will
> be
> > > > cases where a community really didn't get the point of the Apache
> > > license.
> > > > In many cases, the world just changes and by the time it is time to
> > > > graduate, the project just isn't the right thing to do any more.
> > > >
> > > > As such, I think we need to (somewhat) over-admit podlings when there
> > is
> > > > doubt. That doesn't mean admit projects that just won't ever succeed,
> > but
> > > > it does mean we should be a little generous in terms of admission. We
> > > > should vote to admit in cases of some doubt.
> > > >
> > > > If that is true, then we have to expect that there will be a variety
> of
> > > > outcomes and we have to take that as a consequence of our initial
> > > > generosity. This is not a cause for tears. Frankly, every project
> that
> > > > becomes an obvious candidate for retirement means that there is
> another
> > > > successful project that we admitted even though there was doubt.
> > > >
> > > > IF it is time to retire Sirona, let's just do it.
> > > >
> > > >
> > > >
> > > > On Sat, Apr 15, 2017 at 10:09 AM, Pierre Smits <
> pierre.sm...@gmail.com
> > >
> > > > wrote:
> > > >
> > > > > It is very sad to see a project failing at growing a community.
> > Looking
> > > > at
> > > > > the various public sources, I see:
> > > > >
> > > > >- just 2 pull request since its start in incubation
> > > > >- no postings on the user ml since December 2015
> > > > >- only 3 committing contributors since start in incubation
> > > > >- No description (readme) in github
> > > > >- No mission statement/goal description of the project on the
> > > > project's
> > > > >home page
> > > > >
> > > > > I fear this will not turn around due to the lack of interest in the
> > > world
> > > > > beyond the project. At the moment I am inclined to say: time for
> > > > > retirement.
> > > > >
> > > > 

Re: The state of Sirona

[larry mccay]

H - interesting points about incubator vs github and overhead.
I do think my statement was unclear though.

I was saying exactly the same thing about struggling podlings.
Much better to find out in the incubator than as a TLP that the apache way
isn't really going to work for them at the moment.


On Sun, Apr 16, 2017 at 7:21 AM, John D. Ament 
wrote:

> On Sat, Apr 15, 2017 at 3:04 PM larry mccay  wrote:
>
> > Well said.
> > It is healthy to not have a podling graduate and subsequently struggle
> as a
> > TLP.
> > This is actually a success of sorts.
> >
> > At least until a majority of podlings have trouble. :)
> >
> >
> I may be reading Ted's email differently.  Or I might be reading your
> response wrong.
>
> Retirement isn't a failure.  Podlings are meant to be experiments in some
> cases.  Can I build a strong enough community, can we follow the apache
> way.
>
> There's a notion that the incubator adds over head to smaller projects.  If
> you're a one-or-two developer group, who can commit one small change and
> cut a release in an afternoon, coming to apache with our 3 day voting
> periods seems crazy.
>
> For small projects like Sirona, they may benefit from rapid iterate,
> release, feedback cycles. This is where tooling like GitHub becomes much
> more useful.  Once you get wikis, websites going, you can iterate and seem
> like a strong community.  Until you become a community of 100's of users.
>
> We don't want to see struggling podlings graduate.  This is why the
> incubator has no time limit.  We do get worried when a podling's been here
> for too long.
>
> Basically, Sirona may see some success retiring from Apache, moving
> development to github, until they've been able to build a bigger community.
>
>
> > On Sat, Apr 15, 2017 at 2:55 PM, Ted Dunning 
> > wrote:
> >
> > > I think that we need to get over thinking of this state of affairs is a
> > > "failure".
> > >
> > > It is just one of the many different possible outcomes for incubation.
> To
> > > my mind, having multiple possible outcomes is a *feature*, not a bug.
> > >
> > > Obviously, we should not admit podlings that we aren't committed to
> > helping
> > > become TLP's and we should help those podlings become TLP's. But there
> > are
> > > lots of different possible outcomes and only the podling can really
> > > determine which outcome it will have.
> > >
> > > It is a fact of nature that we cannot always know whether a new podling
> > > really has the right intent and contributor mix to become a good TLP.
> > > Sometimes it is apparent that the project will be a great fit and
> > sometimes
> > > it is apparent that it won't be, but many times we won't exactly know.
> > > There will be cases where a community will melt away and there will be
> > > cases where a community really didn't get the point of the Apache
> > license.
> > > In many cases, the world just changes and by the time it is time to
> > > graduate, the project just isn't the right thing to do any more.
> > >
> > > As such, I think we need to (somewhat) over-admit podlings when there
> is
> > > doubt. That doesn't mean admit projects that just won't ever succeed,
> but
> > > it does mean we should be a little generous in terms of admission. We
> > > should vote to admit in cases of some doubt.
> > >
> > > If that is true, then we have to expect that there will be a variety of
> > > outcomes and we have to take that as a consequence of our initial
> > > generosity. This is not a cause for tears. Frankly, every project that
> > > becomes an obvious candidate for retirement means that there is another
> > > successful project that we admitted even though there was doubt.
> > >
> > > IF it is time to retire Sirona, let's just do it.
> > >
> > >
> > >
> > > On Sat, Apr 15, 2017 at 10:09 AM, Pierre Smits  >
> > > wrote:
> > >
> > > > It is very sad to see a project failing at growing a community.
> Looking
> > > at
> > > > the various public sources, I see:
> > > >
> > > >- just 2 pull request since its start in incubation
> > > >- no postings on the user ml since December 2015
> > > >- only 3 committing contributors since start in incubation
> > > >- No description (readme) in github
> > > >- No mission statement/goal description of the project on the
> > > project's
> > > >home page
> > > >
> > > > I fear this will not turn around due to the lack of interest in the
> > world
> > > > beyond the project. At the moment I am inclined to say: time for
> > > > retirement.
> > > >
> > > > Best regards,
> > > >
> > > >
> > > > Pierre Smits
> > > >
> > > > ORRTIZ.COM 
> > > > OFBiz based solutions & services
> > > >
> > > > OFBiz Extensions Marketplace
> > > > http://oem.ofbizci.net/oci-2/
> > > >
> > > > On Sat, Apr 15, 2017 at 5:07 PM, Jean-Baptiste Onofré <
> j...@nanthrax.net
> > >
> > > > wrote:
> > > >
> > > > > Hi John
> > > > >
> > 

Re: The state of Sirona

[John D. Ament]

On Sat, Apr 15, 2017 at 3:04 PM larry mccay  wrote:

> Well said.
> It is healthy to not have a podling graduate and subsequently struggle as a
> TLP.
> This is actually a success of sorts.
>
> At least until a majority of podlings have trouble. :)
>
>
I may be reading Ted's email differently.  Or I might be reading your
response wrong.

Retirement isn't a failure.  Podlings are meant to be experiments in some
cases.  Can I build a strong enough community, can we follow the apache way.

There's a notion that the incubator adds over head to smaller projects.  If
you're a one-or-two developer group, who can commit one small change and
cut a release in an afternoon, coming to apache with our 3 day voting
periods seems crazy.

For small projects like Sirona, they may benefit from rapid iterate,
release, feedback cycles. This is where tooling like GitHub becomes much
more useful.  Once you get wikis, websites going, you can iterate and seem
like a strong community.  Until you become a community of 100's of users.

We don't want to see struggling podlings graduate.  This is why the
incubator has no time limit.  We do get worried when a podling's been here
for too long.

Basically, Sirona may see some success retiring from Apache, moving
development to github, until they've been able to build a bigger community.


> On Sat, Apr 15, 2017 at 2:55 PM, Ted Dunning 
> wrote:
>
> > I think that we need to get over thinking of this state of affairs is a
> > "failure".
> >
> > It is just one of the many different possible outcomes for incubation. To
> > my mind, having multiple possible outcomes is a *feature*, not a bug.
> >
> > Obviously, we should not admit podlings that we aren't committed to
> helping
> > become TLP's and we should help those podlings become TLP's. But there
> are
> > lots of different possible outcomes and only the podling can really
> > determine which outcome it will have.
> >
> > It is a fact of nature that we cannot always know whether a new podling
> > really has the right intent and contributor mix to become a good TLP.
> > Sometimes it is apparent that the project will be a great fit and
> sometimes
> > it is apparent that it won't be, but many times we won't exactly know.
> > There will be cases where a community will melt away and there will be
> > cases where a community really didn't get the point of the Apache
> license.
> > In many cases, the world just changes and by the time it is time to
> > graduate, the project just isn't the right thing to do any more.
> >
> > As such, I think we need to (somewhat) over-admit podlings when there is
> > doubt. That doesn't mean admit projects that just won't ever succeed, but
> > it does mean we should be a little generous in terms of admission. We
> > should vote to admit in cases of some doubt.
> >
> > If that is true, then we have to expect that there will be a variety of
> > outcomes and we have to take that as a consequence of our initial
> > generosity. This is not a cause for tears. Frankly, every project that
> > becomes an obvious candidate for retirement means that there is another
> > successful project that we admitted even though there was doubt.
> >
> > IF it is time to retire Sirona, let's just do it.
> >
> >
> >
> > On Sat, Apr 15, 2017 at 10:09 AM, Pierre Smits 
> > wrote:
> >
> > > It is very sad to see a project failing at growing a community. Looking
> > at
> > > the various public sources, I see:
> > >
> > >- just 2 pull request since its start in incubation
> > >- no postings on the user ml since December 2015
> > >- only 3 committing contributors since start in incubation
> > >- No description (readme) in github
> > >- No mission statement/goal description of the project on the
> > project's
> > >home page
> > >
> > > I fear this will not turn around due to the lack of interest in the
> world
> > > beyond the project. At the moment I am inclined to say: time for
> > > retirement.
> > >
> > > Best regards,
> > >
> > >
> > > Pierre Smits
> > >
> > > ORRTIZ.COM 
> > > OFBiz based solutions & services
> > >
> > > OFBiz Extensions Marketplace
> > > http://oem.ofbizci.net/oci-2/
> > >
> > > On Sat, Apr 15, 2017 at 5:07 PM, Jean-Baptiste Onofré  >
> > > wrote:
> > >
> > > > Hi John
> > > >
> > > > I think you did the right thing by bringing the point on the table.
> > > >
> > > > AFAIR I already stated some months ago that, regarding the activity
> and
> > > > regarding the community around, we should really think about
> retirement
> > > of
> > > > Sirona. Some can argue about the fact that Sirona is a "stable"
> project
> > > > that's not really valid: if it's valid we should see questions,
> feature
> > > > requests, etc coming from the user community. And obviously it's not
> > the
> > > > case. So I think that Sirona is just use for specific use cases in a
> > very
> > > > limited community.
> > 

Re: The state of Sirona

[Romain Manni-Bucau]

Le 16 avr. 2017 06:58, "Niclas Hedhman"  a écrit :

One could also ask the question; Considering how hyped "devops" culture is
right now, the central role that monitoring and visualization of that is
for devops, How come this project can't attract hordes of people? Is there
something inherent in Apache Incubator that interested parties have some
aversion of "incubating" or is it ASF as a whole isn't the right place for
these kinds of efforts?

The answer of "Too many out there", didn't seemed to have played a role in
the days of XML and WebApp frameworks, so I doubt that is the cause.



Adopters mainly were 100% java in term of philosophy or starting from
nothing so my (personal) explanation is devops is trendy but game was
already played in term of tool adoption. Not bringing anything really new
made our proposal having this characteristic. Just my interpretation but
dont think it is far to the reality.

Also think we were really bad in term of comm and, not sure why, comm
channels were always elsewhere than sirona@ (irc, direct ping, tomee
channels, ).




Cheers
Niclas

On Sun, Apr 16, 2017 at 2:55 AM, Ted Dunning  wrote:

> I think that we need to get over thinking of this state of affairs is a
> "failure".
>
> It is just one of the many different possible outcomes for incubation. To
> my mind, having multiple possible outcomes is a *feature*, not a bug.
>
> Obviously, we should not admit podlings that we aren't committed to
helping
> become TLP's and we should help those podlings become TLP's. But there are
> lots of different possible outcomes and only the podling can really
> determine which outcome it will have.
>
> It is a fact of nature that we cannot always know whether a new podling
> really has the right intent and contributor mix to become a good TLP.
> Sometimes it is apparent that the project will be a great fit and
sometimes
> it is apparent that it won't be, but many times we won't exactly know.
> There will be cases where a community will melt away and there will be
> cases where a community really didn't get the point of the Apache license.
> In many cases, the world just changes and by the time it is time to
> graduate, the project just isn't the right thing to do any more.
>
> As such, I think we need to (somewhat) over-admit podlings when there is
> doubt. That doesn't mean admit projects that just won't ever succeed, but
> it does mean we should be a little generous in terms of admission. We
> should vote to admit in cases of some doubt.
>
> If that is true, then we have to expect that there will be a variety of
> outcomes and we have to take that as a consequence of our initial
> generosity. This is not a cause for tears. Frankly, every project that
> becomes an obvious candidate for retirement means that there is another
> successful project that we admitted even though there was doubt.
>
> IF it is time to retire Sirona, let's just do it.
>
>
>
> On Sat, Apr 15, 2017 at 10:09 AM, Pierre Smits 
> wrote:
>
> > It is very sad to see a project failing at growing a community. Looking
> at
> > the various public sources, I see:
> >
> >- just 2 pull request since its start in incubation
> >- no postings on the user ml since December 2015
> >- only 3 committing contributors since start in incubation
> >- No description (readme) in github
> >- No mission statement/goal description of the project on the
> project's
> >home page
> >
> > I fear this will not turn around due to the lack of interest in the
world
> > beyond the project. At the moment I am inclined to say: time for
> > retirement.
> >
> > Best regards,
> >
> >
> > Pierre Smits
> >
> > ORRTIZ.COM 
> > OFBiz based solutions & services
> >
> > OFBiz Extensions Marketplace
> > http://oem.ofbizci.net/oci-2/
> >
> > On Sat, Apr 15, 2017 at 5:07 PM, Jean-Baptiste Onofré 
> > wrote:
> >
> > > Hi John
> > >
> > > I think you did the right thing by bringing the point on the table.
> > >
> > > AFAIR I already stated some months ago that, regarding the activity
and
> > > regarding the community around, we should really think about
retirement
> > of
> > > Sirona. Some can argue about the fact that Sirona is a "stable"
project
> > > that's not really valid: if it's valid we should see questions,
feature
> > > requests, etc coming from the user community. And obviously it's not
> the
> > > case. So I think that Sirona is just use for specific use cases in a
> very
> > > limited community.
> > >
> > > My €0.01 ;)
> > >
> > > Regards
> > > JB
> > >
> > > On Apr 15, 2017, 15:49, at 15:49, "John D. Ament" <
> johndam...@apache.org
> > >
> > > wrote:
> > > >All,
> > > >
> > > >I hate bringing up these topics.  But I think we as the IPMC we have
> to
> > > >take a close look at how Sirona is running and figure out what to do
> > > >next.
> > > >
> > > >- The podling has not reported in several months (this is 

Re: [VOTE] Apache Gearpump (incubating) 0.8.3-RC1

[Willem Jiang]

I ran the build from source and went through the source code, every thing
looks good.

Here is my +1.


Willem Jiang

Blog: http://willemjiang.blogspot.com (English)
  http://jnn.iteye.com  (Chinese)
Twitter: willemjiang
Weibo: 姜宁willem

On Tue, Apr 11, 2017 at 5:33 PM, Karol Brejna 
wrote:

> Hi IPMC Community,
>
> The PPMC vote to release Apache Gearpump (incubating) 0.8.3-RC1 has passed.
> We would like to now submit this release candidate to the IPMC.
>
> The PPMC vote thread is here:
> https://lists.apache.org/thread.html/0e1022d2f3b5b2a2b879e4c278d7fc
> 44d094058550d47ae7e07702ec@%3Cdev.gearpump.apache.org%3E
>
> The source and binary tarballs, including signatures, digests, etc.
> can be found at:
> https://dist.apache.org/repos/dist/dev/incubator/gearpump/0.
> 8.3-incubating/RC1/
>
> Release artifacts are signed with the key with fingerprint:
> 3F12 81A2 DB58 0842 5ABA  6962 D8A8 4FBC 0A83 B291
>
> The KEYS file is available here:
> https://dist.apache.org/repos/dist/dev/incubator/gearpump/KEYS
>
> The tag to be voted upon is:
> https://git-wip-us.apache.org/repos/asf?p=incubator-
> gearpump.git;a=shortlog;h=refs/tags/0.8.3-RC1
>
> The release hash is:
> https://git-wip-us.apache.org/repos/asf?p=incubator-
> gearpump.git;a=commit;h=80f49154428cd18b5a27d946b8c9536124849cc9
>
> For information about the contents of this release see:
> https://issues.apache.org/jira/browse/GEARPUMP-294?jql=
> project%20%3D%20GEARPUMP%20AND%20status%20in%20(
> Resolved%2C%20Closed)%20AND%20fixVersion%20%3D%200.8.3
>
> This vote will be open for 72 hours (Thursday, April 13, 2017 at 3:00AM
> PST).
>
> Please download the release candidate and evaluate the necessary items
> including checking hashes, signatures, build from source, run the
> binary artifacts in the binary release and test.
> Please vote:
>
> [ ] +1 Release this package as gearpump-0.8.3
> [ ] +0 no opinion
> [ ] -1 Do not release this package because because...
>
> Thanks,
> Karol
>
> -
> To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
> For additional commands, e-mail: general-h...@incubator.apache.org
>
>