Re: Welcome Maxim Muzafarov as Cassandra Committer

[Lorina Poland]

Congratulations Maxim!

On 2024/01/08 18:19:04 Josh McKenzie wrote:
> The Apache Cassandra PMC is pleased to announce that Maxim Muzafarov has 
> accepted
> the invitation to become a committer.
> 
> Thanks for all the hard work and collaboration on the project thus far, and 
> we're all looking forward to working more with you in the future. 
> Congratulations and welcome!
> 
> The Apache Cassandra PMC members
> 
> 

Re: Harry in-tree (Forked from "Long tests, Burn tests, Simulator tests, Fuzz tests - can we clarify the diffs?")

[Lorina Poland]

Is there any user-facing documentation (for developers) that should be added? I 
note that you say there is "extensive documentation"; I presume that you are 
referring to the README.md in the repo?

If there is a desire to add documentation to the website, as opposed to the MD 
files in the repo, please reach out to me.

Thanks,
Lorina

On 2023/12/21 21:22:54 Alex Petrov wrote:
> Hey folks,
> 
> I am mostly done with a patch that brings Harry in-tree [1]. I will trigger 
> one more CI run overnight, and my intention was to merge it some time soon, 
> but I wanted to give a fair warning here, since this is a relatively large 
> patch. 
> 
> Good news for everyone that it: 
>   a) touches no production code whatsoever. Only test (in-jvm dtest namely) 
> code that was using Harry already.
>   b) the only tests that are changed are ones that used a duplicate version 
> of placement simulator we had both for testing TCM, and in Harry
>   c) in addition, I have converted 3 existing TCM tests to a new API to have 
> some base for examples/usage.
> 
> Since we were effectively relying on this code for a while now, and the 
> intention now is to converge to: 
>   a) fewer different generators, and have a shareable version of generators 
> for everyone to use accross the base
>   b) a testing tool that can be useful for both trivial cases, and complex 
> scenarios 
> myself and many other Cassandra contributors have expressed an opinion that 
> bringing Harry in-tree will be highly benefitial.
> 
> I strongly believe that bringing Harry in-tree will help to lower the barrier 
> for fuzz test and simplify co-development of Cassandra and Harry. Previously, 
> it has been rather difficult to debug edge cases because I had to either 
> re-compile an in-jvm dtest jar and bring it to Harry, or re-compile a Harry 
> jar and bring it to Cassandra, which is both tedious and time consuming. 
> Moreover, I believe we have missed at very least one RT regression [2] 
> because Harry was not in-tree, as its tests would've caught the issue even 
> with the model that existed.
> 
> For other recently found issues, I think having Harry in-tree would have 
> substantially lowered a turnaround time, and allowed me to share repros with 
> developers of corresponding features much quicker.
> 
> I do expect a slight learning curve for Harry, but my intention is to build a 
> web of simple tests (worked on some of them yesterday after conversation with 
> David already), which can follow the in-jvm-dtest pattern of 
> find-similar-test / copy / modify. There's already copious documentation, so 
> I do not believe not having docs for Harry was ever an issue, since there 
> have been plenty. 
> 
> You all are aware of my dedication to testing and quality of Apache 
> Cassandra, and I hope you also see the benefits of having a model checker 
> in-tree.
> 
> Thank you and happy upcoming holidays,
> --Alex
> 
> [1] https://issues.apache.org/jira/browse/CASSANDRA-19210
> [2] https://issues.apache.org/jira/browse/CASSANDRA-18932
> 

Re: Welcome Mike Adamson as Cassandra committer

[Lorina Poland]

Congratulations, Mike!

Re: Status Update on CEP-7 Storage Attached Indexes (SAI)

[Lorina Poland]

I have to say how excited I am that I get to emphasize SAI as an indexing
method for Apache C*, rather than the much less capable 2i! I have been
waiting for this day for years! Thanks Caleb and all who worked to make
this day a reality!

Lorina

On Wed, Jul 26, 2023 at 10:08 PM Berenguer Blasi 
wrote:

> Nice one!
> On 26/7/23 21:11, Ekaterina Dimitrova wrote:
>
> Thanks Caleb!
> Great  job everyone! 
>
> On Wed, 26 Jul 2023 at 15:07, J. D. Jordan 
> wrote:
>
>> Thanks for all the work here!
>>
>> On Jul 26, 2023, at 1:57 PM, Caleb Rackliffe 
>> wrote:
>>
>> 
>>
>> Alright, the cep-7-sai branch is now merged to trunk!
>>
>> Now we move to addressing the most urgent items from "Phase 2" (
>> CASSANDRA-18473 )
>> before (and in the case of some testing after) the 5.0 freeze...
>>
>> On Wed, Jul 26, 2023 at 6:07 AM Jeremy Hanna 
>> wrote:
>>
>>> Thanks Caleb and Mike and Zhao and Andres and Piotr and everyone else
>>> involved with the SAI implementation!
>>>
>>> On Jul 25, 2023, at 3:01 PM, Caleb Rackliffe 
>>> wrote:
>>>
>>> 
>>> Just a quick update...
>>>
>>> With CASSANDRA-18670
>>>  complete, and
>>> all remaining items in the category of performance optimizations and
>>> further testing, the process of merging to trunk will likely start today,
>>> beginning with a final rebase on the current trunk and J11 and J17 test
>>> runs.
>>>
>>> On Tue, Jul 18, 2023 at 3:47 PM Caleb Rackliffe <
>>> calebrackli...@gmail.com> wrote:
>>>
 Hello there!

 After much toil, the first phase of CEP-7 is nearing completion (see
 CASSANDRA-16052 ).
 There are presently two issues to resolve before we'd like to merge the
 cep-7-sai feature branch and all its goodness to trunk:

 CASSANDRA-18670 
 - Importer should build SSTable indexes successfully before making new
 SSTables readable (in review)

 CASSANDRA-18673 
 - Reduce size of per-SSTable index components (in progress)

 (We've been getting clean CircleCI runs for a while now, and have been
 using the multiplexer to sniff out as much flakiness as possible up front.)

 Once merged to trunk, the next steps are:

 1.) Finish a Harry model that we can use to further fuzz test SAI
 before 5.0 releases (see CASSANDRA-18275
 ). We've done a
 fair amount of fuzz/randomized testing at the component level, but I'd
 still consider Harry (at least around single-partition query use-cases) a
 critical item for us to have confidence before release.

 2.) Start pursuing Phase 2 items as time and our needs allow. (see
 CASSANDRA-18473 
 )

 A reminder, SAI is a secondary index, and therefore is by definition an
 opt-in feature, and has no explicit "feature flag". However, its
 availability to users is still subject to the secondary_indexes_enabled
 guardrail, which currently defaults to allowing creation.

 Any thoughts, questions, or comments on the pre-merge plan here?

>>>

Re: [DISCUSS] CEP-29 CQL NOT Operator

[Lorina Poland]

Wow, you know, J.D., I've never actually heard ALLOW FILTERING described as
you did. Generally, the discussion is always in terms of
multiple partitions, probably because that is the situation in which the
memory is exceeded. Thanks for that definition.

Regardless of how this discussion goes, I'll make a ticket to change that
doc.

Lorina

On Thu, Apr 13, 2023 at 4:17 AM J. D. Jordan 
wrote:

> The documentation is wrong. ALLOW FILTERING has always meant that “rows
> will need to be materialized in memory and accepted or rejected by a column
> filter” aka the full primary key was not specified and some other column
> was specified.  It has never been about multiple partitions.
> Basically “will the server need to read from disk more data (possibly a
> lot more) than will be returned to the client”.
> Should we change how that works? Maybe. But let move such discussions to a
> new thread and keep this one about the CEP proposal.
>
> On Apr 13, 2023, at 6:00 AM, Andrés de la Peña 
> wrote:
>
> 
> Indeed requiring AF for "select * from ks.tb where p1 = 1 and c1 = 2 and
> col2 = 1", where p1 and c1 are all the columns in the primary key, sounds
> like a bug.
>
> I think the criterion in the code is that we require AF if there is any
> column restriction that cannot be processed by the primary key or a
> secondary index. The error message indeed seems to reject any kind of
> filtering, independently of primary key filters. We can see this even
> without defined clustering keys:
>
> CREATE TABLE t (k int PRIMARY KEY, v int);
> SELECT * FROM  t WHERE  k = 1 AND v = 1; # requires AF
>
> That clashes with documentation, where it's said that AF is required for
> filters that require scanning all partitions. If we were to adapt the code
> to the behaviour described in documentation we shouldn't require AF if
> there are restrictions specifying a partition key. Or possibly a group of
> partition keys, if a IN restriction is used. So both within row and within
> partition filtering wouldn't require AF.
>
> Regarding adding a new ALLOW FILTERING WITHIN PARTITION, I think we could
> just add a guardrail to directly disallow those queries, without needing to
> add the WITHIN PARTITION clause to the CQL grammar.
>
> On Thu, 13 Apr 2023 at 11:11, Henrik Ingo 
> wrote:
>
>>
>>
>> On Thu, Apr 13, 2023 at 10:20 AM Miklosovic, Stefan <
>> stefan.mikloso...@netapp.com> wrote:
>>
>>> Somebody correct me if I am wrong but "partition key" itself is not
>>> enough (primary keys = partition keys + clustering columns). It will
>>> require ALLOW FILTERING when clustering columns are not specified either.
>>>
>>> create table ks.tb (p1 int, c1 int, col1 int, col2 int, primary key (p1,
>>> c1));
>>> select * from ks.tb where p1 = 1 and col1 = 2; // this will require
>>> allow filtering
>>>
>>> The documentation seems to omit this fact.
>>>
>>
>> It does seem so.
>>
>> That said, personally I was assuming, and would still argue it's the
>> optimal choice, that the documentation was right and reality is wrong.
>>
>> If there is a partition key, then the query can avoid scanning the entire
>> table, across all nodes, potentially petabytes.
>>
>> If a query specifies a partition key but not the full clustering key, of
>> course there will be some scanning needed, but this is marginal compared to
>> the need to scan the entire table. Even in the worst case, a partition with
>> 2 billion cells, we are talking about seconds to filter the result from the
>> single partition.
>>
>> > Aha I get what you all mean:
>>
>> No, I actually think both are unnecessary. But yeah, certainly this
>> latter case is a bug?
>>
>> henrik
>>
>> --
>>
>> Henrik Ingo
>>
>> c. +358 40 569 7354
>>
>> w. www.datastax.com
>>
>>
>> 
>> 
>> 
>> 
>>
>>

Re: Google Season of Documentation proposal

[Lorina Poland]

Good news! The Open Collective application was accepted! Step one is done.

Lorina

On 2023/02/13 22:23:35 Lorina Poland wrote:
> Hi all -
> 
> I have submitted an application to the Open Collective, so that we would
> have a funding mechanism to pay 1-2 technical writers if we are successful
> with our GSoD proposal.
> 
> I have the GSoD proposal ready, and am only waiting for the first date for
> submission, Feb 15, 2023. Here is a link to the proposal:
> https://docs.google.com/document/d/1611cuNDcC0S_xwfHbRca1AGqgqDr606a2DCznKabAMg/edit?usp=sharing
> 
> If you have comments or questions, please let me know. I'll be waiting on:
> 
>- Open Collective to accept the application
>- Google to open for submissions for GSoD
> 
> If successful, we'll need a blog post for cassandra.apache.com to announce
> to technical writers that they should apply.
> 
> Thanks,
> Lorina
> 

Google Season of Documentation proposal

[Lorina Poland]

Hi all -

I have submitted an application to the Open Collective, so that we would
have a funding mechanism to pay 1-2 technical writers if we are successful
with our GSoD proposal.

I have the GSoD proposal ready, and am only waiting for the first date for
submission, Feb 15, 2023. Here is a link to the proposal:
https://docs.google.com/document/d/1611cuNDcC0S_xwfHbRca1AGqgqDr606a2DCznKabAMg/edit?usp=sharing

If you have comments or questions, please let me know. I'll be waiting on:

   - Open Collective to accept the application
   - Google to open for submissions for GSoD

If successful, we'll need a blog post for cassandra.apache.com to announce
to technical writers that they should apply.

Thanks,
Lorina

Re: Welcome Patrick McFadin as Cassandra Committer

[Lorina Poland]

Absolutely, a big woot for you, Patrick! Congratulations!

Lorina

On Thu, Feb 2, 2023 at 12:09 PM Sharan F  wrote:

> Congratulations Patrick!
>
> Thanks
> Sharan
>
> On Thu, 2 Feb 2023, 18:58 Benjamin Lerer,  wrote:
>
>> The PMC members are pleased to announce that Patrick McFadin has accepted
>> the invitation to become committer today.
>>
>> Thanks a lot, Patrick, for everything you have done for this project and
>> its community through the years.
>>
>> Congratulations and welcome!
>>
>> The Apache Cassandra PMC members
>>
>

Cassandra 5.0 Documentation Plan

[Lorina Poland]

Hey all -

I presented a potential Docs Information Architecture recently, and
promised a Doc Plan for the upcoming C* 5.0 release. Please give me
feedback, especially if you feel that the priorities for upcoming features
should be different than what I propose. Also understand that the priority
is just to make absolutely certain that the most impactful features are
covered at GA. Eventually, and hopefully also before GA, all the items
listed in the Doc Plan will be completed. Just depends on the effort
devoted by the community, myself included.

Here's the link:
https://docs.google.com/document/d/1FAACcAxtV9qLJS05RLt85S_6Gb4C4t4g9DhmfLufjOk/edit?usp=sharing

Happy reading!

Lorina

Re: Apache Cassandra 5.0 documentation

[Lorina Poland]

I've not had any comment on this topic. Can I assume that no one has objections?

Lorina

On 2023/01/25 19:02:41 Lorina Poland wrote:
> Greetings!
> 
> I'm gearing up to help get the Cassandra 5.0 docs in good order before the
> GA release occurs later this year. Recently, I've been thinking about a
> more standardized organization to docs, to make it simpler for users to
> find what they are looking for, separate from searching. [That's the kind
> of thing docs nerds think about.] To that end, I've created a unified
> information architecture (IA) that can apply to any kind of documentation,
> including the Apache C* docs.
> 
> Up front, I'll say, not every section of this organization applies to
> Apache C* docs, but reorganizing the docs to follow this pattern as much as
> possible will help users find what they need.
> 
> I'd like your input into this IA that I've outlined. Please give me
> feedback about your opinions! If I can tackle this issue before launching
> into adding CEP features, working down the existing JIRA tickets for
> documentation, and backfilling missing items, it would be immensely
> helpful. No opinion will go unaddressed, so please take a few minutes to
> take a look.
> 
> I'm linking a google doc, to make it easy for anyone to make comments:
> https://docs.google.com/document/d/1A96K73vj9MbJoD7wJNgIKWrOkLq-ZL2cNZAEXSWrciY/edit?usp=sharing
> 
> I'm also drafting an Apache C* 5.0 Doc Plan for the work, to make it simple
> for anyone to know what is being done, and will share that next. In
> addition, I've started consolidating the current Documentation tickets that
> are open under the JIRA project, component "Documentation".
> 
> Thanks,
> Lorina Poland
> 

Apache Cassandra 5.0 documentation

[Lorina Poland]

Greetings!

I'm gearing up to help get the Cassandra 5.0 docs in good order before the
GA release occurs later this year. Recently, I've been thinking about a
more standardized organization to docs, to make it simpler for users to
find what they are looking for, separate from searching. [That's the kind
of thing docs nerds think about.] To that end, I've created a unified
information architecture (IA) that can apply to any kind of documentation,
including the Apache C* docs.

Up front, I'll say, not every section of this organization applies to
Apache C* docs, but reorganizing the docs to follow this pattern as much as
possible will help users find what they need.

I'd like your input into this IA that I've outlined. Please give me
feedback about your opinions! If I can tackle this issue before launching
into adding CEP features, working down the existing JIRA tickets for
documentation, and backfilling missing items, it would be immensely
helpful. No opinion will go unaddressed, so please take a few minutes to
take a look.

I'm linking a google doc, to make it easy for anyone to make comments:
https://docs.google.com/document/d/1A96K73vj9MbJoD7wJNgIKWrOkLq-ZL2cNZAEXSWrciY/edit?usp=sharing

I'm also drafting an Apache C* 5.0 Doc Plan for the work, to make it simple
for anyone to know what is being done, and will share that next. In
addition, I've started consolidating the current Documentation tickets that
are open under the JIRA project, component "Documentation".

Thanks,
Lorina Poland

Re: GSoD 2023

[Lorina Poland]

Hi Deepak -

I'll have more to post soon, but I have started working on a proposal for GSoD 
2023 for Apache Cassandra. Keep an eye out for that post.

On 2023/01/11 09:56:36 Deepak Vohra via dev wrote:
> Lorina,
> Happy New Year.
> You mentioned this year you might apply. As I am interested in being the Tech 
> Writer, a reminder to apply as applications are to open from January to March 
> according to 
> https://sites.google.com/view/gsoc-sod-fosdem-2023/google-season-of-docs. 
> Detail yet to be posted for  GSOD 2023.
> regards,Deepak

Re: Fw: GSOD 2022

[Lorina Poland]

I did not. We'll figure out the best way to do this for next year.

On Fri, Mar 25, 2022 at 3:59 PM Deepak Vohra  wrote:

> I don't know if you applied.
> [Season of Docs - Announcements] Organization application phase is now
> closed
>
> - Forwarded Message -
> *From:* Deepak Vohra 
> *To:* dev@cassandra.apache.org 
> *Sent:* Thursday, March 10, 2022, 02:05:51 p.m. EST
> *Subject:* Re: GSOD 2022
>
> I sent the following clarification request to GSoD:
>
>
> "Apache Cassandra, an open source project under Apache Software Foundation
> (ASF), and a GSoD 2019-20 participant,  might be interested in applying as
> an organization to GSoD 2022. Apache Cassandra mainly does code development
> and documentation and is not structured for the administrative tasks of
> collecting a GSoD grant if accepted, hiring technical writer/s, and
> disbursing grant funds.
>
> How could Apache Cassandra apply as an organization?"
>
> I got following reply from GSoD:
>
> "If you don’t have a bank account for your project, you can sign up with
> Open Source Collective to be your fiscal host, which means they will hold
> the funds on your behalf as you pay them out. No fees from Open Source
> Collective will apply to your grant payment.  You can find more information
> on grants and opening an Open Collective account here
> <https://developers.google.com/season-of-docs/docs/org-payments> or email
> Open Collective directly for more information through
> supp...@opencollective.com.
>
> Regarding technical writers, please review the selecting a technical
> writer
> <https://developers.google.com/season-of-docs/docs/tech-writer-selection?hl=en>
>  guide
> and our GitHub <https://github.com/google/season-of-docs> page."
>
> GitHub - google/season-of-docs: Supporting materials for Google's Season...
>
> Supporting materials for Google's Season of Docs 2021 - GitHub -
> google/season-of-docs: Supporting materials for...
> <https://github.com/google/season-of-docs>
> THANKS,
> Deepak
>
>
>
>
>
> On Wednesday, March 9, 2022, 11:57:55 a.m. EST, Dinesh Joshi <
> djo...@apache.org> wrote:
>
>
> I looked into the GSoD rules for this year and they have changed
> significantly. Critically, the process requires organizations to collect a
> list of projects and apply to Google for a grant. This includes project
> ideas, budget and metrics for success. If the proposal is accepted Google
> will issue a grant and expect the organizations to select and pay the
> technical writers. This is a significant change from prior years and I
> don't think, we (Cassandra community), are setup for this. We need the ASF
> to apply as an organization as it requires a legal entity to sponsor the
> whole process including payments. This has come up in a separate discussion
> on comdev so we'll see how it goes. As GSoD deadline is March 25, I am not
> sure if we can participate.
>
> > On Mar 8, 2022, at 5:13 PM, Dinesh Joshi  wrote:
> >
> > I haven't looked into GSoD this year. However, the scope of a GSoD
> project has to be sufficient for the amount of time that is allocated by
> GSoD. They had 2 project lengths when we last participated - short & long.
> Projects need to be defined accordingly. It is a lot of work and I
> personally don't have time to select and mentor the technical writers. I
> can definitely help guide the application process as I think we also
> require someone from the PMC to actually submit the application. Nate
> helped me out when we last participated in GSoD so I'll be happy to help
> out on that front.
> >
> > Here's the page we created for tracking the GSoD Participation and
> project ideas:
> https://cwiki.apache.org/confluence/display/CASSANDRA/Cassandra+GSoD+2019+application
> >
> > It would be a good idea to do something similar and get a sense of where
> our documentation is lacking and then proceed from there.
> >
> >> On Mar 8, 2022, at 1:56 PM, Lorina Poland  wrote:
> >>
> >> I'm willing to take the lead on GSoD. Let me think about what projects
> I think would benefit the docs.
> >>
> >> Lorina
> >>
> >> On 2022/03/08 16:03:48 Paulo Motta wrote:
> >>> Any of the docs contributors interested in taking the lead on this?
> Perhaps
> >>> Dinesh could share some tips on how to create the GSoD application.
> >>>
> >>> I think there is a lot of documentation that needs to be
> created/migrated,
> >>> would be nice to have some external help on this.
> >>>
> >>> For instance, some virtual tables were added but we have no
> documentation
> >>> on them. Perhaps we could have a GSoD project to better document
> Virtual
> >>> Tables?
> >>>
> >>> Em seg., 7 de mar. de 2022 às 17:54, Deepak Vohra 
> >>> escreveu:
> >>>
> >>>> Has anyone applied for GSOD this year?  Organization application
> closes
> >>>> March 25th.
> >>>> https://developers.google.com/season-of-docs/docs/timeline
> >>>>
> >>>>
> >>>> thanks,
> >>>> Deepak
> >>>>
> >>>
> >
>
>

Re: GSOD 2022

[Lorina Poland]

Yes, in that case, it sounds like much more than I can support as well.
Perhaps next year we'll be in a position to participate.

Lorina

On Wed, Mar 9, 2022 at 8:57 AM Dinesh Joshi  wrote:

> I looked into the GSoD rules for this year and they have changed
> significantly. Critically, the process requires organizations to collect a
> list of projects and apply to Google for a grant. This includes project
> ideas, budget and metrics for success. If the proposal is accepted Google
> will issue a grant and expect the organizations to select and pay the
> technical writers. This is a significant change from prior years and I
> don't think, we (Cassandra community), are setup for this. We need the ASF
> to apply as an organization as it requires a legal entity to sponsor the
> whole process including payments. This has come up in a separate discussion
> on comdev so we'll see how it goes. As GSoD deadline is March 25, I am not
> sure if we can participate.
>
> > On Mar 8, 2022, at 5:13 PM, Dinesh Joshi  wrote:
> >
> > I haven't looked into GSoD this year. However, the scope of a GSoD
> project has to be sufficient for the amount of time that is allocated by
> GSoD. They had 2 project lengths when we last participated - short & long.
> Projects need to be defined accordingly. It is a lot of work and I
> personally don't have time to select and mentor the technical writers. I
> can definitely help guide the application process as I think we also
> require someone from the PMC to actually submit the application. Nate
> helped me out when we last participated in GSoD so I'll be happy to help
> out on that front.
> >
> > Here's the page we created for tracking the GSoD Participation and
> project ideas:
> https://cwiki.apache.org/confluence/display/CASSANDRA/Cassandra+GSoD+2019+application
> >
> > It would be a good idea to do something similar and get a sense of where
> our documentation is lacking and then proceed from there.
> >
> >> On Mar 8, 2022, at 1:56 PM, Lorina Poland  wrote:
> >>
> >> I'm willing to take the lead on GSoD. Let me think about what projects
> I think would benefit the docs.
> >>
> >> Lorina
> >>
> >> On 2022/03/08 16:03:48 Paulo Motta wrote:
> >>> Any of the docs contributors interested in taking the lead on this?
> Perhaps
> >>> Dinesh could share some tips on how to create the GSoD application.
> >>>
> >>> I think there is a lot of documentation that needs to be
> created/migrated,
> >>> would be nice to have some external help on this.
> >>>
> >>> For instance, some virtual tables were added but we have no
> documentation
> >>> on them. Perhaps we could have a GSoD project to better document
> Virtual
> >>> Tables?
> >>>
> >>> Em seg., 7 de mar. de 2022 às 17:54, Deepak Vohra 
> >>> escreveu:
> >>>
> >>>> Has anyone applied for GSOD this year?  Organization application
> closes
> >>>> March 25th.
> >>>> https://developers.google.com/season-of-docs/docs/timeline
> >>>>
> >>>>
> >>>> thanks,
> >>>> Deepak
> >>>>
> >>>
> >
>
>

Re: GSOD 2022

[Lorina Poland]

I'm willing to take the lead on GSoD. Let me think about what projects I think 
would benefit the docs.

Lorina

On 2022/03/08 16:03:48 Paulo Motta wrote:
> Any of the docs contributors interested in taking the lead on this? Perhaps
> Dinesh could share some tips on how to create the GSoD application.
> 
> I think there is a lot of documentation that needs to be created/migrated,
> would be nice to have some external help on this.
> 
> For instance, some virtual tables were added but we have no documentation
> on them. Perhaps we could have a GSoD project to better document Virtual
> Tables?
> 
> Em seg., 7 de mar. de 2022 às 17:54, Deepak Vohra 
> escreveu:
> 
> > Has anyone applied for GSOD this year?  Organization application closes
> > March 25th.
> > https://developers.google.com/season-of-docs/docs/timeline
> >
> >
> > thanks,
> > Deepak
> >
> 

Re: [DISCUSS] Non Coding Committers

[Lorina Poland]

+1 to this conversation, from a Docs wonk. :-)

On Tue, Feb 8, 2022 at 1:40 PM Patrick McFadin  wrote:

> Sharan has done a good job shining a spotlight on something that has
> created a weird bottleneck in the project. Docs and the Cassandra website
> are all in-tree, but it takes somebody who probably isn't even working on
> those things to commit any changes. Dinesh nailed it. It's silly. I'm sure
> the PMC can come up with a reasonable solution that can be done quickly.
> There are a lot of us that love this project that contribute in ways that
> don't get compiled into a jar file. This is something that needs to be
> solved for the sake of project velocity.
>
> Patrick
>
> On Sun, Feb 6, 2022 at 10:28 PM Mick Semb Wever  wrote:
>
>>
>> Thank you Sharan for sharing.
>>
>>
>>> So here in Apache Cassandra I see there is a whole lot of activity
>>> happening around the website, marketing, project promotion, blogs, social
>>> media - these activities are all contributions to the project. If there are
>>> contributions happening in the project that need a committer to action,
>>> then it could make sense to consider having committers that are focussed
>>> around the 'non coding' parts.
>>>
>>>
>>>
>>
>> This is so true for us. We are spending a lot of extra time getting these
>> non-code contributions across the finish line. The context switching and
>> wait time involved in just one more handover, and often across time zones,
>> is hurting. And regardless, totally agree we should be formally recognising
>> the ongoing work that goes into these non-coding contributions.
>>
>>

[DISCUSS] Cleaning up docs, completing CASSANDRA-16763

[Lorina Poland]

This is a discussion about how to tackle getting the docs “fixed”.

As many of you know, I started months ago to convert the Apache Cassandra
in-tree docs
from reStructedText (rST)to AsciiDoc. [1]
The conversion required both the docs source files to be converted, but
also the cassandra-website
source to be updated, to build the docs from AsciiDoc.[2] You all have seen
the results of that
conversion + the beautiful new design work accomplished.
When Apache Cassandra 4.0 was ready to GA, we used my private repo
(polandll/cassandra) to build the docs for
publication. (The new cassandra-website procedure allows for any repo to be
used to build.)
Due to a series of interferences with virtually all the people on the
project
(myself, Anthony Grasso, Mick Semb Wever, Paul Lau) in the time leading up
to the GA or right after,
we have never gotten my repo work committed and merged to the official
source (apache/cassandra).
So, here is the proposal for a plan of action:

(1) Anthony and Lorina get the 4.0/trunk and 3.11 branches that Lorina
worked on for the last 18 months
ready for merge from polandll/cassandra -> apache/cassandra.
(2) There are changes that were made in the last 18 months to docs (in the
current rST docs) that need
to be backported to the new adoc docs. We can use the commit history to
hunt down those changes and make
tickets for each of them. Those tickets can be listed under an umbrella
ticket.
(3) There are tickets that already exist that I asked people to wait on
merging during the conversion.
Those tickets also need to be completed.
(4) There are a few tickets for PRs people submitted to my private repo (oh
my!) that should be completed
again in the official repo.
(5) I will write a “how to contribute to docs” that gives people a rundown
of how to write AsciiDoc.

We would like to merge the docs in their current state, step (1), then make
the backports, rather than make the
backports then merge to the apache/cassandra repo. Main reason for this
order is that, at least the docs
and website could be built from official repos once that is done. Until the
adoc conversion is merged,
the docs and website can only be built from my personal repo, which is a
sad situation.

Lastly, just to clarify the work we want to merge. I modified the trunk for
4.0 and made all the changes
required. (750+ files). Then, rather than modify the 3.11 branch, I wrote
trunk to 3.11 and
removed the “What’s new” folder (called /new, unimaginatively). I had
planned to then go back and
incorporate the "What’s new" material into the appropriate places in the
4.0 docs, because, in short order,
those changes are no longer what’s new.

[1]
https://lists.apache.org/thread.html/r42802f86d7893c42b5091fe7f7d4b048a63cbe0fd11fadcd120596e3%40%3Cdev.cassandra.apache.org%3E
[2]
https://lists.apache.org/thread.html/r961c52f58a42a3b2cae7299244a525311283cd2758d0201f8b0feb83%40%3Cdev.cassandra.apache.org%3E

Re: [DISCUSS] Virtual Tables and the future of NodeTool/JMX

[Lorina Poland]

I think it is important to keep in mind that users may be utilizing
nodetool programmatically, in scripts. Obviously, those scripts could use
calls to cqlsh as an alternative, but I'm a fan of keeping nodetool intact,
building out virtual table capability, and then deprecating nodetool. In
other words, only deprecate/remove nodetool commands once a *whole*
replacement is available. And then deprecate slowly, perhaps with migration
help in the docs for nodetool -> virtual tables.

Lorina

On Thu, Jul 15, 2021 at 6:59 AM Paulo Motta 
wrote:

> Perhaps one approach to expose VirtualTables via nodetool without requiring
> the user to provide CQL credentials would be to provide a generic
> StorageServiceMBean.queryVirtualTable(String name) JMX method returning a
> TabularData result. This would allow to keep a consistent nodetool frontend
> to users while progressively switching the backend from JMX to
> VirtualTables.
>
> We could create a framework to automatically expose a basic nodetool
> getter/setter command whenever a new virtual table is added, making the new
> feature visible to non-power nodetool users while requiring little
> additional effort from the VirtualTable implementor.
>
> When migrating commands from JMX to VirtualTables we could just update the
> legacy nodetool command implementation to access the virtual table via the
> generic StorageServiceMBean.queryVirtualTable(String name) method while
> keeping the output consistent with the previous implementation, and
> deprecating their JMX counterpart.
>
> Ultimately when all commands are migrated from JMX to VirtualTables we
> could decide if we want to keep the nodetool CLI, acessing all virtual
> tables via the generic JMX virtual table accessor, or to deprecate nodetool
> altogether and tell users to query virtual tables directly via cqlsh
> instead.
>
> Em qui., 15 de jul. de 2021 às 10:34, Paulo Motta <
> pauloricard...@gmail.com>
> escreveu:
>
> > Thanks for bringing this discussion Benjamin. I raised a similar point in
> > CASSANDRA-16725 
> > and it may become a recurrent topic now the code freeze is lifted and
> more
> > contributors will want to add new administrative commands to nodetool so
> > it's important that we discuss and decide a consistent approach to this
> > transition moving forward.
> >
> > I was planning to write a CEP to propose a migration strategy from JMX to
> > Virtual tables but since this discussion came before I will detail my
> > thoughts so far.
> >
> > I think that we should add new commands exclusively to Virtual Tables and
> > progressively migrate existing nodetool/JMX commands to VirtualTables/CQL
> > until we ultimately get rid of JMX/nodetool. Nevertheless, from the user
> > point of view it may be inconvenient/confusing to have administrative
> > commands split between different interfaces so we need to think about
> this
> > transition carefully to provide the best possible user experience.
> >
> > My motivation for CASSANDRA-16513 <
> > https://issues.apache.org/jira/browse/CASSANDRA-16513> was that we're
> > already providing some functionalities exclusively via Virtual Tables, so
> > these features may not be visible to non-power users which are accustomed
> > to the nodetool CLI interface for admin commands. The original plan for
> > that ticket was to make nodetool abstract away the underlying interface
> > (JMX, CQL) for administrative commands, so we would expose admin
> > functionality via the same CLI interface (nodetool) to users while
> > progressively migrating the backend from JMX to CQL/VirtualTables.
> >
> > Some people raised the concern that this could cause confusion among
> users
> > about which credentials to use if JMX or CQL for nodetool. Based on this
> > feedback I adapted the proposal to create an entirely different
> > administrative CLI tool (which I called admintool) to access/modify
> virtual
> > tables. In this proposal new administrative commands would be added
> > exclusively to Virtual Tables and would automatically land on this tool,
> > and legacy nodetool commands (via JMX) would be progressively migrated to
> > admintool (CQL/VT) until the migration is completed. The drawback of this
> > alternative proposal is that it would still split administrative commands
> > between different CLI tools.
> >
> > So, if we decide to stop adding new admin functionality to JMX we have a
> > few options to make this transition smoother for our users:
> > 1) Do nothing and tell users some admin functionalities will be
> accessible
> > exclusively via cqlsh/virtual tables - imo this option is the least
> > user-friendly.
> > 2) Make nodetool hybrid and provide a consistent interface to users while
> > abstracting away the backend (JMX/CQL)
> > 3) Create a new CLI tool (admintool) to provide CLI access to  virtual
> > tables and tell users to use both nodetool and admintool.
> >
> > I personally think option 2 is the least 

Re: Additions to Cassandra ecosystem page?

[Lorina Poland]

I agree with Ben - why can other Apache communities navigate this issue,
and Apache Cassandra cannot?

I think that we grow the community when we make people aware of how
Cassandra is used. Why make new users to Cassandra search for things that
we all know exist? Help them to discover!
I would like to open the list of C* products, C*-like products, and
C*-related software as wide as possible. Again, it can only be to Apache
Cassandra's advantage to have a large group of people using
Cassandra and Cassandra-related software. Then make Apache Cassandra so
damn good that it's what people want to use.

Lorina

On Wed, Jun 30, 2021 at 9:03 PM Ben Bromhead  wrote:

> I would be sad to see us drop this just because it's a hard discussion with
> a few different opinions. My apologies if this discussion is making folks
> feel excluded.
>
> Whilst I don't have a problem with a strict approach and it does improve
> user clarity. I can understand how it might feel exclusionary. Having
> classifications can make the tent bigger and allow for things that are API
> compatible to be celebrated (the owners of some of the API compatible
> offerings make significant contributions to the community and I would love
> for them to be on the list).
>
> Having some classification would better allow us to celebrate the different
> offerings in the community and be more inclusive without misrepresenting
> things to our users and making it easy to meet our obligations around how
> we talk about Apache trademarks.
>
> Part of demonstrating the health of the project is to talk about the
> broader ecosystem around it.  Most other communities can seem to maintain
> an ecosystem list that is fairly broad.
>
> E.g.
> Apache Kafka ->
> https://cwiki.apache.org/confluence/display/KAFKA/Ecosystem
> - Maintains a set of groupings and listings. Also listed projects could be
> considered quite competitive.
> Apache Spark -> A simple list of folk who use or do something with spark
> https://spark.apache.org/powered-by.html
> Apache Samza -> Again a simple list
> http://samza.incubator.apache.org/powered-by/
>
> Outside of the Apache landscape. The Postgres folk also simply have a list
> of derived or adjacent PG databases which is kinda cool
>
> https://urldefense.proofpoint.com/v2/url?u=https-3A__wiki.postgresql.org_wiki_PostgreSQL-5Fderived-5Fdatabases=DwIFaQ=adz96Xi0w1RHqtPMowiL2g=bL2UpIjL4Mm1mCbqWThJUiPD-CmTXMALsIT2Ta-KfGk=CYtMBYwxhvN_OeCccFJ5-f88svNuwiGFg3pUEfeFtFw=yPqqmvHn4JhmTBaHeOMO4VA33OaXbTAUN53_1w1xuyw=
> .
>
> Personally I think including the "API compatible offerings" is fine and
> further demonstrates the power and reach of our community. For the
> commercial vendors out there we have our marketing budgets and will do fine
> (as Patrick said), but I would hate to see an opportunity to demonstrate
> the breadth and depth of our community be missed.
>
> As demonstrated with some of the above links, there should be a good
> inclusive solution out there.
>
>
> On Thu, Jul 1, 2021 at 2:33 PM Erick Ramirez 
> wrote:
>
> > >
> > > And I'm thinking of anyone that has to update this list and reason
> > through
> > > all of the complex rulesets of why or why not, It's really not fair to
> > > them.
> >
> > My proposal is that we completely drop the Cassandra Cloud Offereing
> > > section.
> > > Given that criteria, Professional Support and Education might be on the
> > > chopping
> > > block as well.
> > >
> >
> > +1 would definitely make my life easier when I'm reviewing/pushing
> updates
> > to the site. 
> >
>
>
> --
>
> Ben Bromhead
>
> Instaclustr | www.instaclustr.com | @instaclustr
>  | +64 27 383 8975
>

Re: Welcome Dinesh Joshi as Cassandra PMC member

[Lorina Poland]

Congratulations, Dinesh!

Lorina Poland
e. lor...@datastax.com
w. www.datastax.com



On Wed, Jun 2, 2021 at 9:22 AM Vinay Chella 
wrote:

> Congratulations Dinesh.
>
> On Wed, Jun 2, 2021 at 9:18 AM Brandon Williams  wrote:
>
> > Congrats, Dinesh!
> >
> > On Wed, Jun 2, 2021 at 11:16 AM Benjamin Lerer 
> wrote:
> > >
> > >  The PMC's members are pleased to announce that Dinesh Joshi has
> accepted
> > > the invitation to become a PMC member.
> > >
> > > Thanks a lot, Dinesh, for everything you have done for the project all
> > > these years.
> > >
> > > Congratulations and welcome
> > >
> > > The Apache Cassandra PMC members
> >
> > -
> > To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org
> > For additional commands, e-mail: dev-h...@cassandra.apache.org
> >
> > --
> Regards,
> Vinay Chella
> Engineering Manager, Data Abstractions Platform Team
>
> pronouns: he/him
>

Re: Welcome Caleb Rackliffe as Cassandra committer

[Lorina Poland]

Really glad to see your addition to the committer list, Caleb!
Congratulations!


Lorina Poland
e. lor...@datastax.com
w. www.datastax.com



On Mon, May 17, 2021 at 1:12 AM Benjamin Lerer  wrote:

> Congratulations Caleb :-)
>
> Le lun. 17 mai 2021 à 07:15, Berenguer Blasi  a
> écrit :
>
> > Congrats Caleb!
> >
> > On 17/5/21 4:22, Sumanth Pasupuleti wrote:
> > > Congratulations Caleb!!
> > >
> > > On Sun, May 16, 2021 at 6:29 PM Jeremy Hanna <
> jeremy.hanna1...@gmail.com
> > >
> > > wrote:
> > >
> > >> Congratulations Caleb!
> > >>
> > >>> On May 14, 2021, at 11:02 PM, Mick Semb Wever 
> wrote:
> > >>>
> > >>> The PMC members are pleased to announce that Caleb Rackliffe has
> > >>> accepted the invitation to become committer.
> > >>>
> > >>> Thanks heaps Caleb for helping make Cassandra awesome!
> > >>>
> > >>> Congratulations and welcome,
> > >>> The Apache Cassandra PMC members
> > >>
> > >> -
> > >> 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: [DISCUSSION] Attracting new contributors

[Lorina Poland]

I should chime in and mention that we are in the process of migrating the
Contributing/Development sections of the documentation to the site-wide,
non-versioned "docs" in cassandra-website, rather than in the docs. That
will come into existence when we can get the "new" docs, written in
asciidoc, in place. Soon.

Lorina
Lorina Poland
e. lor...@datastax.com
w. www.datastax.com



On Tue, Apr 27, 2021 at 11:32 AM Mick Semb Wever  wrote:

> > Thanks for bringing this important topic for discussion Benjamin. I think
> > it would help to enumerate what issues we face to attract new
> contributors
> > currently and then try to act on those.
> >
> > 1. Committers have little bandwidth to review low-impact issues (ie. Low
> > Hanging Fruit (LHF)), which are generally the entry-point for new
> > contributors. Lack of feedback on these initial contributions discourage
> > new contributions, creating a barrier for new contributors to join the
> > community (this point was raised by Stefan on this thread[1]).
> >
> > 2. Lack of consistency when labeling tickets as LHF. Some tickets are
> easy
> > but not tagged as LHF, some tickets are tagged as LHF but are not easy
> > enough for new contributors.
> >
> > 3. Lack of consistency when filling JIRA tickets. Some tickets have a
> clear
> > scope and definition, making it easier for new contributors to self serve
> > and figure out what needs to be done, while others have bad descriptions
> or
> > ill-defined scopes making it hard for beginners to work on these tickets.
> >
> > 4. Out of date or invalid JIRA tickets, making it harder for beginners to
> > figure out if a given ticket is valid or not to work on.
>
>
> I agree with this list Paulo. And I can see the hygiene of jira
> tickets, individually and overall, being one of the key points that we
> can immediately address (and you are!)
>
> This article was recently shared with me and I think it is a good
> starting point:
>
> https://urldefense.proofpoint.com/v2/url?u=https-3A__opensource.com_article_19_12_open-2Dsource-2Dcontributors=DwIBaQ=adz96Xi0w1RHqtPMowiL2g=bL2UpIjL4Mm1mCbqWThJUiPD-CmTXMALsIT2Ta-KfGk=q_dsXQ6jX9WOdt0mTaSMswT8YBVJJ3tuHsqmiomJHYc=__XC3za3frwYqDZAgqymi4eS1lA6mVMYWt4NSw_8cF4=
>
> We do definitely have a blocker on reviewers' bandwidth, and I think
> this overlaps with how we can better front-load patch requirements,
> code style, testing, and access to CI.
>
> CI is an interesting one. CircleCI is for those (in a company) with a
> premium account. CI-cassandra for committers (reviewers). Often what a
> new contributor thinks is a simple patch won't pass CI, and it's a
> waste to have to rely on a reviewer getting involved to provide this
> feedback. I don't have any great answer to this. Though I am still
> keen to see a script that uses the jenkins k8s operator to set up our
> jenkins DSL on anyone's own k8s cluster and run the full pipeline. On
> a much simpler front, maybe hooking up GH actions to generate the
> documentation and website would help attract (and keep around) the doc
> and website contributors.
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org
> For additional commands, e-mail: dev-h...@cassandra.apache.org
>
>

Re: Welcome Berenguer Blasi as Cassandra committer

[Lorina Poland]

Just adding more congratulations, Berenguer! Well-deserved!

Lorina Poland
e. lor...@datastax.com
w. www.datastax.com



On Fri, Mar 26, 2021 at 12:17 PM Yifan Cai  wrote:

>
> Congratulations Berenguer!
>
> - Yifan
>
> > On Mar 26, 2021, at 11:49 AM, Sumanth Pasupuleti <
> sumanth.pasupuleti...@gmail.com> wrote:
> >
> > Congratulations Berenguer!
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org
> For additional commands, e-mail: dev-h...@cassandra.apache.org
>
>

Re: Project website analytics

[Lorina Poland]

Excited to have this capability!

Lorina Poland




On Thu, Mar 11, 2021 at 6:16 AM Berenguer Blasi 
wrote:

> Thx a lot indeed!
>
> On 11/3/21 14:59, Benjamin Lerer wrote:
> > Thanks a lot to Stefan, Mick and Instaclustr. :-)
> >
> > On Wed, Mar 10, 2021 at 2:28 PM Mick Semb Wever  wrote:
> >
> >>>
> >>> The box this service runs at is donated by Instaclustr, we are glad to
> >>> help!
> >>>
> >>
> >> This is really awesome of you, Stefan and Instaclustr. Thanks!
> >>
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org
> For additional commands, e-mail: dev-h...@cassandra.apache.org
>
>

Re: Welcome Paulo Motta as Cassandra PMC member

[Lorina Poland]

Congratulations Paulo!
Lorina Poland
e. lor...@datastax.com
w. www.datastax.com



On Tue, Feb 9, 2021 at 10:30 AM Andrés de la Peña 
wrote:

> Congrats Paulo!
>
> On Tue, 9 Feb 2021 at 17:42, Sumanth Pasupuleti <
> sumanth.pasupuleti...@gmail.com> wrote:
>
> > Congratulations Paulo!
> >
> > On Tue, Feb 9, 2021 at 8:10 AM Jasonstack Zhao Yang <
> > jasonstack.z...@gmail.com> wrote:
> >
> > > Congrats Paulo!
> > >
> > > On Wed, 10 Feb 2021 at 00:03, Ekaterina Dimitrova <
> e.dimitr...@gmail.com
> > >
> > > wrote:
> > >
> > > > Congrats! Well done!
> > > >
> > > > On Tue, 9 Feb 2021 at 11:02, J. D. Jordan  >
> > > > wrote:
> > > >
> > > > > Congrats Paulo! A great addition to the PMC.
> > > > >
> > > > > > On Feb 9, 2021, at 9:59 AM, Jonathan Ellis 
> > > wrote:
> > > > > >
> > > > > > Congratulations, Paulo!  Well deserved.
> > > > > >
> > > > > >> On Tue, Feb 9, 2021 at 9:54 AM Benjamin Lerer <
> > > > > benjamin.le...@datastax.com>
> > > > > >> wrote:
> > > > > >>
> > > > > >> The PMC's members are pleased to announce that Paulo Motta has
> > > > accepted
> > > > > >> the invitation to become a PMC member yesterday.
> > > > > >>
> > > > > >> Thanks a lot, Paulo, for everything you have done for the
> project
> > > all
> > > > > these
> > > > > >> years.
> > > > > >>
> > > > > >> Congratulations and welcome
> > > > > >>
> > > > > >> The Apache Cassandra PMC members
> > > > > >>
> > > > > >
> > > > > >
> > > > > > --
> > > > > > Jonathan Ellis
> > > > > > co-founder, http://www.datastax.com
> > > > > > @spyced
> > > > >
> > > > >
> -
> > > > > To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org
> > > > > For additional commands, e-mail: dev-h...@cassandra.apache.org
> > > > >
> > > > >
> > > >
> > >
> >
>

Re: [DISCUSS] Removal of third-party plug-ins doc page

[Lorina Poland]

Sounds good. Thanks for the feedback everyone.

Lorina Poland




On Thu, Jan 21, 2021 at 3:07 AM Stefan Miklosovic <
stefan.mikloso...@instaclustr.com> wrote:

> Hi Lorina,
>
> we at Instaclustr are supporting that Lucene plugin for Cassandra 3
> and we work towards Cassandra 4 support too.
>
> I suggest you proceed with the removal of that plugin page and later
> down the road I will add it to tooling page as Michael sent it.
>
> How does that sound?
>
> Regards
>
> On Thu, 21 Jan 2021 at 11:36, Benjamin Lerer
>  wrote:
> >
> > +1
> >
> >
> >
> >
> > On Thu, Jan 21, 2021 at 10:58 AM Michael Semb Wever 
> wrote:
> >
> > >
> > > > Should this page be removed from at least the Cassandra 4.0
> > > documentation?
> > > > Neither seems to have been updated beyond C* 3.0.
> > >
> > >
> > > Good idea Lorina. Do please remove it.
> > >
> > > We have now https://cassandra.apache.org/third-party/ anyway.
> > >
> > > -
> > > 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: Upgrade chronicle-queue version from 4 to 5

[Lorina Poland]

Great - thanks for the follow-up.

Lorina Poland




On Thu, Jan 21, 2021 at 12:38 AM Michael Semb Wever  wrote:

>
>
> > Do you happen to know if there is any documentation impact to the change?
>
>
> Not that I can see.
>
> Neither of these page make reference about the minimal chronicle-queue
> versions required
>
> - https://cassandra.apache.org/doc/latest/new/auditlogging.html
> - https://cassandra.apache.org/doc/latest/new/fqllogging.html
>
>
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org
> For additional commands, e-mail: dev-h...@cassandra.apache.org
>
>

Re: Upgrade chronicle-queue version from 4 to 5

[Lorina Poland]

Do you happen to know if there is any documentation impact to the change?

Lorina Poland




On Wed, Jan 20, 2021 at 1:27 PM Jeff Jirsa  wrote:

> No objection and strong agreement that it should happen with 4.0 for arm64
>
>
> On Wed, Jan 20, 2021 at 12:44 PM Mick Semb Wever  wrote:
>
> > To get Cassandra 4.0 working on arm64 we have a number of dependencies
> > we need to upgrade. See CASSANDRA-16384, CASSANDRA-16392 and
> > CASSANDRA-15889.
> >
> > CASSANDRA-16384 requires the major version upgrade from
> > chronicle-queue 4 to 5. A consequence[1] of this is any external
> > trailers (consumers) must also be upgraded to version 5. This is a
> > breakage of our Beta Release Lifecycle rules[2]. Chronicle-queue is
> > used by Auditing, FQL, and Diagnostic Events.
> >
> > I would like to request an exception to the Beta release to get the
> > upgrade in place and to support arm64. Does anyone have any objection
> > or concern to the upgrade? An entry in NEWS.txt will be added.
> >
> >
> > [1]
> >
> https://issues.apache.org/jira/browse/CASSANDRA-16384?focusedCommentId=17268671=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-17268671
> >
> > [2]
> > https://cwiki.apache.org/confluence/display/CASSANDRA/Release+Lifecycle
> >
> > -
> > To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org
> > For additional commands, e-mail: dev-h...@cassandra.apache.org
> >
> >
>

[DISCUSS] Removal of third-party plug-ins doc page

[Lorina Poland]

This page, https://cassandra.apache.org/doc/latest/plugins/index.html,
seems to reference two abandoned plugin projects for Cassandra.

Should this page be removed from at least the Cassandra 4.0 documentation?
Neither seems to have been updated beyond C* 3.0.

Thanks,
Lorina Poland

Re: Welcome Jordan West, David Capwell, Zhao Yang and Ekaterina Dimitrova as Cassandra committers

[Lorina Poland]

I'm really excited to see these four folks become committers!
Congratulations!

Lorina Poland



On Wed, Dec 16, 2020 at 11:16 AM Paulo Motta 
wrote:

> Great news, congratulations to the new committers!
>
> Em qua., 16 de dez. de 2020 às 14:52, Patrick McFadin 
> escreveu:
>
> > Congratulations Jordan, David, Zhao and Ekaterina! It's great to see your
> > names on the committer list! You have definitely made Apache Cassandra
> > better through your efforts.
> >
> > Patrick
> >
> > On Wed, Dec 16, 2020 at 9:03 AM Jonathan Ellis 
> wrote:
> >
> > > Well-deserved congratulations!
> > >
> > > On Wed, Dec 16, 2020 at 10:56 AM Benjamin Lerer <
> > > benjamin.le...@datastax.com>
> > > wrote:
> > >
> > > > The PMC's members are pleased to announce that Jordan West, David
> > > Capwell,
> > > > Zhao Yang and Ekaterina Dimitrova have accepted the invitations to
> > become
> > > > committers this year.
> > > >
> > > > Jordan West accepted the invitation in April
> > > > David Capwell accepted the invitation in July
> > > > Zhao Yang accepted the invitation in September
> > > > Ekaterina Dimitrova accepted the invitation in December
> > > >
> > > > Thanks a lot for everything you have done.
> > > >
> > > > Congratulations and welcome
> > > >
> > > > The Apache Cassandra PMC members
> > > >
> > >
> > >
> > > --
> > > Jonathan Ellis
> > > co-founder, http://www.datastax.com
> > > @spyced
> > >
> >
>

Re: [DISCUSS] Updating the C* website design

[Lorina Poland]

The one issue I see with your suggestion about versioned/non-versioned docs
is that the cassandra/doc repo will have asciidoc files, and currently, all
the items in the cassandra-website repo are in markdown. There are possible
solutions (use antora for the website, put the non-versioned docs in their
own repo which antora can use for building, for example), but that needs
exploration.

Lorina Poland




On Wed, Aug 5, 2020 at 12:06 PM Michael Semb Wever  wrote:

>
>
> > See that here:
> >
> https://docs.google.com/document/d/1aeNtgyPAsKcNa0GSKvl2ywlFEj30714ry4Sb5turWeE/edit?usp=sharing
> >
> > This outline is not complete, just my initial scribblings. Certainly
> > collaboration would be welcome.
>
>
> This is awesome Lorina. It would also be great to see all non-versioned
> docs moved out of the cassandra repository and into the cassandra-website
> repository (where they become easier to update).
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org
> For additional commands, e-mail: dev-h...@cassandra.apache.org
>
>

Re: [DISCUSS] CASSANDRA Jira modification - add Doc Impact field

[Lorina Poland]

I was just working from this doc:
https://cwiki.apache.org/confluence/display/CASSANDRA/JIRA+Workflow+Proposals

Test and Documentation Plan
> A new required field containing free-form text field, required when
> transitioning to 'In Progress'.
> The intended purpose is to encourage explicit upfront consideration of the
> work needed on these areas
> either before or following commit. This may entail filing follow-up
> tickets that need to be resolved before release,
> or a brief statement on the tests that will be written, or simply 'n/a'.
> This also provides a promise to hold implementors to before release, and a
> point of discussion before a ticket lands.

Now that you pointed it out, I do see the "Impacts" field. A search of:

*Impacts in (Docs) and project in (Cassandra) and fixVersion in (4.0)*

does turn up what I'm looking for in terms of knowing about tickets that
require docs.

The automation rule would still be nice, and could be triggered when
Impacts = Docs.

Thanks for the info, Benedict!

Lorina Poland




On Fri, Jul 31, 2020 at 1:10 PM Benedict Elliott Smith 
wrote:

> > It is mandatory to move a ticket to "In Progress"
>
> I think you are mistaken; I have triple-checked, and it appears to be
> required on "Submit Patch" - the problem is that nobody really fills it out
> very well.  Being mandatory is insufficient.
>
> Also, to clarify my earlier email, there already exists a field called
> "Impacts" which includes "Docs" as an option to indicate there exists a
> documentation impact to consider, mostly to support search.
>
>
> On 31/07/2020, 20:51, "Lorina Poland"  wrote:
>
> I believe that the Test and Documentation Plan field is required too
> early
> in the progress for Documentation needs. It is mandatory to move a
> ticket
> to "In Progress". I suspect that, while a developer may say something
> in
> this field, they won't really be sure of the doc impact at that stage.
>
> I would find it useful to have a mandatory Doc Impact field before a
> ticket
> moves from "In Progress" to "Patch Available". The design and
> implementation of the code work will be uppermost at that point, when
> the
> developer has finally made the code changes.
>
> I see tickets that have wonderful design docs early in the process.
> But as
> the work progresses, the design changes, and those changes are not
> captured
> in any summary manner.
>
> For instance, I'm currently working to rewrite audit logging (
> https://issues.apache.org/jira/browse/CASSANDRA-12151). Weeding
> through 4
> years of comments and changes is challenging. If the developer had
> marked
> Doc Impact and perhaps written some Doc Notes right before "Patch
> Available", I'd feel much more confident that I understand what the
> submitted change is. For some development, I can look at the code and
> figure out what it does. A topic like audit logging is likely to use
> many
> classes and touch on many items that I'm not familiar with nor be the
> most
> readable code.
>
> Lorina Poland
>
>
>
>
> On Fri, Jul 31, 2020 at 12:35 PM Benedict Elliott Smith <
> bened...@apache.org>
> wrote:
>
> > Impacts -> Docs
> >
> > It's not mandatory, but we could perhaps consider making it so
> somewhere
> > in the workflow.  Do you have a good suggestion for where?
> >
> > There's also "Test and Documentation Plan" which is already
> mandatory.
> >
> >
> > On 31/07/2020, 20:28, "Lorina Poland"  wrote:
> >
> > This morning, Caleb Rackliffe mentioned to me that
> CASSANDRA-15907
> > involved
> > some code work that has Documentation implications, just to let
> me
> > know.
> >
> > I'd like to propose a change to the Cassandra Jira system, to
> include a
> > field called "Doc Impact" that a developer could check if there
> is
> > accompanying documentation that should be written. It would help
> with
> > discovery, so that a corresponding  _Documentation%Website_ Jira
> ticket
> > could be written for the work.
> >
> > At DataStax, I've gone even a step further and added an
> automation rule
> > that makes a copy of the original ticket if the Doc Impact field
> is
> > checked. I would love to have that as well, but would be happy
> just
> > for the
> > Doc Impact field. If Doc Impact was mandat

Re: [DISCUSS] CASSANDRA Jira modification - add Doc Impact field

[Lorina Poland]

I believe that the Test and Documentation Plan field is required too early
in the progress for Documentation needs. It is mandatory to move a ticket
to "In Progress". I suspect that, while a developer may say something in
this field, they won't really be sure of the doc impact at that stage.

I would find it useful to have a mandatory Doc Impact field before a ticket
moves from "In Progress" to "Patch Available". The design and
implementation of the code work will be uppermost at that point, when the
developer has finally made the code changes.

I see tickets that have wonderful design docs early in the process. But as
the work progresses, the design changes, and those changes are not captured
in any summary manner.

For instance, I'm currently working to rewrite audit logging (
https://issues.apache.org/jira/browse/CASSANDRA-12151). Weeding through 4
years of comments and changes is challenging. If the developer had marked
Doc Impact and perhaps written some Doc Notes right before "Patch
Available", I'd feel much more confident that I understand what the
submitted change is. For some development, I can look at the code and
figure out what it does. A topic like audit logging is likely to use many
classes and touch on many items that I'm not familiar with nor be the most
readable code.

Lorina Poland




On Fri, Jul 31, 2020 at 12:35 PM Benedict Elliott Smith 
wrote:

> Impacts -> Docs
>
> It's not mandatory, but we could perhaps consider making it so somewhere
> in the workflow.  Do you have a good suggestion for where?
>
> There's also "Test and Documentation Plan" which is already mandatory.
>
>
> On 31/07/2020, 20:28, "Lorina Poland"  wrote:
>
> This morning, Caleb Rackliffe mentioned to me that CASSANDRA-15907
> involved
> some code work that has Documentation implications, just to let me
> know.
>
> I'd like to propose a change to the Cassandra Jira system, to include a
> field called "Doc Impact" that a developer could check if there is
> accompanying documentation that should be written. It would help with
> discovery, so that a corresponding  _Documentation%Website_ Jira ticket
> could be written for the work.
>
> At DataStax, I've gone even a step further and added an automation rule
> that makes a copy of the original ticket if the Doc Impact field is
> checked. I would love to have that as well, but would be happy just
> for the
> Doc Impact field. If Doc Impact was mandatory when a ticket moves from
> review to merge, for instance, that would be useful, too.
>
> Thanks,
> Lorina Poland
>
>
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org
> For additional commands, e-mail: dev-h...@cassandra.apache.org
>
>

[DISCUSS] CASSANDRA Jira modification - add Doc Impact field

[Lorina Poland]

This morning, Caleb Rackliffe mentioned to me that CASSANDRA-15907 involved
some code work that has Documentation implications, just to let me know.

I'd like to propose a change to the Cassandra Jira system, to include a
field called "Doc Impact" that a developer could check if there is
accompanying documentation that should be written. It would help with
discovery, so that a corresponding  _Documentation%Website_ Jira ticket
could be written for the work.

At DataStax, I've gone even a step further and added an automation rule
that makes a copy of the original ticket if the Doc Impact field is
checked. I would love to have that as well, but would be happy just for the
Doc Impact field. If Doc Impact was mandatory when a ticket moves from
review to merge, for instance, that would be useful, too.

Thanks,
Lorina Poland

Re: [DISCUSS] Updating the C* website design

[Lorina Poland]

Perhaps I should start another thread, but I have started to outline a more
solution-based approach to the docs that I was considering implementing.

See that here:
https://docs.google.com/document/d/1aeNtgyPAsKcNa0GSKvl2ywlFEj30714ry4Sb5turWeE/edit?usp=sharing

This outline is not complete, just my initial scribblings. Certainly
collaboration would be welcome.

Lorina Poland




On Wed, Jul 29, 2020 at 2:13 PM Mick Semb Wever  wrote:

> > I would offer that design is important, but content matters more -- so
> > would suggest adding content strategy/development and information
> > architecture to the checkpoints list. For example, an ecosystem page
> could
> > be highly beneficial to end users (what does C* work with?), as well as a
> > use case/case studies page.
>
>
> Couldn't agree more Melissa. If we can come up with a list of
> content/pages we are currently missing, and agree on it, that's going
> to make this process easier. The more we can define and spec, the
> better.
>
>
> > like say, https://spark.apache.org or https://ignite.apache.org/,
>
> For the sake of brainstorming, my favourite two apache project
> websites are skywalking.apache.org and ignite.apache.org
> But I don't think we should limit what's possible, I certainly am not
> a designer.
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org
> For additional commands, e-mail: dev-h...@cassandra.apache.org
>
>

Re: [DISCUSS] Updating the C* website design

[Lorina Poland]

To address Melissa's comments - the main reason that this proposal is
offered right now is that the Documentation renewal involves a change to a
new static site generator, Antora (https://antora.org). Because of this
change, the UI for cassandra.apache.org/doc must be rebuilt using the
Antora UI (https://gitlab.com/antora/antora-ui-default). If we are
rebuilding the UI anyway, why not take the opportunity to update the look
and feel of the whole site?

I have pretty much reproduced the current look and feel and built an antora
UI bundle, but I'm a copier of design, not a designer. To accomplish a UI
that is more modern, like say, https://spark.apache.org or
https://ignite.apache.org/, is beyond my expertise. So, an effort to do
website UI design would be concurrent with my continued work to improve the
content of both the docs pages and the other pages on the Cassandra website.

Lorina



On Wed, Jul 29, 2020 at 11:34 AM Melissa Logan 
wrote:

> I would offer that design is important, but content matters more -- so
> would suggest adding content strategy/development and information
> architecture to the checkpoints list. For example, an ecosystem page could
> be highly beneficial to end users (what does C* work with?), as well as a
> use case/case studies page.
>
>
> On Wed, Jul 29, 2020 at 7:49 AM Mick Semb Wever  wrote:
>
> > We have funds on offer to the project to hire a contractor to update
> > the website.
> >
> > Personally I think this is a fantastic opportunity, it would be great
> > to see the website afresh in coordination with the 4.0 release.
> >
> > With no up-front defining goals or improvements specified, if we go
> > forth with the offer, how can we go about optimising such a
> > contractor's time? Achieving something we all accept and own can be
> > challenging. And I am aware this is a little at odds with how open
> > source typically operates, the closest I can think of is code bounties
> > which are usually easier to define and spec in advance. In those
> > situations the bounty hunter interfaces directly with the community.
> > In this situation, we want broader community involvement on something
> > as touching as the landing page to the project's website, while
> > optimising the contractor's time to their speciality.
> >
> > If we want to take this on, how can we go about it?
> >
> > My first suggestion to throw out there, is to tackle it incrementally
> > with a few checkpoints along the way: where we can pause and discuss
> > and bike-shed all we like without having to involve the contractor's
> > time.  It’s also worth keeping in mind the ongoing work on converting
> > the in-tree docs, its design changes and impact it will have on our
> > user base…
> >
> > Some example of checkpoints are:
> >  * Various sketches presented and a straw poll from PMC (or the
> > broader dev group) (this could also be a 99design contest)
> >  * Initial prototype of selected sketch
> >  * Near completion of new website
> >  * Sign-off of final website (weighted to those actively involved in 2-3)
> >
> > Do we want to do this?
> > Do we think it is feasible?
> > Is the above suggestion sound?
> > Do we want more/less/different checkpoints?
> >
> > -
> > To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org
> > For additional commands, e-mail: dev-h...@cassandra.apache.org
> >
> >
>

[DISCUSS] Updating the companies listed on the home page as C* users

[Lorina Poland]

While creating a third-party page (CASSANDRA-15940), I decided to check the
links in the Proven block on the home page:
[image: Screen Shot 2020-07-15 at 12.44.30.png]
Turns out, a lot of those links are dead planetcassandra links. And some of
those companies are now using other software, like Scylla. If anyone can
offer current links that show company usage, I'd appreciate it. I've found
these:

 




For two of these, I found talks in the last 2 years at DataStax events, but
I didn't find more general links. Feel free to point me to different
resources.

Thanks,
Lorina

Lorina Poland
e. lor...@datastax.com
w. www.datastax.com

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_=DwIFaQ=adz96Xi0w1RHqtPMowiL2g=bL2UpIjL4Mm1mCbqWThJUiPD-CmTXMALsIT2Ta-KfGk=idt7YJPlj_-MlXoX_MmrNOwk02d_1YwoXwUrVeeXTVc=1dX-CHHtPCG4TsXGFb6bc31vxc6UKnduXjPRKgyNMO0=
> ) 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: Proof of concept for Cassandra docs conversion

[Lorina Poland]

I just wanted to update everyone on the POC for the docs website:
https://polandll.github.io/site/Cassandra/4.0/index.html

I've added lunr search to the site, and (mostly finished) custom header and
footer that matches the current site. I've also added a dummy 3.11 version
(same source files as 4.0-rc5) to demonstrate having selectable doc
versions. Still manually editing files, so yes - I know there are still
pages messed up. And the Last/Next buttons - trying to figure out the
implementation.

But all comments appreciated and solicited.
Thanks,
Lorina
Lorina Poland
e. lor...@datastax.com
w. www.datastax.com



On Thu, Jun 11, 2020 at 7:13 PM Anthony Grasso 
wrote:

> I agree as well. Nice work, Lorina!
>
> This POC is a really good start. It has a bit more of a modern feel to it.
> The navigation bar on the side makes the information very accessible. This
> is a must for technical documentation.
>
> Would it be possible to have a search bar somewhere on the site? I think
> this would be useful to allow a user to navigate quickly to something they
> know they are after e.g. a nodetool command or configuration setting.
>
> Kind regards,
>
> On Fri, 12 Jun 2020 at 02:02, Jon Haddad  wrote:
>
> > Agreed.  This is an awesome POC in a pretty short period of time.
> >
> > I suspect with a little polish and cleanup this will be an improvement
> over
> > the existing site in every way.
> >
> > Thanks for putting this together, Lorina!
> >
> > On Thu, Jun 11, 2020 at 7:36 AM Joshua McKenzie 
> > wrote:
> >
> > > Left bar navigation and content navigation on top right are both
> > > aesthetically and usability-wise quite superior IMO (comparing to
> > >
> https://cassandra.apache.org/doc/latest/getting_started/configuring.html
> > ).
> > >
> > > I'm a fan.
> > >
> > > On Wed, Jun 10, 2020 at 2:21 PM Lorina Poland 
> > wrote:
> > >
> > > > Hello all!
> > > >
> > > > Based on an earlier discussion about moving the OSS C* docs to
> > > > asciidoc, to allow more flexibility in maintaining the docs, I've
> done
> > > > a proof of concept about what it would take to accomplish a
> > > > conversion. I converted rSt files to asciidoc files using pandoc, did
> > > > some additional editing, and use antora (antora.org) as a static
> site
> > > > generator to build the docs. The result is here:
> > > >
> > > >
> > >
> >
> https://urldefense.proofpoint.com/v2/url?u=https-3A__polandll.github.io_site_ASCIIDOC-5FPOC_4.0_cassandra_getting-5Fstarted_configuring.html-23changing-2Dthe-2Dlocation-2Dof-2DdirectoriesThe=DwIBaQ=adz96Xi0w1RHqtPMowiL2g=bL2UpIjL4Mm1mCbqWThJUiPD-CmTXMALsIT2Ta-KfGk=57qpHuofWcJzqnGIF_M7WxOaLaNAKs4buNLWOFM0vMs=wTEu0dtK7H2_LkcYq7Xxw2VjPDLl-QSVb4tScXcS6mk=
> > > > editing of the docs is NOT complete, but I completed enough to feel
> > > > confident that this process can be accomplished. Some YAML
> > > > configuration for antora was required, and I did a minimum of UI
> > > > configuration (added color banner, logo). Looking for feedback and
> > > > questions anyone may have.
> > > >
> > > > Thanks,
> > > >
> > > > Lorina Poland (DataStax tech writer)
> > > >
> > >
> >
>

Re: Proof of concept for Cassandra docs conversion

[Lorina Poland]

Thanks for the vote of confidence, Anthony! Yes, search can be integrated
into the antora SSG; I just haven't pursued that yet. Obviously a feature
that is needed.

Lorina




On Thu, Jun 11, 2020 at 7:13 PM Anthony Grasso 
wrote:

> I agree as well. Nice work, Lorina!
>
> This POC is a really good start. It has a bit more of a modern feel to it.
> The navigation bar on the side makes the information very accessible. This
> is a must for technical documentation.
>
> Would it be possible to have a search bar somewhere on the site? I think
> this would be useful to allow a user to navigate quickly to something they
> know they are after e.g. a nodetool command or configuration setting.
>
> Kind regards,
>
> On Fri, 12 Jun 2020 at 02:02, Jon Haddad  wrote:
>
> > Agreed.  This is an awesome POC in a pretty short period of time.
> >
> > I suspect with a little polish and cleanup this will be an improvement
> over
> > the existing site in every way.
> >
> > Thanks for putting this together, Lorina!
> >
> > On Thu, Jun 11, 2020 at 7:36 AM Joshua McKenzie 
> > wrote:
> >
> > > Left bar navigation and content navigation on top right are both
> > > aesthetically and usability-wise quite superior IMO (comparing to
> > >
> https://cassandra.apache.org/doc/latest/getting_started/configuring.html
> > ).
> > >
> > > I'm a fan.
> > >
> > > On Wed, Jun 10, 2020 at 2:21 PM Lorina Poland 
> > wrote:
> > >
> > > > Hello all!
> > > >
> > > > Based on an earlier discussion about moving the OSS C* docs to
> > > > asciidoc, to allow more flexibility in maintaining the docs, I've
> done
> > > > a proof of concept about what it would take to accomplish a
> > > > conversion. I converted rSt files to asciidoc files using pandoc, did
> > > > some additional editing, and use antora (antora.org) as a static
> site
> > > > generator to build the docs. The result is here:
> > > >
> > > >
> > >
> >
> https://urldefense.proofpoint.com/v2/url?u=https-3A__polandll.github.io_site_ASCIIDOC-5FPOC_4.0_cassandra_getting-5Fstarted_configuring.html-23changing-2Dthe-2Dlocation-2Dof-2DdirectoriesThe=DwIBaQ=adz96Xi0w1RHqtPMowiL2g=bL2UpIjL4Mm1mCbqWThJUiPD-CmTXMALsIT2Ta-KfGk=57qpHuofWcJzqnGIF_M7WxOaLaNAKs4buNLWOFM0vMs=wTEu0dtK7H2_LkcYq7Xxw2VjPDLl-QSVb4tScXcS6mk=
> > > > editing of the docs is NOT complete, but I completed enough to feel
> > > > confident that this process can be accomplished. Some YAML
> > > > configuration for antora was required, and I did a minimum of UI
> > > > configuration (added color banner, logo). Looking for feedback and
> > > > questions anyone may have.
> > > >
> > > > Thanks,
> > > >
> > > > Lorina Poland (DataStax tech writer)
> > > >
> > >
> >
>

Re: Proof of concept for Cassandra docs conversion

[Lorina Poland]

Thanks for the feedback, Murukesh! As I mentioned, the editing to fix all
the formatting is not completed, but I wanted to share the work so far to
get feedback.

I have not tailored most of the styling of the website. I literally used
the default antora UI, only changing the banner to green and adding the
Cassandra logo. So all the navigation can use some additional work; in
fact, I only created the navigation files for 2-3 of the sections. Same
with the breadcrumbs, more work to make it production-worthy. (But aren't
those breadcrumbs cool?!)

I have tried a few different conversions. I believe I did try rSt-> HTML ->
asciidoc, but I'll check my files again.

I have 4 separate sources of files used to create this POC, some local on
my Macbook, and some publicly available:

So, right now, the pieces of the process are in 4 locations:

1. docs-site (local - where I run antora)
2. a clone of https://gitlab.com/antora/antora-ui-default (local - where I
made minimal look and feel changes)
3.
https://github.com/polandll/cassandra-examples/tree/master/rst-to-asciidoc-tests/ASCIIDOC
(where
I am storing the asciidoc files that I’ve converted/editing)
4. https://github.com/polandll/polandll.github.io (where the prototype
docs website
is located)
Feel free to check out the *.adoc files in the 3rd resource, but know that
I am actively making changes there.

Thanks,
Lorina



On Thu, Jun 11, 2020 at 8:15 AM Murukesh Mohanan 
wrote:

> Is the AsciiDoc source also on GitHub?
>
> Some things that I noticed:
>
> - The FAQ sidebar navigation is great!  The TOC list at the top isn't
> needed at all now.
> - In the breadcrumb trail (e.g., ASCIIDOC_POC > Cassandra > FAQ, or
> ASCIIDOC_POC > Cassandra Documentation > Glossary), *Cassandra* in the
> Cassandra pages isn't a link but Cassandra Documentation is.
> - Some of the code blocks are off (e.g,
>
> https://urldefense.proofpoint.com/v2/url?u=https-3A__polandll.github.io_site_ASCIIDOC-5FPOC_4.0_cassandra_cql_indexes.html-23create-2Dindex-2Dstatement=DwIBaQ=adz96Xi0w1RHqtPMowiL2g=bL2UpIjL4Mm1mCbqWThJUiPD-CmTXMALsIT2Ta-KfGk=8C0qNdZj2XHZ-aA4ZjwgWI_Y6Nael_kjR7Wp-6CiOLU=Eg_JbhzOrbE1c5RgXi1UHjOQ-Np-uTmzDyPukPwWvfE=
> ,
>
> https://urldefense.proofpoint.com/v2/url?u=https-3A__polandll.github.io_site_ASCIIDOC-5FPOC_4.0_cassandra_cql_mvs.html=DwIBaQ=adz96Xi0w1RHqtPMowiL2g=bL2UpIjL4Mm1mCbqWThJUiPD-CmTXMALsIT2Ta-KfGk=8C0qNdZj2XHZ-aA4ZjwgWI_Y6Nael_kjR7Wp-6CiOLU=emL2s3ZZkCU5-L2Zg0-mlYKamtcCh2NkqVSu5Wn41Ss=
> )
> - Pandoc clobbered the "MV select" part in
>
> https://urldefense.proofpoint.com/v2/url?u=https-3A__polandll.github.io_site_ASCIIDOC-5FPOC_4.0_cassandra_cql_mvs.html=DwIBaQ=adz96Xi0w1RHqtPMowiL2g=bL2UpIjL4Mm1mCbqWThJUiPD-CmTXMALsIT2Ta-KfGk=8C0qNdZj2XHZ-aA4ZjwgWI_Y6Nael_kjR7Wp-6CiOLU=emL2s3ZZkCU5-L2Zg0-mlYKamtcCh2NkqVSu5Wn41Ss=
> into the preceding note.
>
> I wonder if it will be worth it to try rSt -> HTML (using the current build
> tools) -> AsciiDoc (using Pandoc).
>
> Yours,
> Murukesh Mohanan
>
>
> On Thu, 11 Jun 2020 at 03:21, Lorina Poland  wrote:
>
> > Hello all!
> >
> > Based on an earlier discussion about moving the OSS C* docs to
> > asciidoc, to allow more flexibility in maintaining the docs, I've done
> > a proof of concept about what it would take to accomplish a
> > conversion. I converted rSt files to asciidoc files using pandoc, did
> > some additional editing, and use antora (antora.org) as a static site
> > generator to build the docs. The result is here:
> >
> >
> https://urldefense.proofpoint.com/v2/url?u=https-3A__polandll.github.io_site_ASCIIDOC-5FPOC_4.0_cassandra_getting-5Fstarted_configuring.html-23changing-2Dthe-2Dlocation-2Dof-2DdirectoriesThe=DwIBaQ=adz96Xi0w1RHqtPMowiL2g=bL2UpIjL4Mm1mCbqWThJUiPD-CmTXMALsIT2Ta-KfGk=8C0qNdZj2XHZ-aA4ZjwgWI_Y6Nael_kjR7Wp-6CiOLU=a_fQx4FtvGnSkExAfzZM2BZAiaOmEeo9EA8DXjAYKz4=
> > editing of the docs is NOT complete, but I completed enough to feel
> > confident that this process can be accomplished. Some YAML
> > configuration for antora was required, and I did a minimum of UI
> > configuration (added color banner, logo). Looking for feedback and
> > questions anyone may have.
> >
> > Thanks,
> >
> > Lorina Poland (DataStax tech writer)
> >
>

Re: Proof of concept for Cassandra docs conversion

[Lorina Poland]

Just a note, to emphasize - I did not complete the conversion of all the
files from rSt to asciidoc yet. I wanted feedback that this direction
seemed acceptable to everyone.

Sylvain, I'll check out the tool you mention and see if it provides better
translation. A one-time conversion effort is just that, though; rSt has
some decided quirks that make the conversion to any other markup
challenging.

Thanks for the feedback!
Lorina



On Thu, Jun 11, 2020 at 8:13 AM Sylvain Lebresne  wrote:

> Agreed the navigation is nicer.
>
> The content rst conversion is however far from perfect, especially in the
> CQL parts. The grammar parts are all broken, most tables are really weird
> (example:
>
> https://urldefense.proofpoint.com/v2/url?u=https-3A__polandll.github.io_site_ASCIIDOC-5FPOC_4.0_cassandra_cql_types.html=DwIBaQ=adz96Xi0w1RHqtPMowiL2g=bL2UpIjL4Mm1mCbqWThJUiPD-CmTXMALsIT2Ta-KfGk=HsSPj9vYYbc2vVPNFrAqnMLZAz2ViLNZhPvU3cP1dCc=v5p3jTSLjuG_8QlzsBv2bqNKV0OM7v2vrVfN85YAduc=
> )
> and we lost almost all linking in those parts.
>
> I think that's up to pandoc not handling rst too well, and while that could
> be fixed manually, it's going to be some work. So I'd suggest giving a shot
> at
> https://urldefense.proofpoint.com/v2/url?u=https-3A__pypi.org_project_sphinx-2Dasciidoc_=DwIBaQ=adz96Xi0w1RHqtPMowiL2g=bL2UpIjL4Mm1mCbqWThJUiPD-CmTXMALsIT2Ta-KfGk=HsSPj9vYYbc2vVPNFrAqnMLZAz2ViLNZhPvU3cP1dCc=Sk4bb6rmPcdu_CsF426Ta-p5mwkcJirmv5hsNf2FZxo=
> as an alternative. I haven't
> tested it, but it supposedly exists to be a better converter than pandoc
> and it may save some of that manual work.
> --
> Sylvain
>
>
> On Thu, Jun 11, 2020 at 4:45 PM Ekaterina Dimitrova  >
> wrote:
>
> > I told the same to Lorina in person, +1 more fan
> >
> > On Thu, 11 Jun 2020 at 10:36, Joshua McKenzie 
> > wrote:
> >
> > > Left bar navigation and content navigation on top right are both
> > > aesthetically and usability-wise quite superior IMO (comparing to
> > >
> https://cassandra.apache.org/doc/latest/getting_started/configuring.html
> > ).
> > >
> > > I'm a fan.
> > >
> > > On Wed, Jun 10, 2020 at 2:21 PM Lorina Poland 
> > wrote:
> > >
> > > > Hello all!
> > > >
> > > > Based on an earlier discussion about moving the OSS C* docs to
> > > > asciidoc, to allow more flexibility in maintaining the docs, I've
> done
> > > > a proof of concept about what it would take to accomplish a
> > > > conversion. I converted rSt files to asciidoc files using pandoc, did
> > > > some additional editing, and use antora (antora.org) as a static
> site
> > > > generator to build the docs. The result is here:
> > > >
> > > >
> > >
> >
> https://urldefense.proofpoint.com/v2/url?u=https-3A__polandll.github.io_site_ASCIIDOC-5FPOC_4.0_cassandra_getting-5Fstarted_configuring.html-23changing-2Dthe-2Dlocation-2Dof-2DdirectoriesThe=DwIBaQ=adz96Xi0w1RHqtPMowiL2g=bL2UpIjL4Mm1mCbqWThJUiPD-CmTXMALsIT2Ta-KfGk=HsSPj9vYYbc2vVPNFrAqnMLZAz2ViLNZhPvU3cP1dCc=wrHgAx24wI9dskwFiDgg8jtb__tc9HLjRDaCeerk7XE=
> > > > editing of the docs is NOT complete, but I completed enough to feel
> > > > confident that this process can be accomplished. Some YAML
> > > > configuration for antora was required, and I did a minimum of UI
> > > > configuration (added color banner, logo). Looking for feedback and
> > > > questions anyone may have.
> > > >
> > > > Thanks,
> > > >
> > > > Lorina Poland (DataStax tech writer)
> > > >
> > >
> >
>

Proof of concept for Cassandra docs conversion

[Lorina Poland]

Hello all!

Based on an earlier discussion about moving the OSS C* docs to
asciidoc, to allow more flexibility in maintaining the docs, I've done
a proof of concept about what it would take to accomplish a
conversion. I converted rSt files to asciidoc files using pandoc, did
some additional editing, and use antora (antora.org) as a static site
generator to build the docs. The result is here:
https://polandll.github.io/site/ASCIIDOC_POC/4.0/cassandra/getting_started/configuring.html#changing-the-location-of-directoriesThe
editing of the docs is NOT complete, but I completed enough to feel
confident that this process can be accomplished. Some YAML
configuration for antora was required, and I did a minimum of UI
configuration (added color banner, logo). Looking for feedback and
questions anyone may have.

Thanks,

Lorina Poland (DataStax tech writer)

CQL and pygments

[Lorina Poland]

Some time back, someone (Sylvain?) wrote some code to use CQL with pygments. 
Can I interest anyone in picking up that work, perhaps doing some update and 
submitting it upstream to pygments.org? It would be exceedingly helpful to me 
personally (for C* documentation work), but also a wider audience, I'm sure. 
Here's a pointer to the existing code: 

github.com/apache/cassandra/doc/source/_util

Thanks, Lorina

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