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

[Richard Frovarp]

On 11/18/2015 09:20 AM, Stephen Connolly wrote:

On 18 November 2015 at 14:24, Emmanuel Lécharny  wrote:


Le 18/11/15 14:34, Stephen Connolly a écrit :

On Wednesday 18 November 2015, Emmanuel Lécharny 
wrote:


Le 18/11/15 11:31, Stephen Connolly a écrit :

I believe the issue here is that with CTR it is very easy to miss the

72h

lazy consensus voting (with an assumed +1 absence any votes cast) that

most

CTR projects operate under... and thus it can also be very easy to miss

the

fact that there are reviews going on (and I am being generous here, I
suspect that a lot of CTR commits are only reviewed within the 72h by a
blind man on a galloping horse)

I'm not sure why you are correlating commit reviews and a 72h vote...
They are two really different things.

When I last read up my understanding is that CTR operates as if there is

a

vote for each commit.

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

*Commit-Then-Review*<
http://www.apache.org/foundation/glossary.html#CommitThenReview>
 (Often abbreviated 'CTR' or 'C-T-R'.) A policy governing code
 changes which permits developers to make changes at will, with the
 possibility of being retroactively vetoed
 . C-T-R is an
 application of decision making through lazy consensus
 . The
 C-T-R model is useful in rapid-prototyping environments, but because
 of the lack of mandatory review it may permit more bugs through in
 daily practice than the R-T-C
 
 alternative.

The important piece here is '...the lack of mandatory review...'


 From the same glossary:

Lazy consensus

(Also called 'lazy approval'.) A decision-making policy which assumes
general consent if no responses are posted within a defined period. For
example, "I'm going to commit this by lazy consensus if no-one objects
within the next three days." Also see Consensus Approval
 , Majority
Approval  ,
and the description of the voting process
.



So Lazy consensus is a voting process... if the code was committed more
than three days ago, then there must have been a successful vote for
committing that code... it was a lazy vote because there was no explicit
[VOTE] thread.

My point is that when I see people arguing for RTC over CTR what I maintain
they are actually arguing over is the lazy consensus voting of each commit.

People who want RTC really do not want lazy voting.
People who want CTR really want lazy voting.

I suspect that RTC with lazy consensus would be just as good an option for
Greg and just as bad an option for Tony

I also suspect that (in a parallel universe where the mess of revert
commits could be magically resolved) CTR without lazy consensus would be
just as good an option for Tony and just as bad an option for Greg.

*My* point is that it is the lazy consensus that people are arguing about.

CTR works best with lazy consensus (as there is the whole mess of
reverting... but you'd only do that for commits that fail on the code
provenance issue... so in practice it's not really anything even close to a
big deal)

RTC works best with non-lazy consensus and is acceptable with lazy
consensus.

In my day job, we use a sort of RTC with lazyish consensus...
It helps that all our stuff happens on DSCMs where we can just commit away
to our own branch until we are ready to merge.
We then flag the merge request for review... if you have 2 positive reviews
and no negative reviews in 12 hours, merge away... if you have 1 positive
review and no negative reviews after 12 hours, merge away... if you have no
reviews after 1 week, merge away




Isn't the RTC that is being described actually lazy consensus as well? 
If I submit, you review and apply, where is the active decision from the 
rest of the PMC? If it has been committed, presumably two people have 
agreed, but they need not be PMC and two people doesn't count as a 
successful vote. You at least need a third, and a option for others to 
disagree.


So my guess is that RTC is being done as a lazy consensus all of the time.

-
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/17/2015 08:13 PM, Marko Rodriguez wrote:
> Hi,
> 
> I suppose the distilled intention of the proposal is to identify the 
> answer(s) to the following question:
> 
>   What makes a "good" open source project?
> 
> As I read on general@ and from our project's mentors, "good" is grounded in 
> personal experience (i.e. anecdotes). Why not use the data you gather to 
> quantify "good." This way its not a "well I believe," its more of "in this 
> particular situation given these variables, there is a X% success rate." 
> Also, it leads to more exploration -- "Huh, I don't think I've ever seen an 
> Apache project do it like that -- hell, give it a try and lets glean the 
> stats from it. If anything, we learn."
> 
> Personally, I'm all about: "Do whatever you want." (try it -- who cares as 
> long as its legal). However, if there must be structure, perhaps The Apache 
> Way is a local optima? Only a broad statistical landscape will tell. And only 
> in data gathering and analysis will that landscape be constructed from the 
> numerous, diverse social/technical experiments -- i.e. Apache projects!  
> Without the openness and computational introspection, Apache podlings will 
> simply internalize the objective of "just do as expected and graduate." The 
> problem is that this only engrains a particular philosophy/approach that may 
> not be fit in the long run. It just seems (to me) that this 
> "carrot-on-a-stick model" of podling/top-level is outdated much like our 
> modern education system (just take the classes, get the grades, give the 
> teacher an apple, and get the hell out of here).
> 
> Again -- just shootin' ideas. I have no bee-in-the-bonet or axe-to-grind. 
> I've just become interested in how your minds tick...
> 

So, I am a huge fan of collecting metrics, trying to squeeze wisdom out
of them, and making community decisions based on what's likely to
succeed. The trouble is, past performance is not a guarantee - or even a
reliable indicator - of future performance, because there are so many
variables to consider.

So, yes, we should do this, but we should avoid trusting it completely,
because it is known to fail.

We can cite numerous examples of deeply dysfunctional, hostile,
unhealthy communities that are HUGELY successful. Several come to mind
immediately.

We can also cite friendly, welcoming, well-managed communities that are
unable to achieve any measurable success in terms of actual user adoption.

In each of these case, the metrics are useful, and interesting, and
worthy of study, and even suggest decisions that should/could be made.
But they are misleading unless a human is there to interpret and
implement them.

I'd love to see more things like Black Duck and Bitergia, and see them
being open sourced like some of the work that Roberto Galoppini has
worked on, and see more intelligence and less shot-in-the-dark
understanding coming out of them. If there is wisdom to be gained, and
things that can be consistently reproducible, we should pursue that. So
much in open source, however, depends on personalities, and we tend to
attract some of the more ... ahem ... interesting personalities in the
world.


-- 
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: RTC vs CTR (was: Concerning Sentry...)

[Stephen Connolly]

typo s/every/revert/

If you do CTR and there are lots of vetos... which can happen if the
reviews are requesting rework or changes... then there would need to be a
lot of revert commits to revert the commits that were vetoed.

Thankfully in CTR mostly the case is you just commit the rework rather than
revert the commit. The only case where you want to revert the commit is the
case of compromised IP where the revert is saying "actually this IP is not
correctly assigned"

On 18 November 2015 at 17:02, Ross Gardler 
wrote:

> I agree, mostly, with your mail Stephen, but I wonder about the reference
> you make to "the mess of every commits". Do you really see that?
>
> If you do see it I suspect the project has a problem. In my experience
> reverts are rare. We prefer people improve what is there rather than revert
> what they don't like. It's not always possible so occasional reverts are
> likely, but you shouldn't be seeing lots of reverts.
>
> Sent from my Windows Phone
> 
> From: Stephen Connolly
> Sent: ‎11/‎18/‎2015 7:21 AM
> To: general@incubator.apache.org
> Subject: Re: RTC vs CTR (was: Concerning Sentry...)
>
> On 18 November 2015 at 14:24, Emmanuel Lécharny 
> wrote:
>
> > Le 18/11/15 14:34, Stephen Connolly a écrit :
> > > On Wednesday 18 November 2015, Emmanuel Lécharny 
> > > wrote:
> > >
> > >> Le 18/11/15 11:31, Stephen Connolly a écrit :
> > >>> I believe the issue here is that with CTR it is very easy to miss the
> > 72h
> > >>> lazy consensus voting (with an assumed +1 absence any votes cast)
> that
> > >> most
> > >>> CTR projects operate under... and thus it can also be very easy to
> miss
> > >> the
> > >>> fact that there are reviews going on (and I am being generous here, I
> > >>> suspect that a lot of CTR commits are only reviewed within the 72h
> by a
> > >>> blind man on a galloping horse)
> > >> I'm not sure why you are correlating commit reviews and a 72h vote...
> > >> They are two really different things.
> > >
> > > When I last read up my understanding is that CTR operates as if there
> is
> > a
> > > vote for each commit.
> >
> >
> https://na01.safelinks.protection.outlook.com/?url=http%3a%2f%2fwww.apache.org%2ffoundation%2fglossary.html=01%7c01%7cRoss.Gardler%40microsoft.com%7cd4b92b7624054c648d7a08d2f02bdd99%7c72f988bf86f141af91ab2d7cd011db47%7c1=TL9a3HXjrIU7ntwJs8RqxDraGBtcz%2bzbjJACbgh%2f9LM%3d
> :
> >
> > *Commit-Then-Review*<
> >
> https://na01.safelinks.protection.outlook.com/?url=http%3a%2f%2fwww.apache.org%2ffoundation%2fglossary.html%23CommitThenReview=01%7c01%7cRoss.Gardler%40microsoft.com%7cd4b92b7624054c648d7a08d2f02bdd99%7c72f988bf86f141af91ab2d7cd011db47%7c1=3qCZYrBRMPK4j7qZpzlgHAmNW9L%2bGQp2QYgPjeDzm%2bI%3d
> >
> > (Often abbreviated 'CTR' or 'C-T-R'.) A policy governing code
> > changes which permits developers to make changes at will, with the
> > possibility of being retroactively vetoed
> > <
> https://na01.safelinks.protection.outlook.com/?url=http%3a%2f%2fwww.apache.org%2ffoundation%2fglossary.html%23Veto=01%7c01%7cRoss.Gardler%40microsoft.com%7cd4b92b7624054c648d7a08d2f02bdd99%7c72f988bf86f141af91ab2d7cd011db47%7c1=Bwshvacajf1bpiCM%2bmzVxo0Ow8DgsidGmOhW5dLKSEY%3d>.
> C-T-R is an
> > application of decision making through lazy consensus
> > <
> https://na01.safelinks.protection.outlook.com/?url=http%3a%2f%2fwww.apache.org%2ffoundation%2fglossary.html%23LazyConsensus=01%7c01%7cRoss.Gardler%40microsoft.com%7cd4b92b7624054c648d7a08d2f02bdd99%7c72f988bf86f141af91ab2d7cd011db47%7c1=7GegAJIQoysXF8P6q2pb17XIDqDaNo3G48W0uYME9%2bk%3d>.
> The
> > C-T-R model is useful in rapid-prototyping environments, but because
> > of the lack of mandatory review it may permit more bugs through in
> > daily practice than the R-T-C
> > <
> https://na01.safelinks.protection.outlook.com/?url=http%3a%2f%2fwww.apache.org%2ffoundation%2fglossary.html%23ReviewThenCommit=01%7c01%7cRoss.Gardler%40microsoft.com%7cd4b92b7624054c648d7a08d2f02bdd99%7c72f988bf86f141af91ab2d7cd011db47%7c1=WwxXkFBwIeUhUMcao%2ff4kffNgSy8T8eN1amIhOiv%2fvo%3d
> >
> > alternative.
> >
> > The important piece here is '...the lack of mandatory review...'
> >
> >
> > From the same glossary:
>
> Lazy consensus
> > (Also called 'lazy approval'.) A decision-making policy which assumes
> > general consent if no responses are posted within a defined period. For
> > example, "I'm going to commit this by lazy consensus if no-one objects
> > within the next three days." Also see Consensus Approval
> > <
> https://na01.safelinks.protection.outlook.com/?url=http%3a%2f%2fwww.apache.org%2ffoundation%2fglossary.html%23ConsensusApproval=01%7c01%7cRoss.Gardler%40microsoft.com%7cd4b92b7624054c648d7a08d2f02bdd99%7c72f988bf86f141af91ab2d7cd011db47%7c1=9zElQFn5AfUKcvECMlo4S0H1eN5NTgBy6vDQSYKg2gQ%3d>
> , Majority
> > 

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

[Ross Gardler]

Summarizing:

In a healthy project I believe that the only significant things that change 
between CTR and RTC are:

1) speed of commit (CTR is faster)
2) quality of master, not releases (RTC catches most issues before commit, CTR 
shortly after commit)

I agree with others, nothing in the Apache Way says RTC is bad. Personally I 
believe CTR builds communities faster, but there are successful RTC projects. 
What really matters is  managing the trade off above.

Justification (mostly a repeat of what has been said already):

I don't care what the website says. If I have a personal interest in a project 
succeeding then I will do everything in my power to ensure it succeeds. I 
assume the same is true for everyone else. This means that "mandatory" reviews 
are not required because they just get done by the people who care about 
project success.

RTC does not guarantee reviews any more than CTR does, despite what a web page 
says. It merely guarantees a way period in which someone will give a patch a 
cursory glance. I'm not saying this is the normal RTC behavior, I'm merely 
saying this is all that is guaranteed. Fortunately the process doesn't change 
the way most people behave in a project, we can still trust them to do their 
reviews.

Furthermore, there seems to be an assumption that CTR means complex or 
controversial code will be committed. In my experience this is not true. People 
don't like to waste time writing code that may be rejected. What I see is 
people discussing such changes, and providing psuedo code and then real code 
for review before committing to master. It saves time to get early review.

Ross

Sent from my Windows Phone

From: Emmanuel Lécharny
Sent: ‎11/‎18/‎2015 6:25 AM
To: general@incubator.apache.org
Subject: Re: RTC vs CTR (was: Concerning Sentry...)

Le 18/11/15 14:34, Stephen Connolly a écrit :
> On Wednesday 18 November 2015, Emmanuel Lécharny 
> wrote:
>
>> Le 18/11/15 11:31, Stephen Connolly a écrit :
>>> I believe the issue here is that with CTR it is very easy to miss the 72h
>>> lazy consensus voting (with an assumed +1 absence any votes cast) that
>> most
>>> CTR projects operate under... and thus it can also be very easy to miss
>> the
>>> fact that there are reviews going on (and I am being generous here, I
>>> suspect that a lot of CTR commits are only reviewed within the 72h by a
>>> blind man on a galloping horse)
>> I'm not sure why you are correlating commit reviews and a 72h vote...
>> They are two really different things.
>
> When I last read up my understanding is that CTR operates as if there is a
> vote for each commit.

https://na01.safelinks.protection.outlook.com/?url=http%3a%2f%2fwww.apache.org%2ffoundation%2fglossary.html=01%7c01%7cRoss.Gardler%40microsoft.com%7ced413f018da3415cdfc108d2f0240bc9%7c72f988bf86f141af91ab2d7cd011db47%7c1=zFAIzqa9u1j6hu4m21erCSE9DRBOlcuEqRh5%2bRzHdZg%3d
 :

*Commit-Then-Review*
(Often abbreviated 'CTR' or 'C-T-R'.) A policy governing code
changes which permits developers to make changes at will, with the
possibility of being retroactively vetoed

.
 C-T-R is an
application of decision making through lazy consensus

.
 The
C-T-R model is useful in rapid-prototyping environments, but because
of the lack of mandatory review it may permit more bugs through in
daily practice than the R-T-C


alternative.

The important piece here is '...the lack of mandatory review...'



>  It's a really lazy vote though as the vote passes if
> nobody comments on the commit after 72h... And personally I do not see much
> value in post-hoc votes... What are we going to do, rewrite history? But as
> I understand the "vote" is so that the code in source control 

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

[Ross Gardler]

I agree, mostly, with your mail Stephen, but I wonder about the reference you 
make to "the mess of every commits". Do you really see that?

If you do see it I suspect the project has a problem. In my experience reverts 
are rare. We prefer people improve what is there rather than revert what they 
don't like. It's not always possible so occasional reverts are likely, but you 
shouldn't be seeing lots of reverts.

Sent from my Windows Phone

From: Stephen Connolly
Sent: ‎11/‎18/‎2015 7:21 AM
To: general@incubator.apache.org
Subject: Re: RTC vs CTR (was: Concerning Sentry...)

On 18 November 2015 at 14:24, Emmanuel Lécharny  wrote:

> Le 18/11/15 14:34, Stephen Connolly a écrit :
> > On Wednesday 18 November 2015, Emmanuel Lécharny 
> > wrote:
> >
> >> Le 18/11/15 11:31, Stephen Connolly a écrit :
> >>> I believe the issue here is that with CTR it is very easy to miss the
> 72h
> >>> lazy consensus voting (with an assumed +1 absence any votes cast) that
> >> most
> >>> CTR projects operate under... and thus it can also be very easy to miss
> >> the
> >>> fact that there are reviews going on (and I am being generous here, I
> >>> suspect that a lot of CTR commits are only reviewed within the 72h by a
> >>> blind man on a galloping horse)
> >> I'm not sure why you are correlating commit reviews and a 72h vote...
> >> They are two really different things.
> >
> > When I last read up my understanding is that CTR operates as if there is
> a
> > vote for each commit.
>
> https://na01.safelinks.protection.outlook.com/?url=http%3a%2f%2fwww.apache.org%2ffoundation%2fglossary.html=01%7c01%7cRoss.Gardler%40microsoft.com%7cd4b92b7624054c648d7a08d2f02bdd99%7c72f988bf86f141af91ab2d7cd011db47%7c1=TL9a3HXjrIU7ntwJs8RqxDraGBtcz%2bzbjJACbgh%2f9LM%3d
>  :
>
> *Commit-Then-Review*<
> https://na01.safelinks.protection.outlook.com/?url=http%3a%2f%2fwww.apache.org%2ffoundation%2fglossary.html%23CommitThenReview=01%7c01%7cRoss.Gardler%40microsoft.com%7cd4b92b7624054c648d7a08d2f02bdd99%7c72f988bf86f141af91ab2d7cd011db47%7c1=3qCZYrBRMPK4j7qZpzlgHAmNW9L%2bGQp2QYgPjeDzm%2bI%3d>
> (Often abbreviated 'CTR' or 'C-T-R'.) A policy governing code
> changes which permits developers to make changes at will, with the
> possibility of being retroactively vetoed
> 
> .
>  C-T-R is an
> application of decision making through lazy consensus
> 
> .
>  The
> C-T-R model is useful in rapid-prototyping environments, but because
> of the lack of mandatory review it may permit more bugs through in
> daily practice than the R-T-C
> 
> 
> alternative.
>
> The important piece here is '...the lack of mandatory review...'
>
>
> From the same glossary:

Lazy consensus
> (Also called 'lazy approval'.) A decision-making policy which assumes
> general consent if no responses are posted within a defined period. For
> example, "I'm going to commit this by lazy consensus if no-one objects
> within the next three days." Also see Consensus Approval
> 
>  , Majority
> Approval 
> 
>  ,
> and the description of the voting process
> .

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

[Emmanuel Lécharny]

Le 18/11/15 17:54, Ross Gardler a écrit :
> Summarizing:
>
> In a healthy project I believe that the only significant things that change 
> between CTR and RTC are:
>
> 1) speed of commit (CTR is faster)
> 2) quality of master, not releases (RTC catches most issues before commit, 
> CTR shortly after commit)
>
> I agree with others, nothing in the Apache Way says RTC is bad. Personally I 
> believe CTR builds communities faster, but there are successful RTC projects. 
> What really matters is  managing the trade off above.
>
> Justification (mostly a repeat of what has been said already):
>
> I don't care what the website says. If I have a personal interest in a 
> project succeeding then I will do everything in my power to ensure it 
> succeeds. I assume the same is true for everyone else. This means that 
> "mandatory" reviews are not required because they just get done by the people 
> who care about project success.
>
> RTC does not guarantee reviews any more than CTR does, despite what a web 
> page says. It merely guarantees a way period in which someone will give a 
> patch a cursory glance. I'm not saying this is the normal RTC behavior, I'm 
> merely saying this is all that is guaranteed. Fortunately the process doesn't 
> change the way most people behave in a project, we can still trust them to do 
> their reviews.
>
> Furthermore, there seems to be an assumption that CTR means complex or 
> controversial code will be committed. In my experience this is not true. 
> People don't like to waste time writing code that may be rejected. What I see 
> is people discussing such changes, and providing psuedo code and then real 
> code for review before committing to master. It saves time to get early 
> review.

+1.

Thi is well summarized. We don't care what the project picks (CTR or
RTC), because at the end of the day, nobody can ensure the 'review' is
done. The only difference between teh two modes is that you expect the
+1 to be gathered before the commit in RTC, which is likely to be
bypassed at some poing by those who don't have time to review
thouroughly the commits.

And those who think that with RTC, it will never happen, then they
should be aware that it's already a battle to get PMC members to
actually *review* a release befoe casting a vote :/

-
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...)

[Stephen Connolly]

On 18 November 2015 at 14:24, Emmanuel Lécharny  wrote:

> Le 18/11/15 14:34, Stephen Connolly a écrit :
> > On Wednesday 18 November 2015, Emmanuel Lécharny 
> > wrote:
> >
> >> Le 18/11/15 11:31, Stephen Connolly a écrit :
> >>> I believe the issue here is that with CTR it is very easy to miss the
> 72h
> >>> lazy consensus voting (with an assumed +1 absence any votes cast) that
> >> most
> >>> CTR projects operate under... and thus it can also be very easy to miss
> >> the
> >>> fact that there are reviews going on (and I am being generous here, I
> >>> suspect that a lot of CTR commits are only reviewed within the 72h by a
> >>> blind man on a galloping horse)
> >> I'm not sure why you are correlating commit reviews and a 72h vote...
> >> They are two really different things.
> >
> > When I last read up my understanding is that CTR operates as if there is
> a
> > vote for each commit.
>
> http://www.apache.org/foundation/glossary.html :
>
> *Commit-Then-Review*<
> http://www.apache.org/foundation/glossary.html#CommitThenReview>
> (Often abbreviated 'CTR' or 'C-T-R'.) A policy governing code
> changes which permits developers to make changes at will, with the
> possibility of being retroactively vetoed
> . C-T-R is an
> application of decision making through lazy consensus
> . The
> C-T-R model is useful in rapid-prototyping environments, but because
> of the lack of mandatory review it may permit more bugs through in
> daily practice than the R-T-C
> 
> alternative.
>
> The important piece here is '...the lack of mandatory review...'
>
>
> From the same glossary:

Lazy consensus
> (Also called 'lazy approval'.) A decision-making policy which assumes
> general consent if no responses are posted within a defined period. For
> example, "I'm going to commit this by lazy consensus if no-one objects
> within the next three days." Also see Consensus Approval
>  , Majority
> Approval  ,
> and the description of the voting process
> .



So Lazy consensus is a voting process... if the code was committed more
than three days ago, then there must have been a successful vote for
committing that code... it was a lazy vote because there was no explicit
[VOTE] thread.

My point is that when I see people arguing for RTC over CTR what I maintain
they are actually arguing over is the lazy consensus voting of each commit.

People who want RTC really do not want lazy voting.
People who want CTR really want lazy voting.

I suspect that RTC with lazy consensus would be just as good an option for
Greg and just as bad an option for Tony

I also suspect that (in a parallel universe where the mess of revert
commits could be magically resolved) CTR without lazy consensus would be
just as good an option for Tony and just as bad an option for Greg.

*My* point is that it is the lazy consensus that people are arguing about.

CTR works best with lazy consensus (as there is the whole mess of
reverting... but you'd only do that for commits that fail on the code
provenance issue... so in practice it's not really anything even close to a
big deal)

RTC works best with non-lazy consensus and is acceptable with lazy
consensus.

In my day job, we use a sort of RTC with lazyish consensus...
It helps that all our stuff happens on DSCMs where we can just commit away
to our own branch until we are ready to merge.
We then flag the merge request for review... if you have 2 positive reviews
and no negative reviews in 12 hours, merge away... if you have 1 positive
review and no negative reviews after 12 hours, merge away... if you have no
reviews after 1 week, merge away


>
> >  It's a really lazy vote though as the vote passes if
> > nobody comments on the commit after 72h... And personally I do not see
> much
> > value in post-hoc votes... What are we going to do, rewrite history? But
> as
> > I understand the "vote" is so that the code in source control can be
> > covered by the legal umbrella despite it being outside of a formal source
> > release.
>
> AFAIU, it means it's very much a C[-T-R] and not a C-T-R...
>
>
> -
> 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 Wed, Nov 18, 2015 at 4:31 AM, Stephen Connolly <
stephen.alan.conno...@gmail.com> wrote:

> I believe the issue here is that with CTR it is very easy to miss the 72h
> lazy consensus voting (with an assumed +1 absence any votes cast) that most
> CTR projects operate under... and thus it can also be very easy to miss the
> fact that there are reviews going on (and I am being generous here, I
> suspect that a lot of CTR commits are only reviewed within the 72h by a
> blind man on a galloping horse)
>

There isn't lazy consensus going on. All that really exists is the ability
to veto. If you don't get a veto, then you've achieved consensus :-)

And 72h is not part of the process either ... any change can be vetoed any
time before it gets released. "-1 on releasing that change" can occur
months later as you're preparing a release. See: http://s.apache.org/j4

Cheers,
-g

Re: Incubator mail archives lagging badly

[Gregory Chase]

http://mail-archives.apache.org/mod_mbox/incubator-geode-dev/201511.mbox/browser

As one example.

On Wed, Nov 18, 2015 at 11:00 AM, Bertrand Delacretaz <
bdelacre...@apache.org> wrote:

> Hi,
>
> On Wed, Nov 18, 2015 at 1:49 PM, Gregory Chase  wrote:
> > ...I notice that a number of
> > the incubating projects mail archives have not updated since Nov 2
>
> There are several archives, which archive URLs are you referring to?
>
> -Bertrand
>
> -
> To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
> For additional commands, e-mail: general-h...@incubator.apache.org
>
>


-- 
Greg Chase

Director of Big Data Communities
http://www.pivotal.io/big-data

Pivotal Software
http://www.pivotal.io/

650-215-0477
@GregChase
Blog: http://geekmarketing.biz/

Incubator mail archives lagging badly

[Gregory Chase]

Greetings,
Maybe this belongs in the Infra mail list, but I notice that a number of
the incubating projects mail archives have not updated since Nov 2.

I presume this is a known problem?

-- 
Greg Chase

Director of Big Data Communities
http://www.pivotal.io/big-data

Pivotal Software
http://www.pivotal.io/

650-215-0477
@GregChase
Blog: http://geekmarketing.biz/

Re: Incubator mail archives lagging badly

[Bertrand Delacretaz]

Hi,

On Wed, Nov 18, 2015 at 1:49 PM, Gregory Chase  wrote:
> ...I notice that a number of
> the incubating projects mail archives have not updated since Nov 2

There are several archives, which archive URLs are you referring to?

-Bertrand

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

RE: Incubator mail archives lagging badly

[Dennis E. Hamilton]

I see 253 messages from incubator-geode for November, with the last dated today.

I followed the below-supplied URL, switched to date view, and then went to the 
last available page (3 in this case).

Is this not reproducible?

 - Dennis

> -Original Message-
> From: Gregory Chase [mailto:gch...@pivotal.io]
> Sent: Wednesday, November 18, 2015 11:02
> To: general@incubator.apache.org
> Subject: Re: Incubator mail archives lagging badly
> 
> http://mail-archives.apache.org/mod_mbox/incubator-geode-
> dev/201511.mbox/browser
> 
> As one example.
[ ... ]


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

[VOTE] Release Apache Trafodion (incubating) 1.3.0-incubating (RC4)

[Roberta Marton]

Hello,



The Apache Trafodion community has voted on and approved its first release
– Apache Trafodion 1.3.0 –incubating.



Vote request on dev list:

http://mail-archives.apache.org/mod_mbox/incubator-trafodion-dev/201511.mbox/%3Cedf95f7384696f8ec87bd1b8ad102b52%40mail.gmail.com%3E



Vote result on dev list:

http://mail-archives.apache.org/mod_mbox/incubator-trafodion-dev/201511.mbox/%3Cb681250231a812aa3b8263a6236da228%40mail.gmail.com%3E



The commit id is 1ea3e834b6738617164d2a6ed8b090b3ab497946 which corresponds
to tag 1.3.0rc4:

https://git-wip-us.apache.org/repos/asf?p=incubator-trafodion.git;a=tag;h=4198e21785de89736e3d91f4324dee663566d38e



The release artifacts can be downloaded from:

https://dist.apache.org/repos/dist/dev/incubator/trafodion/apache-trafodion-1.3.0-incubating

Instructions on how to build and run Apache Trafodion are described here:

https://cwiki.apache.org/confluence/display/TRAFODION/Using+the+Software#UsingtheSoftware-Download,build,andinstallTrafodionusingsourcetarfileonApachedistributionsite



The source tar file has been signed with pgp key A44C5A05 which is included
in the download location’s KEYS file:

https://dist.apache.org/repos/dist/dev/incubator/trafodion/KEYS



For changes included in the release, please see the release notes:
https://cwiki.apache.org/confluence/pages/viewpage.action?pageId=61326700



The RAT tool was run on the source and the excluded are defined in the
RAT_README.txt file found in the top level source directory.



There was one comment from the Apache Trafodion community regarding NOTICE
and LICENSE files in the sub-directories wms and dcs.  JIRA
https://issues.apache.org/jira/browse/TRAFODION-1636 has been created and
will be resolved in a subsequent release.



Pursuant to the Release section of the Incubation Policy and with the
endorsement of our mentors we would now like to request the permission  of
the Incubator PMC to publish the release.



The vote will be open for 72 hours.



[ ] +1 approve

[ ] +0 no opinion

[ ] -1 disapprove (and reason why)



   Regards,

Roberta Marton

Re: Incubator mail archives lagging badly

[Bertrand Delacretaz]

On Wed, Nov 18, 2015 at 2:02 PM, Gregory Chase  wrote:
> http://mail-archives.apache.org/mod_mbox/incubator-geode-dev/201511.mbox/browser
>  ...

That looks up to date for me.
That page uses javascript to load the content, maybe it's failing on
your browser?

-Bertrand

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

Re: Incubator mail archives lagging badly

[Gregory Chase]

Sorry all.  It's user error.  I was expecting most recent first :)

On Wed, Nov 18, 2015 at 11:54 AM, Bertrand Delacretaz <
bdelacre...@apache.org> wrote:

> On Wed, Nov 18, 2015 at 2:02 PM, Gregory Chase  wrote:
> >
> http://mail-archives.apache.org/mod_mbox/incubator-geode-dev/201511.mbox/browser
> ...
>
> That looks up to date for me.
> That page uses javascript to load the content, maybe it's failing on
> your browser?
>
> -Bertrand
>
> -
> To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
> For additional commands, e-mail: general-h...@incubator.apache.org
>
>


-- 
Greg Chase

Director of Big Data Communities
http://www.pivotal.io/big-data

Pivotal Software
http://www.pivotal.io/

650-215-0477
@GregChase
Blog: http://geekmarketing.biz/

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

[Emmanuel Lécharny]

Le 18/11/15 11:31, Stephen Connolly a écrit :
> I believe the issue here is that with CTR it is very easy to miss the 72h
> lazy consensus voting (with an assumed +1 absence any votes cast) that most
> CTR projects operate under... and thus it can also be very easy to miss the
> fact that there are reviews going on (and I am being generous here, I
> suspect that a lot of CTR commits are only reviewed within the 72h by a
> blind man on a galloping horse)

I'm not sure why you are correlating commit reviews and a 72h vote...
They are two really different things.

>
> If the PMC is doing its duty, then when release time comes around, if they
> have not been tracking the commits, then they should not be providing a
> binding +1 for the release until they have reviewed the commit delta from
> the last release *at least from the point of view of ASL compliance*.
No. There is nothing that says such a thing. It would be very good if
every PMC member casting a vote were reviewing all the commits since the
last release, but this is unlikely to happen, and it's not even
required. And unless you point us to the so called ASL compliance, I
think this is your own interpretation of the PMC member that you are
pulling here.
>
> So if we look at a well established CTR project such as Maven, you do not
> see many comments on individual commits... from this you might be forgiven
> if you concluded that there is no review going on... and thus infer that
> CTR is really C. I cannot speak for the entire Maven PMC but I can assure
> you that I reviewed each and every commit in the delta between the 3.3.3
> release and the 3.3.9 release from both a technical perspective and the
> legal umbrella perspective (does that mean I spotted every bug, nope... no
> code review can catch every bug... and it took us 6 goes to get the release
> out... but there was review)
That's good for Maven. But that does not mean any other project should
do so.

Look, this is where we *trust* other committers - and this is the reason
we voted them in, btw - : they *know* they should not break the ASF
rules (IP, etc) plus they *know* they should not break the trust the
community has put in them.

In 10 years, I have very rarely seen such things happening - and most of
the time it was a mistake -. I saw someone pushing some revamped Sun
code (and signaled so to the project), vote -1 on one commit (not sure I
should be proud of that veto, btw) and asked for some better code to be
pushed a few times, but more as a discussion than as a formal request.
Otherwise, did I saw some commits that needed some fixe because they
were breaking the build ? You bet ! (and I plaid guilty as charged too).
Bottom line, trusting my co-workers was easy : they are all my pairs,
and I don't feel like I'm any superior in any way, so I was expecting
their code to be at least as good as mine. Who would I be if I was to
check their daily commits and not asking them to review mine otherwise ?

And the best of it : it simply works. With flying colors. We have a
bunch of tests that avoid many errors to be introduced into the code,
and we can release fast enough so that our users can actually be real
users, and provide us with feedbacks. There is nothing better than users
feedbacks : not only they see what's wrong in our products, but they
also use it ways we haven't thought about, discovering new problems we
totally missed. That's the key : release often means get quick feedbacks.

But there is more : asking people who are volunteers to review what
others are pushing would introduce a latency that would certainly kill
the project.

Now I can see how people being paid by a company might *want* such
reviews to be done (regardless of the mode, CTR or RTC), and I feel that
as a bias toward a control by a few companies, excluding de facto those
who don't have time to work on the project but what they squeeze out of
a day job, familly, and sleep... And I saw that frequently in *many*
projects ! Sounds like a hidden agenda, isn't it ?  That would may be
pushing the thing a bit too far, but I suspect that in some case, yes,
that was exactly that. This is *NOT* The Apache Way...



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

Re: [DISCUSS] Impala incubator proposal

[Jean-Baptiste Onofré]

Hi Henry,

good news to see this proposal !

Regards
JB

On 11/17/2015 07:49 PM, Henry Robinson wrote:

Hi all -

We'd like to start a discussion regarding a proposal to submit Impala to
the Apache Incubator.

The proposal text is available on the Wiki here:
https://wiki.apache.org/incubator/ImpalaProposal

and pasted below for convenience.

I'm excited to make this proposal, and look forward to the community's
input!

Best,
Henry


= Abstract =
Impala is a high-performance C++ and Java SQL query engine for data stored
in Apache Hadoop-based clusters.

= Proposal =

We propose to contribute the Impala codebase and associated artifacts (e.g.
documentation, web-site content etc.) to the Apache Software Foundation
with the intent of forming a productive, meritocratic and open community
around Impala’s continued development, according to the ‘Apache Way’.

Cloudera owns several trademarks regarding Impala, and proposes to transfer
ownership of those trademarks in full to the ASF.

= Background =
Engineers at Cloudera developed Impala and released it as an
Apache-licensed open-source project in Fall 2012. Impala was written as a
brand-new, modern C++ SQL engine targeted from the start for data stored in
Apache Hadoop clusters.

Impala’s most important benefit to users is high-performance, making it
extremely appropriate for common enterprise analytic and business
intelligence workloads. This is achieved by a number of software
techniques, including: native support for data stored in HDFS and related
filesystems, just-in-time compilation and optimization of individual query
plans, high-performance C++ codebase and massively-parallel distributed
architecture. In benchmarks, Impala is routinely amongst the very highest
performing SQL query engines.

= Rationale =

Despite the exciting innovation in the so-called ‘big-data’ space, SQL
remains by far the most common interface for interacting with data in both
traditional warehouses and modern ‘big-data’ clusters. There is clearly a
need, as evidenced by the eager adoption of Impala and other SQL engines in
enterprise contexts, for a query engine that offers the familiar SQL
interface, but that has been specifically designed to operate in massive,
distributed clusters rather than in traditional, fixed-hardware,
warehouse-specific deployments. Impala is one such query engine.

We believe that the ASF is the right venue to foster an open-source
community around Impala’s development. We expect that Impala will benefit
from more productive collaboration with related Apache projects, and under
the auspices of the ASF will attract talented contributors who will push
Impala’s development forward at pace.

We believe that the timing is right for Impala’s development to move
wholesale to the ASF: Impala is well-established, has been Apache-licensed
open-source for more than three years, and the core project is relatively
stable. We are excited to see where an ASF-based community can take Impala
from this strong starting point.

= Initial Goals =
Our initial goals are as follows:

* Establish ASF-compatible engineering practices and workflows
* Refactor and publish existing internal build scripts and test
infrastructure, in order to make them usable by any community member.
* Transfer source code, documentation and associated artifacts to the ASF.
* Grow the user and developer communities

= Current Status =

Impala is developed as an Apache-licensed open-source project. The source
code is available at http://github.com/cloudera/Impala, and developer
documentation is at https://github.com/cloudera/Impala/wiki. The majority
of commits to the project have come from Cloudera-employed developers, but
we have accepted some contributions from individuals from other
organizations.

All code reviews are done via a public instance of the Gerrit review tool
at http://gerrit.cloudera.org:8080/, and discussed on a public mailing
list. All patches must be reviewed before they are accepted into the
codebase, via a voting mechanism that is similar to that used on Apache
projects such as Hadoop and HBase.

Before a patch is committed, it must pass a suite of pre-commit tests.
These tests are currently run on Cloudera’s internal infrastructure. One of
our initial goals will be to work with the ASF Infrastructure team to find
a way to run these tests in an acceptable way on publicly accessible
machines.

Issues are tracked in JIRA at https://issues.cloudera.org/projects/IMPALA,
in a way that is extremely similar to existing practices at other ASF
projects.

= Meritocracy =

We understand the central importance of meritocracy to the Apache Way. We
will work to establish a welcoming, fair and meritocratic community, in
part by expanding the set of committers on the project. Although Impala’s
committer list will initially be dominated by members of the Impala
engineering team at Cloudera, we look forward to growing a rich user and
developer community.

= Community =
Impala has a strong user 

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

[Stephen Connolly]

I believe the issue here is that with CTR it is very easy to miss the 72h
lazy consensus voting (with an assumed +1 absence any votes cast) that most
CTR projects operate under... and thus it can also be very easy to miss the
fact that there are reviews going on (and I am being generous here, I
suspect that a lot of CTR commits are only reviewed within the 72h by a
blind man on a galloping horse)

If the PMC is doing its duty, then when release time comes around, if they
have not been tracking the commits, then they should not be providing a
binding +1 for the release until they have reviewed the commit delta from
the last release *at least from the point of view of ASL compliance*.

So if we look at a well established CTR project such as Maven, you do not
see many comments on individual commits... from this you might be forgiven
if you concluded that there is no review going on... and thus infer that
CTR is really C. I cannot speak for the entire Maven PMC but I can assure
you that I reviewed each and every commit in the delta between the 3.3.3
release and the 3.3.9 release from both a technical perspective and the
legal umbrella perspective (does that mean I spotted every bug, nope... no
code review can catch every bug... and it took us 6 goes to get the release
out... but there was review)

[demagogue]
Now if a project is using RTC, in my view they probably should also be
using the 72h lazy consensus rule, in which case in the absence of a -1 the
code can be committed after 72h anyway and that should not slow down a
project or hamper contribution
[/demagogue]

I suspect the real debate should be whether RTC should use lazy consensus
voting or require at least one vote cast... that would - to my mind - get
to the heart of the debate (of course that decision is the responsibility
of each project's PMC)

I suspect that Todd would find a CTR with required vote casting or revert
just as acceptable (though much more noisy in SCM tracking with all the
revert commits)

-Stephen

On 18 November 2015 at 09:16, Ross Gardler 
wrote:

> Interesting, Todd, can you identify which of your three arguments for CTR
> are not present in RTC.
>
> Ross
>
> -Original Message-
> From: Todd Lipcon [mailto:t...@cloudera.com]
> Sent: Tuesday, November 17, 2015 11:23 PM
> To: general@incubator.apache.org
> Subject: Re: RTC vs CTR (was: Concerning Sentry...)
>
> On Tue, Nov 17, 2015 at 11:12 PM, Greg Stein  wrote:
>
> > On Wed, Nov 18, 2015 at 1:07 AM, Todd Lipcon  wrote:
> > >...
> >
> > > I think it's a _plus_ that contributors and committers contribute
> > > code in the same way -- it's more of a level playing field for new
> > > people contributing to the project.
> > >
> >
> > "level playing field"?? seriously??
> >
> > I find no logical or valid reasoning to drag committers down to the
> > same level as drive-by contributors.
> >
>
> I gave the logical and valid reasoning in previous posts in this thread:
> 1) no matter how seasoned a committer you are, you might make mistakes
> which are easily caught in code review
> 2) no matter how good you are at coding, your code might not make sense to
> a second pair of eyes, who can ask you to improve comments or docs
> 3) no matter if your code is perfect, the act of another person reading
> your code builds shared ownership over the code, thus alleviating
> bus-factor issues and improving the general feeling of a cohesive community
> developing a single project instead of a loose coalition of people with
> their own fiefdoms.
>
> I believe this to be generally accepted in the software engineering
> community. I don't know practices at every company, but I know at least
> that most of the well-regarded technology companies I've met with have some
> form of pre-commit review, and certainly many highly adopted open source
> projects as well (especially in infrastructure software).
>
> Either a high percentage of the world does this for "no logical or valid
> reason" or this is just a matter of opinion, and like I said, we can agree
> to disagree.
>
> -Todd
>

Re: [VOTE] Retire Corinthia

[Danese Cooper]

+1 (binding)

D

> On Nov 16, 2015, at 11:01 AM, Marvin Humphrey  wrote:
> 
> Greetings,
> 
> The Corinthia community has voted to retire:
> 
>  http://s.apache.org/odN
> 
> This is a vote of the IPMC to confirm the decision to retire the podling.
> 
> [ ] +1 to retire Corinthia from the Incubator
> [ ] -1 to keep Corinthia in the Incubator
> 
> This vote will be held open for at least 72 hours.
> 
> Should this vote pass, I have volunteered to assist Corinthia with retirement,
> as I am assisting Droids and Kalumet.
> 
> Marvin Humphrey
> 
> -
> To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
> For additional commands, e-mail: general-h...@incubator.apache.org
> 

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

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

[Ross Gardler]

Interesting, Todd, can you identify which of your three arguments for CTR are 
not present in RTC.

Ross

-Original Message-
From: Todd Lipcon [mailto:t...@cloudera.com] 
Sent: Tuesday, November 17, 2015 11:23 PM
To: general@incubator.apache.org
Subject: Re: RTC vs CTR (was: Concerning Sentry...)

On Tue, Nov 17, 2015 at 11:12 PM, Greg Stein  wrote:

> On Wed, Nov 18, 2015 at 1:07 AM, Todd Lipcon  wrote:
> >...
>
> > I think it's a _plus_ that contributors and committers contribute 
> > code in the same way -- it's more of a level playing field for new 
> > people contributing to the project.
> >
>
> "level playing field"?? seriously??
>
> I find no logical or valid reasoning to drag committers down to the 
> same level as drive-by contributors.
>

I gave the logical and valid reasoning in previous posts in this thread:
1) no matter how seasoned a committer you are, you might make mistakes which 
are easily caught in code review
2) no matter how good you are at coding, your code might not make sense to a 
second pair of eyes, who can ask you to improve comments or docs
3) no matter if your code is perfect, the act of another person reading your 
code builds shared ownership over the code, thus alleviating bus-factor issues 
and improving the general feeling of a cohesive community developing a single 
project instead of a loose coalition of people with their own fiefdoms.

I believe this to be generally accepted in the software engineering community. 
I don't know practices at every company, but I know at least that most of the 
well-regarded technology companies I've met with have some form of pre-commit 
review, and certainly many highly adopted open source projects as well 
(especially in infrastructure software).

Either a high percentage of the world does this for "no logical or valid 
reason" or this is just a matter of opinion, and like I said, we can agree to 
disagree.

-Todd

Re: [DISCUSS] Kudu incubator proposal

[Jake Farrell]

merit is merit, why would the barrier for new committers be different here
than in any other project? If the ramp up and time to learn the projects
source is the barrier then it is on us to help make it easier through
documentation, clear project roadmap and entry level consumable tickets to
help those new contributors get a footing

-Jake

On Tue, Nov 17, 2015 at 7:27 PM, Konstantin Boudnik  wrote:

> On Tue, Nov 17, 2015 at 10:43AM, Todd Lipcon wrote:
> > On Tue, Nov 17, 2015 at 10:38 AM, Atri Sharma 
> wrote:
> >
> > > Sounds great.
> > >
> > > I would love to be an help as a committer, if possible. This seems to
> be
> > > fantastic in line with my focus areas and can help existing big data
> > > projects to accelerate so Kudu's growth is something I would care
> about.
> > >
> >
> > Hi Atri,
> >
> > Thanks for the interest! Following the example of other recent incubator
> > projects, we would like to keep the initial committer list to those who
> are
> > already have a track record of contributions to the project. We'd love to
> > have you involved as a contributor during incubation, and of course would
> > be glad to add you as a committer after you've become a regular
> contributor.
>
> Considering that the project has been closed-sourced until very recently
> such
> "following" would surely create pretty high entry barrier for new
> committers.
> Which of course would be a concern, from the community growth perspective.
>
> Cos
>

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

[Steve Loughran]

> On 18 Nov 2015, at 13:34, Stephen Connolly  
> wrote:
> 
> On Wednesday 18 November 2015, Emmanuel Lécharny 
> wrote:
> 
>> Le 18/11/15 11:31, Stephen Connolly a écrit :
>>> I believe the issue here is that with CTR it is very easy to miss the 72h
>>> lazy consensus voting (with an assumed +1 absence any votes cast) that
>> most
>>> CTR projects operate under... and thus it can also be very easy to miss
>> the
>>> fact that there are reviews going on (and I am being generous here, I
>>> suspect that a lot of CTR commits are only reviewed within the 72h by a
>>> blind man on a galloping horse)
>> 
>> I'm not sure why you are correlating commit reviews and a 72h vote...
>> They are two really different things.
> 
> 
> When I last read up my understanding is that CTR operates as if there is a
> vote for each commit. It's a really lazy vote though as the vote passes if
> nobody comments on the commit after 72h... And personally I do not see much
> value in post-hoc votes... What are we going to do, rewrite history? But as
> I understand the "vote" is so that the code in source control can be
> covered by the legal umbrella despite it being outside of a formal source
> release.
> 


Interesting point. I'd personally take the view that if a patch broke a build 
or test then I'm prepared to revert that patch irrespective of when it went in. 

Where any voting is likely to come up is if there's a disagreement about 
whether a patch should go in; thinking of the most recent example of that I was 
involved in was
https://issues.apache.org/jira/browse/HADOOP-12415   .. which was essentially 
"where in the classpath should zk.jar go"

What RTC does do, however, is add an implicit way to veto something: ignore the 
patch. CTR removes that ability to ignore patches from committers, but still 
retains that option for non-committers

-steve

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

[Emmanuel Lécharny]

Le 18/11/15 14:34, Stephen Connolly a écrit :
> On Wednesday 18 November 2015, Emmanuel Lécharny 
> wrote:
>
>> Le 18/11/15 11:31, Stephen Connolly a écrit :
>>> I believe the issue here is that with CTR it is very easy to miss the 72h
>>> lazy consensus voting (with an assumed +1 absence any votes cast) that
>> most
>>> CTR projects operate under... and thus it can also be very easy to miss
>> the
>>> fact that there are reviews going on (and I am being generous here, I
>>> suspect that a lot of CTR commits are only reviewed within the 72h by a
>>> blind man on a galloping horse)
>> I'm not sure why you are correlating commit reviews and a 72h vote...
>> They are two really different things.
>
> When I last read up my understanding is that CTR operates as if there is a
> vote for each commit.

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

*Commit-Then-Review*
(Often abbreviated 'CTR' or 'C-T-R'.) A policy governing code
changes which permits developers to make changes at will, with the
possibility of being retroactively vetoed
. C-T-R is an
application of decision making through lazy consensus
. The
C-T-R model is useful in rapid-prototyping environments, but because
of the lack of mandatory review it may permit more bugs through in
daily practice than the R-T-C

alternative.

The important piece here is '...the lack of mandatory review...'



>  It's a really lazy vote though as the vote passes if
> nobody comments on the commit after 72h... And personally I do not see much
> value in post-hoc votes... What are we going to do, rewrite history? But as
> I understand the "vote" is so that the code in source control can be
> covered by the legal umbrella despite it being outside of a formal source
> release.

AFAIU, it means it's very much a C[-T-R] and not a C-T-R...


-
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...)

[Stephen Connolly]

On Wednesday 18 November 2015, Emmanuel Lécharny 
wrote:

> Le 18/11/15 11:31, Stephen Connolly a écrit :
> > I believe the issue here is that with CTR it is very easy to miss the 72h
> > lazy consensus voting (with an assumed +1 absence any votes cast) that
> most
> > CTR projects operate under... and thus it can also be very easy to miss
> the
> > fact that there are reviews going on (and I am being generous here, I
> > suspect that a lot of CTR commits are only reviewed within the 72h by a
> > blind man on a galloping horse)
>
> I'm not sure why you are correlating commit reviews and a 72h vote...
> They are two really different things.


When I last read up my understanding is that CTR operates as if there is a
vote for each commit. It's a really lazy vote though as the vote passes if
nobody comments on the commit after 72h... And personally I do not see much
value in post-hoc votes... What are we going to do, rewrite history? But as
I understand the "vote" is so that the code in source control can be
covered by the legal umbrella despite it being outside of a formal source
release.


> >
> > If the PMC is doing its duty, then when release time comes around, if
> they
> > have not been tracking the commits, then they should not be providing a
> > binding +1 for the release until they have reviewed the commit delta from
> > the last release *at least from the point of view of ASL compliance*.
> No. There is nothing that says such a thing.


>  http://www.apache.org/dev/release-publishing.html
All the source code of the project must be covered by the Apache License,
version 2.0. The license must be included in each source file. For the
license to be valid, the code must have been contributed by an individual
covered by an appropriate contributor license agreement, or have otherwise
been licensed to the Foundation and passed through IP clearance. S

Now I will agree that the above is not a very high bar:

1. Check all commits are authored by a committer (as committer has an ICLA)
2. For commits authored by non committers (git makes these easier to find)
check that the author provides clear intent to submit the code to the ASF
(a patch submitted to JIRA/project mailing list or a PR against Apache
GitHub repo seems clear intent) and that the patch is not "too big" (a
somewhat nebulous concept but as all the ones I have had to check were
under the 50-60 LOC metric I haven't had to probe that concept too hard)
3. If all else fails as the author to sign an ICLA

It would be very good if
> every PMC member casting a vote were reviewing all the commits since the
> last release, but this is unlikely to happen, and it's not even
> required.


> This is correct, as long as I review as we go for the above
(minimal) provenance checks then I am good to go and provide 1/3rd of the
legal umbrella.

And unless you point us to the so called ASL compliance, I
> think this is your own interpretation of the PMC member that you are
> pulling here.


See the link. It's not a strenuous compliance check like the paper exercise
that the interrupted view of planetary objects foundation performs... Thank
goodness do that... But it is a requirement of you read up on the PMC roles.


> >
> > So if we look at a well established CTR project such as Maven, you do not
> > see many comments on individual commits... from this you might be
> forgiven
> > if you concluded that there is no review going on... and thus infer that
> > CTR is really C. I cannot speak for the entire Maven PMC but I can assure
> > you that I reviewed each and every commit in the delta between the 3.3.3
> > release and the 3.3.9 release from both a technical perspective and the
> > legal umbrella perspective (does that mean I spotted every bug, nope...
> no
> > code review can catch every bug... and it took us 6 goes to get the
> release
> > out... but there was review)
> That's good for Maven. But that does not mean any other project should
> do so.
>
> Look, this is where we *trust* other committers - and this is the reason
> we voted them in, btw - : they *know* they should not break the ASF
> rules (IP, etc) plus they *know* they should not break the trust the
> community has put in them.
>
> In 10 years, I have very rarely seen such things happening - and most of
> the time it was a mistake -. I saw someone pushing some revamped Sun
> code (and signaled so to the project), vote -1 on one commit (not sure I
> should be proud of that veto, btw) and asked for some better code to be
> pushed a few times, but more as a discussion than as a formal request.
> Otherwise, did I saw some commits that needed some fixe because they
> were breaking the build ? You bet ! (and I plaid guilty as charged too).
> Bottom line, trusting my co-workers was easy : they are all my pairs,
> and I don't feel like I'm any superior in any way, so I was expecting
> their code to be at least as good as mine. Who would I be if I was to
> check their daily commits and 

Re: Apache Metrics, Not Apache Humans

[Louis Suárez-Potts]

On 17 November 2015 at 16:20, Ross Gardler  wrote:
> Summary of my objection: community building is an art not a science, there is 
> no "score" that can be placed upon a community.


True.
Louis.

PS Alas, "scores" are chalked against the manager of communities who
fails to satisfy the beany needs of misguided marketing. (Beany
needs=bean counter needs.)

-- 
Louis Suárez-Potts
Mobile: +1.416.625.3843 (ET)
Skype: louisiam
Twitter: @luispo
G+: https://plus.google.com/+LouisSuárezPotts

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

Re: [DISCUSS] S2Graph Incubator Proposal

[Hyunsik Choi]

Thank you very much Stack! It definitely looks better than just wiki.
It would be helpful to improve the proposal.

Best regards,
Hyunsik

On Tue, Nov 17, 2015 at 10:20 PM, Stack  wrote:
> Glad to see s2graph being put up as an incubator project.
>
> Here [1] are some suggested edits to try and help strengthen the proposal
> before it goes up for a vote. Hopefully they help.
>
> St.Ack
> 1.
> https://docs.google.com/document/d/19iNc0u_-9ogb0kDC-WnLoWWg9J_LFeuSGB8GF_rQfEs/edit?usp=sharing
>
> On Tue, Nov 17, 2015 at 3:59 PM, Hyunsik Choi  wrote:
>
>> Thank you Henry. Yes, we already had enough time to discuss the
>> S2Graph proposal. I'll make a vote thread soon.
>>
>> Best regards,
>> Hyunsik
>>
>> On Tue, Nov 17, 2015 at 2:22 PM, Henry Saputra 
>> wrote:
>> > Looks like we have positive responses. I think it is time for VOTE
>> thread :)
>> >
>> > On Friday, November 6, 2015, Hyunsik Choi  wrote:
>> >
>> >> Hi folks,
>> >>
>> >> We would like to start a discussion on S2Graph as an incubation project.
>> >>
>> >> S2Graph is a distributed and scalable OLTP graph database built on
>> >> HBase. It provides interactive queries for vertex/edge/sub-graphs on
>> >> extremely large graph data sets as well as insertion and update
>> >> operations.
>> >>
>> >> S2Graph was already introduced in Apache BigData and HBaseCon this year.
>> >>
>> >> The proposal is available at :
>> >> https://wiki.apache.org/incubator/S2GraphProposal
>> >>
>> >> We are looking forward to any feedback. In addition, we are looking
>> >> for volunteers as mentors.
>> >>
>> >> Best regards,
>> >> Hyunsik
>> >>
>> >> -
>> >> To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
>> >> 
>> >> For additional commands, e-mail: general-h...@incubator.apache.org
>> >> 
>> >>
>> >>
>>
>> -
>> To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
>> For additional commands, e-mail: general-h...@incubator.apache.org
>>
>>

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

Re: [VOTE] Release Apache Myriad 0.1.0 (incubating)

[Justin Mclean]

Hi,

>> Could not find zookeeper-tests.jar (org.apache.zookeeper:zookeeper:3.4.6).
> 
>  Searched in the following locations:
> 
> file:/Users/johnament/.m2/repository/org/apache/zookeeper/zookeeper/3.4.6/zookeeper-3.4.6-tests.jar

I run into the same error, assumed it was my setup and rm -rf 
~/.m2/repository/org/apache/zookeeper/zookeeper/3.4.6 which fixed it for me.

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

Re: [VOTE] Release Apache Myriad 0.1.0 (incubating)

[John D. Ament]

Could you include some build instructions? Got this error trying ./gradlew
build

Could not resolve all dependencies for configuration
':myriad-scheduler:compile'.

> Could not find zookeeper-tests.jar (org.apache.zookeeper:zookeeper:3.4.6).

  Searched in the following locations:


file:/Users/johnament/.m2/repository/org/apache/zookeeper/zookeeper/3.4.6/zookeeper-3.4.6-tests.jar



On Mon, Nov 16, 2015 at 8:48 PM Santosh Marella 
wrote:

> 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)
>

Re: [DISCUSS] OpenMiracl for Incubation

[Nick Kew]

On Wed, 2015-11-18 at 08:48 +0900, Brian Spector wrote:
> Hi Alex, thank you for the suggestion, but from our point of view, as I
> outlined below, we would disadvantage the project as a whole by not having
> the MIRACL name in it.
> 
> At the same time, I completely understand the concern that a company who
> creates a product based on OpenMiracl might feel themselves disadvantaged
> by having to state an attribution 'based on Apache OpenMiracl' while
> MIRACL, the company, sells a product called Datacenter Cryptosystem will
> also say 'based on Apache OpenMiracl'. We get that.

If folks are uneasy about OpenMiracl, how far does that extend?
Would (for example) a name taking the "Mira" stem be sufficiently
distinct for those expressing concerns here?  For example,
Mirabile (Latin pronunciation) kind-of offers an element of
historic continuity through the linguistic association with
the miracle.

-- 
Nick Kew


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

Re: [VOTE] Release Apache Trafodion (incubating) 1.3.0-incubating (RC4)

[Justin Mclean]

Hi,

Sorry -1 Due to license and copyright issues and possible crypto issue.

I checked:
- artefact contains incubating
- signature and hashes good
- DISCLAIMER exists
- LICENSE is missing a couple of things/has a few issues
- NOTICE is good but may be missing thing form other Apache bundled software
- rat exclusions bay be a bit wide
- no unexpected binaries in release
- while most source file have Apache headers there are serval issues with 
copyright owners and multiple headers in files
- didn’t compile as the build process looks rather difficult

If OpenSSL is being bundled has this process been followed? [8] I’m not 
familiar with the process and it may not apply here. Can someone who more 
familiar with this please comment.

LICENSE issues:
- License implies that all BSD licensed software is "Copyright (c) 2008-2010, 
Allan Jardine” which is not the case. Each piece of licensed software will have 
it’s own owner.
- missing MIT licensed Asciidoctor [1]
- Jquery UI is MIT licensed not BSD [2]
- missing MIT license MooTools Framework [3]
- missing BSD style OpenSSL license [4]
- missing MIT JavaScript InfoVis Toolkit license [5]
- missing MIT JQuery license [6]
- And while the code under [7] is MIT it's not copyright SpryMedia Ltd
- missing license for CSS Document by Codify Design Studio [15] How is this 
file  licensed?

Also this file [9] is marked as copyright ASF but contains  other possible 
copyright owners:

Re: [VOTE] Release Apache Myriad 0.1.0 (incubating)

[Justin Mclean]

Hi,

Sorry but it -1 due to inclusion of a jar in the source release. This issue has 
come up before on the incubator mailing list e.g. [4].

Other than some minor license issues everything else is good.

I checked:
- artefact name contains incubating
- signatures and hashes good
- DISCLAIMER exists
- LICENSE has a couple of minor issues
- NOTICE good
- unexpected binary file in the source release [3]
- all source code has Apache headers
- Can build from source

For the LICENSE:
- The appendix part of the LICENSE isn’t correct (i.e. the Apache licence can 
apply to non ASF licensed software). Best to use the stock one and not modify 
it [1]
- LICENSE mentions sub components but there are none listed
- LICENSE is missing normalise.css which is MIT licensed see [2]

You may want to consider:
- Signing with an apache.org email address
- Adding some build instruction to README

Thanks,
Justin

1. http://www.apache.org/licenses/LICENSE-2.0.txt
2. ./myriad-scheduler/src/main/resources/webapp/css/bootstrap-myriad.css
3../gradle/wrapper/gradle-wrapper.jar
4. http://apache.markmail.org/thread/stygi2hnnovbmf46
-
To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
For additional commands, e-mail: general-h...@incubator.apache.org

Re: [VOTE][RESULT] Retire Droids (IPMC)

[Marvin Humphrey]

On Sun, Nov 1, 2015 at 3:32 PM, Marvin Humphrey  wrote:

> I will attend to the retirement procedures.

The retirement procedures for Droids have been completed.

Marvin Humphrey

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

Re: Kalumet retirement steps

[Hadrian Zbarcea]

Hi Marvin,

As far as I remember, Kalumet is almost exclusively the work of JB 
Onofre who is an ASF member, therefore I don't see a problem.


That said I think it's best to wait a bit and let JB speak up. I cc'ed 
him, just to make sure he notices this thread.


Cheers,
Hadrian

On 11/18/2015 05:29 PM, Marvin Humphrey wrote:

On Sun, Nov 15, 2015 at 6:56 PM, Marvin Humphrey  wrote:


The copyright checkbox for Kalumet is marked with a question mark, which I
interpret as "not checked off":

 http://incubator.apache.org/projects/kalumet#Copyright

A successful incubating release would have settled the issue, but I did some
research and it seems that while the Kalumet podling attempted an incubating
release of their 0.6 branch, it doesn't look like it was ever officially
completed.

If the copyright status cannot be resolved, I will have to delete `trunk`,
`tags`, and `branches` from
.

Can someone provide a definitive answer on whether it is OK for Kalumet's code
to remain visible in svn?


I'll give this a couple more days.  If no one has spoken up by then, I
will proceed with deleting the code from svn.

Marvin Humphrey

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



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

Re: Kalumet retirement steps

[Marvin Humphrey]

On Sun, Nov 15, 2015 at 6:56 PM, Marvin Humphrey  wrote:

> The copyright checkbox for Kalumet is marked with a question mark, which I
> interpret as "not checked off":
>
> http://incubator.apache.org/projects/kalumet#Copyright
>
> A successful incubating release would have settled the issue, but I did some
> research and it seems that while the Kalumet podling attempted an incubating
> release of their 0.6 branch, it doesn't look like it was ever officially
> completed.
>
> If the copyright status cannot be resolved, I will have to delete `trunk`,
> `tags`, and `branches` from
> .
>
> Can someone provide a definitive answer on whether it is OK for Kalumet's code
> to remain visible in svn?

I'll give this a couple more days.  If no one has spoken up by then, I
will proceed with deleting the code from svn.

Marvin Humphrey

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