Re: Making RF4 useful aka primary and secondary ranges

[Carl Mueller]

Close. I'm suggesting that if you have RF4 or 5 or 6, you get to designate
a subset of three replicas that are strongly preferred. From this "virtual
subset/datacenter" if you do QUORUM against that subset, it just does n/2+1
of the subset. Updates are still sent to the non-primary replicas, and if a
primary fails one of the replicas is then added as a primary.

For your RF4 case you write QUORUM and read HALF, but that limits the
number of "hot spares" although with admittedly better consistency
guarantee on the hot spares.

I'm suggesting something where you could have a ton more hot spares, say
RF8 or RF10, but you still rely on the first three in the ring as the
primary that you do CL.2 QUORUM against, and you accept the additional
replicas are eventually consistent when they are eventually consistent.

Yours, mine, and the two others that were linked all kind of bandy around
the same thing: trying to finagle more replicas while not being shoehorned
into having to do more replica agreements on the reads. Some have better
guarantees than the others...

To do mine via the driver is basically making the driver the coordinator.
Works in some network topologies, but would be too high otherwise.


On Wed, Mar 14, 2018 at 9:14 PM, Jason Brown  wrote:

> I feel like we've had a very similar conversation (not so) recently:
> https://lists.apache.org/thread.html/9952c419398a1a2f22e2887e3492f9
> d6899365f0ea7c2b68d6fbe0d4@%3Cuser.cassandra.apache.org%3E
>
> Which led to the creation of this JIRA:
> https://issues.apache.org/jira/browse/CASSANDRA-13645
>
>
> On Wed, Mar 14, 2018 at 4:23 PM, Carl Mueller <
> carl.muel...@smartthings.com>
> wrote:
>
> > Since this is basically driver syntactic sugar... Yes I'll try that.
> >
> >
> > On Wed, Mar 14, 2018 at 5:59 PM, Jonathan Haddad 
> > wrote:
> >
> > > You could use a load balancing policy at the driver level to do what
> you
> > > want, mixed with the existing consistency levels as Jeff suggested.
> > >
> > > On Wed, Mar 14, 2018 at 3:47 PM Carl Mueller <
> > carl.muel...@smartthings.com
> > > >
> > > wrote:
> > >
> > > > But we COULD have CL2 write (for RF4)
> > > >
> > > > The extension to this idea is multiple backup/secondary replicas. So
> > you
> > > > have RF5 or RF6 or higher, but still are performing CL2 against the
> > > > preferred first three for both read and write.
> > > >
> > > > You could also ascertain the general write health of affected ranges
> > > before
> > > > taking a node down for maintenance from the primary, and then know
> the
> > > > switchover is in good shape. Yes there are CAP limits and race
> > conditions
> > > > there, but you could get pretty good assurances (all repaired,
> low/zero
> > > > queued hinted handoffs, etc).
> > > >
> > > > This is essentially like if you had two datacenters, but are doing
> > > > local_quorum on the one datacenter. Well, except switchover is a bit
> > more
> > > > granular if you run out of replicas in the local.
> > > >
> > > >
> > > >
> > > > On Wed, Mar 14, 2018 at 5:17 PM, Jeff Jirsa 
> wrote:
> > > >
> > > > > Write at CL 3 and read at CL 2
> > > > >
> > > > > --
> > > > > Jeff Jirsa
> > > > >
> > > > >
> > > > > > On Mar 14, 2018, at 2:40 PM, Carl Mueller <
> > > > carl.muel...@smartthings.com>
> > > > > wrote:
> > > > > >
> > > > > > Currently there is little use for RF4. You're getting the
> > > requirements
> > > > of
> > > > > > QUORUM-3 but only one extra backup.
> > > > > >
> > > > > > I'd like to propose something that would make RF4 a sort of more
> > > > heavily
> > > > > > backed up RF3.
> > > > > >
> > > > > > A lot of this is probably achievable with strictly driver-level
> > > logic,
> > > > so
> > > > > > perhaps it would belong more there.
> > > > > >
> > > > > > Basically the idea is to have four replicas of the data, but only
> > > have
> > > > to
> > > > > > practically do QUORUM with three nodes. We consider the first
> three
> > > > > > replicas the "primary replicas". On an ongoing basis for QUORUM
> > reads
> > > > and
> > > > > > writes, we would rely on only those three replicas to satisfy
> > > > > > two-out-of-three QUORUM. Writes are persisted to the fourth
> replica
> > > in
> > > > > the
> > > > > > normal manner of cassandra, it just doesn't count towards the
> > QUORUM
> > > > > write.
> > > > > >
> > > > > > On reads, with token and node health awareness by the driver, if
> > the
> > > > > > primaries are all healthy, two-of-three QUORUM is calculated from
> > > > those.
> > > > > >
> > > > > > If however one of the three primaries is down, read QUORUM is a
> bit
> > > > > > different:
> > > > > > 1) if the first two replies come from the two remaining primaries
> > and
> > > > > > agree, the is returned
> > > > > > 2) if the first two replies are a primary and the "hot spare" and
> > > those
> > > > > > agree, that is returned
> > > > > > 3) if the primary and hot spare disagree, wait for the next
> 

RE: NVIDIA TESLA: The World's Most Advance Data Center GPU's for accelerating demanding HPC workloads

[Kenneth Brotman]

It's off topic if there aren't any C* uses but I wasn't (still not sure) there 
aren't. Maybe you're missing out.

-Original Message-
From: Jason Brown [mailto:jasedbr...@gmail.com] 
Sent: Thursday, March 15, 2018 10:26 AM
To: dev@cassandra.apache.org
Subject: Re: NVIDIA TESLA: The World's Most Advance Data Center GPU's for 
accelerating demanding HPC workloads

All,

This is completely OFF-TOPIC for this mailing list. Please stop.

-Jason

On Thu, Mar 15, 2018 at 10:09 AM, daemeon reiydelle 
wrote:

> Not so sure they are C* relevant, I build (100's of GPU enabled node) 
> HPC's that use them for ML, AI, Graph analytics, etc. with the sources 
> in C* or more typically Hadoop/EMR data.
>
>
> <==>
> "Who do you think made the first stone spear? The Asperger guy.
> If you get rid of the autism genetics, there would be no Silicon Valley"
> Temple Grandin
>
>
> *Daemeon C.M. ReiydelleSan Francisco 1.415.501.0198London 44 020 8144 
> 9872*
>
>
> On Thu, Mar 15, 2018 at 8:40 AM, Kenneth Brotman < 
> kenbrot...@yahoo.com.invalid> wrote:
>
> > I see things like this
> > https://www.nvidia.com/en-us/data-center/tesla/#section3 as 
> > something I might be using in things I help build.  Does anyone have 
> > any experience with them?
> >
> >
> >
> > Kenneth Brotman
> >
> >
>


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

Re: NVIDIA TESLA: The World's Most Advance Data Center GPU's for accelerating demanding HPC workloads

[Jason Brown]

All,

This is completely OFF-TOPIC for this mailing list. Please stop.

-Jason

On Thu, Mar 15, 2018 at 10:09 AM, daemeon reiydelle 
wrote:

> Not so sure they are C* relevant, I build (100's of GPU enabled node) HPC's
> that use them for ML, AI, Graph analytics, etc. with the sources in C* or
> more typically Hadoop/EMR data.
>
>
> <==>
> "Who do you think made the first stone spear? The Asperger guy.
> If you get rid of the autism genetics, there would be no Silicon Valley"
> Temple Grandin
>
>
> *Daemeon C.M. ReiydelleSan Francisco 1.415.501.0198London 44 020 8144 9872*
>
>
> On Thu, Mar 15, 2018 at 8:40 AM, Kenneth Brotman <
> kenbrot...@yahoo.com.invalid> wrote:
>
> > I see things like this
> > https://www.nvidia.com/en-us/data-center/tesla/#section3 as something I
> > might be using in things I help build.  Does anyone have any experience
> > with
> > them?
> >
> >
> >
> > Kenneth Brotman
> >
> >
>

Re: NVIDIA TESLA: The World's Most Advance Data Center GPU's for accelerating demanding HPC workloads

[daemeon reiydelle]

Not so sure they are C* relevant, I build (100's of GPU enabled node) HPC's
that use them for ML, AI, Graph analytics, etc. with the sources in C* or
more typically Hadoop/EMR data.


<==>
"Who do you think made the first stone spear? The Asperger guy.
If you get rid of the autism genetics, there would be no Silicon Valley"
Temple Grandin


*Daemeon C.M. ReiydelleSan Francisco 1.415.501.0198London 44 020 8144 9872*


On Thu, Mar 15, 2018 at 8:40 AM, Kenneth Brotman <
kenbrot...@yahoo.com.invalid> wrote:

> I see things like this
> https://www.nvidia.com/en-us/data-center/tesla/#section3 as something I
> might be using in things I help build.  Does anyone have any experience
> with
> them?
>
>
>
> Kenneth Brotman
>
>

RE: A JIRA proposing a seperate repository for the online documentation

[Kenneth Brotman]

Well pickle my cucumbers Jon!  It's good to know that you have experience with 
Hugo, see it as a good fit and that all has been well.  I look forward to the 
jira epic!  

How exactly does the group make such a decision:  Call for final discussion?  
Call for vote?  Wait for the PMC to vote?  

Kenneth Brotman

-Original Message-
From: Jon Haddad [mailto:jonathan.had...@gmail.com] On Behalf Of Jon Haddad
Sent: Thursday, March 15, 2018 9:24 AM
To: dev@cassandra.apache.org
Subject: Re: A JIRA proposing a seperate repository for the online documentation

Murukesh is correct on a very useable, pretty standard process of 
multi-versioned docs.

I’ll put my thoughts in a JIRA epic tonight.  I’ll be a multi-phase process.  
Also correct in that I’d like us to move to Hugo for the site, I’d like us to 
have a unified system between the site & the docs, and hugo has been excellent. 
We run the reaper site & docs off hugo, it works well.  We just don’t do 
multi-versions (because we don’t support multiple): 
https://github.com/thelastpickle/cassandra-reaper/tree/master/src/docs 
. 

Jon

> On Mar 15, 2018, at 8:57 AM, Murukesh Mohanan  
> wrote:
> 
> On Fri, Mar 16, 2018 at 0:19 Kenneth Brotman 
> >
> wrote:
> 
>> Help me out here.  I could have had a website with support for more 
>> than one version done several different ways by now.
>> 
>> A website with several versions of documentation is going to have 
>> sub-directories for each version of documentation obviously.  I've 
>> offered to create those sub-directories under the "doc" folder of the 
>> current repository; and I've offered to move the online documentation 
>> to a separate repository and have the sub-directories there.  Both 
>> were shot down.  Is there a third way?  If so please just spill the beans.
>> 
> 
> There is. Note that the website is an independent repository. So to 
> host docs for multiple versions, only the website's repository (or 
> rather, the final built contents) needs multiple directories. You can 
> just checkout each branch or tag, generate the docs, make a directory 
> for that branch or tag in the website repo, and copy the generated 
> docs there with appropriate modifications.
> 
> I do this on a smaller scale using GitHub Pages (repo:
> https://github.com/murukeshm/cassandra 
>  site:
> https://murukeshm.github.io/cassandra/ 
> 
>  > ). The method is a 
> bit hacky as I noted in CASSANDRA-13907. A daily cronjobs updated the repo if 
> docs are updated. 3.9+ versions are available.
> 
> 
> 
> 
>> Also, no offense to anyone at Sphinx but for a project our size it's 
>> not suitable.  We need to move off it now.  It's a problem.
>> 
>> Can we go past this and on to the documenting!  Please help resolve this.
>> 
>> How are we going to:
>> Make the submission of code changes include required changes to 
>> documentation including the online documentation?
>> Allow, encourage the online documentation to publish multiple 
>> versions of documentation concurrently including all officially supported 
>> versions?
> 
> 
> Only on this point: we'll need to start by improving the website build 
> process. Michael's comment on 13907 (
> https://issues.apache.org/jira/browse/CASSANDRA-13907?focusedCommentId
> =16211365=com.atlassian.jira.plugin.system.issuetabpanels:comment
> -tabpanel#comment-16211365 
>  d=16211365=com.atlassian.jira.plugin.system.issuetabpanels:commen
> t-tabpanel#comment-16211365>
> )
> shows it's a painful, fiddly process. That seems to be the main 
> blocker. I think Jon has shown interest in moving to Hugo from the 
> current Jekyll setup.
> 
> 
> 
>> Move our project onto a more suitable program than Sphinx for our needs?
>> 
>> Kenneth Brotman
>> 
>> -Original Message-
>> From: Eric Evans [mailto:john.eric.ev...@gmail.com]
>> Sent: Thursday, March 15, 2018 7:50 AM
>> To: dev@cassandra.apache.org
>> Subject: Re: A JIRA proposing a seperate repository for the online 
>> documentation
>> 
>> On Thu, Mar 15, 2018 at 4:58 AM, Rahul Singh 
>> 
>> wrote:
>>> 
>>> I don’t understand why it’s so complicated. In tree docs are as good 
>>> as
>> any. All the old docs are there in the version control system.
>>> 
>>> All we need to is a) generate docs for old versions b) improve user
>> experience on the site by having it clearly laid out what is latest 
>> vs. old docs and c) have some semblance of a search maybe using 
>> something like Algolia or whatever.
>> 
>> This.
>> 
>> Keeping the docs in-tree is a huge win, because they can move in 
>> lock-step with 

Re: A JIRA proposing a seperate repository for the online documentation

[Jon Haddad]

Murukesh is correct on a very useable, pretty standard process of 
multi-versioned docs.

I’ll put my thoughts in a JIRA epic tonight.  I’ll be a multi-phase process.  
Also correct in that I’d like us to move to Hugo for the site, I’d like us to 
have a unified system between the site & the docs, and hugo has been excellent. 
We run the reaper site & docs off hugo, it works well.  We just don’t do 
multi-versions (because we don’t support multiple): 
https://github.com/thelastpickle/cassandra-reaper/tree/master/src/docs 
. 

Jon

> On Mar 15, 2018, at 8:57 AM, Murukesh Mohanan  
> wrote:
> 
> On Fri, Mar 16, 2018 at 0:19 Kenneth Brotman  >
> wrote:
> 
>> Help me out here.  I could have had a website with support for more than
>> one version done several different ways by now.
>> 
>> A website with several versions of documentation is going to have
>> sub-directories for each version of documentation obviously.  I've offered
>> to create those sub-directories under the "doc" folder of the current
>> repository; and I've offered to move the online documentation to a separate
>> repository and have the sub-directories there.  Both were shot down.  Is
>> there a third way?  If so please just spill the beans.
>> 
> 
> There is. Note that the website is an independent repository. So to host
> docs for multiple versions, only the website's repository (or rather, the
> final built contents) needs multiple directories. You can just checkout
> each branch or tag, generate the docs, make a directory for that branch or
> tag in the website repo, and copy the generated docs there with appropriate
> modifications.
> 
> I do this on a smaller scale using GitHub Pages (repo:
> https://github.com/murukeshm/cassandra 
>  site:
> https://murukeshm.github.io/cassandra/ 
> 
>  > ). The method is a bit
> hacky as I noted in CASSANDRA-13907. A daily cronjobs updated the repo if
> docs are updated. 3.9+ versions are available.
> 
> 
> 
> 
>> Also, no offense to anyone at Sphinx but for a project our size it's not
>> suitable.  We need to move off it now.  It's a problem.
>> 
>> Can we go past this and on to the documenting!  Please help resolve this.
>> 
>> How are we going to:
>> Make the submission of code changes include required changes to
>> documentation including the online documentation?
>> Allow, encourage the online documentation to publish multiple versions of
>> documentation concurrently including all officially supported versions?
> 
> 
> Only on this point: we'll need to start by improving the website build
> process. Michael's comment on 13907 (
> https://issues.apache.org/jira/browse/CASSANDRA-13907?focusedCommentId=16211365=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-16211365
>  
> 
> )
> shows it's a painful, fiddly process. That seems to be the main blocker. I
> think Jon has shown interest in moving to Hugo from the current Jekyll
> setup.
> 
> 
> 
>> Move our project onto a more suitable program than Sphinx for our needs?
>> 
>> Kenneth Brotman
>> 
>> -Original Message-
>> From: Eric Evans [mailto:john.eric.ev...@gmail.com]
>> Sent: Thursday, March 15, 2018 7:50 AM
>> To: dev@cassandra.apache.org
>> Subject: Re: A JIRA proposing a seperate repository for the online
>> documentation
>> 
>> On Thu, Mar 15, 2018 at 4:58 AM, Rahul Singh 
>> wrote:
>>> 
>>> I don’t understand why it’s so complicated. In tree docs are as good as
>> any. All the old docs are there in the version control system.
>>> 
>>> All we need to is a) generate docs for old versions b) improve user
>> experience on the site by having it clearly laid out what is latest vs. old
>> docs and c) have some semblance of a search maybe using something like
>> Algolia or whatever.
>> 
>> This.
>> 
>> Keeping the docs in-tree is a huge win, because they can move in lock-step
>> with changes occurring in that branch/version.  I don't think we've been
>> enforcing this, but code-changes that alter documented behavior should be
>> accompanied by corresponding changes to the documentation, or be rejected.
>> Code-changes that correspond with undocumented behavior are an opportunity
>> to include some docs (not grounds to reject a code-review IMO, but
>> certainly an opportunity to politely ask/suggest).
>> 
>> Publishing more than one version (as generated from the respective
>> branches/tags), is a solvable problem.
>> 
 On Thu, Mar 15, 2018 at 1:22 Kenneth Brotman
 

Re: A JIRA proposing a seperate repository for the online documentation

[Murukesh Mohanan]

On Fri, Mar 16, 2018 at 0:19 Kenneth Brotman 
wrote:

> Help me out here.  I could have had a website with support for more than
> one version done several different ways by now.
>
> A website with several versions of documentation is going to have
> sub-directories for each version of documentation obviously.  I've offered
> to create those sub-directories under the "doc" folder of the current
> repository; and I've offered to move the online documentation to a separate
> repository and have the sub-directories there.  Both were shot down.  Is
> there a third way?  If so please just spill the beans.
>

There is. Note that the website is an independent repository. So to host
docs for multiple versions, only the website's repository (or rather, the
final built contents) needs multiple directories. You can just checkout
each branch or tag, generate the docs, make a directory for that branch or
tag in the website repo, and copy the generated docs there with appropriate
modifications.

I do this on a smaller scale using GitHub Pages (repo:
https://github.com/murukeshm/cassandra site:
https://murukeshm.github.io/cassandra/
 ). The method is a bit
hacky as I noted in CASSANDRA-13907. A daily cronjobs updated the repo if
docs are updated. 3.9+ versions are available.




> Also, no offense to anyone at Sphinx but for a project our size it's not
> suitable.  We need to move off it now.  It's a problem.
>
> Can we go past this and on to the documenting!  Please help resolve this.
>
> How are we going to:
> Make the submission of code changes include required changes to
> documentation including the online documentation?
> Allow, encourage the online documentation to publish multiple versions of
> documentation concurrently including all officially supported versions?


Only on this point: we'll need to start by improving the website build
process. Michael's comment on 13907 (
https://issues.apache.org/jira/browse/CASSANDRA-13907?focusedCommentId=16211365=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-16211365
)
shows it's a painful, fiddly process. That seems to be the main blocker. I
think Jon has shown interest in moving to Hugo from the current Jekyll
setup.



> Move our project onto a more suitable program than Sphinx for our needs?
>
> Kenneth Brotman
>
> -Original Message-
> From: Eric Evans [mailto:john.eric.ev...@gmail.com]
> Sent: Thursday, March 15, 2018 7:50 AM
> To: dev@cassandra.apache.org
> Subject: Re: A JIRA proposing a seperate repository for the online
> documentation
>
> On Thu, Mar 15, 2018 at 4:58 AM, Rahul Singh 
> wrote:
> >
> > I don’t understand why it’s so complicated. In tree docs are as good as
> any. All the old docs are there in the version control system.
> >
> > All we need to is a) generate docs for old versions b) improve user
> experience on the site by having it clearly laid out what is latest vs. old
> docs and c) have some semblance of a search maybe using something like
> Algolia or whatever.
>
> This.
>
> Keeping the docs in-tree is a huge win, because they can move in lock-step
> with changes occurring in that branch/version.  I don't think we've been
> enforcing this, but code-changes that alter documented behavior should be
> accompanied by corresponding changes to the documentation, or be rejected.
> Code-changes that correspond with undocumented behavior are an opportunity
> to include some docs (not grounds to reject a code-review IMO, but
> certainly an opportunity to politely ask/suggest).
>
> Publishing more than one version (as generated from the respective
> branches/tags), is a solvable problem.
>
> > > On Thu, Mar 15, 2018 at 1:22 Kenneth Brotman
> > >  > > wrote:
> > >
> > > > https://issues.apache.org/jira/browse/CASSANDRA-14313
> > > >
> > > >
> > > >
> > > > For some reason I'm told by many committers that we should not
> > > > have sets of documentation for other versions than the current
> > > > version in a tree for that version. This has made it difficult,
> > > > maybe impossible to have documentation for all the supported
> > > > versions on the website at one time.
> > > >
> > > >
> > > >
> > > > As a solution I propose that we maintain the online documentation
> > > > in a separate repository that is managed as the current repository
> > > > under the guidance of the Apache Cassandra PMC (Project Management
> > > > Committee); and that in the new repository . . .
> > > >
> > > >
> > > >
> > > > Please see the jira. I hope it's a good answer to everyone.
>
> --
> Eric Evans
> john.eric.ev...@gmail.com
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org
> For additional commands, e-mail: dev-h...@cassandra.apache.org
>
>
> -
> To 

NVIDIA TESLA: The World's Most Advance Data Center GPU's for accelerating demanding HPC workloads

[Kenneth Brotman]

I see things like this
https://www.nvidia.com/en-us/data-center/tesla/#section3 as something I
might be using in things I help build.  Does anyone have any experience with
them?  

 

Kenneth Brotman

RE: A JIRA proposing a seperate repository for the online documentation

[Kenneth Brotman]

Help me out here.  I could have had a website with support for more than one 
version done several different ways by now.  

A website with several versions of documentation is going to have 
sub-directories for each version of documentation obviously.  I've offered to 
create those sub-directories under the "doc" folder of the current repository; 
and I've offered to move the online documentation to a separate repository and 
have the sub-directories there.  Both were shot down.  Is there a third way?  
If so please just spill the beans.

Also, no offense to anyone at Sphinx but for a project our size it's not 
suitable.  We need to move off it now.  It's a problem.

Can we go past this and on to the documenting!  Please help resolve this.  

How are we going to:
Make the submission of code changes include required changes to documentation 
including the online documentation?
Allow, encourage the online documentation to publish multiple versions of 
documentation concurrently including all officially supported versions?
Move our project onto a more suitable program than Sphinx for our needs?

Kenneth Brotman

-Original Message-
From: Eric Evans [mailto:john.eric.ev...@gmail.com] 
Sent: Thursday, March 15, 2018 7:50 AM
To: dev@cassandra.apache.org
Subject: Re: A JIRA proposing a seperate repository for the online documentation

On Thu, Mar 15, 2018 at 4:58 AM, Rahul Singh  
wrote:
>
> I don’t understand why it’s so complicated. In tree docs are as good as any. 
> All the old docs are there in the version control system.
>
> All we need to is a) generate docs for old versions b) improve user 
> experience on the site by having it clearly laid out what is latest vs. old 
> docs and c) have some semblance of a search maybe using something like 
> Algolia or whatever.

This.

Keeping the docs in-tree is a huge win, because they can move in lock-step with 
changes occurring in that branch/version.  I don't think we've been enforcing 
this, but code-changes that alter documented behavior should be accompanied by 
corresponding changes to the documentation, or be rejected.  Code-changes that 
correspond with undocumented behavior are an opportunity to include some docs 
(not grounds to reject a code-review IMO, but certainly an opportunity to 
politely ask/suggest).

Publishing more than one version (as generated from the respective 
branches/tags), is a solvable problem.

> > On Thu, Mar 15, 2018 at 1:22 Kenneth Brotman 
> >  > wrote:
> >
> > > https://issues.apache.org/jira/browse/CASSANDRA-14313
> > >
> > >
> > >
> > > For some reason I'm told by many committers that we should not 
> > > have sets of documentation for other versions than the current 
> > > version in a tree for that version. This has made it difficult, 
> > > maybe impossible to have documentation for all the supported 
> > > versions on the website at one time.
> > >
> > >
> > >
> > > As a solution I propose that we maintain the online documentation 
> > > in a separate repository that is managed as the current repository 
> > > under the guidance of the Apache Cassandra PMC (Project Management 
> > > Committee); and that in the new repository . . .
> > >
> > >
> > >
> > > Please see the jira. I hope it's a good answer to everyone.

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

-
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: A JIRA proposing a seperate repository for the online documentation

[Eric Evans]

On Thu, Mar 15, 2018 at 4:58 AM, Rahul Singh
 wrote:
>
> I don’t understand why it’s so complicated. In tree docs are as good as any. 
> All the old docs are there in the version control system.
>
> All we need to is a) generate docs for old versions b) improve user 
> experience on the site by having it clearly laid out what is latest vs. old 
> docs. and c) have some semblance of a search maybe using something like 
> Algolia or whatever.

This.

Keeping the docs in-tree is a huge win, because they can move in
lock-step with changes occurring in that branch/version.  I don't
think we've been enforcing this, but code-changes that alter
documented behavior should be accompanied by corresponding changes to
the documentation, or be rejected.  Code-changes that correspond with
undocumented behavior are an opportunity to include some docs (not
grounds to reject a code-review IMO, but certainly an opportunity to
politely ask/suggest).

Publishing more than one version (as generated from the respective
branches/tags), is a solvable problem.

> > On Thu, Mar 15, 2018 at 1:22 Kenneth Brotman  > wrote:
> >
> > > https://issues.apache.org/jira/browse/CASSANDRA-14313
> > >
> > >
> > >
> > > For some reason I'm told by many committers that we should not have sets 
> > > of
> > > documentation for other versions than the current version in a tree for
> > > that
> > > version. This has made it difficult, maybe impossible to have
> > > documentation
> > > for all the supported versions on the website at one time.
> > >
> > >
> > >
> > > As a solution I propose that we maintain the online documentation in a
> > > separate repository that is managed as the current repository under the
> > > guidance of the Apache Cassandra PMC (Project Management Committee); and
> > > that in the new repository . . .
> > >
> > >
> > >
> > > Please see the jira. I hope it's a good answer to everyone.

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

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

Re: A JIRA proposing a seperate repository for the online documentation

[Rahul Singh]

I don’t understand why it’s so complicated. In tree docs are as good as any. 
All the old docs are there in the version control system.

All we need to is a) generate docs for old versions b) improve user experience 
on the site by having it clearly laid out what is latest vs. old docs. and c) 
have some semblance of a search maybe using something like Algolia or whatever.

--
Rahul Singh
rahul.si...@anant.us

Anant Corporation

On Mar 14, 2018, 7:58 PM -0400, Murukesh Mohanan , 
wrote:
> I think this was how it was in the dark ages, with the wiki and all. I
> believe the reason why they shifted to in-tree docs is that this way,
> people who make changes to the code are more likely to make the
> corresponding doc changes as well, and reviewers have it easier to ensure
> docs are updated with new patches. The wiki was often left behind the code.
> So I they will move back to an out-of-tree doc system again. The way
> Michael put it in CASSANDRA-13907, the main blocker behind having docs for
> multiple versions online is that it's a pain just to get the docs for trunk
> updated. Once the current site update process is improved, multiple
> versions can more easily be added.
>
>
> On Thu, Mar 15, 2018 at 1:22 Kenneth Brotman  wrote:
>
> > https://issues.apache.org/jira/browse/CASSANDRA-14313
> >
> >
> >
> > For some reason I'm told by many committers that we should not have sets of
> > documentation for other versions than the current version in a tree for
> > that
> > version. This has made it difficult, maybe impossible to have
> > documentation
> > for all the supported versions on the website at one time.
> >
> >
> >
> > As a solution I propose that we maintain the online documentation in a
> > separate repository that is managed as the current repository under the
> > guidance of the Apache Cassandra PMC (Project Management Committee); and
> > that in the new repository . . .
> >
> >
> >
> > Please see the jira. I hope it's a good answer to everyone.
> >
> >
> >
> > KennethBrotman
> >
> >
> >
> >
> >
> > --
>
> Murukesh Mohanan,
> Yahoo! Japan