Re: [DISCUSS] Cleaning up docs, completing CASSANDRA-16763

[Anthony Grasso]

Hi Stefan and Ekaterina,

First point to note is CASSANDRA-16763 is now closed. A big thank you to
Lorina Poland for converting the Cassandra documentation from
reStructuredText to AsciiDoc and to Mick Semb Wever for working over the
holiday period to get the ticket over the line! We are now at a point where
we can start documentation back-porting work thanks to those efforts.

I do like Stefan's idea of tagging tickets that had documentation changes
with a label like "need-docs-backported". As Ekaterina points out, if we
reopen old tickets, this would get confusing to people unfamiliar with the
documentation work going on. The alternative is to create a new ticket for
each old ticket. From a practical perspective, I think labelling and
reopening an old ticket is the lesser of two evils.

However, we should approach this from the point of view of any other
piece of work in the project. That is, consider the case where ticket
CASSANDRA-xyz had a committed patch, was resolved, but was later found to
have an issue due to the implementation of a feature that was later added.
Would we reopen it to fix the problem or would we open a new ticket? Do we
have project guidelines around this? I would think in this scenario a new
ticket would be created?

In anycase, I feel we need to resolve the issue on how to track the work
first before we figure out how to divide it up.

Kind regards,
Anthony

On Thu, 14 Oct 2021 at 02:57, Ekaterina Dimitrova 
wrote:

> Hey Stefan,
>
> Thank you for your support and spending the time to think about this.
>
> If I understand you correctly, you suggest reopening the old tickets to
> finish the docs, I have two concerns:
> - we might work a few times on one and the same doc until we bring it to
> the latest state instead of getting a doc to latest state at once. I think
> that’s what Anthony was trying to take care of in his approach, to save
> some time? No?
> - Reopening old tickets which primary goal is not the docs brings more
> confusion, in my opinion.
>
> Otherwise, I think we have a required field for Testing and docs but
> splitting those in two and being more diligent around that might be a good
> idea?
>
> Thanks again,
> Ekaterina
>
> On Wed, 13 Oct 2021 at 3:27, Stefan Miklosovic <
> stefan.mikloso...@instaclustr.com> wrote:
>
> > Hey,
> >
> > I got an idea how this might be simplified.
> >
> > Every commit in Cassandra repository belongs to a ticket (except
> > ninjas but they are irrelevant here).
> >
> > So if you look over the commits, what about looking at what Jira
> > ticket they belong to (this information is in each commit message) and
> > then go to that Jira and label that with "need-docs-backported" or
> > something like that?
> >
> > The idea here is that we can filter tickets like these and if we fix
> > it / backport it (under the same Jira ticket number), we will just
> > remove that label and the work is done if there are no tickets with
> > such label anymore.
> >
> > Hence we do not create any additional ticket at all, we may even
> > reopen tickets which are resolved now.
> >
> > Regards
> >
> > On Mon, 11 Oct 2021 at 01:06, Anthony Grasso 
> > wrote:
> > >
> > > Hi Stefan,
> > >
> > > I agree with your thoughts around grouping together changes touching a
> > > subsystem. This is exactly how I started doing the backporting work a
> few
> > > weeks ago. For example I started by looking at all the changes in the
> > > 'doc/source/architecture' folder of the rST docs, and back ported only
> > > those.
> > >
> > > I propose every subsection (child folder in doc/source/; e.g.
> > > 'architecture', 'configuration', 'cql') that has rST doc changes dating
> > > back to June 2020 has a ticket. Each ticket would list the commit
> hashes
> > > that need to be backported. For commit hashes that span multiple
> > > subsections we pick a single ticket for that hash to be done under.
> This
> > > will allow us to divide up the work fairly easily with minimal
> conflicts
> > > when merging.
> > >
> > > This process would need to be done for both Cassandra 3.11 and
> 4.0/trunk.
> > >
> > > We can use CASSANDRA-16761
> > >  as the
> umbrella
> > > ticket for these changes. This epic was opened to capture all the work
> > > related to migrating from the old website and rTS docs to the new
> website
> > > and AsciiDoc. It is the ideal location for the tickets which will
> capture
> > > the backporting work.
> > >
> > > Kind regards,
> > > Anthony
> > >
> > >
> > >
> > > On Sat, 9 Oct 2021 at 04:02, Ekaterina Dimitrova <
> e.dimitr...@gmail.com>
> > > wrote:
> > >
> > > > Hey Stefan,
> > > >
> > > > Thank you for your response.
> > > >
> > > > “If it was feasible to gather all related changes touching a
> subsystem
> > > > under one umbrella ticket, that would be very nice but I do not know
> > > > if that makes sense from your point of view (what workflow you
> have).”
> > > >
> > > > It is up to us to decide what 

Re: Issue while trying to run pytest command

[Francisco Guerrero]

Hi Manish,

I suspect this has to do with spaces (or special characters) in the 
cassandra-dir argument. Can you try again wrapping the path in quotes, for 
example:

pytest --cassandra-dir="/Users//cassandra"

Hope that helps.

- Francisco

On 2022/01/09 10:43:05 Manish G wrote:
> I am trying to run pytest command :
> 
> (dtest) manish.ghildiyal@MacBook-Pro-3 cassandra % pytest
> > --cassandra-dir=/Users/../cassandra
> 
> 
> But I get error as:
> 
> pytest: error: unrecognized arguments:
> > --cassandra-dir=/Users/./cassandra
> 
> 
> I have done initial installation following  this.
> 
> Do I need to do any more configuration?
> 
> Manish
> 

Re: Issue while trying to run pytest command

[Mick Semb Wever]

This works for me.

source ~/dtest/bin/activate
pytest --cassandra-dir=/Users/mick/src/apache/cassandra
jmx_test.py::TestJMX::test_netstats


What's the output of

pytest --help

Are you in the cassandra-dtest directory when running pytest?





On Sun, 9 Jan 2022 at 12:33, Manish G  wrote:
>
> Initial installation is done following 
> https://github.com/apache/cassandra-dtest#python-dependencies.
>
>
> On Sun, Jan 9, 2022 at 11:43 AM Manish G  wrote:
>>
>> I am trying to run pytest command :
>>
>>> (dtest) manish.ghildiyal@MacBook-Pro-3 cassandra % pytest 
>>> --cassandra-dir=/Users/../cassandra
>>
>>
>> But I get error as:
>>
>>> pytest: error: unrecognized arguments: 
>>> --cassandra-dir=/Users/./cassandra
>>
>>
>> I have done initial installation following  this.
>>
>> Do I need to do any more configuration?
>>
>> Manish

Re: Issue while trying to run pytest command

[Manish G]

Initial installation is done following
https://github.com/apache/cassandra-dtest#python-dependencies.


On Sun, Jan 9, 2022 at 11:43 AM Manish G 
wrote:

> I am trying to run pytest command :
>
> (dtest) manish.ghildiyal@MacBook-Pro-3 cassandra % pytest
>> --cassandra-dir=/Users/../cassandra
>
>
> But I get error as:
>
> pytest: error: unrecognized arguments:
>> --cassandra-dir=/Users/./cassandra
>
>
> I have done initial installation following  this.
>
> Do I need to do any more configuration?
>
> Manish
>

Issue while trying to run pytest command

[Manish G]

I am trying to run pytest command :

(dtest) manish.ghildiyal@MacBook-Pro-3 cassandra % pytest
> --cassandra-dir=/Users/../cassandra


But I get error as:

pytest: error: unrecognized arguments:
> --cassandra-dir=/Users/./cassandra


I have done initial installation following  this.

Do I need to do any more configuration?

Manish