Using labels on pull requests in GitHub

[Stefan Miklosovic]

Hello,

Is somebody fundamentally opposing the idea of applying labels to pull
requests when applicable? I went through the pull requests and it
would be nice to have some basic filters, like "show me all pull
requests related to documentation" would be labeled as "docs", then
PRs fixing some tests would be "tests" and so on. We may further
narrow it down for subsystems etc.

I do not mind applying myself in this to tag the PRs as they come if
people do not tag it themselves in order to have at least some basic
"filterability". As I went through PRs closing already committed ones,
I noticed there are a lot of PRs related to documentation which just
tend to be completely forgotten in the long run.

Does this make sense to people?

Regards

Stefan

Re: Using labels on pull requests in GitHub

[Erick Ramirez]

+1 it's a great idea. I have to admit that I don't go through the PRs and I
only pay attention to tickets so if doc PRs are "orphans" (don't have
associated tickets), I don't ever work on them. I'll aim to do this when I
have bandwidth. Cheers! 🍻

On Wed, 16 Mar 2022 at 19:02, Stefan Miklosovic <
stefan.mikloso...@instaclustr.com> wrote:

> Hello,
>
> Is somebody fundamentally opposing the idea of applying labels to pull
> requests when applicable? I went through the pull requests and it
> would be nice to have some basic filters, like "show me all pull
> requests related to documentation" would be labeled as "docs", then
> PRs fixing some tests would be "tests" and so on. We may further
> narrow it down for subsystems etc.
>
> I do not mind applying myself in this to tag the PRs as they come if
> people do not tag it themselves in order to have at least some basic
> "filterability". As I went through PRs closing already committed ones,
> I noticed there are a lot of PRs related to documentation which just
> tend to be completely forgotten in the long run.
>
> Does this make sense to people?
>
> Regards
>
> Stefan
>

Re: Using labels on pull requests in GitHub

[Stefan Miklosovic]

Yeah, what I see quite frequently is that people come over, they open
PR but it does not have any related JIRA ticket and they just drop it
there and never return hence these PRs are in a constant limbo, not in
JIRA and they are more often than not left behind completely. Creating
categories would at least provide some minimal visibility where we are
at.

On Wed, 16 Mar 2022 at 09:07, Erick Ramirez  wrote:
>
> +1 it's a great idea. I have to admit that I don't go through the PRs and I 
> only pay attention to tickets so if doc PRs are "orphans" (don't have 
> associated tickets), I don't ever work on them. I'll aim to do this when I 
> have bandwidth. Cheers! 🍻
>
> On Wed, 16 Mar 2022 at 19:02, Stefan Miklosovic 
>  wrote:
>>
>> Hello,
>>
>> Is somebody fundamentally opposing the idea of applying labels to pull
>> requests when applicable? I went through the pull requests and it
>> would be nice to have some basic filters, like "show me all pull
>> requests related to documentation" would be labeled as "docs", then
>> PRs fixing some tests would be "tests" and so on. We may further
>> narrow it down for subsystems etc.
>>
>> I do not mind applying myself in this to tag the PRs as they come if
>> people do not tag it themselves in order to have at least some basic
>> "filterability". As I went through PRs closing already committed ones,
>> I noticed there are a lot of PRs related to documentation which just
>> tend to be completely forgotten in the long run.
>>
>> Does this make sense to people?
>>
>> Regards
>>
>> Stefan

Re: [FOR REVIEW] Blog post: An Interview with Project Contributor, Lorina Poland

[bened...@apache.org]

+1

From: Erick Ramirez 
Date: Tuesday, 15 March 2022 at 22:08
To: dev@cassandra.apache.org 
Subject: Re: [FOR REVIEW] Blog post: An Interview with Project Contributor, 
Lorina Poland
Looks good to me! 🍻

On Wed, 16 Mar 2022 at 08:17, Chris Thornett 
mailto:ch...@constantia.io>> wrote:
As requested, I'm posting content contributions for community review on the ML 
for those that might not spot them on Slack.

We're currently mid-review for our first contributor Q&A which is with Lorina 
Poland:
https://docs.google.com/document/d/1nnH4V1XvTcfTeeUdZ_mjSxlNlWTbSXFu_qKtJRQUFBk/edit.
 Please add edits or suggests as comments.

Thanks!
--

Chris Thornett
senior content strategist, Constantia.io
ch...@constantia.io

Re: Using labels on pull requests in GitHub

[bened...@apache.org]

Since PRs are a second class citizen to Jira, mostly used for a scratch pad for 
nits and questions with code context, I suspect any improvements here will need 
to be automated to have any hope of success.

From: Stefan Miklosovic 
Date: Wednesday, 16 March 2022 at 08:16
To: dev@cassandra.apache.org 
Subject: Re: Using labels on pull requests in GitHub
Yeah, what I see quite frequently is that people come over, they open
PR but it does not have any related JIRA ticket and they just drop it
there and never return hence these PRs are in a constant limbo, not in
JIRA and they are more often than not left behind completely. Creating
categories would at least provide some minimal visibility where we are
at.

On Wed, 16 Mar 2022 at 09:07, Erick Ramirez  wrote:
>
> +1 it's a great idea. I have to admit that I don't go through the PRs and I 
> only pay attention to tickets so if doc PRs are "orphans" (don't have 
> associated tickets), I don't ever work on them. I'll aim to do this when I 
> have bandwidth. Cheers! 🍻
>
> On Wed, 16 Mar 2022 at 19:02, Stefan Miklosovic 
>  wrote:
>>
>> Hello,
>>
>> Is somebody fundamentally opposing the idea of applying labels to pull
>> requests when applicable? I went through the pull requests and it
>> would be nice to have some basic filters, like "show me all pull
>> requests related to documentation" would be labeled as "docs", then
>> PRs fixing some tests would be "tests" and so on. We may further
>> narrow it down for subsystems etc.
>>
>> I do not mind applying myself in this to tag the PRs as they come if
>> people do not tag it themselves in order to have at least some basic
>> "filterability". As I went through PRs closing already committed ones,
>> I noticed there are a lot of PRs related to documentation which just
>> tend to be completely forgotten in the long run.
>>
>> Does this make sense to people?
>>
>> Regards
>>
>> Stefan

Re: Using labels on pull requests in GitHub

[Paulo Motta]

Thanks for doing this Stefan.

The fact that PRs are abandoned and piling up on github demonstrates a
hygiene problem and creates a bad user experience to newcomers which are
accustomed to the Github workflow. I'm supportive of any initiative to
improve this

I think starting labelling PRs manually and then looking into ways to
automate this would be a good improvement from the status quo.

Re: [FOR REVIEW] Blog post: An Interview with Project Contributor, Lorina Poland

[Anthony Grasso]

+1

On Wed, 16 Mar 2022 at 21:58, bened...@apache.org 
wrote:

> +1
>
>
>
> *From: *Erick Ramirez 
> *Date: *Tuesday, 15 March 2022 at 22:08
> *To: *dev@cassandra.apache.org 
> *Subject: *Re: [FOR REVIEW] Blog post: An Interview with Project
> Contributor, Lorina Poland
>
> Looks good to me! 🍻
>
>
>
> On Wed, 16 Mar 2022 at 08:17, Chris Thornett  wrote:
>
> As requested, I'm posting content contributions for community review on
> the ML for those that might not spot them on Slack.
>
>
>
> We're currently mid-review for our first contributor Q&A which is with
> Lorina Poland:
>
>
> https://docs.google.com/document/d/1nnH4V1XvTcfTeeUdZ_mjSxlNlWTbSXFu_qKtJRQUFBk/edit.
> Please add edits or suggests as comments.
>
>
>
> Thanks!
>
> --
>
>
>
> Chris Thornett
>
> senior content strategist, Constantia.io
>
> ch...@constantia.io
>
>

Re: [FOR REVIEW] Blog post: An Interview with Project Contributor, Lorina Poland

[Andrés de la Peña]

+1

On Wed, 16 Mar 2022 at 11:55, Anthony Grasso 
wrote:

> +1
>
> On Wed, 16 Mar 2022 at 21:58, bened...@apache.org 
> wrote:
>
>> +1
>>
>>
>>
>> *From: *Erick Ramirez 
>> *Date: *Tuesday, 15 March 2022 at 22:08
>> *To: *dev@cassandra.apache.org 
>> *Subject: *Re: [FOR REVIEW] Blog post: An Interview with Project
>> Contributor, Lorina Poland
>>
>> Looks good to me! 🍻
>>
>>
>>
>> On Wed, 16 Mar 2022 at 08:17, Chris Thornett  wrote:
>>
>> As requested, I'm posting content contributions for community review on
>> the ML for those that might not spot them on Slack.
>>
>>
>>
>> We're currently mid-review for our first contributor Q&A which is with
>> Lorina Poland:
>>
>>
>> https://docs.google.com/document/d/1nnH4V1XvTcfTeeUdZ_mjSxlNlWTbSXFu_qKtJRQUFBk/edit.
>> Please add edits or suggests as comments.
>>
>>
>>
>> Thanks!
>>
>> --
>>
>>
>>
>> Chris Thornett
>>
>> senior content strategist, Constantia.io
>>
>> ch...@constantia.io
>>
>>

Re: Using labels on pull requests in GitHub

[Josh McKenzie]

I think the fact that they pile up is because our merge strategy means we don't 
actually merge using the PR's we use for review so there's nothing codified in 
the workflow to close them out when a ticket's done.

An easy fix would be to change our merge strategy and use the merge button on 
PR's to merge things in so they auto-close. :)

(/grinding my axe)

On Wed, Mar 16, 2022, at 7:27 AM, Paulo Motta wrote:
> Thanks for doing this Stefan.
> 
> The fact that PRs are abandoned and piling up on github demonstrates a 
> hygiene problem and creates a bad user experience to newcomers which are 
> accustomed to the Github workflow. I'm supportive of any initiative to 
> improve this
> 
> I think starting labelling PRs manually and then looking into ways to 
> automate this would be a good improvement from the status quo.

Re: Using labels on pull requests in GitHub

[Erick Ramirez]

I confess, I'm guilty as charged. I use the git CLI for everything else but
use the merge button on the web UI for convenience. 🙂

Re: Using labels on pull requests in GitHub

[bened...@apache.org]

+1, let’s change our merge strategy 😊


From: Josh McKenzie 
Date: Wednesday, 16 March 2022 at 12:47
To: dev@cassandra.apache.org 
Subject: Re: Using labels on pull requests in GitHub
I think the fact that they pile up is because our merge strategy means we don't 
actually merge using the PR's we use for review so there's nothing codified in 
the workflow to close them out when a ticket's done.

An easy fix would be to change our merge strategy and use the merge button on 
PR's to merge things in so they auto-close. :)

(/grinding my axe)

On Wed, Mar 16, 2022, at 7:27 AM, Paulo Motta wrote:
Thanks for doing this Stefan.

The fact that PRs are abandoned and piling up on github demonstrates a hygiene 
problem and creates a bad user experience to newcomers which are accustomed to 
the Github workflow. I'm supportive of any initiative to improve this

I think starting labelling PRs manually and then looking into ways to automate 
this would be a good improvement from the status quo.

Re: [FOR REVIEW] Blog post: An Interview with Project Contributor, Lorina Poland

[Brandon Williams]

+1

Kind Regards,
Brandon

On Tue, Mar 15, 2022 at 4:17 PM Chris Thornett  wrote:
>
> As requested, I'm posting content contributions for community review on the 
> ML for those that might not spot them on Slack.
>
> We're currently mid-review for our first contributor Q&A which is with Lorina 
> Poland:
> https://docs.google.com/document/d/1nnH4V1XvTcfTeeUdZ_mjSxlNlWTbSXFu_qKtJRQUFBk/edit.
>  Please add edits or suggests as comments.
>
> Thanks!
> --
>
> Chris Thornett
> senior content strategist, Constantia.io
> ch...@constantia.io

Welcome Aleksandr Sorokoumov as Cassandra committer

[Benjamin Lerer]

 The PMC members are pleased to announce that Aleksandr Sorokoumov has
accepted
the invitation to become committer.

Thanks a lot, Aleksandr , for everything you have done for the project.

Congratulations and welcome

The Apache Cassandra PMC members

Re: Welcome Aleksandr Sorokoumov as Cassandra committer

[Paulo Motta]

Congratulations Alex, well deserved! :-)

Em qua., 16 de mar. de 2022 às 10:15, Benjamin Lerer 
escreveu:

> The PMC members are pleased to announce that Aleksandr Sorokoumov has
> accepted
> the invitation to become committer.
>
> Thanks a lot, Aleksandr , for everything you have done for the project.
>
> Congratulations and welcome
>
> The Apache Cassandra PMC members
>

Re: Welcome Aleksandr Sorokoumov as Cassandra committer

[Ekaterina Dimitrova]

Great news! Well deserved! Congrats and thank you for all your support!

On Wed, 16 Mar 2022 at 9:41, Paulo Motta  wrote:

> Congratulations Alex, well deserved! :-)
>
> Em qua., 16 de mar. de 2022 às 10:15, Benjamin Lerer 
> escreveu:
>
>> The PMC members are pleased to announce that Aleksandr Sorokoumov has
>> accepted
>> the invitation to become committer.
>>
>> Thanks a lot, Aleksandr , for everything you have done for the project.
>>
>> Congratulations and welcome
>>
>> The Apache Cassandra PMC members
>>
>

Re: Welcome Aleksandr Sorokoumov as Cassandra committer

[J. D. Jordan]

Congratulations!

> On Mar 16, 2022, at 8:43 AM, Ekaterina Dimitrova  
> wrote:
> 
> 
> Great news! Well deserved! Congrats and thank you for all your support!
> 
>> On Wed, 16 Mar 2022 at 9:41, Paulo Motta  wrote:
>> Congratulations Alex, well deserved! :-)
>> 
>>> Em qua., 16 de mar. de 2022 às 10:15, Benjamin Lerer  
>>> escreveu:
>>> The PMC members are pleased to announce that Aleksandr Sorokoumov has 
>>> accepted
>>> the invitation to become committer.
>>> 
>>> Thanks a lot, Aleksandr , for everything you have done for the project.
>>> 
>>> Congratulations and welcome
>>> 
>>> The Apache Cassandra PMC members

Re: Using labels on pull requests in GitHub

[Jeff Jirsa]

An easier fix here is just to put a close action into the commit message:

Closes #nnn

e.g.
https://github.com/apache/cassandra/commit/ad249424814836bd00f47931258ad58bfefb24fd
/ https://github.com/apache/cassandra/pull/1046

On Wed, Mar 16, 2022 at 5:40 AM Josh McKenzie  wrote:

> I think the fact that they pile up is because our merge strategy means we
> don't actually merge using the PR's we use for review so there's nothing
> codified in the workflow to close them out when a ticket's done.
>
> An easy fix would be to change our merge strategy and use the merge button
> on PR's to merge things in so they auto-close. :)
>
> (/grinding my axe)
>
> On Wed, Mar 16, 2022, at 7:27 AM, Paulo Motta wrote:
>
> Thanks for doing this Stefan.
>
> The fact that PRs are abandoned and piling up on github demonstrates a
> hygiene problem and creates a bad user experience to newcomers which are
> accustomed to the Github workflow. I'm supportive of any initiative to
> improve this
>
> I think starting labelling PRs manually and then looking into ways to
> automate this would be a good improvement from the status quo.
>
>
>

[Discuss] replacement of airlift/airline framework in CLI tools

[Tibor Répási]

In CASSANDRA-17445 we’ve started discussing the options of replacing the 
deprecated airlift/airline framework used in CLI tools.

Considering the amount of commands this framework is used in, the impact this 
might cause and the future possibilities the operational aspects of Cassandra 
could leverage, first comments at slack revealed an in-depth discussion would 
be desirable.

Kind request for comments.

Re: Welcome Aleksandr Sorokoumov as Cassandra committer

[Jasonstack Zhao Yang]

Congrats Aleks!

On Wed, 16 Mar 2022 at 22:01, J. D. Jordan 
wrote:

> Congratulations!
>
> On Mar 16, 2022, at 8:43 AM, Ekaterina Dimitrova 
> wrote:
>
> 
> Great news! Well deserved! Congrats and thank you for all your support!
>
> On Wed, 16 Mar 2022 at 9:41, Paulo Motta  wrote:
>
>> Congratulations Alex, well deserved! :-)
>>
>> Em qua., 16 de mar. de 2022 às 10:15, Benjamin Lerer 
>> escreveu:
>>
>>> The PMC members are pleased to announce that Aleksandr Sorokoumov has
>>> accepted
>>> the invitation to become committer.
>>>
>>> Thanks a lot, Aleksandr , for everything you have done for the project.
>>>
>>> Congratulations and welcome
>>>
>>> The Apache Cassandra PMC members
>>>
>>

Re: Welcome Aleksandr Sorokoumov as Cassandra committer

[Andrés de la Peña]

Congrats, well deserved!

On Wed, 16 Mar 2022 at 14:01, J. D. Jordan 
wrote:

> Congratulations!
>
> On Mar 16, 2022, at 8:43 AM, Ekaterina Dimitrova 
> wrote:
>
> 
> Great news! Well deserved! Congrats and thank you for all your support!
>
> On Wed, 16 Mar 2022 at 9:41, Paulo Motta  wrote:
>
>> Congratulations Alex, well deserved! :-)
>>
>> Em qua., 16 de mar. de 2022 às 10:15, Benjamin Lerer 
>> escreveu:
>>
>>> The PMC members are pleased to announce that Aleksandr Sorokoumov has
>>> accepted
>>> the invitation to become committer.
>>>
>>> Thanks a lot, Aleksandr , for everything you have done for the project.
>>>
>>> Congratulations and welcome
>>>
>>> The Apache Cassandra PMC members
>>>
>>

Re: [FOR REVIEW] Blog post: An Interview with Project Contributor, Lorina Poland

[Sharan Foga]

Hi Chris

+1

This looks really good. I added a few comments and suggestions so feel free to 
use what you think.

Thanks
Sharan

On 2022/03/15 21:16:34 Chris Thornett wrote:
> As requested, I'm posting content contributions for community review on the
> ML for those that might not spot them on Slack.
> 
> We're currently mid-review for our first contributor Q&A which is with
> Lorina Poland:
> https://docs.google.com/document/d/1nnH4V1XvTcfTeeUdZ_mjSxlNlWTbSXFu_qKtJRQUFBk/edit.
> Please add edits or suggests as comments.
> 
> Thanks!
> -- 
> 
> Chris Thornett
> senior content strategist, Constantia.io
> ch...@constantia.io
> 

Re: Performance Engineering Track at ApacheCon NA?

[Sharan Foga]

Hi Paulo

Thanks for the feedback. If we do get the track accepted then we will 
definitely be needing help reviewing the submissions - so may take you up on 
your offer :-)

Thanks
Sharan

On 2022/03/14 16:32:23 Paulo Motta wrote:
> This Apachecon track sounds fun! I hope someone from the Cassandra
> community steps up to help on this track.
> 
> I would be happy to help on reviews but not organize the event per se as I
> will likely not attend the event.
> 
> Em sex., 11 de mar. de 2022 às 09:26, sharanf  escreveu:
> 
> > Hi All
> >
> > The call for tracks for ApacheCon NA is open. There is a suggestion to
> > try and run a Performance Engineering track at ApacheCon this year. At
> > the end of the message I have included some details including a
> > definition of what we mean by it and some reasoning about why it could
> > be good to run. We have a list of projects that have something to do
> > with performance engineering and if you take a look -  you will see that
> > this project is on the list!
> >
> > So what I need is a some feedback as to whether the community thinks
> > that this could be an interesting track topic to run at ApacheCon..and
> > more importantly would the community be willing to submit talks for it
> > or attend ApacheCon to see it.
> >
> > Like I say - this is just an idea at this stage. If the Performance
> > Engineering track does get approval to be included at ApacheCon  - do we
> > have any volunteers willing to help with managing and promoting the
> > track on behalf of the project?
> >
> > Thanks
> > Sharan
> >
> > -
> >
> > *Performance Engineering*  is the science and practice of engineering
> > software with the required performance and scalability characteristics.
> > Many Apache projects focus on solving hard Big Data performance and
> > scalability challenges, while others provide tools for performance
> > engineering - but there are few projects that don’t care about some
> > aspect of software performance.
> >
> > This track will enable Apache projects members to share their
> > experiences of performance engineering best practices, tools,
> > techniques, and results, from their own communities, with the benefits
> > of cross-fertilization between projects. Performance Engineering in the
> > wider open source community is pervasive and includes methods and tools
> > (including automation and agile approaches) for performance:
> > architecting and design, benchmarking, monitoring, tracing, analysis,
> > prediction, modeling and simulation, testing and reporting, regression
> > testing, and source code analysis and instrumentation techniques.
> >
> > Performance Engineering also has wider applicability to DevOps, the
> > operation of cloud platforms by managed service providers (hence some
> > overlap with SRE - Site Reliability Engineering), and customer
> > application performance and tuning.  This track would therefore be
> > applicable to the wider open source community.
> >
> > *SUPPORTING DETAILS*
> >
> > *Google Searches*
> > Google “Open source performance engineering” has 4,180,000,000 results
> > Google “site:apache.org  performance” has 147,000
> > results
> >
> > *Apache Projects *which may have some interest in, or focus on,
> > performance (just the top results):
> > JMeter, Cassandra, Storm, Spark, Samza, Pulsar, Kafka, Log4J, SystemML,
> > Drill, HTTP Server, Cayenne, ActiveMQ, Impala, Geode, Flink, Ignite,
> > Impala, Lucene, TVM, Tika, YuniKorn, Solr, Iceberg, Dubbo, Hudi,
> > Accumulo, Xerces, MXNet, Zookeeper
> >
> > *Incubator projects *which may have some interest in, or focus on,
> > performance**(again just top results):
> > Crail, Eagle, Nemo, Skywalking, MXnet, HAWQ, Mnemonic, CarbonData,
> > Drill, ShenYu, Tephra, Sedona
> >
> > *References *(randomly selected to show the range of open-source
> > performance engineering topics available, rather than the quality of
> > articles):
> >
> >   1. Performance Engineering for Apache Spark and Databricks Runtime
> >  ETHZ, Big Data HS19
> >  <
> > https://archive-systems.ethz.ch/sites/default/files/courses/2019-fall/bigdata/Databricks%20ETHZ%20Big%20Data%20HS19.pdf
> > >
> >   2. Real time insights into LinkedIn's performance using Apache Samza
> >  <
> > https://engineering.linkedin.com/samza/real-time-insights-linkedins-performance-using-apache-samza
> > >
> >   3. A day in the life of an open source performance engineering team
> >  
> >   4. Locating Performance Regression Root Causes in the Field Operations
> >  ofWeb-based Systems:
> >  An Experience Report Published in: IEEE Transactions on Software
> >  Engineering (Early Access)
> >  
> >   5. How to Detect Performance Changes in Software History: Performance
> >  Analysis of Software System Versions
> >   

Re: Using labels on pull requests in GitHub

[Stefan Miklosovic]

So, I went through all pull requests we have on GitHub manually (yes,
I did that, never more!) and out of ~550 PRs I managed to reduce it to
188 so I closed around 400 PRs.

All remaining PRs are of this nature:

1) Every PR has a name of "CASSANDRA-XYZ - description" or there is a
ticket number in it so it is searchable on GH.
2) PR which does not have a ticket is labeled "missing-ticket"
3) PRs which are related to docs are labeled as docs, PRs related to
tests are labeled as "tests"
4) There are combinations of 2) and 3) so we can have, for example,
only PRs which are missing ticket and they are related to docs.

docs PRs: 
https://github.com/apache/cassandra/pulls?q=is%3Apr+is%3Aopen+label%3Adocs
missing tickets PRs:
https://github.com/apache/cassandra/pulls?q=is%3Apr+is%3Aopen+label%3Amissing-ticket
tests PRs: https://github.com/apache/cassandra/labels/tests

Out of 188 PRs open, there is 35 documentation related PRs and 54 PRs
are missing their tickets.

What I would like to do now is to go to documentation guys and it
would be awesome if they can go through documentation PRs and resolve
all of them, preferably in one big PRs to solve it all. It does not
make a lot of sense to deal with each minor thing separately. Then we
might deal with the PRs which are solely missing tickets separately.

How does this sound to you?

Regards,

Stefan

On Wed, 16 Mar 2022 at 15:02, Jeff Jirsa  wrote:
>
> An easier fix here is just to put a close action into the commit message:
>
> Closes #nnn
>
> e.g. 
> https://github.com/apache/cassandra/commit/ad249424814836bd00f47931258ad58bfefb24fd
>  / https://github.com/apache/cassandra/pull/1046
>
> On Wed, Mar 16, 2022 at 5:40 AM Josh McKenzie  wrote:
>>
>> I think the fact that they pile up is because our merge strategy means we 
>> don't actually merge using the PR's we use for review so there's nothing 
>> codified in the workflow to close them out when a ticket's done.
>>
>> An easy fix would be to change our merge strategy and use the merge button 
>> on PR's to merge things in so they auto-close. :)
>>
>> (/grinding my axe)
>>
>> On Wed, Mar 16, 2022, at 7:27 AM, Paulo Motta wrote:
>>
>> Thanks for doing this Stefan.
>>
>> The fact that PRs are abandoned and piling up on github demonstrates a 
>> hygiene problem and creates a bad user experience to newcomers which are 
>> accustomed to the Github workflow. I'm supportive of any initiative to 
>> improve this
>>
>> I think starting labelling PRs manually and then looking into ways to 
>> automate this would be a good improvement from the status quo.
>>
>>

Re: Using labels on pull requests in GitHub

[Erick Ramirez]

Sounds good to me. Thanks for doing all this work, Stefan. 🍻

Re: Using labels on pull requests in GitHub

[Yifan Cai]

Thank you Stefan for all the efforts!

Regarding the "merge strategy change", should we start a new thread?

I am +1 on adopting the merge button. It should work in the single branch
commit. Just the cross branch commit could be tricky.

- Yifan

Re: Welcome Aleksandr Sorokoumov as Cassandra committer

[Yifan Cai]

Congratulations Aleksandr!

On Wed, Mar 16, 2022 at 7:34 AM Andrés de la Peña 
wrote:

> Congrats, well deserved!
>
> On Wed, 16 Mar 2022 at 14:01, J. D. Jordan 
> wrote:
>
>> Congratulations!
>>
>> On Mar 16, 2022, at 8:43 AM, Ekaterina Dimitrova 
>> wrote:
>>
>> 
>> Great news! Well deserved! Congrats and thank you for all your support!
>>
>> On Wed, 16 Mar 2022 at 9:41, Paulo Motta  wrote:
>>
>>> Congratulations Alex, well deserved! :-)
>>>
>>> Em qua., 16 de mar. de 2022 às 10:15, Benjamin Lerer 
>>> escreveu:
>>>
 The PMC members are pleased to announce that Aleksandr Sorokoumov has
 accepted
 the invitation to become committer.

 Thanks a lot, Aleksandr , for everything you have done for the project.

 Congratulations and welcome

 The Apache Cassandra PMC members

>>>

Re: Welcome Aleksandr Sorokoumov as Cassandra committer

[Erick Ramirez]

Congratulations Aleksandr and welcome aboard! 🍻

On Thu, 17 Mar 2022 at 00:15, Benjamin Lerer  wrote:

> The PMC members are pleased to announce that Aleksandr Sorokoumov has
> accepted
> the invitation to become committer.
>
> Thanks a lot, Aleksandr , for everything you have done for the project.
>
> Congratulations and welcome
>
> The Apache Cassandra PMC members
>

Re: Welcome Aleksandr Sorokoumov as Cassandra committer

[Anthony Grasso]

Congratulations Aleksandr! Thank you for your work on the project.

On Thu, 17 Mar 2022 at 12:33, Erick Ramirez 
wrote:

> Congratulations Aleksandr and welcome aboard! 🍻
>
> On Thu, 17 Mar 2022 at 00:15, Benjamin Lerer  wrote:
>
>> The PMC members are pleased to announce that Aleksandr Sorokoumov has
>> accepted
>> the invitation to become committer.
>>
>> Thanks a lot, Aleksandr , for everything you have done for the project.
>>
>> Congratulations and welcome
>>
>> The Apache Cassandra PMC members
>>
>

Re: Updating our Code Contribution/Style Guide

[Yifan Cai]

+1 to the guideline.


> > For the instance() / getInstance() methods - I know it is an additional
> effort, but on the other hand it has many advantages because you can
> replace the singleton for testing
>
> Again, do this as necessary. I think for public instances this is a fine
> recommendation, but for private uses it should not be prescribed, only used
> if there is an explicit benefit.


It is regarding testability. Where mock is desired, there should be
getter methods, instead of 'public final'. Otherwise, `public final` is
preferred for its simplicity.
It is more tricky in terms of singletons though. I feel there is no good
use of private singleton, which is ugly and makes the referencing code
difficult to test. So probably for singleton, we want to declare the
'instance()' method.
It is good that the guideline is not rigid.


I don’t think it is good idea to prohibit or discourage to use final, which
> is a tool to guard immutability.

Ruslan,
What is proposed is to prohibit or discourage the use of `final` *within a
method body*. I think it is less useful to mark a variable's *reference* as
being immutable within such scope. In the other scenario, e.g. class member
fields, `final` should be used when reference/primitive immutability is
desired.

- Yifan

On Tue, Mar 15, 2022 at 3:46 AM Ruslan Fomkin 
wrote:

> Hi,
>
> I hope it’s OK I jump to the discussion.
>
> I find it is important to automate code formatting and have a build check
> to verify it, otherwise there are many examples in other projects that
> formatting is not followed. To make formatting to be not painful for
> contributors it will be good to setup git commit hooks (which will require
> to have a command line formatting tool) in addition to IDE support. In such
> case the main task for the formatting CI build check will be to fail
> environments, which are not yet set.
> For example, cassandra-dtest already has a CI formatting check in place
> for Python code, which runs on each PR. There is a Python formatting
> command line tool, which can be easily run locally, and if I don’t mistake
> it is easy to setup git commit hook with it. (also works to setup the
> formatting in VScode)
>
> I don’t think it is good idea to prohibit or discourage to use final,
> which is a tool to guard immutability. As mentioned unfortunately Java is
> not designed to be safe by default and thus makes code more noisy by
> requiring to use the keyword.
>
> I noticed an issue with current formatting that there is no indentation if
> an assignment statement is split to multiple lines before or without using
> parenthesis. For example:
> ImmutableMap.Builder InetAddressAndPort>> dcRackBuilder =
> ImmutableMap.builder();
> It would be nice if the next line is intended to understand that it is
> part of the previous line.
>
> I support Jacek’s request to have each argument on a separate line when
> they are many and need to be placed on multiple lines. For me it takes less
> effort to grasp arguments on separate lines than when several arguments are
> combined on the same line. IMHO the root cause is having too many
> arguments, which is common issue for non-OOP languages.
>
> Best regards,
> Ruslan Fomkin
>
> On 15 Mar 2022, at 10:04, Stefan Miklosovic <
> stefan.mikloso...@instaclustr.com> wrote:
>
> I agree with the single commit approach to fix it all. TBH Javadocs
> are a little bit messy as well, warnings on generating them,
> incomplete, in a lot of cases obsolete or they do not reflect the code
> anymore etc.
>
> On Tue, 15 Mar 2022 at 09:44, bened...@apache.org 
> wrote:
>
>
> I’d be fine with that, though I think if we want to start enforcing
> imports we probably want to mass correct them first. It’s not like other
> style requirements in that there should not be unintended consequences. A
> single (huge) commit to standardise the orders and introduce a build-time
> check would be fine IMO.
>
>
>
> I also don’t really think it is that important.
>
>
>
> From: Jacek Lewandowski 
> Date: Tuesday, 15 March 2022 at 05:18
> To: dev@cassandra.apache.org 
> Subject: Re: Updating our Code Contribution/Style Guide
>
> I do think that we should at least enforce the import order. What is now
> is a complete mess and causes a lot of conflicts during rebasing / merging.
> Perhaps we could start enforcing such rules only on modified files, this
> way we could gradually go towards consistency... wdyt?
>
>
> - - -- --- -  -
> Jacek Lewandowski
>
>
>
>
>
> On Tue, Mar 15, 2022 at 1:52 AM Dinesh Joshi  wrote:
>
> Benedict, I agree. We should not be rigid about applying any style.
> stylechecks are meant to bring uniformity in the codebase. I assure you
> what I am proposing is neither rigid nor curbs the ability to apply the
> rules flexibly.
>
>
>
> On Mar 14, 2022, at 4:52 PM, bened...@apache.org wrote:
>
>
>
> I’m a strong -1 on strictly enforcing any style guide. It is there to help
> shape contributions, review feedback and responding 

Re: Welcome Aleksandr Sorokoumov as Cassandra committer

[Berenguer Blasi]

Well done Aleksandr!

On 17/3/22 3:44, Anthony Grasso wrote:

Congratulations Aleksandr! Thank you for your work on the project.

On Thu, 17 Mar 2022 at 12:33, Erick Ramirez 
 wrote:


Congratulations Aleksandr and welcome aboard! 🍻

On Thu, 17 Mar 2022 at 00:15, Benjamin Lerer 
wrote:

The PMC members are pleased to announce that Aleksandr
Sorokoumov has accepted
the invitation to become committer.

Thanks a lot, Aleksandr , for everything you have done for the
project.

Congratulations and welcome

The Apache Cassandra PMC members