Re: Broader community involvement in 4.0 (WAS Re: Rough roadmap for 4.0)

[Dikang Gu]

My 2 cents. I'm wondering is it a good idea to have some high level goals
for the major release? For example, the goals could be something like:
1. Improve the scalability/reliability/performance by X%.
2. Add Y new features (feature A, B, C, D...).
3. Fix Z known issues  (issue A, B, C, D...).

I feel If we can have the high level goals, it would be easy to pick the
jiras to be included in the release.

Does it make sense?

Thanks
Dikang.

On Mon, Nov 7, 2016 at 11:22 AM, Oleksandr Petrov <
oleksandr.pet...@gmail.com> wrote:

> Recently there was another discussion on documentation and comments [1]
>
> On one hand, documentation and comments will help newcomers to familiarise
> themselves with the codebase. On the other - one may get up to speed by
> reading the code and adding some docs. Such things may require less
> oversight and can play some role in improving diversity / increasing an
> amount of involved people.
>
> Same thing with tests. There are some areas where tests need some
> refactoring / improvements, or even just splitting them from one file to
> multiple. It's a good way to experience the process and get involved into
> discussion.
>
> For that, we could add some issues with subtasks (just a few for starters)
> or even just a wiki page with a doc/test wishlist where everyone could add
> a couple of points.
>
> Docs and tests could be used in addition to lhf issues, helping people,
> having comprehensive and quick process and everything else that was
> mentioned in this thread.
>
> Thank you.
>
> [1]
> http://mail-archives.apache.org/mod_mbox/cassandra-dev/201605.mbox/%
> 3ccakkz8q088ojbvhycyz2_2eotqk4y-svwiwksinpt6rr9pop...@mail.gmail.com%3E
>
> On Mon, Nov 7, 2016 at 5:38 PM Aleksey Yeschenko 
> wrote:
>
> > Agreed.
> >
> > --
> > AY
> >
> > On 7 November 2016 at 16:38:07, Jeff Jirsa (jeff.ji...@crowdstrike.com)
> > wrote:
> >
> > ‘Accepted’ JIRA status seems useful, but would encourage something more
> > explicit like ‘Concept Accepted’ or similar to denote that the concept is
> > agreed upon, but the actual patch itself may not be accepted yet.
> >
> > /bikeshed.
> >
> > On 11/7/16, 2:56 AM, "Ben Slater"  wrote:
> >
> > >Thanks Dave. The shepherd concept sounds a lot like I had in mind (and a
> > >better name).
> > >
> > >One other thing I noted from the Mesos process - they have an “Accepted”
> > >jira status that comes after open and means “at least one Mesos
> developer
> > >thought that the ideas proposed in the issue are worth pursuing
> further”.
> > >Might also be something to consider as part of a process like this?
> > >
> > >Cheers
> > >Ben
> > >
> > >On Mon, 7 Nov 2016 at 09:37 Dave Lester  wrote:
> > >
> > >> Hi Ben,
> > >>
> > >> A few ideas to add to your suggestions [inline]:
> > >>
> > >> On 2016-11-06 13:51 (-0800), Ben Slater <
> > https://urldefense.proofpoint.com/v2/url?u=http-3A__ben.
> slater-40instaclustr.com=DgIFaQ=08AGY6txKsvMOP6lYkHQpPMRA1U6kq
> hAwGa8-0QCg3M=yfYEBHVkX6l0zImlOIBID0gmhluYPD5Jje-3CtaT3ow=
> 0Ynrto5MaNdgc2fOUtxv50ouikBU_P7VEv6KNub9Bhk=
> MAZTdq4wfrTiqh7nImEMcFWtTrsixRFOX7Pi0SKqQv0=
> > >
> > >> wrote:
> > >> > Hi All,
> > >> >
> > >> > I thought I would add a couple of observations and suggestions as
> > someone
> > >> > who has both personally made my first contributions to the project
> in
> > the
> > >> > last few months and someone in a leadership role in an organisation
> > >> > (Instaclustr) that is feeling it’s way through increasing our
> > >> contributions
> > >> > as an organisation.
> > >> >
> > >> > Firstly - an observation on contribution experience and what I think
> > is
> > >> > likely to make people want to contribute again:
> > >> > 1) The worst thing that can happen is for your contribution to be
> > >> > completely ignored.
> > >> > 2) The second worst thing is for it to be rejected without a good
> > >> > explanation (that you can learn from) or with hostility.
> > >> > 3) Having it rejected with a good reason is not a bad thing (you
> > learn)
> > >> > 4) Having it accepted is, of course, the best!
> > >> >
> > >> > With this as a background I would suggest a couple of thing that
> help
> > >> make
> > >> > sure (3) and (4) are always more common that (1) and (2) (good
> > outcomes
> > >> are
> > >> > probably more common than bad at the moment but we’ve experienced
> all
> > >> four
> > >> > scenarios in the last few months):
> > >> > 1) I think some process of assigning a committer of a “sponsor” of a
> > >> change
> > >> > (which would probably mean committers volunteering) before it
> > commences
> > >> > would be useful. You can kind of do this at the moment by creating a
> > JIRA
> > >> > and asking for comment but I think the process is a bit unclear and
> a
> > bit
> > >> > intimidating for people starting off and it would be nice to know
> who
> > was
> > >> > your primary reviewer for a piece of work. (Or maybe this process
> does
> > >> > exist 

Re: Rough roadmap for 4.0

[Jeff Jirsa]

Also https://issues.apache.org/jira/browse/CASSANDRA-12676



-- 
Jeff Jirsa


> On Nov 4, 2016, at 11:51 AM, Jason Brown  wrote:
> 
> +1 to epaxos
> 
>> On Fri, Nov 4, 2016 at 11:40 AM, Jonathan Haddad  wrote:
>> 
>> epaxos would be nice, it's been about 2 years since it was started, and
>> Blake asked for a first review well over a year ago.  the benchmarks and
>> thorough test suite look like a huge improvement over the current
>> situation.
>> 
>> https://issues.apache.org/jira/browse/CASSANDRA-6246
>> 
>> On Fri, Nov 4, 2016 at 3:28 AM Edward Capriolo 
>> wrote:
>> 
>>> I would like to propose features around seeds:
>>> https://issues.apache.org/jira/browse/CASSANDRA-12627
>>> 
>>> I have other follow up issues like getting seeds from Amazon API, or from
>>> JNDI/ DNS, etc.
>>> 
>>> I was hoping 12627 was an easy way to grease the wheels.
>>> 
>>> 
>>> On Fri, Nov 4, 2016 at 8:39 AM, Jason Brown 
>> wrote:
>>> 
 Hey Nate,
 
 I'd like to add CASSANDRA-11559 (Enhance node representation) to the
>>> list,
 including the comment I made on the ticket (different storage ports for
 each node). For us, it's a great "would really like to have" as our
>> group
 will probably need this in production within the next 1 year or less.
 However since it hasn't gotten much attention, I'm not sure if we
>> should
 add it to the list of "must haves" for 4.0. I'm planning on bringing it
>>> up
 internally today, as well.
 
 Also, from the previous 4.0 email thread that Jonathan started back in
>>> July
 (
 https://mail-archives.apache.org/mod_mbox/cassandra-dev/
 201607.mbox/%3CCALdd-zhW3qJ%3DOWida9nMXPj0JOsru7guOYh6-
 7uTjqEBvacrgQ%40mail.gmail.com%3E
 )
 
 - CASSANDRA-5 (thrift removal) - ticket not mentioned explicitly in
>>> the
 email, but the notion of removing thrift was
 - CASSANDRA-10857 (Allow dropping COMPACT STORAGE flag)
 
 Thanks,
 
 -Jason
 
 On Thu, Nov 3, 2016 at 8:43 PM, sankalp kohli 
 wrote:
 
> List looks really good. I will let you know if there is something
>> else
>>> we
> plan to add to this list.
> 
> On Thu, Nov 3, 2016 at 7:47 PM, Nate McCall 
>>> wrote:
> 
>> It was brought up recently at the PMC level that our goals as a
>> project are not terribly clear.
>> 
>> This is a pretty good point as outside of Jira 'Fix Version'
>>> labelling
>> (which we actually suck less at compared to a lot of other ASF
>> projects) this really isnt tracked anywhere outside of general
>> tribal
>> knowledge about who is working on what.
>> 
>> I would like to see us change this for two reasons:
>> - it's important we are clear with our community about where we are
 going
>> - we need to start working more closely together
>> 
>> To that end, i've put together a list (in no particular order) of
>> the
>> *major* features in which I know folks are interested, have patches
>> coming, are awaiting design review, etc.:
>> 
>> - CASSANDRA-9425 Immutable node-local schema
>> - CASSANDRA-10699 Strongly consistent schema alterations
>> - CASSANDRA-12229 NIO streaming
>> - CASSANDRA-8457 NIO messaging
>> - CASSANDRA-12345 Gossip 2.0
>> - CASSANDRA-9754 Birch trees
>> 
>> What did I miss? What else would folks like to see? Specifically,
>>> this
>> should be "new stuff that could/will break things" given we are
>>> upping
>> the major version.
>> 
>> To be clear, it's not my intention to set this in stone and then
>> beat
>> people about the head with it. More to have it there to point it
>> at a
>> high level and foster better communication with our users from the
>> perspective of an open source project.
>> 
>> Please keep in mind that given everything else going on, I think
>> it's
>> a fantastic idea to keep this list small and spend some time
>> focusing
>> on stability particularly as we transition to a new release
>> process.
>> 
>> -Nate
>> 
> 
 
>>> 
>> 

Re: [VOTE] Close client-...@cassandra.apache.org mailing list

[Dave Lester]

+1 (non-binding)

On 2016-11-07 12:52 (-0800), sankalp kohli  wrote: 
> +1
> 
> On Mon, Nov 7, 2016 at 10:19 AM, Brandon Williams  wrote:
> 
> > As the moderator of this list, +1.  It was more helpful in the thrift days
> > (where I built a client, and thus became the moderator) but is practically
> > useless in the cql world.
> >
> > On Sun, Nov 6, 2016 at 11:11 PM, Jeff Jirsa  wrote:
> >
> > > There exists a nearly unused mailing list, client-dev@cassandra.apache.
> > org
> > > [0].
> > >
> > > This is a summary of the email threads over the past 12 months on that
> > > list:
> > >
> > > 1) ApacheCon Seville CFP Close notice
> > > 2) Datastax .NET driver question
> > > 3) Datastax Java driver question
> > > 4) FOSDEM announce
> > > 5) ApacheCon NA CFP Open noticed
> > >
> > > In order to avoid confusion, and given the lack of relevant and
> > > appropriate traffic, I propose we close the client-dev@ list entirely.
> > > Any traffic appropriate for the client-dev@ list would likely be better
> > > served if it were directed at dev@, which is more active.
> > >
> > > This vote will remain open for 72 hours.
> > >
> > > 0: https://lists.apache.org/list.html?client-...@cassandra.apache.org
> > >
> > >
> > >
> >
> 

[GitHub] cassandra pull request #79: Correct Spelling Errors in JavaDoc for IEndPoint...

[asfgit]

Github user asfgit closed the pull request at:

https://github.com/apache/cassandra/pull/79


---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

Re: Review of Cassandra actions

[Eric Evans]

On Sun, Nov 6, 2016 at 3:42 PM, Mark Thomas  wrote:
> A number of posts from a variety of authors on this topic in recent days
> have fallen short of the standard expected on an Apache list. Trying to
> correct that without causing the situation to escalate is hard. The last
> thing I want to do is add fuel to the fire. I've started to draft a
> couple of emails at various points over the weekend only to find by the
> time I'm happy(ish) with the draft, the thread has moved on and I need
> to start again.
>
> Alongside this I had hoped that things would have slowed down enough
> over the weekend to give everyone time to reflect, recognise where they
> might need to apologise and aim to start this coming week on a more
> positive footing. There have been signs of this which I take to be
> encouraging. Moving forward I'd encourage everyone to pause and review
> what they have just written with the Code of Conduct in mind before
> pressing send.

Thank you for this Mark.

And while we're at it, thank you for all of your input these past
weeks.  It's been incredibly helpful and constructive.


-- 
Eric Evans
john.eric.ev...@gmail.com

Re: Broader community involvement in 4.0 (WAS Re: Rough roadmap for 4.0)

[Oleksandr Petrov]

Recently there was another discussion on documentation and comments [1]

On one hand, documentation and comments will help newcomers to familiarise
themselves with the codebase. On the other - one may get up to speed by
reading the code and adding some docs. Such things may require less
oversight and can play some role in improving diversity / increasing an
amount of involved people.

Same thing with tests. There are some areas where tests need some
refactoring / improvements, or even just splitting them from one file to
multiple. It's a good way to experience the process and get involved into
discussion.

For that, we could add some issues with subtasks (just a few for starters)
or even just a wiki page with a doc/test wishlist where everyone could add
a couple of points.

Docs and tests could be used in addition to lhf issues, helping people,
having comprehensive and quick process and everything else that was
mentioned in this thread.

Thank you.

[1]
http://mail-archives.apache.org/mod_mbox/cassandra-dev/201605.mbox/%3ccakkz8q088ojbvhycyz2_2eotqk4y-svwiwksinpt6rr9pop...@mail.gmail.com%3E

On Mon, Nov 7, 2016 at 5:38 PM Aleksey Yeschenko  wrote:

> Agreed.
>
> --
> AY
>
> On 7 November 2016 at 16:38:07, Jeff Jirsa (jeff.ji...@crowdstrike.com)
> wrote:
>
> ‘Accepted’ JIRA status seems useful, but would encourage something more
> explicit like ‘Concept Accepted’ or similar to denote that the concept is
> agreed upon, but the actual patch itself may not be accepted yet.
>
> /bikeshed.
>
> On 11/7/16, 2:56 AM, "Ben Slater"  wrote:
>
> >Thanks Dave. The shepherd concept sounds a lot like I had in mind (and a
> >better name).
> >
> >One other thing I noted from the Mesos process - they have an “Accepted”
> >jira status that comes after open and means “at least one Mesos developer
> >thought that the ideas proposed in the issue are worth pursuing further”.
> >Might also be something to consider as part of a process like this?
> >
> >Cheers
> >Ben
> >
> >On Mon, 7 Nov 2016 at 09:37 Dave Lester  wrote:
> >
> >> Hi Ben,
> >>
> >> A few ideas to add to your suggestions [inline]:
> >>
> >> On 2016-11-06 13:51 (-0800), Ben Slater <
> https://urldefense.proofpoint.com/v2/url?u=http-3A__ben.slater-40instaclustr.com=DgIFaQ=08AGY6txKsvMOP6lYkHQpPMRA1U6kqhAwGa8-0QCg3M=yfYEBHVkX6l0zImlOIBID0gmhluYPD5Jje-3CtaT3ow=0Ynrto5MaNdgc2fOUtxv50ouikBU_P7VEv6KNub9Bhk=MAZTdq4wfrTiqh7nImEMcFWtTrsixRFOX7Pi0SKqQv0=
> >
> >> wrote:
> >> > Hi All,
> >> >
> >> > I thought I would add a couple of observations and suggestions as
> someone
> >> > who has both personally made my first contributions to the project in
> the
> >> > last few months and someone in a leadership role in an organisation
> >> > (Instaclustr) that is feeling it’s way through increasing our
> >> contributions
> >> > as an organisation.
> >> >
> >> > Firstly - an observation on contribution experience and what I think
> is
> >> > likely to make people want to contribute again:
> >> > 1) The worst thing that can happen is for your contribution to be
> >> > completely ignored.
> >> > 2) The second worst thing is for it to be rejected without a good
> >> > explanation (that you can learn from) or with hostility.
> >> > 3) Having it rejected with a good reason is not a bad thing (you
> learn)
> >> > 4) Having it accepted is, of course, the best!
> >> >
> >> > With this as a background I would suggest a couple of thing that help
> >> make
> >> > sure (3) and (4) are always more common that (1) and (2) (good
> outcomes
> >> are
> >> > probably more common than bad at the moment but we’ve experienced all
> >> four
> >> > scenarios in the last few months):
> >> > 1) I think some process of assigning a committer of a “sponsor” of a
> >> change
> >> > (which would probably mean committers volunteering) before it
> commences
> >> > would be useful. You can kind of do this at the moment by creating a
> JIRA
> >> > and asking for comment but I think the process is a bit unclear and a
> bit
> >> > intimidating for people starting off and it would be nice to know who
> was
> >> > your primary reviewer for a piece of work. (Or maybe this process does
> >> > exist and I don’t know about.)
> >>
> >> I've seen this approach before and it that can reduce ambiguity on the
> >> state of contributions; the Apache Mesos project has a shepherding
> system
> >> similar to this. I would shy away from the term "sponsor" since it could
> >> infer a non-voluntary relationship between contributors and volunteer
> >> committers.
> >>
> >> From the Mesos docs: "Find a shepherd to collaborate on your patch. A
> >> shepherd is a Mesos committer that will work with you to give you
> feedback
> >> on your proposed design, and to eventually commit your change into the
> >> Mesos source tree." More info on how they approach this is in both their
> >> newbie guide:
> 

Re: Wiki edit

[Michael Shuler]

On 11/06/2016 11:59 PM, Vladimir Yudovin wrote:
> Please add user winguzone to Wiki,

Done. Thanks!

-- 
Michael

Re: [VOTE] Close client-...@cassandra.apache.org mailing list

[Brandon Williams]

As the moderator of this list, +1.  It was more helpful in the thrift days
(where I built a client, and thus became the moderator) but is practically
useless in the cql world.

On Sun, Nov 6, 2016 at 11:11 PM, Jeff Jirsa  wrote:

> There exists a nearly unused mailing list, client-...@cassandra.apache.org
> [0].
>
> This is a summary of the email threads over the past 12 months on that
> list:
>
> 1) ApacheCon Seville CFP Close notice
> 2) Datastax .NET driver question
> 3) Datastax Java driver question
> 4) FOSDEM announce
> 5) ApacheCon NA CFP Open noticed
>
> In order to avoid confusion, and given the lack of relevant and
> appropriate traffic, I propose we close the client-dev@ list entirely.
> Any traffic appropriate for the client-dev@ list would likely be better
> served if it were directed at dev@, which is more active.
>
> This vote will remain open for 72 hours.
>
> 0: https://lists.apache.org/list.html?client-...@cassandra.apache.org
>
>
>

Re: [VOTE] Close client-...@cassandra.apache.org mailing list

[Nate McCall]

+1

On Mon, Nov 7, 2016 at 6:11 PM, Jeff Jirsa  wrote:
> There exists a nearly unused mailing list, client-...@cassandra.apache.org 
> [0].
>
> This is a summary of the email threads over the past 12 months on that list:
>
> 1) ApacheCon Seville CFP Close notice
> 2) Datastax .NET driver question
> 3) Datastax Java driver question
> 4) FOSDEM announce
> 5) ApacheCon NA CFP Open noticed
>
> In order to avoid confusion, and given the lack of relevant and appropriate 
> traffic, I propose we close the client-dev@ list entirely. Any traffic 
> appropriate for the client-dev@ list would likely be better served if it were 
> directed at dev@, which is more active.
>
> This vote will remain open for 72 hours.
>
> 0: https://lists.apache.org/list.html?client-...@cassandra.apache.org
>
>

Re: Wiki admin

[Brandon Williams]

Done.

On Mon, Nov 7, 2016 at 9:37 AM, Michael Shuler 
wrote:

> If someone could set the user MichaelShuler as admin, I can help with
> user requests, such as the the current request on the list to add
> winguzone.
>
> --
> Michael
>

Re: Broader community involvement in 4.0 (WAS Re: Rough roadmap for 4.0)

[Aleksey Yeschenko]

Agreed.

-- 
AY

On 7 November 2016 at 16:38:07, Jeff Jirsa (jeff.ji...@crowdstrike.com) wrote:

‘Accepted’ JIRA status seems useful, but would encourage something more 
explicit like ‘Concept Accepted’ or similar to denote that the concept is 
agreed upon, but the actual patch itself may not be accepted yet.  

/bikeshed.  

On 11/7/16, 2:56 AM, "Ben Slater"  wrote:  

>Thanks Dave. The shepherd concept sounds a lot like I had in mind (and a  
>better name).  
>  
>One other thing I noted from the Mesos process - they have an “Accepted”  
>jira status that comes after open and means “at least one Mesos developer  
>thought that the ideas proposed in the issue are worth pursuing further”.  
>Might also be something to consider as part of a process like this?  
>  
>Cheers  
>Ben  
>  
>On Mon, 7 Nov 2016 at 09:37 Dave Lester  wrote:  
>  
>> Hi Ben,  
>>  
>> A few ideas to add to your suggestions [inline]:  
>>  
>> On 2016-11-06 13:51 (-0800), Ben Slater 
>> >  >  
>> wrote:  
>> > Hi All,  
>> >  
>> > I thought I would add a couple of observations and suggestions as someone  
>> > who has both personally made my first contributions to the project in the  
>> > last few months and someone in a leadership role in an organisation  
>> > (Instaclustr) that is feeling it’s way through increasing our  
>> contributions  
>> > as an organisation.  
>> >  
>> > Firstly - an observation on contribution experience and what I think is  
>> > likely to make people want to contribute again:  
>> > 1) The worst thing that can happen is for your contribution to be  
>> > completely ignored.  
>> > 2) The second worst thing is for it to be rejected without a good  
>> > explanation (that you can learn from) or with hostility.  
>> > 3) Having it rejected with a good reason is not a bad thing (you learn)  
>> > 4) Having it accepted is, of course, the best!  
>> >  
>> > With this as a background I would suggest a couple of thing that help  
>> make  
>> > sure (3) and (4) are always more common that (1) and (2) (good outcomes  
>> are  
>> > probably more common than bad at the moment but we’ve experienced all  
>> four  
>> > scenarios in the last few months):  
>> > 1) I think some process of assigning a committer of a “sponsor” of a  
>> change  
>> > (which would probably mean committers volunteering) before it commences  
>> > would be useful. You can kind of do this at the moment by creating a JIRA  
>> > and asking for comment but I think the process is a bit unclear and a bit  
>> > intimidating for people starting off and it would be nice to know who was  
>> > your primary reviewer for a piece of work. (Or maybe this process does  
>> > exist and I don’t know about.)  
>>  
>> I've seen this approach before and it that can reduce ambiguity on the  
>> state of contributions; the Apache Mesos project has a shepherding system  
>> similar to this. I would shy away from the term "sponsor" since it could  
>> infer a non-voluntary relationship between contributors and volunteer  
>> committers.  
>>  
>> From the Mesos docs: "Find a shepherd to collaborate on your patch. A  
>> shepherd is a Mesos committer that will work with you to give you feedback  
>> on your proposed design, and to eventually commit your change into the  
>> Mesos source tree." More info on how they approach this is in both their  
>> newbie guide: 
>> https://urldefense.proofpoint.com/v2/url?u=http-3A__mesos.apache.org_documentation_newbie-2Dguide_=DgIFaQ=08AGY6txKsvMOP6lYkHQpPMRA1U6kqhAwGa8-0QCg3M=yfYEBHVkX6l0zImlOIBID0gmhluYPD5Jje-3CtaT3ow=0Ynrto5MaNdgc2fOUtxv50ouikBU_P7VEv6KNub9Bhk=MB2cGSGm5RHMnWWRGLZ4h8P7Mo0Rvm6k5mW2yhQVZ7U=
>>  , and  
>> submitting a patch guide:  
>> https://urldefense.proofpoint.com/v2/url?u=http-3A__mesos.apache.org_documentation_latest_submitting-2Da-2Dpatch_=DgIFaQ=08AGY6txKsvMOP6lYkHQpPMRA1U6kqhAwGa8-0QCg3M=yfYEBHVkX6l0zImlOIBID0gmhluYPD5Jje-3CtaT3ow=0Ynrto5MaNdgc2fOUtxv50ouikBU_P7VEv6KNub9Bhk=PSj3seUwzL_USxWvdvqlMKrU_yfBXpOSQ4XfjdhnmO0=
>>  .  
>>  
>> In practice, there are some limitations and risks to this model. For one,  
>> a shepherding process is not a substitute for the Apache Way, and it's  
>> critical that design decisions and reviews are still done in the open.  
>> Additionally, in projects where a single organization has disproportionate  
>> representation at the committer level it can create bottlenecks if features  
>> are a lower priority for those orgs (while not malicious, it may mean that  
>> certain patches are shepherded while others are ignored). It's possible to  
>> work within these limitations, especially in cases where the community is  
>> having healthy conversations 

Re: Broader community involvement in 4.0 (WAS Re: Rough roadmap for 4.0)

[Jeff Jirsa]

‘Accepted’ JIRA status seems useful, but would encourage something more 
explicit like ‘Concept Accepted’ or similar to denote that the concept is 
agreed upon, but the actual patch itself may not be accepted yet.

/bikeshed. 

On 11/7/16, 2:56 AM, "Ben Slater"  wrote:

>Thanks Dave. The shepherd concept sounds a lot like I had in mind (and a
>better name).
>
>One other thing I noted from the Mesos process - they have an “Accepted”
>jira status that comes after open and means “at least one Mesos developer
>thought that the ideas proposed in the issue are worth pursuing further”.
>Might also be something to consider as part of a process like this?
>
>Cheers
>Ben
>
>On Mon, 7 Nov 2016 at 09:37 Dave Lester  wrote:
>
>> Hi Ben,
>>
>> A few ideas to add to your suggestions [inline]:
>>
>> On 2016-11-06 13:51 (-0800), Ben Slater 
>> >  >
>> wrote:
>> > Hi All,
>> >
>> > I thought I would add a couple of observations and suggestions as someone
>> > who has both personally made my first contributions to the project in the
>> > last few months and someone in a leadership role in an organisation
>> > (Instaclustr) that is feeling it’s way through increasing our
>> contributions
>> > as an organisation.
>> >
>> > Firstly - an observation on contribution experience and what I think is
>> > likely to make people want to contribute again:
>> > 1) The worst thing that can happen is for your contribution to be
>> > completely ignored.
>> > 2) The second worst thing is for it to be rejected without a good
>> > explanation (that you can learn from) or with hostility.
>> > 3) Having it rejected with a good reason is not a bad thing (you learn)
>> > 4) Having it accepted is, of course, the best!
>> >
>> > With this as a background I would suggest a couple of thing that help
>> make
>> > sure (3) and (4) are always more common that (1) and (2) (good outcomes
>> are
>> > probably more common than bad at the moment but we’ve experienced all
>> four
>> > scenarios in the last few months):
>> > 1) I think some process of assigning a committer of a “sponsor” of a
>> change
>> > (which would probably mean committers volunteering) before it commences
>> > would be useful. You can kind of do this at the moment by creating a JIRA
>> > and asking for comment but I think the process is a bit unclear and a bit
>> > intimidating for people starting off and it would be nice to know who was
>> > your primary reviewer for a piece of work. (Or maybe this process does
>> > exist and I don’t know about.)
>>
>> I've seen this approach before and it that can reduce ambiguity on the
>> state of contributions; the Apache Mesos project has a shepherding system
>> similar to this. I would shy away from the term "sponsor" since it could
>> infer a non-voluntary relationship between contributors and volunteer
>> committers.
>>
>> From the Mesos docs: "Find a shepherd to collaborate on your patch. A
>> shepherd is a Mesos committer that will work with you to give you feedback
>> on your proposed design, and to eventually commit your change into the
>> Mesos source tree." More info on how they approach this is in both their
>> newbie guide: 
>> https://urldefense.proofpoint.com/v2/url?u=http-3A__mesos.apache.org_documentation_newbie-2Dguide_=DgIFaQ=08AGY6txKsvMOP6lYkHQpPMRA1U6kqhAwGa8-0QCg3M=yfYEBHVkX6l0zImlOIBID0gmhluYPD5Jje-3CtaT3ow=0Ynrto5MaNdgc2fOUtxv50ouikBU_P7VEv6KNub9Bhk=MB2cGSGm5RHMnWWRGLZ4h8P7Mo0Rvm6k5mW2yhQVZ7U=
>>  , and
>> submitting a patch guide:
>> https://urldefense.proofpoint.com/v2/url?u=http-3A__mesos.apache.org_documentation_latest_submitting-2Da-2Dpatch_=DgIFaQ=08AGY6txKsvMOP6lYkHQpPMRA1U6kqhAwGa8-0QCg3M=yfYEBHVkX6l0zImlOIBID0gmhluYPD5Jje-3CtaT3ow=0Ynrto5MaNdgc2fOUtxv50ouikBU_P7VEv6KNub9Bhk=PSj3seUwzL_USxWvdvqlMKrU_yfBXpOSQ4XfjdhnmO0=
>>  .
>>
>> In practice, there are some limitations and risks to this model. For one,
>> a shepherding process is not a substitute for the Apache Way, and it's
>> critical that design decisions and reviews are still done in the open.
>> Additionally, in projects where a single organization has disproportionate
>> representation at the committer level it can create bottlenecks if features
>> are a lower priority for those orgs (while not malicious, it may mean that
>> certain patches are shepherded while others are ignored). It's possible to
>> work within these limitations, especially in cases where the community is
>> having healthy conversations about the direction and roadmap for the
>> project (similar to the original thread).
>>
>> If this is something the project would like to push forward, I'd suggest a
>> committer vote to ensure there's sufficient buy-in.
>>
>> > 2) I think the “how to 

Re: Moderation

[Eric Evans]

On Fri, Nov 4, 2016 at 11:57 AM, Chris Mattmann  wrote:
> Yet you act like it's volunteer time that's preventing moderating a message 
> through in 12 hours.

Here it is again, 12 hours.  If we have a 12 hour SLA on moderation,
then you can remove me as a moderator; I can't do that.

-- 
Eric Evans
john.eric.ev...@gmail.com

Re: Moderation

[Eric Evans]

On Fri, Nov 4, 2016 at 11:51 AM, Gary Dusbabek  wrote:
> I'm beginning to wonder if I'm the only one with moderator privs. Any other
> committer/PMCs interested?

You are not.

> Sorry, it's a chore to begin with and I've been traveling this week.

No need to be sorry.

-- 
Eric Evans
john.eric.ev...@gmail.com

Re: Moderation

[Eric Evans]

On Fri, Nov 4, 2016 at 11:44 AM, Chris Mattmann  wrote:
> So seriously, we're going to send now 4 emails talking about what a user of 
> Apache Cassandra and possible community member could have done right or 
> better or sooner, or that there is no time limit to moderating shit when it 
> could have been as simple as literally sending a confirmation email to 
> moderate it through? This is the definition of process over community. And 
> it's the definition (wrongly so) of why people think it's "Apache" that 
> induces the processes that make shit hard, and not the community itself. 
> Seriously this is a joke. So what if she didn't do it right the first time. 
> You think potentially moderating her mail through and then sending a kind 
> email suggesting she look at the instructions for how to subscribe, which oh 
> someone may not have found easy to do or simply not understood that simply 
> sending an email to the list wouldn't have made it go through the first time? 
> Is it that hard to figure out? Really?
>
> This is the definition of making things hard and not making them easy or 
> friendly. And this is also exactly what enables people to sound off on 
> Twitter about a project, and loses the conversation that could have been had 
> on Apache mailing lists. Kelly has been tweeting for days. I saw her tweets 
> retweeted by someone in my feed, and yesterday asked her kindly to bring her 
> conversation to the list. 12 hours later it's still in moderation, and we are 
> arguing whether to f'ing moderate it through. Wow. Great job.

Wait, what?  As a moderator of this list (unpaid, volunteer), did I
miss the SLA I was being held to?  Are you volunteering to moderate
this list?


-- 
Eric Evans
john.eric.ev...@gmail.com

Re: [VOTE] Close client-...@cassandra.apache.org mailing list

[Licata, Christopher (CONT)]

+1

Thanks,
Christopher Licata
Senior Software Engineer
Game Changers 
Card Rewards
718.916.8940



On 11/7/16, 10:29 AM, "Michael Shuler"  wrote:

1) ApacheCon Seville CFP Close notice
2) Datastax .NET driver question 
3) Datastax Java driver question
4) FOSDEM announce
5) ApacheCon NA CFP Open noticed

In order to avoid confusion, and given the lack of relevant and appropriate 
traffic, I propose we close the client-dev@ list entirely. Any traffic 
appropriate for the client-dev@ list would likely be better served if it were 
directed at dev@, which is more active.




The information contained in this e-mail is confidential and/or proprietary to 
Capital One and/or its affiliates and may only be used solely in performance of 
work or services for Capital One. The information transmitted herewith is 
intended only for use by the individual or entity to which it is addressed. If 
the reader of this message is not the intended recipient, you are hereby 
notified that any review, retransmission, dissemination, distribution, copying 
or other use of, or taking of any action in reliance upon this information is 
strictly prohibited. If you have received this communication in error, please 
contact the sender and delete the material from your computer.

[GitHub] cassandra issue #79: Correct Spelling Errors in JavaDoc for IEndPointSnitch

[cmlicata]

Github user cmlicata commented on the issue:

https://github.com/apache/cassandra/pull/79
  
Removed correction of datacenter to data center @michaelsembwever.


---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

Re: DataStax role in Cassandra and the ASF

[Ross Gardler]

Again. If the PMC fails to bring board (and trademark) feedback to the 
community it is not a failing of the board. Board minutes are available. Review 
comments and actions over the last 12 months or so.

---
Twitter: @rgardler


From: Jeremy Hanna 
Sent: Saturday, November 5, 2016 8:30:20 AM
To: Jim Jagielski
Cc: dev@cassandra.apache.org; Łukasz Dywicki; Chris Mattmann; Kelly Sommers; 
Apache Board
Subject: Re: DataStax role in Cassandra and the ASF

No it wasn't. You're citing the eventual and agreed upon outcome. I was talking 
about the approach which is clear in the dev and user list threads that the 
board was involved in. It is also apparently much more apparent in the private 
threads which apparently the PMC can make public.

> On Nov 5, 2016, at 10:02 AM, Jim Jagielski  wrote:
>
> Which is what was done: 
> https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwhimsy.apache.org%2Fboard%2Fminutes%2FCassandra.html=02%7C01%7CRoss.Gardler%40microsoft.com%7Ca198e6c0a658409b0b8208d406e21b78%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636141015575977801=xL7B%2F1xNDCfgnZ2pvTnuuhZWIymllsNV1Z0WNghuot4%3D=0
>
>> On Nov 5, 2016, at 10:48 AM, Jeremy Hanna  wrote:
>>
>> If the ASF is at risk with a single company allowed to dominate a project 
>> then why couldn't the approach have been something like: "great job on 
>> building a successful project and community. We think there is great 
>> potential for more involvement at the core contribution level. How can we 
>> work together to augment the existing efforts to encourage contribution and 
>> bring in new contributors? By the way here are a couple of policy and 
>> trademark things that we need to get fixed."
>>
>> I didn't understand the assumption that DataStax was doing something 
>> nefarious nor the approach that was taken.  On a personal note I had tried 
>> to ask about evidence and the approach previously but was ignored: 
>> https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.mail-archive.com%2Fdev%40cassandra.apache.org%2Fmsg09101.html=02%7C01%7CRoss.Gardler%40microsoft.com%7Ca198e6c0a658409b0b8208d406e21b78%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636141015575977801=tvQacSr5ikOC8wgxR6iD2QdtqEYc13rjiA977Ic6FNM%3D=0
>>   Perhaps that was due to the volume of messages on that thread but I don't 
>> feel those questions were ever addressed.
>>
>> Regardless, I see a positive way forward for the project and am grateful to 
>> everyone working towards that.
>>
>

Wiki admin

[Michael Shuler]

If someone could set the user MichaelShuler as admin, I can help with
user requests, such as the the current request on the list to add winguzone.

-- 
Michael

Re: [VOTE] Close client-...@cassandra.apache.org mailing list

[Michael Shuler]

+1

On 11/06/2016 11:11 PM, Jeff Jirsa wrote:
> There exists a nearly unused mailing list, client-...@cassandra.apache.org 
> [0]. 
> 
> This is a summary of the email threads over the past 12 months on that list:
> 
> 1) ApacheCon Seville CFP Close notice
> 2) Datastax .NET driver question 
> 3) Datastax Java driver question
> 4) FOSDEM announce
> 5) ApacheCon NA CFP Open noticed
> 
> In order to avoid confusion, and given the lack of relevant and appropriate 
> traffic, I propose we close the client-dev@ list entirely. Any traffic 
> appropriate for the client-dev@ list would likely be better served if it were 
> directed at dev@, which is more active.
> 
> This vote will remain open for 72 hours. 
> 
> 0: https://lists.apache.org/list.html?client-...@cassandra.apache.org
> 
> 

Re: Broader community involvement in 4.0 (WAS Re: Rough roadmap for 4.0)

[Ben Slater]

Thanks Dave. The shepherd concept sounds a lot like I had in mind (and a
better name).

One other thing I noted from the Mesos process - they have an “Accepted”
jira status that comes after open and means “at least one Mesos developer
thought that the ideas proposed in the issue are worth pursuing further”.
Might also be something to consider as part of a process like this?

Cheers
Ben

On Mon, 7 Nov 2016 at 09:37 Dave Lester  wrote:

> Hi Ben,
>
> A few ideas to add to your suggestions [inline]:
>
> On 2016-11-06 13:51 (-0800), Ben Slater 
> wrote:
> > Hi All,
> >
> > I thought I would add a couple of observations and suggestions as someone
> > who has both personally made my first contributions to the project in the
> > last few months and someone in a leadership role in an organisation
> > (Instaclustr) that is feeling it’s way through increasing our
> contributions
> > as an organisation.
> >
> > Firstly - an observation on contribution experience and what I think is
> > likely to make people want to contribute again:
> > 1) The worst thing that can happen is for your contribution to be
> > completely ignored.
> > 2) The second worst thing is for it to be rejected without a good
> > explanation (that you can learn from) or with hostility.
> > 3) Having it rejected with a good reason is not a bad thing (you learn)
> > 4) Having it accepted is, of course, the best!
> >
> > With this as a background I would suggest a couple of thing that help
> make
> > sure (3) and (4) are always more common that (1) and (2) (good outcomes
> are
> > probably more common than bad at the moment but we’ve experienced all
> four
> > scenarios in the last few months):
> > 1) I think some process of assigning a committer of a “sponsor” of a
> change
> > (which would probably mean committers volunteering) before it commences
> > would be useful. You can kind of do this at the moment by creating a JIRA
> > and asking for comment but I think the process is a bit unclear and a bit
> > intimidating for people starting off and it would be nice to know who was
> > your primary reviewer for a piece of work. (Or maybe this process does
> > exist and I don’t know about.)
>
> I've seen this approach before and it that can reduce ambiguity on the
> state of contributions; the Apache Mesos project has a shepherding system
> similar to this. I would shy away from the term "sponsor" since it could
> infer a non-voluntary relationship between contributors and volunteer
> committers.
>
> From the Mesos docs: "Find a shepherd to collaborate on your patch. A
> shepherd is a Mesos committer that will work with you to give you feedback
> on your proposed design, and to eventually commit your change into the
> Mesos source tree." More info on how they approach this is in both their
> newbie guide: http://mesos.apache.org/documentation/newbie-guide/, and
> submitting a patch guide:
> http://mesos.apache.org/documentation/latest/submitting-a-patch/.
>
> In practice, there are some limitations and risks to this model. For one,
> a shepherding process is not a substitute for the Apache Way, and it's
> critical that design decisions and reviews are still done in the open.
> Additionally, in projects where a single organization has disproportionate
> representation at the committer level it can create bottlenecks if features
> are a lower priority for those orgs (while not malicious, it may mean that
> certain patches are shepherded while others are ignored). It's possible to
> work within these limitations, especially in cases where the community is
> having healthy conversations about the direction and roadmap for the
> project (similar to the original thread).
>
> If this is something the project would like to push forward, I'd suggest a
> committer vote to ensure there's sufficient buy-in.
>
> > 2) I think the “how to contribute” docs could emphasise activities other
> > than creating new features as a great place to start.It seems that
> review,
> > testing and doco could all do with more hands (as on just about any
> > project). So, encouraging this as a way to start on the project might
> help
> > to get some more bandwidth in this area rather than people creating
> patches
> > that the committers don’t have bandwidth to review. I would be happy to
> > draft an update to the docs including some of this if people think it’s a
> > good idea.
>
> This would be great. If you make changes here and create a JIRA ticket
> associated with it, please add me to the ticket and I'll happily provide
> feedback.
>
> Dave
>
> >
> > Cheers
> > Ben
> >
> > On Sun, 6 Nov 2016 at 06:40 Michael Shuler 
> wrote:
> >
> > > On 11/04/2016 06:43 PM, Jeff Beck wrote:
> > > > I run the local Cassandra User Group and I would love to help get the
> > > > community more involved.  I would propose holding a night to add
> patches
> > > to
> > > > Cassandra some will be simple things like making sure some 

Re: Review of Cassandra actions

[Benedict Elliott Smith]

Hi Mark,

Thanks, that was a calm and diplomatic email.

recognise where they might need to apologise


I will start the ball rolling here, as I have not always been generous in
my interpretations of others' actions, and have certainly contributed to
escalation.

But I wonder if you would also help get the ball rolling; your reasonable
tone gives me hope that you can.  The topic for me has been: can board
members recognise publicly where they have misstepped.  Doing so provides
assurances to the whole ASF community that the board can be trusted.

https://www.mail-archive.com/user@cassandra.apache.org/msg48692.html

In this email chain not long ago, you attempted to apply a misreading of
the ASF guidelines to non-ASF individuals.  When I pointed this out, you
went silent.  In that chain, as now, I had a righteous indignation that no
doubt inflamed the topic, and could have resolved the issue with more
diplomacy.  I'm also sure you had excellent intentions.

Nevertheless, you did misstep as a board member by quite badly misapplying
the guidelines.  With no public recognition of this, I was left with an
impression of unaccountability; I don't know how others responded.

I think it would be fantastic if board members, as people in positions of
authority, lead by example and began recognising where their public
behaviour has missed the mark.  Perhaps that would promote those in less
lofty positions to begin doing the same, and greater trust all round.




On 6 November 2016 at 21:42, Mark Thomas  wrote:

> For the sake of clarity I am a member of the ASF board but I am not
> speaking on behalf of the board in this email.
>
> On 06/11/2016 01:25, Jeff Jirsa wrote:
> > I hope the other 7 members of the board take note of this response,
> > and other similar reactions on dev@ today.
>
> I can't speak for all seven other board members but I can say that I am
> monitoring this thread and the related threads (although I haven't
> looked at Twitter where a lot of this seems to have originated). It is
> apparent to me that a number of the other directors are monitoring these
> threads too.
>
> > When Datastax violated trademark, they acknowledged it and worked to
> > correct it. To their credit, they tried to do the right thing.
> > When the PMC failed to enforce problems, we acknowledged it and worked
> > to correct it. We aren't perfect, but we're trying.
>
> I think you are being a little hard on the PMC there. There was scope
> for both parties to do better in a number of areas.
>
> I do agree that things in the PMC have improved and are heading in the
> right direction (with some more work still to do), as I hope I made
> clear in the summary section of the review e-mail I wrote (privately) to
> the PMC a few weeks ago.
>
> > When a few members the board openly violate the code of conduct, being
> > condescending and disrespectful under the auspices of "enforcing the
> > rules" and "protecting the community", they're breaking the rules,
> > damaging the community, and nobody seems willing to acknowledge it or
> > work to correct it. It's not isolated, I'll link examples if it's
> > useful.
>
> I take it you mean "nobody on the board seems willing...". Again, I
> can't speak for the other board members but let me try and explain my
> own thinking.
>
> A number of posts from a variety of authors on this topic in recent days
> have fallen short of the standard expected on an Apache list. Trying to
> correct that without causing the situation to escalate is hard. The last
> thing I want to do is add fuel to the fire. I've started to draft a
> couple of emails at various points over the weekend only to find by the
> time I'm happy(ish) with the draft, the thread has moved on and I need
> to start again.
>
> Alongside this I had hoped that things would have slowed down enough
> over the weekend to give everyone time to reflect, recognise where they
> might need to apologise and aim to start this coming week on a more
> positive footing. There have been signs of this which I take to be
> encouraging. Moving forward I'd encourage everyone to pause and review
> what they have just written with the Code of Conduct in mind before
> pressing send.
>
> > In a time when we're all trying to do the right thing to protect the
> > project and the community, it's unfortunate that high ranking, long
> > time members within the ASF actively work to undermine trust and
> > community while flaunting the code of conduct, which requires
> > friendliness, empathy, and professionalism, and the rest of the board
> > is silent on the matter.
>
> Your calm responses and efforts to inform the community are appreciated.
> It is not an easy task and kudos to you for taking it on.
>
> As as been said several times in recent days, board members are rarely
> speaking on behalf of the board (i.e. representing the agreed position
> of the board). It is unusual enough that when we do we'll make it
> explicit. One of the reasons for 

Re: DataStax and Cassandra

[Alain RODRIGUEZ]

Hi,

On a personal note, I’d like to thank those in this weekend’s threads who have
> tried to de-escalate tensions rather than inflame them.


I agree. Thanks. Let's try to all learn from that, please. I believe we can
disagree politely and respectfully. And we must do so. We can still express
anything we want to express. It's just a bit harder, it takes a bit longer
this way, but it's so much more efficient to have your real message
reaching people.

Jeff Jirsa’s diplomacy stands out to me as particularly mature.
>

True, that was my opinion as well while reading the threads. I also want to
take the chance to say that this applies to you as well Jonathan. IMHO,
your message is just what the community needed right now. So thanks for the
clarification...

... And for what you have done in the last years. As Aaron said at the
Summit, you, as an individual, have changed my life, and many other, in a
very good way. From my first message in the user mailing list you answered
to this last message in the dev list to preserve the community, even after
stepping down from the project chair. The amount, variety and quality of
work you have done and the way you are behaving are inspiring for me.

As has been said before, we’re all on the same team here.  Now let’s get back
> to making Apache Cassandra the best open source distributed database in
> the world!


Sounds good :-).

A community is nothing but what we bring to it as individuals. Looking
forward to working all together, with our disagreements, but peacefully, in
the same direction, once again.

C*heers,
---
Alain Rodriguez - @arodream - al...@thelastpickle.com
France

The Last Pickle - Apache Cassandra Consulting
http://www.thelastpickle.com

2016-11-06 21:43 GMT+01:00 Jonathan Ellis :

> Hi all,
>
> There’s been some conversation and some acrimony kicked up by my recent
> blog post here
> .
> I appreciate the conversation and regret the acrimony!
>
> Fundamentally I was trying to convey two complementary messages:
>
>
>1.
>
>DataStax wants to see Apache Cassandra thrive and will continue to
>contribute in multiple ways to make that happen, but at the same time
>2.
>
>DataStax will be placing more emphasis on DSE and more engineering
>effort behind it.
>
>
> It’s unfortunate that the timing here coincides with some regrettable
> actions by the Apache Board of Directors, but this change in emphasis is
> primarily driven by business factors unrelated to the ASF.  DataStax shares
> Apache’s commitment to community-led development independent of any single
> vendor.
>
> One friend pointed out to me that any vagueness can be interpreted as
> “weasel words” and turned into alarmist conjectures as to what this really
> means.  I gave several specifics in the post as to how DataStax will
> continue to contribute to Apache Cassandra, but maybe I can simplify
> things:
>
> This has been going on for months.  DataStax’s level of contribution moving
> forward will be nearly indistinguishable from our level in October and
> September.  If that was no cause for alarm then, I hope it will not be
> cause for alarm now that we have articulated how we are moving forward.
>
> To be explicit: DataStax engineers will continue to contribute code
> reviews, bug fixes, and selected new features to Apache Cassandra.  In a
> qualitative sense then, you could almost say that nothing has changed.
>
> On a personal note, I’d like to thank those in this weekend’s threads who
> have tried to de-escalate tensions rather than inflame them.  Jeff Jirsa’s
> diplomacy stands out to me as particularly mature.
>
> As has been said before, we’re all on the same team here.  Now let’s get
> back to making Apache Cassandra the best open source distributed database
> in the world!
>
> --
> Jonathan Ellis
> co-founder, http://www.datastax.com
> @spyced
>

Re: Moderation

[Ross Gardler]

Because of the way we are structured from an operations point of view or is 
necessary to have s commit bit to be a PMC member. However, that doesn't mean 
one needs to commit code.

A good PMC member looks after the health of the community. They do not 
necessarily write code. We have foundation members who have never committed a 
line of code.

Ross

---
Twitter: @rgardler

_
From: Jonathan Haddad >
Sent: Sunday, November 6, 2016 11:47 PM
Subject: Re: Moderation
To: >, 
>


I took a look at 
https://www.apache.org/dev/pmc.html,
 and it doesn't seem to give any guidelines on who should be on the PMC.  My 
assumption has always been the most active committers become PMC members, but 
it sounds like that's not the case on other projects.  Is the process to be 
added to the PMC supposed to be the same everywhere, or is it up to the 
project?  Can you be on the PMC but not have commit access?

On Sun, Nov 6, 2016 at 5:04 AM Chris Mattmann 
> wrote:
Sorry one typo below:

Where I said:

“The Cassandra MVP comment was also not a diss on you as much as it was me 
saying – ideally – I would hope that
the Apache Cassandra MVP people promote the concept of their community leaders 
becoming “ASF members”,
and that Cassandra MVPs are great – but secondary – to the responsibilities of 
the PMC to move towards ensuring
its community understands the Apache Way.”

I meant to say:

“The Cassandra MVP comment was also not a diss on you as much as it was me 
saying – ideally – I would hope that
the Apache Cassandra *PMC* people promote the concept of their community 
leaders becoming “ASF members”,
and that Cassandra MVPs are great – but secondary – to the responsibilities of 
the PMC to move towards ensuring
its community understands the Apache Way.”

Thanks.

Cheers,
Chris


On 11/6/16, 6:53 AM, "Chris Mattmann" 
> wrote:

For the record, your breakdown of the email trying to decipher what I meant 
is not
correct. It’s not your fault, but email doesn’t convey tone, nor do you 
know what I am
thinking or what I was trying to say. In fact, I was actually saying the 
PMC wasn’t doing its job,
because (as I stated to you months ago), you (and many other community 
members of
Cassandra) *should* have a binding vote. It wasn’t discrediting to you to 
point out that
you don’t have the PMC or committer credentials; it was an example trying 
to point out
that you *should* have them. And that you clearly care about the project as 
I believe you
have developed a book on the subject of Apache Cassandra a while back IIRC 
which in Tika,
Nutch, OODT, and a number of other projects would have earned you the 
ability to have a
direct say in those Apache projects. And a lot of others.

It’s these systematic fracturing of the community under the guise of a 
single vendor who
has stated that they care about Cassandra (note the omission of Apache), 
but by demonstration
has shown they either don’t understand, or don’t care about the Apache part 
of the equation.
That’s what caused me to become frustrated when the following sequence of 
events
happened:

1. After the Board meeting Mark Thomas one of our Directors took point on 
engaging
the Apache Cassandra PMC with some of the concerns brought up over the past 
6
months and the role I was filling there became a back seat for me.
2. I saw over the past few days on a Twitter feed retweeted by an ASF 
member that
Kelly Sommers (whom I have never met in person and do not know previously) 
was asking
questions and stating negative things about the ASF that I believed could 
be much better
understood by bringing them here to the ASF mailing lists for Apache 
Cassandra. I suggested
on Twitter that she bring her concerns to the Apache lists and told her 
which email address
to send it to. Some of the same people that eventually came onto the thread 
were people
who were communicating with her on Twitter – this was disappointing as they 
could have
done the same thing, and suggested Kelly come to the lists, Apache 
Cassandra PMC or not.
3. After 12 hours I checked back with Kelly and the Twitter dialogue had 
continued with several
ASF members and even some Board members getting involved. Again, I asked 
Kelly why talk
there, and why not just talk to the email list which is the canonical home 
for Apache Cassandra?
She told me she sent