Re: Concerning Sentry: A disagreement over the Apache Way and graduation

[Ralph Goers]

And I have to disagree with you Joe. To me, a mandatory RTC policy says “we 
don’t trust anybody”. Sure, it doesn’t discriminate, but it is also a PITA. One 
project I mentored uses RTC along with ReviewBoard and mandates that you cannot 
commit your own work and every commit must be formally reviewed. I have found 
this process to be so onerous that I have never committed any code to the 
project, even though I really would like to.  I find the pace of this project 
to be fairly slow.  But it seems to fit within the corporate culture that most 
of the committers seem to work in.

OTOH, I am involved in a project that uses CTR but where feature branches are 
frequently created to allow others to review and improve significant new work 
before it is integrated. As a consequence, new features are introduced at a 
much faster pace in this project.

Ralph

> On Nov 11, 2015, at 11:16 AM, Joe Witt  wrote:
> 
> "Trust is the basis of a healthy community"
> 
> -- For sure.
> 
> "and RTC (via Jira or otherwise) just screams "we don't trust you. we
> must review all commits first.""
> 
> -- I disagree.  RTC has merit independent of concerns of trust.  If
> trust issues are present in a community then any number of challenges
> will exist and all processes will suffer.  Keep in mind RTC applies to
> everyone (PMC, committer, contributor).  So it isn't about trust at
> all.  It is about community.
> 
> Not wanting to sidetrack this thread but also didn't want that comment
> to go without a counter.
> 
> Thanks
> Joe



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

Re: Apache Metrics, Not Apache Humans

[Bertrand Delacretaz]

On Mon, Nov 16, 2015 at 3:12 PM, Steve Loughran  wrote:
> ...The standard way to test this is run a test workload through the system and
> verify the results are as expected. For an ASF project, that'd probably be
> submitting a patch and seeing what happened

Creating a bot that does that autonomously and reports on the results
would be a fantastic research project ;-)

-Bertrand

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

Re: Apache Metrics, Not Apache Humans

[Steve Loughran]

> On 16 Nov 2015, at 00:28, toki  wrote:
> 
>> 
>> not about philosophy as different paths lead to the same mountain top
> 
> Somebody failed Buddhist Logic 101. (Not all paths lead to the same
> mountain top, even if they appear to start at the base of the same
> mountain.)


And foundational alpine mountaineering: a route that leads to the top may be 
beyond your abilities —and you may only discover that at a point where you 
cannot retreat.

This is why it is always good to have your own map and never follow the people 
in front. They may know where they are going, but that doesn't imply its the 
route you should do.

w.r.t metrics, they could be used to detect problems —but systems can look 
healthy metric wise, yet still be utterly broken. The standard way to test this 
is run a test workload through the system and verify the results are as 
expected. For an ASF project, that'd probably be submitting a patch and seeing 
what happened.

-Steve

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

Re: [VOTE] Retire Corinthia

[Joe Brockmeier]

On Sun, Nov 15, 2015, at 10:01 PM, Marvin Humphrey wrote:
> This is a vote of the IPMC to confirm the decision to retire the podling.
> 
> [ ] +1 to retire Corinthia from the Incubator

+1 (binding)

Best,

jzb
-- 
Joe Brockmeier
j...@zonker.net
Twitter: @jzb
http://www.dissociatedpress.net/

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

Re: Apache Metrics, Not Apache Humans

[Rich Bowen]

On 11/15/2015 01:20 PM, Marko Rodriguez wrote:
> The Apache Way should be about metrics, not about philosophy as different 
> paths lead to the same mountain top <--- See! Is that random Buddhist saying 
> that everyone just "believes" even true? :) Get the human out of the loop!

I, for one, welcome our new computer overlords, however ...

Metrics are useful for early warnings, but are awful at actually
determining community health. I would encourage you to ask our friends
at Bitergia, Markmail, Black Duck, and so on, about measuring
communities, since they've spent a decade or more each on the science.
They'll all tell you the same thing - metrics are incredibly useful, but
should be treated with great caution, and always, always, always include
a human element in evaluating. Because numbers don't show the whole
picture. Many healthy communities have low activity from time to time,
or perhaps have community patterns that evade your particular measuring
techniques. And unhealthy communities often learn how to game the
measures, or are doing unhealthy things outside of the scope of what's
being measured.

It's a fascinating thought experiment, and, indeed we should always
strive to have better metrics, but we must be intelligent - and human -
in how we read those numbers. One of the things that separates the ASF
from GitHub or SourceForge, is that we do have a unifying philosophy,
and a community of humans that defend it.


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

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

Re: Apache Metrics, Not Apache Humans

[Joe Brockmeier]

On Sun, Nov 15, 2015, at 11:58 PM, Sergio Fernández wrote:
> Marko, the metrics approach has been discussed in the past, for instance
> http://markmail.org/message/ubx3utli3bnltv75 So far my feeling is that
> the ASF prefer to deliver of people to build an opinion of projects rather
> than based them on pure statistical metrics. But I'd be happy to see something
> like that.

Metrics can help people form opinions ("huh, there's been fewer than 5
emails per month on Project Y's dev list ... that sounds like we should
look more closely at that project") but "pure statistical metrics" are a
*horrible* way to decide whether a project is "healthy."

A project could have a very active set of mailing lists, lots of
commits, push out releases regularly - and still be unhealthy in any
number of ways. (e.g. - all of the work is coming from people paid by
one company, or that community is refusing to accept patches from anyone
employed by another company, or any number of other situations that
don't indicate a project that's "healthy" as we understand health.)

Conversely, a project may have minimal traffic, very few commits, and so
forth - but still be "healthy" because it's a mature project that needs
very little development to stay useful and relevant to its community.

Best,

jzb
-- 
Joe Brockmeier
j...@zonker.net
Twitter: @jzb
http://www.dissociatedpress.net/

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

RTC vs CTR (was: Concerning Sentry...)

[Todd Lipcon]

[editing subject since the discussion has veered away from Sentry]

On Mon, Nov 16, 2015 at 7:56 AM, Ralph Goers 
wrote:

> And I have to disagree with you Joe. To me, a mandatory RTC policy says
> “we don’t trust anybody”. Sure, it doesn’t discriminate, but it is also a
> PITA. One project I mentored uses RTC along with ReviewBoard and mandates
> that you cannot commit your own work and every commit must be formally
> reviewed. I have found this process to be so onerous that I have never
> committed any code to the project, even though I really would like to.  I
> find the pace of this project to be fairly slow.  But it seems to fit
> within the corporate culture that most of the committers seem to work in.
>
> OTOH, I am involved in a project that uses CTR but where feature branches
> are frequently created to allow others to review and improve significant
> new work before it is integrated. As a consequence, new features are
> introduced at a much faster pace in this project.
>

I've seen this RTC vs CTR discussion come up a number of times over the
last ~6 years that I've been involved in ASF projects. For every strong
opinion in favor of CTR (like yours) there is a strong opinion in favor of
RTC (like mine).

The quick summary of my viewpoint is:

1) You're right, I don't trust anybody to make code changes to a complex
project with zero oversight. I currently work on a project that I
originally started, and was the only engineer on for a few months. Even
when I make changes to code that I wrote 100% of the module, I get others
to review my work, and you know what? It turns out better for it. Sometimes
they find bugs. Often they find areas where I didn't comment the code well,
design it as well as I could have, or missed potential performance
optimizations.

Coding's hard. Coding on complex projects is even harder. Some projects
aren't complex, and maybe on those a CTR policy makes a lot more sense. But
distributed systems, database storage engines, etc, are pretty hard to get
right, even for the "experts". I'm always glad to have a second pair of
eyes before I introduce a bug that takes down critical infrastructure.

2) Regardless of trust, code review helps build _shared ownership_ of code.
In community projects, without code review, it's easy to end up with "pet
features" or areas of code that only one person understands. When that
person moves on to new employment or new interests, the project is stuck
with a bunch of source code that no one understands how to maintain.
Forcing the original author to get some reviews before committing ensures
that there is a more likely path to project continuity after they move on
to new pastures.

3) Code reviews are a great way for engineers to learn from others in the
community. Earlier in my career, I certainly learned a lot from the
committers on projects like Hadoop and HBase where I "cut my teeth". And
even as a long-time committer on these systems, I still learn new things
from reviewing code written by newer members of the community. Review is
where a lot of the cross-contributor interaction takes place, so it helps
build a cohesive community.

Given #2 and #3, I see RTC as an extension of "community over code". Sure,
it might slow down the introduction of a new feature or fix to have to wait
to get a review from another community member. But, that's just code.
Getting more eyes and hands on the code builds the community.

After writing the above, I started to feel it was familiar and remember a
very similar discussion on hbase-dev last year:
http://mail-archives.apache.org/mod_mbox/hbase-dev/201508.mbox/%3CCA+RK=_dz+_rzumfwvya0tkvxtk4saeie6pwpgs2mxvsbq8h...@mail.gmail.com%3E
- I'd recommend people go check that one out to see the various viewpoints.

I don't anticipate that the above arguments will convince you, or anyone
else who believes in CTR, to change your mind. But, as mentioned in some
other recent incubator threads, let's not use the incubator as a
battleground for personal opinions. There are successful Apache projects
following all sorts of development models, and the important thing is only
that (a) projects build inclusive communities, and (b) projects follow
proper licensing/release/etc processes for legal reasons.

-Todd

Re: RTC vs CTR (was: Concerning Sentry...)

[Andrew Purtell]

> After writing the above, I started to feel it was familiar and remember a 
> very similar discussion on hbase-dev last year:
http://mail-archives.apache.org/mod_mbox/hbase-dev/201508.mbox/%3CCA+RK=_dz+_rzumfwvya0tkvxtk4saeie6pwpgs2mxvsbq8h...@mail.gmail.com%3E
 - I'd recommend people go check that one out to see the various viewpoints.

That was a great discussion covering all manner of ideas, crazy or otherwise. 
Key is we brought the discussion out to a public forum and had a no drama 
floating of views and options with an aim to build consensus. 

That consensus on HBase was that RTC is preferred over the alternative, pretty 
much for the code quality reasons Todd discusses below. Any other project could 
come to a different consensus. I don't think we need to or should prescribe RTC 
or CTR up front. Each community should have this discussion and come to a 
rational consensus of what choice they should make for their particular needs. 


> On Nov 16, 2015, at 9:53 AM, Todd Lipcon  wrote:
> 
> [editing subject since the discussion has veered away from Sentry]
> 
> On Mon, Nov 16, 2015 at 7:56 AM, Ralph Goers 
> wrote:
> 
>> And I have to disagree with you Joe. To me, a mandatory RTC policy says
>> “we don’t trust anybody”. Sure, it doesn’t discriminate, but it is also a
>> PITA. One project I mentored uses RTC along with ReviewBoard and mandates
>> that you cannot commit your own work and every commit must be formally
>> reviewed. I have found this process to be so onerous that I have never
>> committed any code to the project, even though I really would like to.  I
>> find the pace of this project to be fairly slow.  But it seems to fit
>> within the corporate culture that most of the committers seem to work in.
>> 
>> OTOH, I am involved in a project that uses CTR but where feature branches
>> are frequently created to allow others to review and improve significant
>> new work before it is integrated. As a consequence, new features are
>> introduced at a much faster pace in this project.
> 
> I've seen this RTC vs CTR discussion come up a number of times over the
> last ~6 years that I've been involved in ASF projects. For every strong
> opinion in favor of CTR (like yours) there is a strong opinion in favor of
> RTC (like mine).
> 
> The quick summary of my viewpoint is:
> 
> 1) You're right, I don't trust anybody to make code changes to a complex
> project with zero oversight. I currently work on a project that I
> originally started, and was the only engineer on for a few months. Even
> when I make changes to code that I wrote 100% of the module, I get others
> to review my work, and you know what? It turns out better for it. Sometimes
> they find bugs. Often they find areas where I didn't comment the code well,
> design it as well as I could have, or missed potential performance
> optimizations.
> 
> Coding's hard. Coding on complex projects is even harder. Some projects
> aren't complex, and maybe on those a CTR policy makes a lot more sense. But
> distributed systems, database storage engines, etc, are pretty hard to get
> right, even for the "experts". I'm always glad to have a second pair of
> eyes before I introduce a bug that takes down critical infrastructure.
> 
> 2) Regardless of trust, code review helps build _shared ownership_ of code.
> In community projects, without code review, it's easy to end up with "pet
> features" or areas of code that only one person understands. When that
> person moves on to new employment or new interests, the project is stuck
> with a bunch of source code that no one understands how to maintain.
> Forcing the original author to get some reviews before committing ensures
> that there is a more likely path to project continuity after they move on
> to new pastures.
> 
> 3) Code reviews are a great way for engineers to learn from others in the
> community. Earlier in my career, I certainly learned a lot from the
> committers on projects like Hadoop and HBase where I "cut my teeth". And
> even as a long-time committer on these systems, I still learn new things
> from reviewing code written by newer members of the community. Review is
> where a lot of the cross-contributor interaction takes place, so it helps
> build a cohesive community.
> 
> Given #2 and #3, I see RTC as an extension of "community over code". Sure,
> it might slow down the introduction of a new feature or fix to have to wait
> to get a review from another community member. But, that's just code.
> Getting more eyes and hands on the code builds the community.
> 
> After writing the above, I started to feel it was familiar and remember a
> very similar discussion on hbase-dev last year:
> http://mail-archives.apache.org/mod_mbox/hbase-dev/201508.mbox/%3CCA+RK=_dz+_rzumfwvya0tkvxtk4saeie6pwpgs2mxvsbq8h...@mail.gmail.com%3E
> - I'd recommend people go check that one out to see the various viewpoints.
> 
> I don't anticipate that the above arguments 

Re: [VOTE] Apache Apex Malhar Release 3.2.0-incubating (RC2)

[Alan Gates]

+1, see dev vote thread for details of checking I did.

Alan.


Thomas Weise 
November 13, 2015 at 21:30
Hi,

Please vote on the following Apache Apex Malhar 3.2.0-incubating release
candidate. This is the first release of the Malhar library in ASF and 
it is

based on Apex core 3.2.0-incubating. This is a source release.

The Apache Apex PPMC has voted to release this candidate.

The community vote passed with 14 binding votes from the PPMC (including 3
votes from IPMC members).

PPMC vote call:

http://mail-archives.apache.org/mod_mbox/incubator-apex-dev/201511.mbox/%3CCAKJfLDMWgzncdN7-nxXksE3F2p3xLfCu%2B_nNL-q6p-H_kwASdA%40mail.gmail.com%3E

PPMC vote result:

http://mail-archives.apache.org/mod_mbox/incubator-apex-dev/201511.mbox/%3CCAKJfLDPnu2vJZyt%3D9JNmt3nG_nHYk%2B3AseE__SN%3DKXmJ5AskeQ%40mail.gmail.com%3E

List of all issues fixed: http://s.apache.org/2fZ

Staging directory:
https://dist.apache.org/repos/dist/dev/incubator/apex/malhar/v3.2.0-incubating-RC2
Source zip:
https://dist.apache.org/repos/dist/dev/incubator/apex/malhar/v3.2.0-incubating-RC2/malhar-3.2.0-incubating-source-release.zip
Source tar.gz:
https://dist.apache.org/repos/dist/dev/incubator/apex/malhar/v3.2.0-incubating-RC2/malhar-3.2.0-incubating-source-release.tar.gz
Maven staging repository:
https://repository.apache.org/content/repositories/orgapacheapex-1003/

Git source:
https://git-wip-us.apache.org/repos/asf?p=incubator-apex-malhar.git;a=commit;h=refs/tags/v3.2.0-incubating-RC2
(commit:
ff0b0d080ebd8d00cee47321df90dad9357bbead)

PGP key:
http://pgp.mit.edu:11371/pks/lookup?op=vindex=t...@apache.org
KEYS file:
https://dist.apache.org/repos/dist/release/incubator/apex/KEYS

More information at:
http://apex.incubator.apache.org

Please try the release and vote; vote will close after 72 hours.

[ ] +1 approve
[ ] -1 disapprove (and reason why)

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

Please add (binding) if your vote is binding.

Thanks,
Thomas

Re: RTC vs CTR (was: Concerning Sentry...)

[Greg Stein]

On Mon, Nov 16, 2015 at 11:53 AM, Todd Lipcon  wrote:
>...

> 1) You're right, I don't trust anybody to make code changes to a complex
> project with zero oversight. I currently work on a project that I
>

I have always found the "complex project" to merely be an excuse for
control/no-trust.

All software is hard. Your project is no more complex than others.

-g

Re: RTC vs CTR (was: Concerning Sentry...)

[Todd Lipcon]

On Mon, Nov 16, 2015 at 2:50 PM, Greg Stein  wrote:

> On Mon, Nov 16, 2015 at 11:53 AM, Todd Lipcon  wrote:
> >...
>
> > 1) You're right, I don't trust anybody to make code changes to a complex
> > project with zero oversight. I currently work on a project that I
> >
>
> I have always found the "complex project" to merely be an excuse for
> control/no-trust.
>
> All software is hard. Your project is no more complex than others.
>
>
Having worked on projects in pretty much every layer of the software stack,
I think we'll just have to agree to disagree.

Thankfully, the actual rules of the ASF have nothing to say on this matter,
and it's diversity of opinions that makes it an interesting community. I
just don't want projects in incubation (or considering incubation) to think
that the ASF mandates one or the other style of development.

-Todd
-- 
Todd Lipcon
Software Engineer, Cloudera

Re: RTC vs CTR (was: Concerning Sentry...)

[Ted Dunning]

On Tue, Nov 17, 2015 at 7:56 AM, Todd Lipcon  wrote:

> > I have always found the "complex project" to merely be an excuse for
> > control/no-trust.
> >
> > All software is hard. Your project is no more complex than others.
> >
> >
> Having worked on projects in pretty much every layer of the software stack,
> I think we'll just have to agree to disagree.


Hm

I really have to agree with Todd here.  Systems with formal verification
requirements or strong real-time requirements are much harder to modify
correctly than certain other kinds of code that I have worked on.  Systems
with lower level languages can make these much harder again.

Differing levels of reliability requirements also change the level of
difficulty.  I worked once on a hard real-time medical instrument and am
proud to say that our methods of extensive review resulted in zero bugs
ever detected in the core instrument over tens of thousands of units
shipped and used over >10 years even though we only had stone-age tools for
development.  That was *hard* to do.  Most of the code that I work on is
*much* easier. We succeeded then due to our embrace of aggressive and
ongoing review.

RTC can be framed as "I don't trust you to do things right". It might even
be objectively true for some codes.  I have had far more success in framing
RTC as "I trust you to help me make things better".  The former statement
leads to systems like Greg describes.  The latter statement can bring
people together like Todd describes.

I do believe that CTR is appropriate in many settings, but I do think that
in the extreme that leads to something like github or CPAN or CRAN or PyPi
or npm. There is very little community connection between different
projects (on github) or modules (on CRAN or PyPi), but there is also a nice
freedom to innovate (and freedom to fail). Just as you need to take
measures to avoid RTC being used as a club, you need to take measures to
avoid the community drifting apart with CTR due to low interaction levels.

Metaphorically, with strong binding you have gravitational collapse of a
community which can lead to lots of heat and possibly a supernova or black
hole. With weak binding, you can have the universe expand into a cold quiet
place.  Neither extreme is particularly desirable.

[ANNOUNCE] Apache sirona 0.3-incubating released

[Romain Manni-Bucau]

The Apache Sirona team is pleased to announce the immediate
availability of the 0.3-incubating release. The release note can be
found here [1]; The source code and binary package can be downloaded
from Sirona download page [2].

This release includes several enhancements on the javaagent and path
tracking features as well as new features like websocket push support
and new alerter API.

The Apache Sirona Team would like to hear from you and welcomes your
comments and contributions.

Thanks,
The Apache Sirona Team

[1] http://sirona.incubator.apache.org/docs/0.3-incubating/jira-report.html
[2] http://sirona.incubator.apache.org/download.cgi

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

Re: RTC vs CTR (was: Concerning Sentry...)

[Greg Stein]

On Mon, Nov 16, 2015 at 4:56 PM, Todd Lipcon  wrote:

> On Mon, Nov 16, 2015 at 2:50 PM, Greg Stein  wrote:
> > On Mon, Nov 16, 2015 at 11:53 AM, Todd Lipcon  wrote:
> > >...
> > > 1) You're right, I don't trust anybody to make code changes to a
> complex
> > > project with zero oversight. I currently work on a project that I
> >
> > I have always found the "complex project" to merely be an excuse for
> > control/no-trust.
> >
> > All software is hard. Your project is no more complex than others.
>
> Having worked on projects in pretty much every layer of the software stack,
> I think we'll just have to agree to disagree.
>

hahaha... and you prove my point.

Cheers,
-g

Re: [VOTE] Apache Apex Malhar Release 3.2.0-incubating (RC2)

[Sasha Parfenov]

+1.  Carried over from Apache Apex (incubating) dev list vote.

Thanks,
Sasha

On Mon, Nov 16, 2015 at 11:45 AM, Alan Gates  wrote:

> +1, see dev vote thread for details of checking I did.
>
> Alan.
>
> Thomas Weise 
> November 13, 2015 at 21:30
> Hi,
>
> Please vote on the following Apache Apex Malhar 3.2.0-incubating release
> candidate. This is the first release of the Malhar library in ASF and it is
> based on Apex core 3.2.0-incubating. This is a source release.
>
> The Apache Apex PPMC has voted to release this candidate.
>
> The community vote passed with 14 binding votes from the PPMC (including 3
> votes from IPMC members).
>
> PPMC vote call:
>
>
> http://mail-archives.apache.org/mod_mbox/incubator-apex-dev/201511.mbox/%3CCAKJfLDMWgzncdN7-nxXksE3F2p3xLfCu%2B_nNL-q6p-H_kwASdA%40mail.gmail.com%3E
>
> PPMC vote result:
>
>
> http://mail-archives.apache.org/mod_mbox/incubator-apex-dev/201511.mbox/%3CCAKJfLDPnu2vJZyt%3D9JNmt3nG_nHYk%2B3AseE__SN%3DKXmJ5AskeQ%40mail.gmail.com%3E
>
> List of all issues fixed: http://s.apache.org/2fZ
>
> Staging directory:
>
> https://dist.apache.org/repos/dist/dev/incubator/apex/malhar/v3.2.0-incubating-RC2
> Source zip:
>
> https://dist.apache.org/repos/dist/dev/incubator/apex/malhar/v3.2.0-incubating-RC2/malhar-3.2.0-incubating-source-release.zip
> Source tar.gz:
>
> https://dist.apache.org/repos/dist/dev/incubator/apex/malhar/v3.2.0-incubating-RC2/malhar-3.2.0-incubating-source-release.tar.gz
> Maven staging repository:
> https://repository.apache.org/content/repositories/orgapacheapex-1003/
>
> Git source:
>
> https://git-wip-us.apache.org/repos/asf?p=incubator-apex-malhar.git;a=commit;h=refs/tags/v3.2.0-incubating-RC2
> (commit:
> ff0b0d080ebd8d00cee47321df90dad9357bbead)
>
> PGP key:
> http://pgp.mit.edu:11371/pks/lookup?op=vindex=t...@apache.org
> KEYS file:
> https://dist.apache.org/repos/dist/release/incubator/apex/KEYS
>
> More information at:
> http://apex.incubator.apache.org
>
> Please try the release and vote; vote will close after 72 hours.
>
> [ ] +1 approve
> [ ] -1 disapprove (and reason why)
>
> http://www.apache.org/foundation/voting.html
>
> Please add (binding) if your vote is binding.
>
> Thanks,
> Thomas
>
>

[VOTE] Release Apache Myriad 0.1.0 (incubating)

[Santosh Marella]

Hi,

The Apache Myriad community has voted on and approved a proposal to release
Apache Myriad 0.1.0-incubating.

Vote call:
http://mail-archives.apache.org/mod_mbox/incubator-myriad-dev/201511.mbox/%3CCAGim3%2B2fFCE4LC7HpNPtg5r7_01sFzkfLsyGaLvXcV%2B6f-_CRg%40mail.gmail.com%3E

Vote result:
3 binding +1 votes
4 non-binding +1 votes
No -1 votes
http://mail-archives.apache.org/mod_mbox/incubator-myriad-dev/201511.mbox/%3CCAGim3+3BSP=o1ZoJZq3mau-nFd7CGP1y+mRE9cOdXKpPAm=e...@mail.gmail.com%3E

Release Notes:
https://cwiki.apache.org/confluence/display/MYRIAD/Release+Notes

The commit to be voted upon is tagged with "myriad-0.1.0-incubating-rc2"
and is available here:
https://git1-us-west.apache.org/repos/asf/incubator-myriad/repo?p=incubator-myriad.git;a=commit;h=fb93291e9377cccf625bed93a9ad1ae1c4b76529

The artifacts to be voted upon are located below. Please note that this is
a source release:
https://dist.apache.org/repos/dist/dev/incubator/myriad/myriad-0.1.0-incubating-rc2/

Release artifacts are signed with the following key:
https://people.apache.org/keys/committer/smarella.asc

We request the permission of IPMC to publish the above release candidate as
Apache Myriad 0.1.0-incubating. Please try out the package and vote.

The vote is open for a minimum of 72 hours or until the necessary number of
votes (3 binding +1s) is reached.

[ ] +1 Release this package as Apache Myriad 0.1.0-incubating
[ ]  0 I don't feel strongly about it, but I'm okay with the release
[ ] -1 Do not release this package because...

Please add (binding) if your vote is binding.

Thanks,
Santosh
(On behalf of Apache Myriad PPMC)

[RESULT][VOTE] Apache Apex Malhar Release 3.2.0-incubating (RC2)

[Thomas Weise]

The vote passes with 3, +1 binding votes from IPMC members and no -1s:

Justin Mclean
Hitesh Shah
Alan Gates

Thanks for voting, we will proceed with the release activities.

Thomas

On Mon, Nov 16, 2015 at 5:57 PM, Sasha Parfenov 
wrote:

> +1.  Carried over from Apache Apex (incubating) dev list vote.
>
> Thanks,
> Sasha
>
> On Mon, Nov 16, 2015 at 11:45 AM, Alan Gates  wrote:
>
>> +1, see dev vote thread for details of checking I did.
>>
>> Alan.
>>
>> Thomas Weise 
>> November 13, 2015 at 21:30
>> Hi,
>>
>> Please vote on the following Apache Apex Malhar 3.2.0-incubating release
>> candidate. This is the first release of the Malhar library in ASF and it
>> is
>> based on Apex core 3.2.0-incubating. This is a source release.
>>
>> The Apache Apex PPMC has voted to release this candidate.
>>
>> The community vote passed with 14 binding votes from the PPMC (including 3
>> votes from IPMC members).
>>
>> PPMC vote call:
>>
>>
>> http://mail-archives.apache.org/mod_mbox/incubator-apex-dev/201511.mbox/%3CCAKJfLDMWgzncdN7-nxXksE3F2p3xLfCu%2B_nNL-q6p-H_kwASdA%40mail.gmail.com%3E
>>
>> PPMC vote result:
>>
>>
>> http://mail-archives.apache.org/mod_mbox/incubator-apex-dev/201511.mbox/%3CCAKJfLDPnu2vJZyt%3D9JNmt3nG_nHYk%2B3AseE__SN%3DKXmJ5AskeQ%40mail.gmail.com%3E
>>
>> List of all issues fixed: http://s.apache.org/2fZ
>>
>> Staging directory:
>>
>> https://dist.apache.org/repos/dist/dev/incubator/apex/malhar/v3.2.0-incubating-RC2
>> Source zip:
>>
>> https://dist.apache.org/repos/dist/dev/incubator/apex/malhar/v3.2.0-incubating-RC2/malhar-3.2.0-incubating-source-release.zip
>> Source tar.gz:
>>
>> https://dist.apache.org/repos/dist/dev/incubator/apex/malhar/v3.2.0-incubating-RC2/malhar-3.2.0-incubating-source-release.tar.gz
>> Maven staging repository:
>> https://repository.apache.org/content/repositories/orgapacheapex-1003/
>>
>> Git source:
>>
>> https://git-wip-us.apache.org/repos/asf?p=incubator-apex-malhar.git;a=commit;h=refs/tags/v3.2.0-incubating-RC2
>> (commit:
>> ff0b0d080ebd8d00cee47321df90dad9357bbead)
>>
>> PGP key:
>> http://pgp.mit.edu:11371/pks/lookup?op=vindex=t...@apache.org
>> KEYS file:
>> https://dist.apache.org/repos/dist/release/incubator/apex/KEYS
>>
>> More information at:
>> http://apex.incubator.apache.org
>>
>> Please try the release and vote; vote will close after 72 hours.
>>
>> [ ] +1 approve
>> [ ] -1 disapprove (and reason why)
>>
>> http://www.apache.org/foundation/voting.html
>>
>> Please add (binding) if your vote is binding.
>>
>> Thanks,
>> Thomas
>>
>>
>

Re: RTC vs CTR (was: Concerning Sentry...)

[Bertrand Delacretaz]

On Tue, Nov 17, 2015 at 5:25 AM, Ted Dunning  wrote:
> ...RTC can be framed as "I don't trust you to do things right"...

Or also "I don't trust myself 100% to do things right here and would
like systematic reviews of my commits".

Like all sharp tools I think RTC has its place, but shouldn't be
abused. It's perfectly possible to have some parts of a project's code
under RTC and others under CTR.

-Bertrand

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