Re: Update defaults for 4.0?

[Alex Ott]

In addition to these, maybe we could consider to change other as well? Like:

1. bump roles_validity_in_ms, permissions_validity_in_ms, and
   credentials_validity_in_ms as well - maybe at least to a minute, or 2. I
   have seen multiple times when authentication was failing under the heavy
   load because queries to system tables were timing out - with these
   defaults people may still have the possibility to get updates to
   roles/credentials faster when specifying _update_interval_ variants of
   these configurations.
2. change default snitch from SimpleSnitch to GossipingPropertyFileSnitch -
   we're anyway saying that SimpleSnitch is only appropriate for
   single-datacenter deployments, and for real production we need to use
   GossipingPropertyFileSnitch - why not to set it as default?


Jeremy Hanna  at "Wed, 22 Jan 2020 11:22:36 +1100" wrote:
 JH> I mentioned this in the contributor meeting as a topic to bring up on the 
list - should we
 JH> take the opportunity to update defaults for Cassandra 4.0?

 JH> The rationale is two-fold:
 JH> 1) There are best practices and tribal knowledge around certain properties 
where people
 JH> just know to update those properties immediately as a starting point.  If 
it's pretty much
 JH> a given that we set something as a starting point different than the 
current defaults, why
 JH> not make that the new default?
 JH> 2) We should align the defaults with what we test with.  There may be 
exceptions if we
 JH> have one-off tests but on the whole, we should be testing with defaults.

 JH> As a starting point, compaction throughput and number of vnodes seem like 
good candidates
 JH> but it would be great to get feedback for any others.

 JH> For compaction throughput 
(https://jira.apache.org/jira/browse/CASSANDRA-14902), I've made
 JH> a basic case on the ticket to default to 64 just as a starting point 
because the decision
 JH> for 16 was made when spinning disk was most common.  Hence most people I 
know change that
 JH> and I think without too much bikeshedding, 64 is a reasonable starting 
point.  A case
 JH> could be made that empirically the compaction throughput throttle may have 
less effect
 JH> than many people think, but I still think an updated default would make 
sense.

 JH> For number of vnodes, Michael Shuler made the point in the discussion that 
we already test
 JH> with 32, which is a far better number than the 256 default.  I know many 
new users that
 JH> just leave the 256 default and then discover later that it's better to go 
lower.  I think
 JH> 32 is a good balance.  One could go lower with the new algorithm but I 
think 32 is much
 JH> better than 256 without being too skewed, and it's what we currently test.

 JH> Jeff brought up a good point that we want to be careful with defaults 
since changing them
 JH> could come as an unpleasant surprise to people who don't explicitly set 
them.  As a
 JH> general rule, we should always update release notes to clearly state that 
a default has
 JH> changed.  For these two defaults in particular, I think it's safe.  For 
compaction
 JH> throughput I think a release not is sufficient in case they want to modify 
it.  For number
 JH> of vnodes, it won't affect existing deployments with data - it would be 
for new clusters,
 JH> which would honestly benefit from this anyway.

 JH> The other point is whether it's too late to go into 4.0.  For these two 
changes, I think
 JH> significant testing can still be done with these new defaults before 
release and I think
 JH> testing more explicitly with 32 vnodes in particular will give people more 
confidence in
 JH> the lower number with a wider array of testing (where we don't already use 
32 explicitly).

 JH> In summary, are people okay with considering updating these defaults and 
possibly others
 JH> in the alpha stage of a new major release?  Are there other properties to 
consider?

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



-- 
With best wishes,Alex Ott
Principal Architect, DataStax
http://datastax.com/

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

Re: Apache Cassandra Contributor Meeting

[Scott Andreas]

Patrick's added the recording and linked it via the wiki:
https://cwiki.apache.org/confluence/display/CASSANDRA/Apache+Cassandra+Contributor+Meeting

Here's a direct link:
https://www.youtube.com/watch?v=DprX7Y5v30M&feature=emb_logo

Thanks, Patrick!


From: Scott Andreas 
Sent: Tuesday, January 21, 2020 9:58 PM
To: dev@cassandra.apache.org
Cc: Jordan West
Subject: Re: Apache Cassandra Contributor Meeting

Hi Laxmikant,

Thanks for reaching out. The meeting was recorded; I think the video is being 
prepared now. Patrick can probably share a link when ready + uploaded.

Draft notes from the meeting are available here and will be migrated to 
Confluence shortly (likely tomorrow): 
https://docs.google.com/document/d/1Us7y1zgntklNgqcNBAK8bGWDUSb5BhB5MprOSl3500w/edit

– Scott

> On Jan 21, 2020, at 9:20 PM, Laxmikant Upadhyay  
> wrote:
>
> Please share the recording link if the meeting was recorded. Also could not
> find the MoM on shared confluence link.
>
> regards,
> Laxmikant
>
> On Tue, Jan 21, 2020 at 9:39 PM Scott Andreas  wrote:
>
>> Thanks Jordan!
>>
>> Added a couple more items as well:
>> – Call for volunteers to lead 4.0 quality tracks that need an owner
>> – 3.0 / 3.11 branch status
>>
>> 
>> From: Jordan West 
>> Sent: Monday, January 20, 2020 7:27 PM
>> To: dev@cassandra.apache.org
>> Subject: Re: Apache Cassandra Contributor Meeting
>>
>> Thanks Patrick. Looking forward to tomorrow’s meeting. I added an agenda
>> item around 4.0 — it’s not my intention to lead that section necessarily
>> but I think a check in / progress update / follow up on Josh’s email will
>> be good to cover.
>>
>> Jordan
>>
>> On Mon, Jan 13, 2020 at 6:11 PM Patrick McFadin 
>> wrote:
>>
>>> And I sent this without saying when. Let me save you a click on the
>>> confluence link.
>>>
>>> January 21, 1PM PST
>>>
>>> On Mon, Jan 13, 2020 at 5:28 PM Patrick McFadin 
>>> wrote:
>>>
 Hi everyone,

 In order to catch up on what's happening here, here's the establishing
 thread:

>>>
>> https://lists.apache.org/thread.html/aa54420a43671c00392978f2b0920bc6926ca9ba1e61a486ad39fb21%40%3Cdev.cassandra.apache.org%3E

 Key points that Scott Andreas proposed in the initial email was

 Motivation for such a meeting
 1. We currently have Slack, JIRA and emails however an agenda driven
>>> video
 meeting can help facilitate alignment within the community.
 2. This will give an opportunity to the community to summarize past
 progress and talk about future tasks.
 3. Agenda notes can serve as newsletters for the community.

 To that, I humbly offer my services as a community organizer to help
>> with
 the logistics and setup. I'm happy to say this is finally happening
>> and I
 apologize this has taken so long. I saw some of the examples mentioned
>> in
 the original thread for other open source projects and I "borrowed"
>>> heavily
 from them.

 I created a page in the Cassandra Confluence page to hopefully
>> centralize
 both logistics and records of each call. You can fine it here:

>>>
>> https://cwiki.apache.org/confluence/display/CASSANDRA/Apache+Cassandra+Contributor+Meeting

 The meetings are on Zoom and set to be wide open. Anyone can join via
 computer or phone. I'm using a tier that allows for 100 participants.
>> If
>>> we
 need more, I can change the type of meeting but it's more of a pain for
 logistics. We can try this and see how it goes. Once the meeting starts
 I'll hit record, I'll post the video on YouTube and add the link to the
 notes. All meeting notes for each agenda items can live in the doc
>> above
 and remain as a permanent record. After the meeting, I'll send the
>> notes
 link to the dev list as a reminder that it happened to anyone
>> subscribed.

 If you have agenda items, please edit the Confluence page and add your
 name and what you would like discussed.

 My contribution here is as an organizer. Please feel free to email or
 Slack if you need anything. Most important, a video meet is an alpha
 product and we'll learn a lot from the first time trying. I'll try to
>>> keep
 note of things to improve in the doc.

 See you there,

 Patrick

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


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

[DISCUSS] Switch to using GitHub pull requests?

[David Capwell]

When submitting or reviewing a change in JIRA I notice that we have three
main patterns for doing this: link branch, link diff, and link GitHub pull
request (PR); I wanted to bring up the idea of switching over to GitHub
pull requests as the norm.


Why should we do this?  The main reasons I can think of are: consistency
within the project, common pattern outside and inside Apache (not a new
process for new members to learn),

PRs are easier to review and comment on (much easier than linking lines in
a branch), Github and JIRA integration is already present so all
conversations will be added to the JIRA work log, and could be linked with
Jenkins to trigger builds and tests and to report the status into JIRA.


How would one start to do this?



   1. Include the JIRA link in a commit message (example:
   CASSANDRA- : message)
   2. Create pull request (when creating the branch, the git message
   provides a link to create a pull request)


That is it, by doing those two steps JIRA will be updated with all Github
conversations, Jenkins could be notified and start building and report back
to JIRA.


Thoughts?


References:

   - https://www.apache.org/dev/svngit2jira.html

Re: [DISCUSS] Switch to using GitHub pull requests?

[Benedict Elliott Smith]

This is brought up roughly once per year.  If anything, you're a bit behind 
schedule

https://lists.apache.org/thread.html/0750a01682eb36374e490385d6776669ac86ebc02efa27a87b2dbf9f%40%3Cdev.cassandra.apache.org%3E
https://lists.apache.org/thread.html/c21ccedc7fbda18558997dee8f86c074514b67387858ec1268c47685%40%3Cdev.cassandra.apache.org%3E
https://lists.apache.org/thread.html/d327a48b6644aecba8d48f31afcba4dff65d97946db2d622186c004f%40%3Cdev.cassandra.apache.org%3E


On 22/01/2020, 22:21, "David Capwell"  wrote:

When submitting or reviewing a change in JIRA I notice that we have three
main patterns for doing this: link branch, link diff, and link GitHub pull
request (PR); I wanted to bring up the idea of switching over to GitHub
pull requests as the norm.


Why should we do this?  The main reasons I can think of are: consistency
within the project, common pattern outside and inside Apache (not a new
process for new members to learn),

PRs are easier to review and comment on (much easier than linking lines in
a branch), Github and JIRA integration is already present so all
conversations will be added to the JIRA work log, and could be linked with
Jenkins to trigger builds and tests and to report the status into JIRA.


How would one start to do this?



   1. Include the JIRA link in a commit message (example:
   CASSANDRA- : message)
   2. Create pull request (when creating the branch, the git message
   provides a link to create a pull request)


That is it, by doing those two steps JIRA will be updated with all Github
conversations, Jenkins could be notified and start building and report back
to JIRA.


Thoughts?


References:

   - https://www.apache.org/dev/svngit2jira.html




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

Re: [DISCUSS] Switch to using GitHub pull requests?

[Dinesh Joshi]

I personally use Github PRs to discuss the changes if there is feedback on the 
code. The discussion does get linked with the JIRA ticket. However, committing 
is manual.

Dinesh

> On Jan 22, 2020, at 2:20 PM, David Capwell  wrote:
> 
> When submitting or reviewing a change in JIRA I notice that we have three
> main patterns for doing this: link branch, link diff, and link GitHub pull
> request (PR); I wanted to bring up the idea of switching over to GitHub
> pull requests as the norm.
> 
> 
> Why should we do this?  The main reasons I can think of are: consistency
> within the project, common pattern outside and inside Apache (not a new
> process for new members to learn),
> 
> PRs are easier to review and comment on (much easier than linking lines in
> a branch), Github and JIRA integration is already present so all
> conversations will be added to the JIRA work log, and could be linked with
> Jenkins to trigger builds and tests and to report the status into JIRA.
> 
> 
> How would one start to do this?
> 
> 
> 
>   1. Include the JIRA link in a commit message (example:
>   CASSANDRA- : message)
>   2. Create pull request (when creating the branch, the git message
>   provides a link to create a pull request)
> 
> 
> That is it, by doing those two steps JIRA will be updated with all Github
> conversations, Jenkins could be notified and start building and report back
> to JIRA.
> 
> 
> Thoughts?
> 
> 
> References:
> 
>   - https://www.apache.org/dev/svngit2jira.html


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

Re: [DISCUSS] Switch to using GitHub pull requests?

[David Capwell]

Thanks for the links Benedict!

Been reading the links and see the following points being made

*) enabling the spark process would lower the process to enter the project
*) high level discussions should be in JIRA [1]
*) not desirable to annotation JIRA and Github; should only annotate JIRA
(reviewer, labels, etc.)
*) given the multi branch nature, pull requires are not intuitive [2]
*) merging is problematic and should keep the current merge process
*) commits@ is not usable with PRs
*) commits@ is better because of PRs
*) people are more willing to nit-pick with PRs, less likely with current
process [3]
*) opens potential to "prevent commits that don't pass the tests" [4]
*) prefer the current process
http://cassandra.apache.org/doc/latest/development/patches.html [5]
*) current process is annoying since you have to take the link in github
and attach to JIRA for each comment in review
*) missed notifications, more trust in commits@
*) if someone rewrites history, comments could be hard to see
*) its better to leave comments in the source code so people don't need to
lookup github

Here is how i see some of the points

1) I agree with the point that the high level discussions should be in
JIRA; PRs are better at specific review and offer no real benefit over JIRA
for larger structural changes
2) there are different patterns with multiple branches as well, but some of
it is possible to codify and include in CI.  For example, you could take
the diff, attempt to apply to 2.2 (maybe if [dtest] in commit?) and forward
merge; of any conflicts are found, could annotate JIRA that the change is
complex and may be best to submit multiple PRs.  Assuming we want something
like this, it is also possible to run the tests against those branches as
well.  I am not saying we do this, but saying that it is possible to
improve or solve this problem, so doesn't appear a blocker to me.
3) by marking it easier to comment i can definitely see this happen, but
don't see this as a reason not to.  I find that you are more willing to
actually talk about small sections of the code in PR than in other forms
and that its easier to track.  One of the things i see now is that the
conversation moves to slack, so is it better not happening, happening in
slack, or happening in github?
4) This is actually why i started this thread.  I created a patch a while
back that passed review, got merged, and has been failing the build ever
since.  I would like to make it more clear that code is likely to do this
or not.
5) The link documents the process as submitting patches generate by "git
format-patch", which i was told not to do my first patch

Think i summarized all I saw.

On Wed, Jan 22, 2020 at 2:30 PM Dinesh Joshi  wrote:

> I personally use Github PRs to discuss the changes if there is feedback on
> the code. The discussion does get linked with the JIRA ticket. However,
> committing is manual.
>
> Dinesh
>
> > On Jan 22, 2020, at 2:20 PM, David Capwell  wrote:
> >
> > When submitting or reviewing a change in JIRA I notice that we have three
> > main patterns for doing this: link branch, link diff, and link GitHub
> pull
> > request (PR); I wanted to bring up the idea of switching over to GitHub
> > pull requests as the norm.
> >
> >
> > Why should we do this?  The main reasons I can think of are: consistency
> > within the project, common pattern outside and inside Apache (not a new
> > process for new members to learn),
> >
> > PRs are easier to review and comment on (much easier than linking lines
> in
> > a branch), Github and JIRA integration is already present so all
> > conversations will be added to the JIRA work log, and could be linked
> with
> > Jenkins to trigger builds and tests and to report the status into JIRA.
> >
> >
> > How would one start to do this?
> >
> >
> >
> >   1. Include the JIRA link in a commit message (example:
> >   CASSANDRA- : message)
> >   2. Create pull request (when creating the branch, the git message
> >   provides a link to create a pull request)
> >
> >
> > That is it, by doing those two steps JIRA will be updated with all Github
> > conversations, Jenkins could be notified and start building and report
> back
> > to JIRA.
> >
> >
> > Thoughts?
> >
> >
> > References:
> >
> >   - https://www.apache.org/dev/svngit2jira.html
>
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org
> For additional commands, e-mail: dev-h...@cassandra.apache.org
>
>

Re: [DISCUSS] Switch to using GitHub pull requests?

[Yifan Cai]

+1 nb to the PR approach for reviewing.


And thanks David for initiating the discussion. I would like to put my 2
cents in it.


IMO, reviews comments are better associated with the changes, precisely to
the line level, if they are put in the PR rather than in the JIRA comments.
Discussions regarding each review comments are naturally organized into
this own dedicated thread. I agree that JIRA comments are more suitable for
high-level discussion regarding the design. But review comments in PR can
do a better job at code-level discussion.


Another benefit is to relief reviewers’ work. In the PR approach, we can
leverage the PR build step to perform an initial qualification. The actual
review can be deferred until the PR build passes. So reviewers are sure
that the change is good at certain level, i.e. it builds and the tests can
pass. Right now, contributors volunteer for providing the link to CI test
(however, one still needs to open the link to see the result).

On Wed, Jan 22, 2020 at 3:16 PM David Capwell  wrote:

> Thanks for the links Benedict!
>
> Been reading the links and see the following points being made
>
> *) enabling the spark process would lower the process to enter the project
> *) high level discussions should be in JIRA [1]
> *) not desirable to annotation JIRA and Github; should only annotate JIRA
> (reviewer, labels, etc.)
> *) given the multi branch nature, pull requires are not intuitive [2]
> *) merging is problematic and should keep the current merge process
> *) commits@ is not usable with PRs
> *) commits@ is better because of PRs
> *) people are more willing to nit-pick with PRs, less likely with current
> process [3]
> *) opens potential to "prevent commits that don't pass the tests" [4]
> *) prefer the current process
> http://cassandra.apache.org/doc/latest/development/patches.html [5]
> *) current process is annoying since you have to take the link in github
> and attach to JIRA for each comment in review
> *) missed notifications, more trust in commits@
> *) if someone rewrites history, comments could be hard to see
> *) its better to leave comments in the source code so people don't need to
> lookup github
>
> Here is how i see some of the points
>
> 1) I agree with the point that the high level discussions should be in
> JIRA; PRs are better at specific review and offer no real benefit over JIRA
> for larger structural changes
> 2) there are different patterns with multiple branches as well, but some of
> it is possible to codify and include in CI.  For example, you could take
> the diff, attempt to apply to 2.2 (maybe if [dtest] in commit?) and forward
> merge; of any conflicts are found, could annotate JIRA that the change is
> complex and may be best to submit multiple PRs.  Assuming we want something
> like this, it is also possible to run the tests against those branches as
> well.  I am not saying we do this, but saying that it is possible to
> improve or solve this problem, so doesn't appear a blocker to me.
> 3) by marking it easier to comment i can definitely see this happen, but
> don't see this as a reason not to.  I find that you are more willing to
> actually talk about small sections of the code in PR than in other forms
> and that its easier to track.  One of the things i see now is that the
> conversation moves to slack, so is it better not happening, happening in
> slack, or happening in github?
> 4) This is actually why i started this thread.  I created a patch a while
> back that passed review, got merged, and has been failing the build ever
> since.  I would like to make it more clear that code is likely to do this
> or not.
> 5) The link documents the process as submitting patches generate by "git
> format-patch", which i was told not to do my first patch
>
> Think i summarized all I saw.
>
> On Wed, Jan 22, 2020 at 2:30 PM Dinesh Joshi  wrote:
>
> > I personally use Github PRs to discuss the changes if there is feedback
> on
> > the code. The discussion does get linked with the JIRA ticket. However,
> > committing is manual.
> >
> > Dinesh
> >
> > > On Jan 22, 2020, at 2:20 PM, David Capwell  wrote:
> > >
> > > When submitting or reviewing a change in JIRA I notice that we have
> three
> > > main patterns for doing this: link branch, link diff, and link GitHub
> > pull
> > > request (PR); I wanted to bring up the idea of switching over to GitHub
> > > pull requests as the norm.
> > >
> > >
> > > Why should we do this?  The main reasons I can think of are:
> consistency
> > > within the project, common pattern outside and inside Apache (not a new
> > > process for new members to learn),
> > >
> > > PRs are easier to review and comment on (much easier than linking lines
> > in
> > > a branch), Github and JIRA integration is already present so all
> > > conversations will be added to the JIRA work log, and could be linked
> > with
> > > Jenkins to trigger builds and tests and to report the status into JIRA.
> > >
> > >
> > > How would one start to do t

Contributor Meeting summary for 2020-01-21

[Patrick McFadin]

Hi everyone,

For a first time, things went amazingly smooth with Zoom and having a good
exchange and participation.

Scott already provided the link but I'll just offer up a quick summary from
the meeting notes and an easy reminder for those that volunteered for
something.

All notes and link to recorded video can be found here:
https://cwiki.apache.org/confluence/display/CASSANDRA/Apache+Cassandra+Contributor+Meeting

*Meeting Notes:*

The community and contributors remain focussed on the 4.0 release. There
was broad consensus that we want to keep working towards the 4.0 QA Test
Plan

and a call for contributors to sign up for major components. We also
touched on a number of other process discussions and agreed to take a few
discussions to the mailing list.

Action Items:

   - *All contributors:* please sign up as either shepherds or contributors
   on the test plan. If we want 4.0 to happen we must get at least minimal
   coverage of these areas.


   - Ahead of next call, review open tickets with “patch available” for
   Alpha and seek reviewers; for unassigned tickets, seek assignees or open
   discussion on scope.
   - Discuss on dev list:
  - Thread regarding when to branch for a post-4.0 release.
  - Cadence of meeting: Consensus on call was “once a month, at an
  earlier time to enable more from European time zones to join - likely
  rotating.”
  - Windows question: potentially a question to the user@ list if there
  are contributors willing to test / contribute patches for Windows.
  - Jeremy Hanna: Discuss changes to defaults prior to 4.0 release.
   - Patrick McFadin: Start discussion on dev list to settle time for next
   meetings and frequency.
   - Anthony raising need for Reaper compatibility testing to other Reaper
   contributors; will note compatibility issues identified (in case they
   warrant a change in C* itself).
   - Josh preparing JIRA epics that capture current headings in the
   Confluence “4.0 open issues” report.

I will start a separate thread about the time and frequency. Any general
feedback/suggestions about the logistics of the meeting can be done in this
thread.

Patrick

Re: [DISCUSS] Switch to using GitHub pull requests?

[J. D. Jordan]

Doesn’t this github review workflow as described work right now?  It’s just not 
the “only” way people do things?

I don’t think we need to forbid other methods of contribution as long as the 
review and testing needs are met.

-Jeremiah

> On Jan 22, 2020, at 6:35 PM, Yifan Cai  wrote:
> 
> +1 nb to the PR approach for reviewing.
> 
> 
> And thanks David for initiating the discussion. I would like to put my 2
> cents in it.
> 
> 
> IMO, reviews comments are better associated with the changes, precisely to
> the line level, if they are put in the PR rather than in the JIRA comments.
> Discussions regarding each review comments are naturally organized into
> this own dedicated thread. I agree that JIRA comments are more suitable for
> high-level discussion regarding the design. But review comments in PR can
> do a better job at code-level discussion.
> 
> 
> Another benefit is to relief reviewers’ work. In the PR approach, we can
> leverage the PR build step to perform an initial qualification. The actual
> review can be deferred until the PR build passes. So reviewers are sure
> that the change is good at certain level, i.e. it builds and the tests can
> pass. Right now, contributors volunteer for providing the link to CI test
> (however, one still needs to open the link to see the result).
> 
>> On Wed, Jan 22, 2020 at 3:16 PM David Capwell  wrote:
>> 
>> Thanks for the links Benedict!
>> 
>> Been reading the links and see the following points being made
>> 
>> *) enabling the spark process would lower the process to enter the project
>> *) high level discussions should be in JIRA [1]
>> *) not desirable to annotation JIRA and Github; should only annotate JIRA
>> (reviewer, labels, etc.)
>> *) given the multi branch nature, pull requires are not intuitive [2]
>> *) merging is problematic and should keep the current merge process
>> *) commits@ is not usable with PRs
>> *) commits@ is better because of PRs
>> *) people are more willing to nit-pick with PRs, less likely with current
>> process [3]
>> *) opens potential to "prevent commits that don't pass the tests" [4]
>> *) prefer the current process
>> http://cassandra.apache.org/doc/latest/development/patches.html [5]
>> *) current process is annoying since you have to take the link in github
>> and attach to JIRA for each comment in review
>> *) missed notifications, more trust in commits@
>> *) if someone rewrites history, comments could be hard to see
>> *) its better to leave comments in the source code so people don't need to
>> lookup github
>> 
>> Here is how i see some of the points
>> 
>> 1) I agree with the point that the high level discussions should be in
>> JIRA; PRs are better at specific review and offer no real benefit over JIRA
>> for larger structural changes
>> 2) there are different patterns with multiple branches as well, but some of
>> it is possible to codify and include in CI.  For example, you could take
>> the diff, attempt to apply to 2.2 (maybe if [dtest] in commit?) and forward
>> merge; of any conflicts are found, could annotate JIRA that the change is
>> complex and may be best to submit multiple PRs.  Assuming we want something
>> like this, it is also possible to run the tests against those branches as
>> well.  I am not saying we do this, but saying that it is possible to
>> improve or solve this problem, so doesn't appear a blocker to me.
>> 3) by marking it easier to comment i can definitely see this happen, but
>> don't see this as a reason not to.  I find that you are more willing to
>> actually talk about small sections of the code in PR than in other forms
>> and that its easier to track.  One of the things i see now is that the
>> conversation moves to slack, so is it better not happening, happening in
>> slack, or happening in github?
>> 4) This is actually why i started this thread.  I created a patch a while
>> back that passed review, got merged, and has been failing the build ever
>> since.  I would like to make it more clear that code is likely to do this
>> or not.
>> 5) The link documents the process as submitting patches generate by "git
>> format-patch", which i was told not to do my first patch
>> 
>> Think i summarized all I saw.
>> 
>>> On Wed, Jan 22, 2020 at 2:30 PM Dinesh Joshi  wrote:
>>> 
>>> I personally use Github PRs to discuss the changes if there is feedback
>> on
>>> the code. The discussion does get linked with the JIRA ticket. However,
>>> committing is manual.
>>> 
>>> Dinesh
>>> 
 On Jan 22, 2020, at 2:20 PM, David Capwell  wrote:
 
 When submitting or reviewing a change in JIRA I notice that we have
>> three
 main patterns for doing this: link branch, link diff, and link GitHub
>>> pull
 request (PR); I wanted to bring up the idea of switching over to GitHub
 pull requests as the norm.
 
 
 Why should we do this?  The main reasons I can think of are:
>> consistency
 within the project, common pattern outside and inside Apache (not a new
 pro

Re: Cassandra 4.0 Dev Work Status

[Jordan West]

Hi Everyone,

Josh is traveling this week so he sent me a brief summary and I offered to
send it to the mailing list w/ a few updates. There was enough progress in
the last week to warrant an update.

The 4.0 board can be found at
https://issues.apache.org/jira/secure/RapidBoard.jspa?rapidView=355. More
details below.

- *Progress*: We closed 8 more tickets this week for a rolling total of 26
(up from 18 in the last update) of 122 (up from 115 last week) across
4.0-alpha, 4.0-beta, and 4.0. Closed:
https://issues.apache.org/jira/issues/?jql=project%20%3D%20CASSANDRA%20AND%20fixversion%20in%20(4.0%2C%204.0.0%2C%204.0-alpha%2C%204.0-beta)%20AND%20resolved%20%3E%3D%20-4w

Total:
https://issues.apache.org/jira/issues/?filter=12347782

*LHF / Failing Tests*: 3 of the 6 failing tests now have an assignee. The
remaining 3 unassigned tickets can be found at
https://issues.apache.org/jira/secure/RapidBoard.jspa?rapidView=355&quickFilter=1660&quickFilter=1658

*Needs Reviewer*: 6 tickets need a reviewer. This is down from 10 last
week. They can be found at
https://issues.apache.org/jira/secure/RapidBoard.jspa?rapidView=355&quickFilter=1659

*Available to work*: 3 alpha (the remaining test failures), 4 beta, and 18
RC issues are unassigned. They can be found at
https://issues.apache.org/jira/secure/RapidBoard.jspa?rapidView=355&view=detail&selectedIssue=CASSANDRA-15308&quickFilter=1661&quickFilter=1658

*Ready to Commit*: 7 tickets are marked ready to commit. They can be found
at
https://issues.apache.org/jira/browse/CASSANDRA-15461?jql=project%20%3D%20CASSANDRA%20AND%20fixversion%20in%20(4.0%2C%204.0.0%2C%204.0-alpha%2C%204.0-beta)%20AND%20status%20%3D%20%22Ready%20to%20Commit%22%20


*Testing*:  On our 4.0 Quality and Test Plan Wiki (
https://cwiki.apache.org/confluence/display/CASSANDRA/4.0+Quality%3A+Components+and+Test+Plans
)
we have 5 remaining open Shepherd positions (down from 7 last week). 11
areas do not have a tracking ticket (down from 13 last week). 13 areas
remain not started.

Thanks everyone for your contributions! Its exciting to see this progress.

Jordan

On Wed, Jan 15, 2020 at 5:37 AM Benedict Elliott Smith 
wrote:

> Specifically, if anyone's interested, I think we should probably maintain
> three tags for work landing in 4.0, e.g. 4.0-alpha1, 4.0-alpha, 4.0
>
> This helps track all of the relevant information, the first limited
> release, the first general release, and the point in the release process it
> was delivered.
>
> On 15/01/2020, 13:34, "Benedict Elliott Smith" 
> wrote:
>
> I think there's always been a distinction in the way we treat
> alphas/betas versus patch releases, because they have a staged delivery
> (landing for dev and users in different releases).  I don't know we've ever
> been totally consistent about it across major versions though.
>
> I think we can view 4.0-alpha as equivalent to 4.x, except that it has
> value being maintained after commit, to historically track where things
> land in the release process.  It was discussed somewhere, not ages ago and
> I can't remember where, that there was value in this.  There's probably
> also value in introducing 4.0-alpha1 etc on top.
>
> We should probably decide and document it, as you say, so that we can
> at least be consistent next major.
>
>
> On 15/01/2020, 13:18, "Joshua McKenzie"  wrote:
>
> Historically I believe we used the ".x" nomenclature to indicate
> general
> release we wanted things in (4.x, 3.11.x, 3.6.x, etc), and then
> upon merge
> update the FixVersion to reflect which release it actually went
> in. Is that
> still a thing, and whether a thing or not, is the current
> appropriate usage
> of FixVersion on the project documented somewhere?
>
> On Wed, Jan 15, 2020 at 2:24 AM Scott Andreas <
> sc...@paradoxica.net> wrote:
>
> > Just realized I'd misunderstood Mick's original email, apologies.
> >
> > I'd originally interpreted it as a question of prioritization,
> but the
> > intent was to ensure that the Fix Version field reflects the
> release a
> > given change is /included in/, not /originally targeted for/.
> Apologies for
> > my misunderstanding.
> >
> > Agreed yes; it'd make sense to update recently-committed items
> that have a
> > future fix version to indicate they were resolved during alpha.
> I haven't
> > seen fix version refer to specific alpha releases (given that
> there's just
> > one at the m

Re: [DISCUSS] Switch to using GitHub pull requests?

[David Capwell]

Sorry Jeremiah, I don't understand your comment, would it be possible to
elaborate more?

About the point on not forbidding as long as the review and testing needs
are met, could you define what that means to you?

There are a few questions I ask myself

"Does the current process stop code which breaks the build from merging?"
And
"How long does it take for regressions to get noticed"

If I take myself as a example, I added a test which always failed in
CircleCI (I assume Jenkins as well), this got merged, and the jira to fix
it was around 3 months later.  I am personally trying to find ways to
detect issues faster, but also see that test fail frequently (unit, jvm
dtest, python dtest, etc.) so it's easy for this to slip through.

My mind set is that by switching to PRs (even if all the conversations are
in JIRA) we can setup automation which helps detect issues before merging.

On Wed, Jan 22, 2020, 7:00 PM J. D. Jordan 
wrote:

> Doesn’t this github review workflow as described work right now?  It’s
> just not the “only” way people do things?
>
> I don’t think we need to forbid other methods of contribution as long as
> the review and testing needs are met.
>
> -Jeremiah
>
> > On Jan 22, 2020, at 6:35 PM, Yifan Cai  wrote:
> >
> > +1 nb to the PR approach for reviewing.
> >
> >
> > And thanks David for initiating the discussion. I would like to put my 2
> > cents in it.
> >
> >
> > IMO, reviews comments are better associated with the changes, precisely
> to
> > the line level, if they are put in the PR rather than in the JIRA
> comments.
> > Discussions regarding each review comments are naturally organized into
> > this own dedicated thread. I agree that JIRA comments are more suitable
> for
> > high-level discussion regarding the design. But review comments in PR can
> > do a better job at code-level discussion.
> >
> >
> > Another benefit is to relief reviewers’ work. In the PR approach, we can
> > leverage the PR build step to perform an initial qualification. The
> actual
> > review can be deferred until the PR build passes. So reviewers are sure
> > that the change is good at certain level, i.e. it builds and the tests
> can
> > pass. Right now, contributors volunteer for providing the link to CI test
> > (however, one still needs to open the link to see the result).
> >
> >> On Wed, Jan 22, 2020 at 3:16 PM David Capwell 
> wrote:
> >>
> >> Thanks for the links Benedict!
> >>
> >> Been reading the links and see the following points being made
> >>
> >> *) enabling the spark process would lower the process to enter the
> project
> >> *) high level discussions should be in JIRA [1]
> >> *) not desirable to annotation JIRA and Github; should only annotate
> JIRA
> >> (reviewer, labels, etc.)
> >> *) given the multi branch nature, pull requires are not intuitive [2]
> >> *) merging is problematic and should keep the current merge process
> >> *) commits@ is not usable with PRs
> >> *) commits@ is better because of PRs
> >> *) people are more willing to nit-pick with PRs, less likely with
> current
> >> process [3]
> >> *) opens potential to "prevent commits that don't pass the tests" [4]
> >> *) prefer the current process
> >> http://cassandra.apache.org/doc/latest/development/patches.html [5]
> >> *) current process is annoying since you have to take the link in github
> >> and attach to JIRA for each comment in review
> >> *) missed notifications, more trust in commits@
> >> *) if someone rewrites history, comments could be hard to see
> >> *) its better to leave comments in the source code so people don't need
> to
> >> lookup github
> >>
> >> Here is how i see some of the points
> >>
> >> 1) I agree with the point that the high level discussions should be in
> >> JIRA; PRs are better at specific review and offer no real benefit over
> JIRA
> >> for larger structural changes
> >> 2) there are different patterns with multiple branches as well, but
> some of
> >> it is possible to codify and include in CI.  For example, you could take
> >> the diff, attempt to apply to 2.2 (maybe if [dtest] in commit?) and
> forward
> >> merge; of any conflicts are found, could annotate JIRA that the change
> is
> >> complex and may be best to submit multiple PRs.  Assuming we want
> something
> >> like this, it is also possible to run the tests against those branches
> as
> >> well.  I am not saying we do this, but saying that it is possible to
> >> improve or solve this problem, so doesn't appear a blocker to me.
> >> 3) by marking it easier to comment i can definitely see this happen, but
> >> don't see this as a reason not to.  I find that you are more willing to
> >> actually talk about small sections of the code in PR than in other forms
> >> and that its easier to track.  One of the things i see now is that the
> >> conversation moves to slack, so is it better not happening, happening in
> >> slack, or happening in github?
> >> 4) This is actually why i started this thread.  I created a patch a
> while
> >> ba

Re: Apache Cassandra Contributor Meeting

[Laxmikant Upadhyay]

Thanks for the update :)...It is difficult to join the meeting from India
due to timezone difference but will try to join some day.

On Thu, Jan 23, 2020 at 2:47 AM Scott Andreas  wrote:

> Patrick's added the recording and linked it via the wiki:
>
> https://cwiki.apache.org/confluence/display/CASSANDRA/Apache+Cassandra+Contributor+Meeting
>
> Here's a direct link:
> https://www.youtube.com/watch?v=DprX7Y5v30M&feature=emb_logo
>
> Thanks, Patrick!
>
> 
> From: Scott Andreas 
> Sent: Tuesday, January 21, 2020 9:58 PM
> To: dev@cassandra.apache.org
> Cc: Jordan West
> Subject: Re: Apache Cassandra Contributor Meeting
>
> Hi Laxmikant,
>
> Thanks for reaching out. The meeting was recorded; I think the video is
> being prepared now. Patrick can probably share a link when ready + uploaded.
>
> Draft notes from the meeting are available here and will be migrated to
> Confluence shortly (likely tomorrow):
> https://docs.google.com/document/d/1Us7y1zgntklNgqcNBAK8bGWDUSb5BhB5MprOSl3500w/edit
>
> – Scott
>
> > On Jan 21, 2020, at 9:20 PM, Laxmikant Upadhyay 
> wrote:
> >
> > Please share the recording link if the meeting was recorded. Also could
> not
> > find the MoM on shared confluence link.
> >
> > regards,
> > Laxmikant
> >
> > On Tue, Jan 21, 2020 at 9:39 PM Scott Andreas 
> wrote:
> >
> >> Thanks Jordan!
> >>
> >> Added a couple more items as well:
> >> – Call for volunteers to lead 4.0 quality tracks that need an owner
> >> – 3.0 / 3.11 branch status
> >>
> >> 
> >> From: Jordan West 
> >> Sent: Monday, January 20, 2020 7:27 PM
> >> To: dev@cassandra.apache.org
> >> Subject: Re: Apache Cassandra Contributor Meeting
> >>
> >> Thanks Patrick. Looking forward to tomorrow’s meeting. I added an agenda
> >> item around 4.0 — it’s not my intention to lead that section necessarily
> >> but I think a check in / progress update / follow up on Josh’s email
> will
> >> be good to cover.
> >>
> >> Jordan
> >>
> >> On Mon, Jan 13, 2020 at 6:11 PM Patrick McFadin 
> >> wrote:
> >>
> >>> And I sent this without saying when. Let me save you a click on the
> >>> confluence link.
> >>>
> >>> January 21, 1PM PST
> >>>
> >>> On Mon, Jan 13, 2020 at 5:28 PM Patrick McFadin 
> >>> wrote:
> >>>
>  Hi everyone,
> 
>  In order to catch up on what's happening here, here's the establishing
>  thread:
> 
> >>>
> >>
> https://lists.apache.org/thread.html/aa54420a43671c00392978f2b0920bc6926ca9ba1e61a486ad39fb21%40%3Cdev.cassandra.apache.org%3E
> 
>  Key points that Scott Andreas proposed in the initial email was
> 
>  Motivation for such a meeting
>  1. We currently have Slack, JIRA and emails however an agenda driven
> >>> video
>  meeting can help facilitate alignment within the community.
>  2. This will give an opportunity to the community to summarize past
>  progress and talk about future tasks.
>  3. Agenda notes can serve as newsletters for the community.
> 
>  To that, I humbly offer my services as a community organizer to help
> >> with
>  the logistics and setup. I'm happy to say this is finally happening
> >> and I
>  apologize this has taken so long. I saw some of the examples mentioned
> >> in
>  the original thread for other open source projects and I "borrowed"
> >>> heavily
>  from them.
> 
>  I created a page in the Cassandra Confluence page to hopefully
> >> centralize
>  both logistics and records of each call. You can fine it here:
> 
> >>>
> >>
> https://cwiki.apache.org/confluence/display/CASSANDRA/Apache+Cassandra+Contributor+Meeting
> 
>  The meetings are on Zoom and set to be wide open. Anyone can join via
>  computer or phone. I'm using a tier that allows for 100 participants.
> >> If
> >>> we
>  need more, I can change the type of meeting but it's more of a pain
> for
>  logistics. We can try this and see how it goes. Once the meeting
> starts
>  I'll hit record, I'll post the video on YouTube and add the link to
> the
>  notes. All meeting notes for each agenda items can live in the doc
> >> above
>  and remain as a permanent record. After the meeting, I'll send the
> >> notes
>  link to the dev list as a reminder that it happened to anyone
> >> subscribed.
> 
>  If you have agenda items, please edit the Confluence page and add your
>  name and what you would like discussed.
> 
>  My contribution here is as an organizer. Please feel free to email or
>  Slack if you need anything. Most important, a video meet is an alpha
>  product and we'll learn a lot from the first time trying. I'll try to
> >>> keep
>  note of things to improve in the doc.
> 
>  See you there,
> 
>  Patrick
> 
> >>>
> >>
> >> -
> >> To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org
> >> For additional