Re: [VOTE] Release Apache Cassandra 4.0-rc1

[Ben Bromhead]

https://issues.apache.org/jira/browse/CASSANDRA-16550 :)

On Wed, Mar 31, 2021 at 10:08 AM Mick Semb Wever  wrote:

> >
> > If we could tidy up the others quickly (I'm happy to submit a PR for
> > anything that is outstanding) I'm ready to jump on board the train!
> >
>
>
> The LICENSE and NOTICE issues remain unassigned, if you are keen!
>


-- 

Ben Bromhead

Instaclustr | www.instaclustr.com | @instaclustr
 | +64 27 383 8975

Re: Download source release / binary files in source release

[Justin Mclean]

Hi,

> I have yet to see a legal reason why including binaries in packages is a
> bad thing.

How do you review the release? How do you know there's not something that 
incompatible with the ALv2 in it? With reproducible builds you might be able to 
do this but I assuming that's not the case here.

> In the end this discussion has moved to a list most of us don’t have access
> to and when asked to contribute the original reporter basically said “Your
> problem. You fix it” despite having a significant amount of experience in
> making builds “comply”. 

I  have offered to help serval times and I'm currently doing so by getting the 
legal policy reworded so it's clearer for all projects.

Kind Regards,
Justin

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

Re: Download source release / binary files in source release

[Justin Mclean]

Hi,

> The current board agenda item is still not accurate. The PMC members and
> the project are not ignoring the issue.

Voting +1 on a release with that issue IMO says otherwise, but others may have 
differing opinions on that.

> Also, it would be nice if you could reference this thread, in both the
> board's agenda item and ML post, to allow people to have a complete view of
> the discussion.

Others are aware of this of this thread, but I'll add a link to it for you. It 
seems possible that this will be resolved before ether next board meeting and 
that action item may disappear.

Thanks,
Justin

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

Re: [VOTE] Release Apache Cassandra 4.0-rc1

[Mick Semb Wever]

>
> If we could tidy up the others quickly (I'm happy to submit a PR for
> anything that is outstanding) I'm ready to jump on board the train!
>


The LICENSE and NOTICE issues remain unassigned, if you are keen!

Re: [VOTE] Release Apache Cassandra 4.0-rc1

[Ben Bromhead]

It was more that I felt bad about raining on the parade, than worried about
other reactions :)

It's good to hear that there is some confidence from folks that one of the
issues is potentially resolvable outside of this vote.

If we could tidy up the others quickly (I'm happy to submit a PR for
anything that is outstanding) I'm ready to jump on board the train!

On Wed, Mar 31, 2021 at 9:51 AM Mick Semb Wever  wrote:

> > I hate that I need to voice this opinion, …
>
> I think it is wonderful that you do! There needs to be more of this,
> without fear :-)
>
>
>
> > Please correct me if I'm wrong here, but a RC is something that could be
> a
> > GA release and due to the outstanding issues we don't meet that criteria.
> > Irrespective of how those issues get resolved.
> >
>
>
> I do not believe we relabel RC releases into GA releases. A new release is
> cut and voted on for the GA. Interestingly, the main issue at hand could be
> addressed in the release scripts, so the exact same SHA of 4.0-rc1 could in
> theory be cut into a GA release. (Though it looks like CASSANDRA-16391 is
> feasible.) And we are not looking at impacting QA or touching any
> compatibility aspect of the code.
>


-- 

Ben Bromhead

Instaclustr | www.instaclustr.com | @instaclustr
 | +64 27 383 8975

Re: [VOTE] Release Apache Cassandra 4.0-rc1

[Mick Semb Wever]

> I hate that I need to voice this opinion, …

I think it is wonderful that you do! There needs to be more of this,
without fear :-)



> Please correct me if I'm wrong here, but a RC is something that could be a
> GA release and due to the outstanding issues we don't meet that criteria.
> Irrespective of how those issues get resolved.
>


I do not believe we relabel RC releases into GA releases. A new release is
cut and voted on for the GA. Interestingly, the main issue at hand could be
addressed in the release scripts, so the exact same SHA of 4.0-rc1 could in
theory be cut into a GA release. (Though it looks like CASSANDRA-16391 is
feasible.) And we are not looking at impacting QA or touching any
compatibility aspect of the code.

Re: [VOTE] Release Apache Cassandra 4.0-rc1

[Ben Bromhead]

-1 (non-binding)

I hate that I need to voice this opinion, as I think this is a wonderful
milestone for the project to reach from a technical perspective and it is
truly ready for it from that perspective.

However given the issues listed by Mick that need to be resolved I don't
think this release truly qualifies as a release candidate (we won't pick
this sha / release as GA... so how could it be a real release candidate).

Please correct me if I'm wrong here, but a RC is something that could be a
GA release and due to the outstanding issues we don't meet that criteria.
Irrespective of how those issues get resolved.

Even though these issues are not technical and don't represent the
readiness of 4.0 from an implementation perspective, we owe it to the
broader community to resolve these (as we all say community > code).

On Wed, Mar 31, 2021 at 6:53 AM Blake Eggleston
 wrote:

> +1
>
> > On Mar 29, 2021, at 6:05 AM, Mick Semb Wever  wrote:
> >
> > Proposing the test build of Cassandra 4.0-rc1 for release.
> >
> > sha1: 2facbc97ea215faef1735d9a3d5697162f61bc8c
> > Git:
> >
> https://gitbox.apache.org/repos/asf?p=cassandra.git;a=shortlog;h=refs/tags/4.0-rc1-tentative
> > Maven Artifacts:
> >
> https://repository.apache.org/content/repositories/orgapachecassandra-1234/org/apache/cassandra/cassandra-all/4.0-rc1/
> >
> > The Source and Build Artifacts, and the Debian and RPM packages and
> > repositories, are available here:
> > https://dist.apache.org/repos/dist/dev/cassandra/4.0-rc1/
> >
> > The vote will be open for 72 hours (longer if needed). Everyone who has
> > tested the build is invited to vote. Votes by PMC members are considered
> > binding. A vote passes if there are at least three binding +1s and no
> -1's.
> >
> > Known issues with this release, that are planned to be fixed in 4.0-rc2,
> are
> > - four files were missing copyright headers,
> > - LICENSE and NOTICE contain additional unneeded information,
> > - jar files under lib/ in the source artefact.
> >
> > These issues are actively being worked on, along with our expectations
> that
> > the ASF makes the policy around them more explicit so it is clear exactly
> > what is required of us.
> >
> >
> > [1]: CHANGES.txt:
> >
> https://gitbox.apache.org/repos/asf?p=cassandra.git;a=blob_plain;f=CHANGES.txt;hb=refs/tags/4.0-rc1-tentative
> > [2]: NEWS.txt:
> >
> https://gitbox.apache.org/repos/asf?p=cassandra.git;a=blob_plain;f=NEWS.txt;hb=refs/tags/4.0-rc1-tentative
>
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org
> For additional commands, e-mail: dev-h...@cassandra.apache.org
>
>

-- 

Ben Bromhead

Instaclustr | www.instaclustr.com | @instaclustr
 | +64 27 383 8975

Re: GSoC

[Brandon Williams]

It probably seems a bit more complicated than it actually is if you
aren't familiar with the code base.  I can provide a quick high level
overview of how this ticket would be accomplished:

First, add the configuration parameter.  This would involve adding it
to o.a.c.config.Config.java[0] with a default of being disabled, and
then a getter and setter should be added to DatabaseDescriptor[1].
>From there it's a matter of having the system check this before
invoking repairs.  We can see from nodetool's repair command[2] that
this ends up calling repairAsync in StorageService[3] via JMX.

Of course the devil is always in the details (and I've glossed over
some here,) but that's what my initial plan of attack would be, and
hopefully it's enough to give you an idea of what might be involved.

If you want more interactive help, I recommend joining the
#cassandra-dev slack channel.

[0] 
https://github.com/apache/cassandra/blob/cassandra-3.0/src/java/org/apache/cassandra/config/Config.java
[1] 
https://github.com/apache/cassandra/blob/cassandra-3.0/src/java/org/apache/cassandra/config/DatabaseDescriptor.java
[2] 
https://github.com/apache/cassandra/blob/cassandra-3.0/src/java/org/apache/cassandra/tools/nodetool/Repair.java
[3] 
https://github.com/apache/cassandra/blob/cassandra-3.0/src/java/org/apache/cassandra/service/StorageService.java


On Tue, Mar 30, 2021 at 10:57 AM Isidoro Garcia Gutierrez
 wrote:
>
> Hello everyone,
> I would like to apply for the idea Global configuration parameter to reject
> repairs with anti-compaction
>  but I don't know if
> I have enough skill to do it right.
> I read that the difficulty is normal but before applying I would like to
> know a little more about this topic before making the proposal for the job.
> Can someone help me?
>
> Thanks.
>
> --
>
>
>
> INFORMACIÓ SOBRE PROTECCIÓ DE DADES DE LA UNIVERSITAT OBERTA DE
> CATALUNYA (UOC)
>
> Us informem que les vostres dades identificatives i les
> contingudes en els missatges electrònics i fitxers adjunts es poden
> incorporar a les nostres bases de dades amb la finalitat de gestionar les
> relacions i comunicacions vinculades a la UOC, i que es poden conservar
> mentre es mantingui la relació. Si ho voleu, podeu exercir el dret a
> accedir a les vostres dades, rectificar-les i suprimir-les i altres drets
> reconeguts normativament adreçant-vos a l'adreça de correu emissora o a
> fuoc...@uoc.edu .
>
> Aquest missatge i qualsevol
> fitxer que porti adjunt, si escau, tenen el caràcter de confidencials i
> s'adrecen únicament a la persona o entitat a qui s'han enviat.
>
> Així
> mateix, posem a la vostra disposició un delegat de protecció de dades que
> no només s'encarregarà de supervisar tots els tractaments de dades de la
> nostra entitat, sinó que us podrà atendre per a qualsevol qüestió
> relacionada amb el tractament de dades. La seva adreça de contacte és
> d...@uoc.edu .
> INFORMACIÓN SOBRE PROTECCIÓN DE DATOS DE
> LA UNIVERSITAT OBERTA DE CATALUNYA (UOC)
> Os informamos de que vuestros
> datos identificativos y los contenidos en los mensajes electrónicos y
> ficheros adjuntos pueden incorporarse a nuestras bases de datos con el fin
> de gestionar las relaciones y comunicaciones vinculadas a la UOC, y de que
> pueden conservarse mientras se mantenga la relación. Si lo deseáis, podéis
> ejercer el derecho a acceder a vuestros datos, rectificarlos y suprimirlos
> y otros derechos reconocidos normativamente dirigiéndoos a la dirección de
> correo emisora o a fuoc...@uoc.edu .
> Este mensaje y
> cualquier fichero que lleve adjunto, si procede, tienen el carácter de
> confidenciales y se dirigen únicamente a la persona o entidad a quien se
> han enviado.
> Así mismo, ponemos a vuestra disposición a un delegado de
> protección de datos que no solo se encargará de supervisar todos los
> tratamientos de datos de nuestra entidad, sino que podrá atenderos para
> cualquier cuestión relacionada con el tratamiento de datos. Su dirección de
> contacto es d...@uoc.edu .
>
>
> UNIVERSITAT OBERTA DE
> CATALUNYA (UOC) DATA PROTECTION INFORMATION
> Your personal data and the data
> contained in your email messages and attached files may be stored in our
> databases for the purpose of maintaining relations and communications
> linked to the UOC, and the data may be stored for as long as these
> relations and communications are maintained. If you so wish, you can
> exercise your rights to access, rectification and erasure of your data, and
> any other legally held rights, by writing to the sender’s email address or
> to fuoc...@uoc.edu .
> This message and, where
> applicable, any attachments are confidential and addressed solely to the
> individual or organization they were sent to.
> The UOC has a data protection
> officer who not only supervises the data processing carried 

Re: [VOTE] Release Apache Cassandra 4.0-rc1

[Blake Eggleston]

+1

> On Mar 29, 2021, at 6:05 AM, Mick Semb Wever  wrote:
> 
> Proposing the test build of Cassandra 4.0-rc1 for release.
> 
> sha1: 2facbc97ea215faef1735d9a3d5697162f61bc8c
> Git:
> https://gitbox.apache.org/repos/asf?p=cassandra.git;a=shortlog;h=refs/tags/4.0-rc1-tentative
> Maven Artifacts:
> https://repository.apache.org/content/repositories/orgapachecassandra-1234/org/apache/cassandra/cassandra-all/4.0-rc1/
> 
> The Source and Build Artifacts, and the Debian and RPM packages and
> repositories, are available here:
> https://dist.apache.org/repos/dist/dev/cassandra/4.0-rc1/
> 
> The vote will be open for 72 hours (longer if needed). Everyone who has
> tested the build is invited to vote. Votes by PMC members are considered
> binding. A vote passes if there are at least three binding +1s and no -1's.
> 
> Known issues with this release, that are planned to be fixed in 4.0-rc2, are
> - four files were missing copyright headers,
> - LICENSE and NOTICE contain additional unneeded information,
> - jar files under lib/ in the source artefact.
> 
> These issues are actively being worked on, along with our expectations that
> the ASF makes the policy around them more explicit so it is clear exactly
> what is required of us.
> 
> 
> [1]: CHANGES.txt:
> https://gitbox.apache.org/repos/asf?p=cassandra.git;a=blob_plain;f=CHANGES.txt;hb=refs/tags/4.0-rc1-tentative
> [2]: NEWS.txt:
> https://gitbox.apache.org/repos/asf?p=cassandra.git;a=blob_plain;f=NEWS.txt;hb=refs/tags/4.0-rc1-tentative


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

Re: Download source release / binary files in source release

[Mick Semb Wever]

> That’s not very in the spirit of open source
> and I am disappointed again by the ASFs role in this — which continues to
> be ambiguous and at the cost of its users and developers.
>


Jordan, we share the same concerns and frustrations.

But, do please be careful not to divide the room. We are all the ASF. If we
are responsible and engaged, we can move forward together. I'd rather think
of it as the difficulty one has to expect when working with such a large
diverse organic group of people.

Re: Download source release / binary files in source release

[Benedict Elliott Smith]

There is no legal reason; this was disavowed on LEGAL-288. The ostensible 
reason is that Roy Fielding, who filed the papers of incorporation, interprets 
the charter to require this. I don't think, however, anybody has challenged 
this interpretation of the charter. I certainly do not interpret it to require 
this, even if you take a very narrow view of open source software.

On 30/03/2021, 16:47, "Jordan West"  wrote:

I have yet to see a legal reason why including binaries in packages is a
bad thing. I’ve read the thread and the documents linked. In fact, it looks
like it’s done specifically to avoid legal issues with copy left licenses.
It’s very common for Apache to hold on to past policies at the expense of
its projects’ users (see the slow transition to Git) all while claiming to
do it for their benefit. It’s a decade later, the landscape has changed. We
should absolutely protect the project legally but trying to guess the
spirit of open source at the cost of users is of little benefit to all
stakeholders.

In the end this discussion has moved to a list most of us don’t have access
to and when asked to contribute the original reporter basically said “Your
problem. You fix it” despite having a significant amount of experience in
making builds “comply”.  It’s also causing the delay of the projects first
major release in 5 years, that many of this list have contributed large
portions of their life too. That’s not very in the spirit of open source
and I am disappointed again by the ASFs role in this — which continues to
be ambiguous and at the cost of its users and developers.

All that said, if we fix this great. If we don’t, eh. As long as we are
legally compliant with the licenses of the dependencies we use we should
value convenience for users over pedanticsm and statements that are a
decade old. If there is a legal reason to change this it’s been explained
poorly by the ASF and needs clarification. It also can only be so important
if we are only catching it now after so many releases with the project.

Jordan

On Tue, Mar 30, 2021 at 7:19 AM Joshua McKenzie 
wrote:

> FWIW I don't have access to what's being raised with the board so
> effectively can't participate in this discussion beyond +1'ing Jirsa:
>
> Based on this point, I personally won't vote to approve a future release
> > with binary packages, but I also strongly disagree with the assertion in
> > that same past thread that it's worth nuking a 10+year history of
> releases.
> > That's the type of action that would severely diminish trust in the
> > foundation.
>
>
> We SHOULD look at what's required to rebuild PAST releases.
>
>
> We should keep in mind what's best for our users. While avoiding including
> compiled binaries that can't be verified as open source makes complete
> sense from a "maximize safety to our users" perspective and can be done on
> forward-going releases with minimal lift, we also have to consider how we
> get There from Here on past releases. Pulling the rug out from our entire
> user-base and releases after over a decade based on a conversation that
> happened off-list (i.e. not on the C* dev list) 9 years ago is, hopefully
> we can agree, not in our users' best interests nor the best interests of
> this project's longevity.
>
> ~Josh
>
> On Tue, Mar 30, 2021 at 9:38 AM Mick Semb Wever  wrote:
>
> > >
> > > It good to see you are taking action, but I think the situation is a
> > > little more seriously that you may realise, I suggest you look at what
> > > actions the board has taken in similar situations in the past. I'll
> > update
> > > the board agenda item to reflect the current situation.
> > >
> >
> >
> > The current board agenda item is still not accurate. The PMC members and
> > the project are not ignoring the issue.
> >
> > Also, it would be nice if you could reference this thread, in both the
> > board's agenda item and ML post, to allow people to have a complete view
> of
> > the discussion.
> >
> > I am happy to add information to the agenda item if you agree to it.
> > Better yet, I suggest that we work together in public to word it. Most
> > people on this list do not have access to the message. There is a
> community
> > here, and the way we work together to solve problems matters.
> >
>



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

GSoC

[Isidoro Garcia Gutierrez]

Hello everyone,
I would like to apply for the idea Global configuration parameter to reject
repairs with anti-compaction
 but I don't know if
I have enough skill to do it right.
I read that the difficulty is normal but before applying I would like to
know a little more about this topic before making the proposal for the job.
Can someone help me?

Thanks.

-- 



INFORMACIÓ SOBRE PROTECCIÓ DE DADES DE LA UNIVERSITAT OBERTA DE 
CATALUNYA (UOC)

Us informem que les vostres dades identificatives i les 
contingudes en els missatges electrònics i fitxers adjunts es poden 
incorporar a les nostres bases de dades amb la finalitat de gestionar les 
relacions i comunicacions vinculades a la UOC, i que es poden conservar 
mentre es mantingui la relació. Si ho voleu, podeu exercir el dret a 
accedir a les vostres dades, rectificar-les i suprimir-les i altres drets 
reconeguts normativament adreçant-vos a l'adreça de correu emissora o a 
fuoc...@uoc.edu .

Aquest missatge i qualsevol 
fitxer que porti adjunt, si escau, tenen el caràcter de confidencials i 
s'adrecen únicament a la persona o entitat a qui s'han enviat.

Així 
mateix, posem a la vostra disposició un delegat de protecció de dades que 
no només s'encarregarà de supervisar tots els tractaments de dades de la 
nostra entitat, sinó que us podrà atendre per a qualsevol qüestió 
relacionada amb el tractament de dades. La seva adreça de contacte és 
d...@uoc.edu .
INFORMACIÓN SOBRE PROTECCIÓN DE DATOS DE 
LA UNIVERSITAT OBERTA DE CATALUNYA (UOC)
Os informamos de que vuestros 
datos identificativos y los contenidos en los mensajes electrónicos y 
ficheros adjuntos pueden incorporarse a nuestras bases de datos con el fin 
de gestionar las relaciones y comunicaciones vinculadas a la UOC, y de que 
pueden conservarse mientras se mantenga la relación. Si lo deseáis, podéis 
ejercer el derecho a acceder a vuestros datos, rectificarlos y suprimirlos 
y otros derechos reconocidos normativamente dirigiéndoos a la dirección de 
correo emisora o a fuoc...@uoc.edu .
Este mensaje y 
cualquier fichero que lleve adjunto, si procede, tienen el carácter de 
confidenciales y se dirigen únicamente a la persona o entidad a quien se 
han enviado.
Así mismo, ponemos a vuestra disposición a un delegado de 
protección de datos que no solo se encargará de supervisar todos los 
tratamientos de datos de nuestra entidad, sino que podrá atenderos para 
cualquier cuestión relacionada con el tratamiento de datos. Su dirección de 
contacto es d...@uoc.edu .


UNIVERSITAT OBERTA DE 
CATALUNYA (UOC) DATA PROTECTION INFORMATION
Your personal data and the data 
contained in your email messages and attached files may be stored in our 
databases for the purpose of maintaining relations and communications 
linked to the UOC, and the data may be stored for as long as these 
relations and communications are maintained. If you so wish, you can 
exercise your rights to access, rectification and erasure of your data, and 
any other legally held rights, by writing to the sender’s email address or 
to fuoc...@uoc.edu .
This message and, where 
applicable, any attachments are confidential and addressed solely to the 
individual or organization they were sent to.
The UOC has a data protection 
officer who not only supervises the data processing carried out at the 
University, but who will also respond to any questions you may have about 
this data processing. You can contact our data protection officer by 
writing to d...@uoc.edu .

Re: Download source release / binary files in source release

[Jordan West]

I have yet to see a legal reason why including binaries in packages is a
bad thing. I’ve read the thread and the documents linked. In fact, it looks
like it’s done specifically to avoid legal issues with copy left licenses.
It’s very common for Apache to hold on to past policies at the expense of
its projects’ users (see the slow transition to Git) all while claiming to
do it for their benefit. It’s a decade later, the landscape has changed. We
should absolutely protect the project legally but trying to guess the
spirit of open source at the cost of users is of little benefit to all
stakeholders.

In the end this discussion has moved to a list most of us don’t have access
to and when asked to contribute the original reporter basically said “Your
problem. You fix it” despite having a significant amount of experience in
making builds “comply”.  It’s also causing the delay of the projects first
major release in 5 years, that many of this list have contributed large
portions of their life too. That’s not very in the spirit of open source
and I am disappointed again by the ASFs role in this — which continues to
be ambiguous and at the cost of its users and developers.

All that said, if we fix this great. If we don’t, eh. As long as we are
legally compliant with the licenses of the dependencies we use we should
value convenience for users over pedanticsm and statements that are a
decade old. If there is a legal reason to change this it’s been explained
poorly by the ASF and needs clarification. It also can only be so important
if we are only catching it now after so many releases with the project.

Jordan

On Tue, Mar 30, 2021 at 7:19 AM Joshua McKenzie 
wrote:

> FWIW I don't have access to what's being raised with the board so
> effectively can't participate in this discussion beyond +1'ing Jirsa:
>
> Based on this point, I personally won't vote to approve a future release
> > with binary packages, but I also strongly disagree with the assertion in
> > that same past thread that it's worth nuking a 10+year history of
> releases.
> > That's the type of action that would severely diminish trust in the
> > foundation.
>
>
> We SHOULD look at what's required to rebuild PAST releases.
>
>
> We should keep in mind what's best for our users. While avoiding including
> compiled binaries that can't be verified as open source makes complete
> sense from a "maximize safety to our users" perspective and can be done on
> forward-going releases with minimal lift, we also have to consider how we
> get There from Here on past releases. Pulling the rug out from our entire
> user-base and releases after over a decade based on a conversation that
> happened off-list (i.e. not on the C* dev list) 9 years ago is, hopefully
> we can agree, not in our users' best interests nor the best interests of
> this project's longevity.
>
> ~Josh
>
> On Tue, Mar 30, 2021 at 9:38 AM Mick Semb Wever  wrote:
>
> > >
> > > It good to see you are taking action, but I think the situation is a
> > > little more seriously that you may realise, I suggest you look at what
> > > actions the board has taken in similar situations in the past. I'll
> > update
> > > the board agenda item to reflect the current situation.
> > >
> >
> >
> > The current board agenda item is still not accurate. The PMC members and
> > the project are not ignoring the issue.
> >
> > Also, it would be nice if you could reference this thread, in both the
> > board's agenda item and ML post, to allow people to have a complete view
> of
> > the discussion.
> >
> > I am happy to add information to the agenda item if you agree to it.
> > Better yet, I suggest that we work together in public to word it. Most
> > people on this list do not have access to the message. There is a
> community
> > here, and the way we work together to solve problems matters.
> >
>

Re: [VOTE] Release Apache Cassandra 4.0-rc1

[Jordan West]

+1 nb. Very excited to see the project reach this milestone. Congrats
everyone and thank you all for the effort and hard work!

Jordan

On Tue, Mar 30, 2021 at 8:33 AM Scott Andreas  wrote:

> +1 nb.
>
> This is a huge milestone for the project.
>
> 
> From: Paulo Motta 
> Sent: Tuesday, March 30, 2021 4:57 AM
> To: Cassandra DEV
> Subject: Re: [VOTE] Release Apache Cassandra 4.0-rc1
>
> +1
>
> Em ter., 30 de mar. de 2021 às 00:25, Dinesh Joshi 
> escreveu:
>
> > +1
> >
> > Dinesh
> >
> > > On Mar 29, 2021, at 1:41 PM, Nate McCall  wrote:
> > >
> > > +1
> > >
> > >
> > >> On Tue, Mar 30, 2021 at 2:06 AM Mick Semb Wever 
> wrote:
> > >>
> > >> Proposing the test build of Cassandra 4.0-rc1 for release.
> > >>
> > >> sha1: 2facbc97ea215faef1735d9a3d5697162f61bc8c
> > >> Git:
> > >>
> > >>
> >
> https://gitbox.apache.org/repos/asf?p=cassandra.git;a=shortlog;h=refs/tags/4.0-rc1-tentative
> > >> Maven Artifacts:
> > >>
> > >>
> >
> https://repository.apache.org/content/repositories/orgapachecassandra-1234/org/apache/cassandra/cassandra-all/4.0-rc1/
> > >>
> > >> The Source and Build Artifacts, and the Debian and RPM packages and
> > >> repositories, are available here:
> > >> https://dist.apache.org/repos/dist/dev/cassandra/4.0-rc1/
> > >>
> > >> The vote will be open for 72 hours (longer if needed). Everyone who
> has
> > >> tested the build is invited to vote. Votes by PMC members are
> considered
> > >> binding. A vote passes if there are at least three binding +1s and no
> > -1's.
> > >>
> > >> Known issues with this release, that are planned to be fixed in
> 4.0-rc2,
> > >> are
> > >> - four files were missing copyright headers,
> > >> - LICENSE and NOTICE contain additional unneeded information,
> > >> - jar files under lib/ in the source artefact.
> > >>
> > >> These issues are actively being worked on, along with our expectations
> > that
> > >> the ASF makes the policy around them more explicit so it is clear
> > exactly
> > >> what is required of us.
> > >>
> > >>
> > >> [1]: CHANGES.txt:
> > >>
> > >>
> >
> https://gitbox.apache.org/repos/asf?p=cassandra.git;a=blob_plain;f=CHANGES.txt;hb=refs/tags/4.0-rc1-tentative
> > >> [2]: NEWS.txt:
> > >>
> > >>
> >
> https://gitbox.apache.org/repos/asf?p=cassandra.git;a=blob_plain;f=NEWS.txt;hb=refs/tags/4.0-rc1-tentative
> > >>
> >
> > -
> > To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org
> > For additional commands, e-mail: dev-h...@cassandra.apache.org
> >
> >
>

Re: [VOTE] Release Apache Cassandra 4.0-rc1

[Scott Andreas]

+1 nb.

This is a huge milestone for the project.


From: Paulo Motta 
Sent: Tuesday, March 30, 2021 4:57 AM
To: Cassandra DEV
Subject: Re: [VOTE] Release Apache Cassandra 4.0-rc1

+1

Em ter., 30 de mar. de 2021 às 00:25, Dinesh Joshi 
escreveu:

> +1
>
> Dinesh
>
> > On Mar 29, 2021, at 1:41 PM, Nate McCall  wrote:
> >
> > +1
> >
> >
> >> On Tue, Mar 30, 2021 at 2:06 AM Mick Semb Wever  wrote:
> >>
> >> Proposing the test build of Cassandra 4.0-rc1 for release.
> >>
> >> sha1: 2facbc97ea215faef1735d9a3d5697162f61bc8c
> >> Git:
> >>
> >>
> https://gitbox.apache.org/repos/asf?p=cassandra.git;a=shortlog;h=refs/tags/4.0-rc1-tentative
> >> Maven Artifacts:
> >>
> >>
> https://repository.apache.org/content/repositories/orgapachecassandra-1234/org/apache/cassandra/cassandra-all/4.0-rc1/
> >>
> >> The Source and Build Artifacts, and the Debian and RPM packages and
> >> repositories, are available here:
> >> https://dist.apache.org/repos/dist/dev/cassandra/4.0-rc1/
> >>
> >> The vote will be open for 72 hours (longer if needed). Everyone who has
> >> tested the build is invited to vote. Votes by PMC members are considered
> >> binding. A vote passes if there are at least three binding +1s and no
> -1's.
> >>
> >> Known issues with this release, that are planned to be fixed in 4.0-rc2,
> >> are
> >> - four files were missing copyright headers,
> >> - LICENSE and NOTICE contain additional unneeded information,
> >> - jar files under lib/ in the source artefact.
> >>
> >> These issues are actively being worked on, along with our expectations
> that
> >> the ASF makes the policy around them more explicit so it is clear
> exactly
> >> what is required of us.
> >>
> >>
> >> [1]: CHANGES.txt:
> >>
> >>
> https://gitbox.apache.org/repos/asf?p=cassandra.git;a=blob_plain;f=CHANGES.txt;hb=refs/tags/4.0-rc1-tentative
> >> [2]: NEWS.txt:
> >>
> >>
> https://gitbox.apache.org/repos/asf?p=cassandra.git;a=blob_plain;f=NEWS.txt;hb=refs/tags/4.0-rc1-tentative
> >>
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org
> For additional commands, e-mail: dev-h...@cassandra.apache.org
>
>

Re: Download source release / binary files in source release

[Joshua McKenzie]

FWIW I don't have access to what's being raised with the board so
effectively can't participate in this discussion beyond +1'ing Jirsa:

Based on this point, I personally won't vote to approve a future release
> with binary packages, but I also strongly disagree with the assertion in
> that same past thread that it's worth nuking a 10+year history of releases.
> That's the type of action that would severely diminish trust in the
> foundation.


We SHOULD look at what's required to rebuild PAST releases.


We should keep in mind what's best for our users. While avoiding including
compiled binaries that can't be verified as open source makes complete
sense from a "maximize safety to our users" perspective and can be done on
forward-going releases with minimal lift, we also have to consider how we
get There from Here on past releases. Pulling the rug out from our entire
user-base and releases after over a decade based on a conversation that
happened off-list (i.e. not on the C* dev list) 9 years ago is, hopefully
we can agree, not in our users' best interests nor the best interests of
this project's longevity.

~Josh

On Tue, Mar 30, 2021 at 9:38 AM Mick Semb Wever  wrote:

> >
> > It good to see you are taking action, but I think the situation is a
> > little more seriously that you may realise, I suggest you look at what
> > actions the board has taken in similar situations in the past. I'll
> update
> > the board agenda item to reflect the current situation.
> >
>
>
> The current board agenda item is still not accurate. The PMC members and
> the project are not ignoring the issue.
>
> Also, it would be nice if you could reference this thread, in both the
> board's agenda item and ML post, to allow people to have a complete view of
> the discussion.
>
> I am happy to add information to the agenda item if you agree to it.
> Better yet, I suggest that we work together in public to word it. Most
> people on this list do not have access to the message. There is a community
> here, and the way we work together to solve problems matters.
>

Re: Download source release / binary files in source release

[Mick Semb Wever]

>
> It good to see you are taking action, but I think the situation is a
> little more seriously that you may realise, I suggest you look at what
> actions the board has taken in similar situations in the past. I'll update
> the board agenda item to reflect the current situation.
>


The current board agenda item is still not accurate. The PMC members and
the project are not ignoring the issue.

Also, it would be nice if you could reference this thread, in both the
board's agenda item and ML post, to allow people to have a complete view of
the discussion.

I am happy to add information to the agenda item if you agree to it.
Better yet, I suggest that we work together in public to word it. Most
people on this list do not have access to the message. There is a community
here, and the way we work together to solve problems matters.

Re: [VOTE] Release Apache Cassandra 4.0-rc1

[Paulo Motta]

+1

Em ter., 30 de mar. de 2021 às 00:25, Dinesh Joshi 
escreveu:

> +1
>
> Dinesh
>
> > On Mar 29, 2021, at 1:41 PM, Nate McCall  wrote:
> >
> > +1
> >
> >
> >> On Tue, Mar 30, 2021 at 2:06 AM Mick Semb Wever  wrote:
> >>
> >> Proposing the test build of Cassandra 4.0-rc1 for release.
> >>
> >> sha1: 2facbc97ea215faef1735d9a3d5697162f61bc8c
> >> Git:
> >>
> >>
> https://gitbox.apache.org/repos/asf?p=cassandra.git;a=shortlog;h=refs/tags/4.0-rc1-tentative
> >> Maven Artifacts:
> >>
> >>
> https://repository.apache.org/content/repositories/orgapachecassandra-1234/org/apache/cassandra/cassandra-all/4.0-rc1/
> >>
> >> The Source and Build Artifacts, and the Debian and RPM packages and
> >> repositories, are available here:
> >> https://dist.apache.org/repos/dist/dev/cassandra/4.0-rc1/
> >>
> >> The vote will be open for 72 hours (longer if needed). Everyone who has
> >> tested the build is invited to vote. Votes by PMC members are considered
> >> binding. A vote passes if there are at least three binding +1s and no
> -1's.
> >>
> >> Known issues with this release, that are planned to be fixed in 4.0-rc2,
> >> are
> >> - four files were missing copyright headers,
> >> - LICENSE and NOTICE contain additional unneeded information,
> >> - jar files under lib/ in the source artefact.
> >>
> >> These issues are actively being worked on, along with our expectations
> that
> >> the ASF makes the policy around them more explicit so it is clear
> exactly
> >> what is required of us.
> >>
> >>
> >> [1]: CHANGES.txt:
> >>
> >>
> https://gitbox.apache.org/repos/asf?p=cassandra.git;a=blob_plain;f=CHANGES.txt;hb=refs/tags/4.0-rc1-tentative
> >> [2]: NEWS.txt:
> >>
> >>
> https://gitbox.apache.org/repos/asf?p=cassandra.git;a=blob_plain;f=NEWS.txt;hb=refs/tags/4.0-rc1-tentative
> >>
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org
> For additional commands, e-mail: dev-h...@cassandra.apache.org
>
>

Re: Download source release / binary files in source release

[Benedict Elliott Smith]

As I'm sure you're aware, only a couple of people in the community are able to 
follow or participate in board discussions without being expressly included.

On 30/03/2021, 09:51, "Justin Mclean"  wrote:

Hi,

JFYI I've started a discussion about this on the board list [1]. Note that 
that list is for the board to conduct business on, so please take care in what 
you post there.

Thanks,
Justin

1. 
https://lists.apache.org/thread.html/rda27b6bc832d7e36eb12cc93343a358f5848bd10198e0165110ed4fc%40%3Cboard.apache.org%3E

-
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: [DISCUSS] Releases after 4.0

[Sam Tunnicliffe]

+1

> On 29 Mar 2021, at 15:41, Joseph Lynch  wrote:
> 
> I am slightly concerned about removing support for critical bug fixes
> in 3.0 on a short time-frame (<1 year). I know of at least a few major
> installations, including ours, who are just now able to finish
> upgrades to 3.0 in production due to the number of correctness and
> performance bugs introduced in that release which have only been
> debugged and fixed in the past ~2 years.
> 
> I like the idea of the 3-year support cycles, but I think since
> 3.0/3.11/4.0 took so long to stabilize to a point folks could upgrade
> to, we should reset the clock somewhat. What about the following
> assuming an April 2021 4.0 cut:
> 
> 4.0: Fully supported until April 2023 and high severity bugs until
> April 2024 (2 year full, 1 year bugfix)
> 3.11: Fully supported until April 2022 and high severity bugs until
> April 2023 (1 year full, 1 year bugfix).
> 3.0: Supported for high severity correctness/performance bugs until
> April 2022 (1 year bugfix)
> 2.2+2.1: EOL immediately.
> 
> Then going forward we could have this nice pattern when we cut the
> yearly release:
> Y(n-0): Support for 3 years from now (2 full, 1 bugfix)
> Y(n-1): Fully supported for 1 more year and supported for high
> severity correctness/perf bugs 1 year after that (1 full, 1 bugfix)
> Y(n-2): Supported for high severity correctness/bugs for 1 more year (1 
> bugfix)
> 
> What do you think?
> -Joey
> 
> On Mon, Mar 29, 2021 at 9:39 AM Benjamin Lerer
>  wrote:
>> 
>> Thanks to everybody and sorry for not finalizing that email thread sooner.
>> 
>> For the release cadence the agreement is:* one release every year +
>> periodic trunc snapshot*
>> For the number of releases being supported the agreement is 3.  *Every
>> incoming release should be supported for 3 years.*
>> 
>> We did not reach a clear agreement on several points :
>> * The naming of versions: semver versus another approach and the name of
>> snapshot versions
>> * How long will we support 3.11. Taking into account that it has been
>> released 4 years ago does it make sense to support it for the next 3 years?
>> 
>> I am planning to open some follow up discussions for those points in the
>> coming weeks.
>> 
>> When there is an agreement we should document the changes on the webpage
>>> and also highlight it as part of the 4.0 release material as it's an
>>> important change to the release cycle and LTS support.
>>> 
>> 
>> It is a valid point. Do you mind if I update the documentation when we have
>> clarified the version names and that we have a more precise idea of when
>> 4.0 GA will be released? That will allow us to make a clear message on when
>> to expect the next supported version.
>> 
>> On Mon, Feb 8, 2021 at 10:05 PM Paulo Motta 
>> wrote:
>> 
>>> +1 to the yearly release cadence + periodic trunk snapshots + support to 3
>>> previous release branches.. I think this will give some nice predictability
>>> to the project.
>>> 
>>> When there is an agreement we should document the changes on the webpage
>>> and also highlight it as part of the 4.0 release material as it's an
>>> important change to the release cycle and LTS support.
>>> 
>>> Em sex., 5 de fev. de 2021 às 18:08, Brandon Williams 
>>> escreveu:
>>> 
 Perhaps on my third try...  keep three branches total, including 3.11:
 3.11, 4, next. Support for 3.11 begins ending after next+1, is what
 I'm trying to convey.
 
 On Fri, Feb 5, 2021 at 2:58 PM Brandon Williams 
>>> wrote:
> 
> Err, to be clear: keep 3.11 until we have 3 other branches.
> 
> On Fri, Feb 5, 2021 at 2:57 PM Brandon Williams 
 wrote:
>> 
>> I'm +1 on 3 branches, and thus ~3 years of support.  So in the
>> transition, would we aim to keep 3.11 until after 4.0 and a successor
>> are released?
>> 
>> On Fri, Feb 5, 2021 at 11:44 AM Benjamin Lerer
>>  wrote:
>>> 
 
 Are we also trying to reach a consensus here that a release
>>> branch
 should
 be supported for ~3 years (i.e. that we are aiming to limit
 ourselves to 3
 release branches plus trunk)?
>>> 
>>> 
>>> 3 release branches make sense to me +1
>>> 
>>> 
>>> 
>>> On Fri, Feb 5, 2021 at 6:15 PM Michael Semb Wever 
 wrote:
>>> 
 
> I believe that there is an appetite for the bleeding edge
 snapshots where
> we do not guarantee stability and that the semver discussion is
 not
> finished yet but I would like us to let those discussions go
>>> for
 some
> follow up threads.
> My goal with this thread was to reach an agreement on a release
 cadence
 for
> the version we will officially support after 4.0.
> 
> My impression is that most people agree with *one release every
 year* so
 I
> would like to propose it as our future release cadence.
> 
 
 
 +1 

Re: Download source release / binary files in source release

[Sam Tunnicliffe]

I agree with Jeff. The inclusion of binary dependencies to assist developers 
building from a source release doesn't seem like a deal breaker to me 
personally as long as these are purely a convenience and not a requirement. 
That said, the stance of the ASF as recorded in the incubator thread is 
pretty clear, so I also will not vote to approve future releases containing 
binary artifacts. However, I don't think that removing any previous releases 
should even be up for debate. In fact, Roy dismisses this idea himself in the 
same thread[1]. So it seems that only releases currently being served from 
dist.apache.org need to be fixed. With the 2.1 and 2.2 lines due for imminent 
EOL, it seems that once CASSANDRA-16391 lands in 3.0, 3.11 and trunk we could 
cut new, compliant releases and be done.

As others have mentioned, relying on knowledge of a specific mail thread as 
the ultimate lsource of truth is somewhat arcane, so I'm glad that the 
discussion on 
legal-discuss is happening and that proposals to clarify the policy 
documentation 
are afoot.

[1] 
https://lists.apache.org/thread.html/c4b374ccd80f0440746dae343b62c3ba6c73e2531e275ca1e194e335%401332935970%40%3Cgeneral.incubator.apache.org%3E



> On 30 Mar 2021, at 03:58, Jeff Jirsa  wrote:
> 
> On Mon, Mar 29, 2021 at 3:45 PM Justin Mclean  wrote:
> 
>> 
>> It good to see you are taking action, but I think the situation is a
>> little more seriously that you may realise, I suggest you look at what
>> actions the board has taken in similar situations in the past. I'll update
>> the board agenda item to reflect the current situation.
>> 
>> 
> The thread linked earlier is worth reading for sure. Again,
> https://lists.apache.org/thread.html/f8022be5a02c6f020aac635193e729a0f73376164cea7c38474c3dc0%401332948346%40%3Cgeneral.incubator.apache.org%3E
> 
> As an ASF member and a member of the Cassandra PMC, it's pretty clear what
> Roy's position was in 2012.
> 
> My personal, emotional response is in line with what Rob Weir said in
> 2012:  "The issue should be lack of source code, not presence of binary
> code."
> 
> If someone asked me what's included in a source release, without reading
> ANY doc or policy, I'd expect there to be the complete, unabridged source
> of the project, and enough context to build it. That's what Cassandra has
> today. The extra binaries are just that - extra. They come with no burden.
> They come with no obligation to use. They come with no penalty. The source
> for which the PMC is responsible is published, and that feels far more
> important to me than the absence of binary code that's trivial to remove.
> 
> Roy's response in the 2012 thread, though, is unambiguous: he strongly
> believes, clearly with authority in 2012, that the presence of ANY binary
> file violates the spirit of a source release. That feels quite extreme to
> me, though this line is probably nuanced enough to inspire a book on trust:
> 
> "One cannot vote to approve a release containing a mix of source and binary
> code because the binary is not open source and cannot be verified to be
> safe for release (even if it was derived from open source)."
> 
> Based on this point, I personally won't vote to approve a future release
> with binary packages, but I also strongly disagree with the assertion in
> that same past thread that it's worth nuking a 10+year history of releases.
> That's the type of action that would severely diminish trust in the
> foundation.
> 
> We SHOULD look at what's required to rebuild PAST releases. We should also
> admit that people are human and be reasonable along the way. Community over
> code and all that.


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

Re: Download source release / binary files in source release

[Justin Mclean]

Hi,

JFYI I've started a discussion about this on the board list [1]. Note that that 
list is for the board to conduct business on, so please take care in what you 
post there.

Thanks,
Justin

1. 
https://lists.apache.org/thread.html/rda27b6bc832d7e36eb12cc93343a358f5848bd10198e0165110ed4fc%40%3Cboard.apache.org%3E

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