Re: [VOTE] Project governance wiki doc (take 2)

[Benedict Elliott Smith]

The purpose of this document is to define only how the project makes decisions, 
and it lists "tenets" of conduct only as a preamble for interpreting the rules 
on decision-making.  The authors' intent was to lean on this to minimise the 
rigidity and prescriptiveness in the formulation of the rules (so that we could 
e.g. use "reasonable" repeatedly, instead of specifying precise expectations), 
in part because this is our first attempt to codify such rules, and in part 
because rigidity can cause unnecessary friction to a project that mostly runs 
smoothly.  

The document provides an avenue for resolving disputes in decision-making when 
these assumptions on behaviour breakdown. However its scope definitely isn't, 
at least in my opinion, addressing misbehaviour by individuals (i.e. one of the 
serious breaches listed in part 5 of the Apache CoC), which it seems to me you 
are addressing here?

Since we reference the ASF CoC, and the ASF provides its own guide for handling 
CoC complaints (including within projects), that applies to that very CoC (and 
which you referenced), it's unclear to me what you're looking for.  Are you 
looking for a more project-specific CoC with different guidelines for 
reporting?  This is something you would be welcome to undertake, and seek 
consensus for.




On 25/06/2020, 02:38, "Dinesh Joshi"  wrote:

> On Jun 24, 2020, at 6:01 PM, Brandon Williams  wrote:
> 
> On Wed, Jun 24, 2020 at 5:43 PM Dinesh Joshi  wrote:
>> 1. How/Who/Where are we planning to deal with Code of Conduct 
violations? I assume this should be private@ but the document does not call it 
out as such. We should call it out explicitly as part of the PMC 
responsibilities. We should also clarify how and where are CoC violations 
against PMC members reported and handled? Should they go to ASF?
> 
> I think if we assume good intent, this will be a non-issue.  People
> may make mistakes, but I try to have faith they will realize them and
> act accordingly when told so without any need to escalate.

We need to spell out in the document how and where the CoC violations are 
reported irrespective of the role of the person in the community. This is a 
critical point to address. ASF spells this out very clearly[1]. We should have 
a similar statement in the Project Governance document, otherwise it feels 
incomplete to me.

Dinesh

[1] 
http://www.apache.org/foundation/policies/conduct.html#reporting-guidelines
-
To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org
For additional commands, e-mail: dev-h...@cassandra.apache.org




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

Re: [VOTE] Project governance wiki doc (take 2)

[Aaron Morton]

+1

-
Aaron Morton
New Zealand
@aaronmorton

CEO
Apache Cassandra Consulting
http://www.thelastpickle.com


On Thu, 25 Jun 2020 at 19:46, Benedict Elliott Smith 
wrote:

> The purpose of this document is to define only how the project makes
> decisions, and it lists "tenets" of conduct only as a preamble for
> interpreting the rules on decision-making.  The authors' intent was to lean
> on this to minimise the rigidity and prescriptiveness in the formulation of
> the rules (so that we could e.g. use "reasonable" repeatedly, instead of
> specifying precise expectations), in part because this is our first attempt
> to codify such rules, and in part because rigidity can cause unnecessary
> friction to a project that mostly runs smoothly.
>
> The document provides an avenue for resolving disputes in decision-making
> when these assumptions on behaviour breakdown. However its scope definitely
> isn't, at least in my opinion, addressing misbehaviour by individuals (i.e.
> one of the serious breaches listed in part 5 of the Apache CoC), which it
> seems to me you are addressing here?
>
> Since we reference the ASF CoC, and the ASF provides its own guide for
> handling CoC complaints (including within projects), that applies to that
> very CoC (and which you referenced), it's unclear to me what you're looking
> for.  Are you looking for a more project-specific CoC with different
> guidelines for reporting?  This is something you would be welcome to
> undertake, and seek consensus for.
>
>
>
>
> On 25/06/2020, 02:38, "Dinesh Joshi"  wrote:
>
> > On Jun 24, 2020, at 6:01 PM, Brandon Williams 
> wrote:
> >
> > On Wed, Jun 24, 2020 at 5:43 PM Dinesh Joshi 
> wrote:
> >> 1. How/Who/Where are we planning to deal with Code of Conduct
> violations? I assume this should be private@ but the document does not
> call it out as such. We should call it out explicitly as part of the PMC
> responsibilities. We should also clarify how and where are CoC violations
> against PMC members reported and handled? Should they go to ASF?
> >
> > I think if we assume good intent, this will be a non-issue.  People
> > may make mistakes, but I try to have faith they will realize them and
> > act accordingly when told so without any need to escalate.
>
> We need to spell out in the document how and where the CoC violations
> are reported irrespective of the role of the person in the community. This
> is a critical point to address. ASF spells this out very clearly[1]. We
> should have a similar statement in the Project Governance document,
> otherwise it feels incomplete to me.
>
> Dinesh
>
> [1]
> http://www.apache.org/foundation/policies/conduct.html#reporting-guidelines
> -
> To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org
> For additional commands, e-mail: dev-h...@cassandra.apache.org
>
>
>
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org
> For additional commands, e-mail: dev-h...@cassandra.apache.org
>
>

Re: [DISCUSS] CASSANDRA-13994

[Sylvain Lebresne]

There appears to be a rather important misunderstanding here.

Compact storage *is removed* from 4.0, it has been since at least
CASSANDRA-10857 which prevented 4.0 to start if any compact tables existed.
This was done 2.5+ years ago and is explicitly indicated in the NEWS file
since
then.

The ticket we're discussing, CASSANDRA-13994, truly is a minor and
unconsequential patch. It does not remove "COMPACT STORAGE", since it is
already removed, it removes some leftover "COMPACT STORAGE *internals*". In
other words, it removes *dead* code, code that cannot ever be run, and
that is just polluting the codebase. None of those changes are invasive. I
don't
know where the idea this patch was invasive came from, but it's just not.

It is not meant to have user-visible consequences and it won't impact any
(past
or future) testing in any meaningful way.

And yes, the patch does cover a non trivial amount of _lines_, but it's all
either the removal of clearly unreachable code, or near automatic changes.

So, tbc, my PMC and reviewer opinion is that this is fine to commit in
either
4.0-alpha or 4.0-beta. It cleans the internal, feels as safe as safe can be
and does not impact testing.

--
Sylvain


On Wed, Jun 24, 2020 at 9:03 PM Dinesh Joshi  wrote:

> I might be missing some context here but I thought we did not intend to
> remove compact storage for 4.0 as it was deemed to be too invasive at this
> point. Did that decision change?
>
> Dinesh
>
> > On Jun 24, 2020, at 10:48 AM, Ekaterina Dimitrova <
> ekaterina.dimitr...@datastax.com> wrote:
> >
> > Dear all,
> > As we talked yesterday during our meeting, I am bringing back to the
> table
> > CASSANDRA-13994 .
> > Description
> >
> > 4.0 comes without thrift (after CASSANDRA-5
> > ) and COMPACT
> > STORAGE (after CASSANDRA-10857
> > ), and since
> Compact
> > Storage flags are now disabled, all of the related functionality is
> useless.
> >
> > There are still some things to consider:
> > 1. One of the system tables (built indexes) was compact. For now, we just
> > added value column to it to make sure it's backwards-compatible, but we
> > might want to make sure it's just a "normal" table and doesn't have
> > redundant columns.
> > 2. Compact Tables were building indexes in KEYS mode. Removing it is
> > trivial, but this would mean that all built indexes will be defunct. We
> > could log a warning for now and ask users to migrate off those for now
> and
> > completely remove it from future releases. It's just a couple of classes
> > though.
> >
> >
> > Thank you Sylvain for the first pass of review.
> >
> > An option, as also Sylvain suggested, is to split the ticket in two
> tickets
> > - clean the Compact storage dead code in this one and open a new ticket
> to
> > handle the indexes.
> >
> > I am pasting here the latest comment, hopefully this makes it easier for
> > the audience:
> >
> > I have made a first pass of review and offered a few remarks above.
> >
> > But I think this ticket is hanging up on us deciding whether removing the
> > KEYS 2ndary index code is ok or not. And this yields, to me, the question
> > of what is the upgrade path to 4.0 for users that still have KEYS index
> > (which, reminder, could only be created with Thrift, but could *used*
> with
> > CQL and thus still be around).
> >
> > Because, while I haven't tested this myself, I suspect we have a hole
> here.
> >
> > Namely, KEYS index were compact tables, and 4.0 does not start if there
> is
> > still compact tables. And while for user tables, user are asked to use
> DROP
> > COMPACT STORAGE before upgrading, this cannot be done on KEYS index
> (there
> > is just no syntax to do it), so unless there is code I'm not aware of
> (and
> > please, someone correct me if I'm wrong), I don't think user can upgrade
> to
> > 4.0 at all if they still have KEYS index. They'd have to drop those index
> > first.
> >
> > So If I'm right here, this technically mean removing the KEYS index code
> in
> > 4.0 is fine, since you cannot upgrade in the first place if you have KEYS
> > index. But the more important question for 4.0 imo is what is the upgrade
> > path for users if they have a KEYS index in 3.X?
> >
> > Currently (without code changes), the only available option I can think
> of
> > is that before upgrade to 4.0, users would have to 1) drop their KEYS
> index
> > and then 2) re-create a "normal" (non-KEYS) equivalent index.
> >
> > Are we comfortable with that being the upgrade path for KEYS index?
> >
> > Personally, I'm not sure I am because this is not a seamless upgrade, as
> > between the 1) and 2) above, there is a window where there is no
> accessible
> > index, so if the user application rely on it, it means a period of
> downtime
> > for the application to perform the upgrade. However, if we want a more
> > seamless u

Re: [VOTE] Project governance wiki doc (take 2)

[Joshua McKenzie]

Vote results:
Binding +1's: 17
Binding +0's: 1
Binding -1's: 0

Non-binding +1's: 9
Non-binding +0's: 1
Non-binding -1's: 0

The vote passes.

pmc quorum for the next six months (or whatever cadence we decide to roll
call on) will be 18, with low watermark of simple majority to pass pmc
votes defined as 10.

Thanks everyone for the great discussion on the topic and all the
collaboration. I'll update the wiki to reflect the state of governance on
the project.

Dinesh - I expect to see a [DISCUSS] thread from you about our CoC shortly.
:)

~Josh

On Thu, Jun 25, 2020 at 4:17 AM Aaron Morton 
wrote:

> +1
>
> -
> Aaron Morton
> New Zealand
> @aaronmorton
>
> CEO
> Apache Cassandra Consulting
> http://www.thelastpickle.com
>
>
> On Thu, 25 Jun 2020 at 19:46, Benedict Elliott Smith 
> wrote:
>
> > The purpose of this document is to define only how the project makes
> > decisions, and it lists "tenets" of conduct only as a preamble for
> > interpreting the rules on decision-making.  The authors' intent was to
> lean
> > on this to minimise the rigidity and prescriptiveness in the formulation
> of
> > the rules (so that we could e.g. use "reasonable" repeatedly, instead of
> > specifying precise expectations), in part because this is our first
> attempt
> > to codify such rules, and in part because rigidity can cause unnecessary
> > friction to a project that mostly runs smoothly.
> >
> > The document provides an avenue for resolving disputes in decision-making
> > when these assumptions on behaviour breakdown. However its scope
> definitely
> > isn't, at least in my opinion, addressing misbehaviour by individuals
> (i.e.
> > one of the serious breaches listed in part 5 of the Apache CoC), which it
> > seems to me you are addressing here?
> >
> > Since we reference the ASF CoC, and the ASF provides its own guide for
> > handling CoC complaints (including within projects), that applies to that
> > very CoC (and which you referenced), it's unclear to me what you're
> looking
> > for.  Are you looking for a more project-specific CoC with different
> > guidelines for reporting?  This is something you would be welcome to
> > undertake, and seek consensus for.
> >
> >
> >
> >
> > On 25/06/2020, 02:38, "Dinesh Joshi"  wrote:
> >
> > > On Jun 24, 2020, at 6:01 PM, Brandon Williams 
> > wrote:
> > >
> > > On Wed, Jun 24, 2020 at 5:43 PM Dinesh Joshi 
> > wrote:
> > >> 1. How/Who/Where are we planning to deal with Code of Conduct
> > violations? I assume this should be private@ but the document does not
> > call it out as such. We should call it out explicitly as part of the PMC
> > responsibilities. We should also clarify how and where are CoC violations
> > against PMC members reported and handled? Should they go to ASF?
> > >
> > > I think if we assume good intent, this will be a non-issue.  People
> > > may make mistakes, but I try to have faith they will realize them
> and
> > > act accordingly when told so without any need to escalate.
> >
> > We need to spell out in the document how and where the CoC violations
> > are reported irrespective of the role of the person in the community.
> This
> > is a critical point to address. ASF spells this out very clearly[1]. We
> > should have a similar statement in the Project Governance document,
> > otherwise it feels incomplete to me.
> >
> > Dinesh
> >
> > [1]
> >
> http://www.apache.org/foundation/policies/conduct.html#reporting-guidelines
> > -
> > To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org
> > For additional commands, e-mail: dev-h...@cassandra.apache.org
> >
> >
> >
> >
> > -
> > To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org
> > For additional commands, e-mail: dev-h...@cassandra.apache.org
> >
> >
>

Re: Community marketing for C*

[Melissa Logan]

Scott, thanks for the welcome, and for your participation! We've got two so
far. :-)

Great to be here. I've been immersing myself in the community's work,
governance etc, but very much still learning so please (anyone) feel free
to guide or redirect.

For content, this sheet has a list of topics as a strawdog:
https://docs.google.com/spreadsheets/d/1bMRNB0KJRN9WsMcfoX8BFwuFDX56QRBKpbQ0N8Zvy5k/edit#gid=0

If there are topics you'd love to write about, put your name in the Author
column. It's not intended to be prescriptive, so do add comments on what
should be added/removed. Once confirmed, we can add a Jira ticket to track.

As a good working process is ironed out, we can add to GitHub so it doesn't
get lost in the mailing list (e.g.
https://github.com/cncf/foundation/blob/master/blog-guidelines.md).

Note: I realize this comes at a time when a release is imminent and
therefore folks may be busy. Know that the offer is ongoing, so reach out
anytime.

Melissa

Melissa

Constantia Marketing - https://constantia.io/
Sexism Field Guide - https://sexismfieldguide.com/


On Wed, Jun 24, 2020 at 9:40 PM Scott Andreas  wrote:

> Melissa, welcome to the project and thank you for your email!
>
> One of Apache Cassandra’s longstanding challenges has been establishing a
> voice for itself as an open source project independent of the many
> corporate entities that support its development. Working together to build
> awareness and enthusiasm leading up to the 4.0 release sounds great.
>
> Happy to help with writing, speaking, and any way I can.
>
> Cheers,
>
> — Scott
>
> > On Jun 24, 2020, at 11:45 AM, Melissa Logan 
> wrote:
> > Hi all,
> >
> > I’m with an open source-focused marketing firm
> > (https://constantia.io/) that works with DataStax -- we’ve been tasked
> > by them to drive awareness of the Apache Cassandra project and
> > community efforts. A neutral marketing “contributor” to C*, if you
> > will.
> >
> > Our team has a long history with open source community marketing.
> > Community-led software is the way to go.
> >
> > As 4.0 release approaches, our goal is to get people interested in C*
> > and testing the beta. To be 100% crystal clear: this is about
> > increasing awareness of the Apache Cassandra project, not vendors or
> > other corporate entities associated with the ecosystem. And just like
> > development, it works best when many participate.
> >
> > To start, we will be contributing C* blogs to opensource.com and
> > others — and doing media outreach (like the recent ZDNet article).
> > Anyone interested in lending a hand as a writer and/or spokesperson?
> >
> > Appreciate your consideration.
> >
> > Melissa Logan
> >
> > -
> > To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org
> > For additional commands, e-mail: dev-h...@cassandra.apache.org
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org
> For additional commands, e-mail: dev-h...@cassandra.apache.org
>
>

Re: [DISCUSS] CASSANDRA-13994

[Joshua McKenzie]

I don't think we really reached a consensus on this one. Some folks
certainly vocalized a preference for not removing in 4.0, but I read it as
debate still ongoing then losing momentum. Specifically thinking of
Sylvain's comment here that kind of dead-ended:
https://issues.apache.org/jira/browse/CASSANDRA-13994?focusedCommentId=17138278&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-17138278

fwiw I'm personally fine w/us deferring this until after 4.0 assuming we
cut a branch for beta so changes like this don't bitrot.

On Wed, Jun 24, 2020 at 3:03 PM Dinesh Joshi  wrote:

> I might be missing some context here but I thought we did not intend to
> remove compact storage for 4.0 as it was deemed to be too invasive at this
> point. Did that decision change?
>
> Dinesh
>
> > On Jun 24, 2020, at 10:48 AM, Ekaterina Dimitrova <
> ekaterina.dimitr...@datastax.com> wrote:
> >
> > Dear all,
> > As we talked yesterday during our meeting, I am bringing back to the
> table
> > CASSANDRA-13994 .
> > Description
> >
> > 4.0 comes without thrift (after CASSANDRA-5
> > ) and COMPACT
> > STORAGE (after CASSANDRA-10857
> > ), and since
> Compact
> > Storage flags are now disabled, all of the related functionality is
> useless.
> >
> > There are still some things to consider:
> > 1. One of the system tables (built indexes) was compact. For now, we just
> > added value column to it to make sure it's backwards-compatible, but we
> > might want to make sure it's just a "normal" table and doesn't have
> > redundant columns.
> > 2. Compact Tables were building indexes in KEYS mode. Removing it is
> > trivial, but this would mean that all built indexes will be defunct. We
> > could log a warning for now and ask users to migrate off those for now
> and
> > completely remove it from future releases. It's just a couple of classes
> > though.
> >
> >
> > Thank you Sylvain for the first pass of review.
> >
> > An option, as also Sylvain suggested, is to split the ticket in two
> tickets
> > - clean the Compact storage dead code in this one and open a new ticket
> to
> > handle the indexes.
> >
> > I am pasting here the latest comment, hopefully this makes it easier for
> > the audience:
> >
> > I have made a first pass of review and offered a few remarks above.
> >
> > But I think this ticket is hanging up on us deciding whether removing the
> > KEYS 2ndary index code is ok or not. And this yields, to me, the question
> > of what is the upgrade path to 4.0 for users that still have KEYS index
> > (which, reminder, could only be created with Thrift, but could *used*
> with
> > CQL and thus still be around).
> >
> > Because, while I haven't tested this myself, I suspect we have a hole
> here.
> >
> > Namely, KEYS index were compact tables, and 4.0 does not start if there
> is
> > still compact tables. And while for user tables, user are asked to use
> DROP
> > COMPACT STORAGE before upgrading, this cannot be done on KEYS index
> (there
> > is just no syntax to do it), so unless there is code I'm not aware of
> (and
> > please, someone correct me if I'm wrong), I don't think user can upgrade
> to
> > 4.0 at all if they still have KEYS index. They'd have to drop those index
> > first.
> >
> > So If I'm right here, this technically mean removing the KEYS index code
> in
> > 4.0 is fine, since you cannot upgrade in the first place if you have KEYS
> > index. But the more important question for 4.0 imo is what is the upgrade
> > path for users if they have a KEYS index in 3.X?
> >
> > Currently (without code changes), the only available option I can think
> of
> > is that before upgrade to 4.0, users would have to 1) drop their KEYS
> index
> > and then 2) re-create a "normal" (non-KEYS) equivalent index.
> >
> > Are we comfortable with that being the upgrade path for KEYS index?
> >
> > Personally, I'm not sure I am because this is not a seamless upgrade, as
> > between the 1) and 2) above, there is a window where there is no
> accessible
> > index, so if the user application rely on it, it means a period of
> downtime
> > for the application to perform the upgrade. However, if we want a more
> > seamless upgrade, we need to figure something out, and that probably
> > involve non trivial amounts of code and testing. And, playing devil's
> > advocate, KEYS index being so old, maybe nobody that plans to upgrade to
> > 4.0 have them anymore, and maybe it's not worth bothering?
> >
> > So I could use others opinions here.
> >
> > Tl;dr, this ticket raises the point that "Oops, I'm not sure we have
> though
> > through the question of upgrade to 4.0 for KEYS indexes". And tbc, it's
> not
> > directly related to this ticket, only indirectly, but it is still
> something
> > we need to figure out. And I'd say, before 4.0-alpha. But I'm happy to
> > cr

Re: [VOTE] Project governance wiki doc (take 2)

[Dinesh Joshi]

> On Jun 25, 2020, at 8:28 AM, Joshua McKenzie  wrote:
> 
> Dinesh - I expect to see a [DISCUSS] thread from you about our CoC shortly.
> :)
> 

I am satisfied with Benedict's clarification. ASF CoC and processes outlined in 
there are fine.

Dinesh



> ~Josh
> 
> On Thu, Jun 25, 2020 at 4:17 AM Aaron Morton 
> wrote:
> 
>> +1
>> 
>> -
>> Aaron Morton
>> New Zealand
>> @aaronmorton
>> 
>> CEO
>> Apache Cassandra Consulting
>> http://www.thelastpickle.com
>> 
>> 
>> On Thu, 25 Jun 2020 at 19:46, Benedict Elliott Smith 
>> wrote:
>> 
>>> The purpose of this document is to define only how the project makes
>>> decisions, and it lists "tenets" of conduct only as a preamble for
>>> interpreting the rules on decision-making.  The authors' intent was to
>> lean
>>> on this to minimise the rigidity and prescriptiveness in the formulation
>> of
>>> the rules (so that we could e.g. use "reasonable" repeatedly, instead of
>>> specifying precise expectations), in part because this is our first
>> attempt
>>> to codify such rules, and in part because rigidity can cause unnecessary
>>> friction to a project that mostly runs smoothly.
>>> 
>>> The document provides an avenue for resolving disputes in decision-making
>>> when these assumptions on behaviour breakdown. However its scope
>> definitely
>>> isn't, at least in my opinion, addressing misbehaviour by individuals
>> (i.e.
>>> one of the serious breaches listed in part 5 of the Apache CoC), which it
>>> seems to me you are addressing here?
>>> 
>>> Since we reference the ASF CoC, and the ASF provides its own guide for
>>> handling CoC complaints (including within projects), that applies to that
>>> very CoC (and which you referenced), it's unclear to me what you're
>> looking
>>> for.  Are you looking for a more project-specific CoC with different
>>> guidelines for reporting?  This is something you would be welcome to
>>> undertake, and seek consensus for.
>>> 
>>> 
>>> 
>>> 
>>> On 25/06/2020, 02:38, "Dinesh Joshi"  wrote:
>>> 
 On Jun 24, 2020, at 6:01 PM, Brandon Williams 
>>> wrote:
 
 On Wed, Jun 24, 2020 at 5:43 PM Dinesh Joshi 
>>> wrote:
> 1. How/Who/Where are we planning to deal with Code of Conduct
>>> violations? I assume this should be private@ but the document does not
>>> call it out as such. We should call it out explicitly as part of the PMC
>>> responsibilities. We should also clarify how and where are CoC violations
>>> against PMC members reported and handled? Should they go to ASF?
 
 I think if we assume good intent, this will be a non-issue.  People
 may make mistakes, but I try to have faith they will realize them
>> and
 act accordingly when told so without any need to escalate.
>>> 
>>>We need to spell out in the document how and where the CoC violations
>>> are reported irrespective of the role of the person in the community.
>> This
>>> is a critical point to address. ASF spells this out very clearly[1]. We
>>> should have a similar statement in the Project Governance document,
>>> otherwise it feels incomplete to me.
>>> 
>>>Dinesh
>>> 
>>>[1]
>>> 
>> http://www.apache.org/foundation/policies/conduct.html#reporting-guidelines
>>>-
>>>To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org
>>>For additional commands, e-mail: dev-h...@cassandra.apache.org
>>> 
>>> 
>>> 
>>> 
>>> -
>>> To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org
>>> For additional commands, e-mail: dev-h...@cassandra.apache.org
>>> 
>>> 
>> 


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

Re: [DISCUSS] Documentation donation

[Joshua McKenzie]

Now that we've got a bit more clarity on our governance model, I was
thinking we could reopen the discussion about doc donations. To preserve
context I figured I'd bring this back up in this thread.

I believe the general points of view I've most recently heard advocated for
by multiple people is as follows:

1) For existing still supported releases (i.e. not trunk), replace existing
docs wholesale w/contribution since there's a lot of holes and ToDo's all
over the existing. Also clean up navigation to them.
2) For trunk / 4.0, change the tool / framework being used (Lorina's
currently PoC'ing that and I think? there's a sufficient consensus there)
and merge in the contribution w/trunk's docs in the new framework
3) We should talk about what we need to do to allow these folks to do their
work at speed without having to constantly interrupt other committers on
the project for merging docs in. A couple folks on the pmc floated the idea
of nominating the full time technical writers to committer so they could
work in tight cycles on the documentation. We could also pair them with
mentors to get through this merge and learn a bit more about project
culture and mores and then go through that process later. No real point of
view I'm advocating for here; attempting to open the discussion

Did I get the above right? Any other positions people are advocating for or
detail to get us aligned?

~Josh



On Fri, May 15, 2020 at 12:59 PM Joshua McKenzie 
wrote:

> Sounds good. Thanks everyone for helping drive to a consensus PoV.
>
> Excited to see this start to roll in.
>
> On Fri, May 15, 2020 at 12:25 PM Jon Haddad  wrote:
>
>> Good summation, yes.  Let's just clear markdown off the table, it's not
>> enough for what we need to do.
>>
>> I spoke briefly with Paul and Lorina, and I think we're all OK with
>> updating the rst docs for now, with a longer term plan to migrate
>> everything to asciidoc.  The priority should be improving what we have for
>> 4.0.  Once that's released we can mess with the doc & website system.
>>
>> There's a nice project that builds on top of asciidoctor called Antora [1]
>> that's specifically built to create documentation websites like ours that
>> might be a good fit for our needs, but we need to evaluate it with a POC
>> to
>> know for sure.
>>
>> [1] https://antora.org
>>
>> On Fri, May 15, 2020 at 7:29 AM Sylvain Lebresne 
>> wrote:
>>
>> > On Thu, May 14, 2020 at 10:08 PM Joshua McKenzie 
>> > wrote:
>> >
>> > > Where did we land on this? Sylvain, Jon, Paul - are you three working
>> > > through differences of opinion in another forum, or has this
>> discussion
>> > > stalled?
>> > >
>> >
>> > I don't feel there is much unresolved differences of opinions (but I
>> could
>> > be
>> > wrong and feel free to correct me), though maybe it's worth summarizing
>> > where
>> > we are.
>> >
>> > The only 3 options that have been mentioned here have been:
>> > 1. moving to markdown
>> > 2. moving to asciidoc
>> > 3. sticking to RST/sphinx
>> >
>> > Afaict:
>> > - there seems to be relatively good consensus on the fact that markdown,
>> > for
>> >   all its qualities, is too limiting for our purpose here.
>> > - there also seem to be good consensus on the fact that asciidoc would
>> work
>> >   fine (Jon is a bit proponent, and unless I misunderstood, all the
>> > features
>> >   that Paul mentioned as important are supported by asciidoc).
>> > - the only difference of POV is on whether asciidoc provides enough
>> > benefits
>> >   over RST to justify migrating. But while I express personal doubt on
>> > that,
>> >   this is just an opinion and, as I already said, I'm not going to be in
>> > the
>> >   way of such migration if it is done (I just won't push for it either).
>> >
>> > Of course, maybe others have opinions, they haven't yet voiced, or other
>> > options they want to propose.
>> >
>> > --
>> > Sylvain
>> >
>> >
>> >
>> > >
>> > > If the latter, how do we unstall it?
>> > >
>> > > On Wed, May 6, 2020 at 3:37 PM Joshua McKenzie 
>> > > wrote:
>> > >
>> > > > Great point about it not being hierarchical Paul; that logic
>> resonates
>> > > > with me.
>> > > >
>> > > > On Wed, May 6, 2020 at 11:50 AM Paul Tepley 
>> > > wrote:
>> > > >
>> > > >> To address your comments, the point I was trying to make is that
>> > > >> correctness, completeness, and usability are really not
>> hierarchical.
>> > > From
>> > > >> a user's point of view not finding information is frustrating,
>> > incorrect
>> > > >> information is frustrating, and incomplete information is
>> frustrating.
>> > > >> Individual user's reaction to these frustrations will vary from
>> taking
>> > > it
>> > > >> in stride to abandoning a product.
>> > > >>
>> > > >> Wrong in documentation isn't analogous to incorrect code. Incorrect
>> > code
>> > > >> breaks something, but there are levels of wrong in docs that can
>> still
>> > > >> provide enough information for users to accomplish tasks or to gain
>> > > >> knowledge. Obvi

Re: Community marketing for C*

[Lorina Poland]

Hi Melissa -

Glad to hear about the marketing efforts! I'm working on an effort to
improve the Apache C* documentation, so if you have questions or
suggestions about that, I'd be happy to hear them. I'm also happy to do any
editing/reading of blogs before they go out.

Cheers,
Lorina




On Wed, Jun 24, 2020 at 11:45 AM Melissa Logan 
wrote:

> Hi all,
>
> I’m with an open source-focused marketing firm
> (
> https://urldefense.proofpoint.com/v2/url?u=https-3A__constantia.io_&d=DwIFaQ&c=adz96Xi0w1RHqtPMowiL2g&r=bL2UpIjL4Mm1mCbqWThJUiPD-CmTXMALsIT2Ta-KfGk&m=idt7YJPlj_-MlXoX_MmrNOwk02d_1YwoXwUrVeeXTVc&s=1dX-CHHtPCG4TsXGFb6bc31vxc6UKnduXjPRKgyNMO0&e=
> ) that works with DataStax -- we’ve been tasked
> by them to drive awareness of the Apache Cassandra project and
> community efforts. A neutral marketing “contributor” to C*, if you
> will.
>
> Our team has a long history with open source community marketing.
> Community-led software is the way to go.
>
> As 4.0 release approaches, our goal is to get people interested in C*
> and testing the beta. To be 100% crystal clear: this is about
> increasing awareness of the Apache Cassandra project, not vendors or
> other corporate entities associated with the ecosystem. And just like
> development, it works best when many participate.
>
> To start, we will be contributing C* blogs to opensource.com and
> others — and doing media outreach (like the recent ZDNet article).
> Anyone interested in lending a hand as a writer and/or spokesperson?
>
> Appreciate your consideration.
>
> Melissa Logan
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org
> For additional commands, e-mail: dev-h...@cassandra.apache.org
>
>

Re: DataStax Driver Donation to Apache Cassandra Project

[Joshua McKenzie]

My understanding is that there's comparable traffic on python, java, and
node drivers in terms of usage out in the Cassandra ecosystem. Shall we get
started w/the java process and incubation on the donation (CLA's, vetting
contributions, etc) with plans to follow up with python and then node?

What are next steps here? Anyone knowledgeable on thread?

On Tue, Apr 28, 2020 at 4:38 PM Nate McCall  wrote:

> >
> >
> > Lastly, and to Stephen's previous email, it might be more manageable to
> > accept one drivers first and figure all the details/issues/questions that
> > are bound to arise before accepting more. It's worth discussing at least.
> >
>
> This approach makes complete sense to me: let's sort out how to accept the
> Java Driver (I guess? most widely used and reference impl) and then we can
> iterate from there.
>

Re: [VOTE] Project governance wiki doc (take 2)

[Joshua McKenzie]

Probably worth linking to the apache CoC in our wiki if we haven't already.

On Thu, Jun 25, 2020 at 2:31 PM Dinesh Joshi  wrote:

> > On Jun 25, 2020, at 8:28 AM, Joshua McKenzie 
> wrote:
> >
> > Dinesh - I expect to see a [DISCUSS] thread from you about our CoC
> shortly.
> > :)
> >
>
> I am satisfied with Benedict's clarification. ASF CoC and processes
> outlined in there are fine.
>
> Dinesh
>
>
>
> > ~Josh
> >
> > On Thu, Jun 25, 2020 at 4:17 AM Aaron Morton 
> > wrote:
> >
> >> +1
> >>
> >> -
> >> Aaron Morton
> >> New Zealand
> >> @aaronmorton
> >>
> >> CEO
> >> Apache Cassandra Consulting
> >> http://www.thelastpickle.com
> >>
> >>
> >> On Thu, 25 Jun 2020 at 19:46, Benedict Elliott Smith <
> bened...@apache.org>
> >> wrote:
> >>
> >>> The purpose of this document is to define only how the project makes
> >>> decisions, and it lists "tenets" of conduct only as a preamble for
> >>> interpreting the rules on decision-making.  The authors' intent was to
> >> lean
> >>> on this to minimise the rigidity and prescriptiveness in the
> formulation
> >> of
> >>> the rules (so that we could e.g. use "reasonable" repeatedly, instead
> of
> >>> specifying precise expectations), in part because this is our first
> >> attempt
> >>> to codify such rules, and in part because rigidity can cause
> unnecessary
> >>> friction to a project that mostly runs smoothly.
> >>>
> >>> The document provides an avenue for resolving disputes in
> decision-making
> >>> when these assumptions on behaviour breakdown. However its scope
> >> definitely
> >>> isn't, at least in my opinion, addressing misbehaviour by individuals
> >> (i.e.
> >>> one of the serious breaches listed in part 5 of the Apache CoC), which
> it
> >>> seems to me you are addressing here?
> >>>
> >>> Since we reference the ASF CoC, and the ASF provides its own guide for
> >>> handling CoC complaints (including within projects), that applies to
> that
> >>> very CoC (and which you referenced), it's unclear to me what you're
> >> looking
> >>> for.  Are you looking for a more project-specific CoC with different
> >>> guidelines for reporting?  This is something you would be welcome to
> >>> undertake, and seek consensus for.
> >>>
> >>>
> >>>
> >>>
> >>> On 25/06/2020, 02:38, "Dinesh Joshi"  wrote:
> >>>
>  On Jun 24, 2020, at 6:01 PM, Brandon Williams 
> >>> wrote:
> 
>  On Wed, Jun 24, 2020 at 5:43 PM Dinesh Joshi 
> >>> wrote:
> > 1. How/Who/Where are we planning to deal with Code of Conduct
> >>> violations? I assume this should be private@ but the document does not
> >>> call it out as such. We should call it out explicitly as part of the
> PMC
> >>> responsibilities. We should also clarify how and where are CoC
> violations
> >>> against PMC members reported and handled? Should they go to ASF?
> 
>  I think if we assume good intent, this will be a non-issue.  People
>  may make mistakes, but I try to have faith they will realize them
> >> and
>  act accordingly when told so without any need to escalate.
> >>>
> >>>We need to spell out in the document how and where the CoC
> violations
> >>> are reported irrespective of the role of the person in the community.
> >> This
> >>> is a critical point to address. ASF spells this out very clearly[1]. We
> >>> should have a similar statement in the Project Governance document,
> >>> otherwise it feels incomplete to me.
> >>>
> >>>Dinesh
> >>>
> >>>[1]
> >>>
> >>
> http://www.apache.org/foundation/policies/conduct.html#reporting-guidelines
> >>>
> -
> >>>To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org
> >>>For additional commands, e-mail: dev-h...@cassandra.apache.org
> >>>
> >>>
> >>>
> >>>
> >>> -
> >>> To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org
> >>> For additional commands, e-mail: dev-h...@cassandra.apache.org
> >>>
> >>>
> >>
>
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org
> For additional commands, e-mail: dev-h...@cassandra.apache.org
>
>

Re: Community marketing for C*

[Joshua McKenzie]

Welcome Melissa! Super excited to be working with you on things.

For context for everyone, I've been working with Melissa and offering what
context and advice I have about engaging with an Apache project as an
individual contributor. This is a new motion for our project and I'm really
excited to see the impact this can have on our community and awareness of
the work we're doing.

I'm at your disposal. :)

~Josh

On Thu, Jun 25, 2020 at 2:35 PM Lorina Poland  wrote:

> Hi Melissa -
>
> Glad to hear about the marketing efforts! I'm working on an effort to
> improve the Apache C* documentation, so if you have questions or
> suggestions about that, I'd be happy to hear them. I'm also happy to do any
> editing/reading of blogs before they go out.
>
> Cheers,
> Lorina
>
>
>
>
> On Wed, Jun 24, 2020 at 11:45 AM Melissa Logan 
> wrote:
>
> > Hi all,
> >
> > I’m with an open source-focused marketing firm
> > (
> >
> https://urldefense.proofpoint.com/v2/url?u=https-3A__constantia.io_&d=DwIFaQ&c=adz96Xi0w1RHqtPMowiL2g&r=bL2UpIjL4Mm1mCbqWThJUiPD-CmTXMALsIT2Ta-KfGk&m=idt7YJPlj_-MlXoX_MmrNOwk02d_1YwoXwUrVeeXTVc&s=1dX-CHHtPCG4TsXGFb6bc31vxc6UKnduXjPRKgyNMO0&e=
> > ) that works with DataStax -- we’ve been tasked
> > by them to drive awareness of the Apache Cassandra project and
> > community efforts. A neutral marketing “contributor” to C*, if you
> > will.
> >
> > Our team has a long history with open source community marketing.
> > Community-led software is the way to go.
> >
> > As 4.0 release approaches, our goal is to get people interested in C*
> > and testing the beta. To be 100% crystal clear: this is about
> > increasing awareness of the Apache Cassandra project, not vendors or
> > other corporate entities associated with the ecosystem. And just like
> > development, it works best when many participate.
> >
> > To start, we will be contributing C* blogs to opensource.com and
> > others — and doing media outreach (like the recent ZDNet article).
> > Anyone interested in lending a hand as a writer and/or spokesperson?
> >
> > Appreciate your consideration.
> >
> > Melissa Logan
> >
> > -
> > To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org
> > For additional commands, e-mail: dev-h...@cassandra.apache.org
> >
> >
>

Re: DataStax Driver Donation to Apache Cassandra Project

[Dinesh Joshi]

I don't see any reason not to bring in other drivers to the project. We can 
start with the Java driver. I think Nate might be aware of the specifics of the 
process.

Dinesh

> On Jun 25, 2020, at 11:36 AM, Joshua McKenzie  wrote:
> 
> My understanding is that there's comparable traffic on python, java, and
> node drivers in terms of usage out in the Cassandra ecosystem. Shall we get
> started w/the java process and incubation on the donation (CLA's, vetting
> contributions, etc) with plans to follow up with python and then node?
> 
> What are next steps here? Anyone knowledgeable on thread?
> 
> On Tue, Apr 28, 2020 at 4:38 PM Nate McCall  wrote:
> 
>>> 
>>> 
>>> Lastly, and to Stephen's previous email, it might be more manageable to
>>> accept one drivers first and figure all the details/issues/questions that
>>> are bound to arise before accepting more. It's worth discussing at least.
>>> 
>> 
>> This approach makes complete sense to me: let's sort out how to accept the
>> Java Driver (I guess? most widely used and reference impl) and then we can
>> iterate from there.
>> 


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

Re: DataStax Driver Donation to Apache Cassandra Project

[Mick Semb Wever]

> > What are next steps here? Anyone knowledgeable on thread?


Can we take it to a CEP now?

Even if the decision is to take one driver as a guinea pig and learn as we
go, there's some questions that need to be thrashed out in advance
(somewhere better than this thread), e.g. the incubator ip clearance steps,
and other questions to tackle along the way: versions and supported
branches, committers and maintainers, artifact and package names, CI, jira,
ML, coordination to server, etc; so a CEP can be the document to land it
all.

Re: DataStax Driver Donation to Apache Cassandra Project

[Joshua McKenzie]

CEP seems reasonable enough. I'll talk to Alex and Olivier.

On Thu, Jun 25, 2020 at 4:51 PM Mick Semb Wever  wrote:

> > > What are next steps here? Anyone knowledgeable on thread?
>
>
> Can we take it to a CEP now?
>
> Even if the decision is to take one driver as a guinea pig and learn as we
> go, there's some questions that need to be thrashed out in advance
> (somewhere better than this thread), e.g. the incubator ip clearance steps,
> and other questions to tackle along the way: versions and supported
> branches, committers and maintainers, artifact and package names, CI, jira,
> ML, coordination to server, etc; so a CEP can be the document to land it
> all.
>

Re: Community marketing for C*

[Melissa Logan]

Lorina, lovely - thanks so much. Editing/proofing would be appreciated, and
perhaps we can add a call to action to improve docs.

And thank you, Josh! Appreciate the help. :-)

If folks have other ideas for awareness, reach out anytime.


On Thu, Jun 25, 2020 at 11:46 AM Joshua McKenzie 
wrote:

> Welcome Melissa! Super excited to be working with you on things.
>
> For context for everyone, I've been working with Melissa and offering what
> context and advice I have about engaging with an Apache project as an
> individual contributor. This is a new motion for our project and I'm really
> excited to see the impact this can have on our community and awareness of
> the work we're doing.
>
> I'm at your disposal. :)
>
> ~Josh
>
> On Thu, Jun 25, 2020 at 2:35 PM Lorina Poland  wrote:
>
> > Hi Melissa -
> >
> > Glad to hear about the marketing efforts! I'm working on an effort to
> > improve the Apache C* documentation, so if you have questions or
> > suggestions about that, I'd be happy to hear them. I'm also happy to do
> any
> > editing/reading of blogs before they go out.
> >
> > Cheers,
> > Lorina
> >
> >
> >
> >
> > On Wed, Jun 24, 2020 at 11:45 AM Melissa Logan <
> loganloganlo...@gmail.com>
> > wrote:
> >
> > > Hi all,
> > >
> > > I’m with an open source-focused marketing firm
> > > (
> > >
> >
> https://urldefense.proofpoint.com/v2/url?u=https-3A__constantia.io_&d=DwIFaQ&c=adz96Xi0w1RHqtPMowiL2g&r=bL2UpIjL4Mm1mCbqWThJUiPD-CmTXMALsIT2Ta-KfGk&m=idt7YJPlj_-MlXoX_MmrNOwk02d_1YwoXwUrVeeXTVc&s=1dX-CHHtPCG4TsXGFb6bc31vxc6UKnduXjPRKgyNMO0&e=
> > > ) that works with DataStax -- we’ve been tasked
> > > by them to drive awareness of the Apache Cassandra project and
> > > community efforts. A neutral marketing “contributor” to C*, if you
> > > will.
> > >
> > > Our team has a long history with open source community marketing.
> > > Community-led software is the way to go.
> > >
> > > As 4.0 release approaches, our goal is to get people interested in C*
> > > and testing the beta. To be 100% crystal clear: this is about
> > > increasing awareness of the Apache Cassandra project, not vendors or
> > > other corporate entities associated with the ecosystem. And just like
> > > development, it works best when many participate.
> > >
> > > To start, we will be contributing C* blogs to opensource.com and
> > > others — and doing media outreach (like the recent ZDNet article).
> > > Anyone interested in lending a hand as a writer and/or spokesperson?
> > >
> > > Appreciate your consideration.
> > >
> > > Melissa Logan
> > >
> > > -
> > > To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org
> > > For additional commands, e-mail: dev-h...@cassandra.apache.org
> > >
> > >
> >
>

Re: [DISCUSS] CASSANDRA-13994

[Ekaterina Dimitrova]

Considering the latest comments  on the ticket from today, I don’t see this
ticket anymore as a beta blocker.
 Also, what is the plan for cutting beta branch? I am still learning the
Apache/C* way so excuse me if I missed something. Looking at the Lifecycle
document, I see a point only about GA major version branch.
My understanding is that we are already in freeze for big changes. When
would be the right time for creating a beta branch? Something more than
closing the last beta blockers tickets?
Thanks
Ekaterina

On Thu, 25 Jun 2020 at 14:25, Joshua McKenzie  wrote:

> I don't think we really reached a consensus on this one. Some folks
> certainly vocalized a preference for not removing in 4.0, but I read it as
> debate still ongoing then losing momentum. Specifically thinking of
> Sylvain's comment here that kind of dead-ended:
>
> https://issues.apache.org/jira/browse/CASSANDRA-13994?focusedCommentId=17138278&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-17138278
>
> fwiw I'm personally fine w/us deferring this until after 4.0 assuming we
> cut a branch for beta so changes like this don't bitrot.
>
> On Wed, Jun 24, 2020 at 3:03 PM Dinesh Joshi  wrote:
>
> > I might be missing some context here but I thought we did not intend to
> > remove compact storage for 4.0 as it was deemed to be too invasive at
> this
> > point. Did that decision change?
> >
> > Dinesh
> >
> > > On Jun 24, 2020, at 10:48 AM, Ekaterina Dimitrova <
> > ekaterina.dimitr...@datastax.com> wrote:
> > >
> > > Dear all,
> > > As we talked yesterday during our meeting, I am bringing back to the
> > table
> > > CASSANDRA-13994  >.
> > > Description
> > >
> > > 4.0 comes without thrift (after CASSANDRA-5
> > > ) and COMPACT
> > > STORAGE (after CASSANDRA-10857
> > > ), and since
> > Compact
> > > Storage flags are now disabled, all of the related functionality is
> > useless.
> > >
> > > There are still some things to consider:
> > > 1. One of the system tables (built indexes) was compact. For now, we
> just
> > > added value column to it to make sure it's backwards-compatible, but we
> > > might want to make sure it's just a "normal" table and doesn't have
> > > redundant columns.
> > > 2. Compact Tables were building indexes in KEYS mode. Removing it is
> > > trivial, but this would mean that all built indexes will be defunct. We
> > > could log a warning for now and ask users to migrate off those for now
> > and
> > > completely remove it from future releases. It's just a couple of
> classes
> > > though.
> > >
> > >
> > > Thank you Sylvain for the first pass of review.
> > >
> > > An option, as also Sylvain suggested, is to split the ticket in two
> > tickets
> > > - clean the Compact storage dead code in this one and open a new ticket
> > to
> > > handle the indexes.
> > >
> > > I am pasting here the latest comment, hopefully this makes it easier
> for
> > > the audience:
> > >
> > > I have made a first pass of review and offered a few remarks above.
> > >
> > > But I think this ticket is hanging up on us deciding whether removing
> the
> > > KEYS 2ndary index code is ok or not. And this yields, to me, the
> question
> > > of what is the upgrade path to 4.0 for users that still have KEYS index
> > > (which, reminder, could only be created with Thrift, but could *used*
> > with
> > > CQL and thus still be around).
> > >
> > > Because, while I haven't tested this myself, I suspect we have a hole
> > here.
> > >
> > > Namely, KEYS index were compact tables, and 4.0 does not start if there
> > is
> > > still compact tables. And while for user tables, user are asked to use
> > DROP
> > > COMPACT STORAGE before upgrading, this cannot be done on KEYS index
> > (there
> > > is just no syntax to do it), so unless there is code I'm not aware of
> > (and
> > > please, someone correct me if I'm wrong), I don't think user can
> upgrade
> > to
> > > 4.0 at all if they still have KEYS index. They'd have to drop those
> index
> > > first.
> > >
> > > So If I'm right here, this technically mean removing the KEYS index
> code
> > in
> > > 4.0 is fine, since you cannot upgrade in the first place if you have
> KEYS
> > > index. But the more important question for 4.0 imo is what is the
> upgrade
> > > path for users if they have a KEYS index in 3.X?
> > >
> > > Currently (without code changes), the only available option I can think
> > of
> > > is that before upgrade to 4.0, users would have to 1) drop their KEYS
> > index
> > > and then 2) re-create a "normal" (non-KEYS) equivalent index.
> > >
> > > Are we comfortable with that being the upgrade path for KEYS index?
> > >
> > > Personally, I'm not sure I am because this is not a seamless upgrade,
> as
> > > between the 1) and 2) above, there is a window where there is no
> > accessible
> > > index, so if