Re: Welcome Berenguer Blasi as Cassandra committer
Congratulations Berenguer!! On Thu, Mar 25, 2021 at 6:18 AM Paulo Motta wrote: > Congratulations Berenguer, well deserved! Happy to see the project > recognizing more contributors! > > Em qui., 25 de mar. de 2021 às 10:09, Brandon Williams > escreveu: > > > Congratulations Berenguer! Thank you for your work. > > > > On Thu, Mar 25, 2021 at 5:10 AM Benjamin Lerer > wrote: > > > > > > The PMC's members are pleased to announce that Berenguer Blasi has > > > accepted the invitation to become committer today. > > > > > > Thanks a lot, Berenguer, for all the work you have done! > > > > > > Congratulations and welcome > > > > > > The Apache Cassandra PMC members > > > > - > > To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org > > For additional commands, e-mail: dev-h...@cassandra.apache.org > > > > >
Re: Welcome Berenguer Blasi as Cassandra committer
Congratulations Berenguer! - Yifan > On Mar 26, 2021, at 11:49 AM, Sumanth Pasupuleti > wrote: > > Congratulations Berenguer! - To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org For additional commands, e-mail: dev-h...@cassandra.apache.org
[ANNOUNCE] Apache Cassandra 4.0-rc1 test artifact available
The test build of Cassandra 4.0-rc1 is available. 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/ A vote of this test build will be initiated within the next couple of days. All testing in advance of the vote is most welcomed. [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
Re: [ANNOUNCE] Apache Cassandra 4.0-rc1 test artifact available
Hi, I took a look at the source release and notice a couple of things from an ASF policy point of view: 1. The LICENSE file may or may not include a list of things that are bundled in the source release.The license seems to refer to 3rd party dependancies rather than what is actually included in the source release. The LICENSE file needs to list the licenses of what is bundled in the source release and not the dependancies. [1] 2. The license is missing the details of some bundled code e.g "Copyright (C) 2007 The Guava Authors" [3], "Copyright (C) 2008 The Android Open Source Project" [4], "Copyright 2005-2010 Roger Kapsi, Sam Berlin" [5] and this [7] 3. The source release contains compiled code (in the lib directory) 4. The license files mentions code under the Eclipse Public License. I assume this code is not included but is just a dependancy? (e.g. ecj-4.6.1, logback-classic-1.2.3, logback-core-1.2.3) [2] Although it does seem to be included as jars. A source release can't contain Category B code [2] 4. The NOTICE file seems to list copyright statements where it doesn't need to. [6] Only when a copyright statement has been relocated does it need to be placed in the NOTICE file. 5. These source files [8][9][10][11] are missing a header. I assume they are ASF licensed? Note it's entirely possible there some history here I'm not aware of and reason for some of the things above. Thanks, Justin 1. https://infra.apache.org/licensing-howto.html#guiding 2. https://apache.org/legal/resolved.html#category-b 3. ./apache-cassandra-4.0-rc1-src/src/java/org/apache/cassandra/index/sasi/utils/AbstractIterator.java 4. ./apache-cassandra-4.0-rc1-src/src/java/org/apache/cassandra/utils/LongTimSort.java 5. ./apache-cassandra-4.0-rc1-src/src/java/org/apache/cassandra/index/sasi/utils/trie/Cursor.java 6. https://infra.apache.org/licensing-howto.html#mod-notice 7. ./apache-cassandra-4.0-rc1-src/test/resources/tokenization/adventures_of_huckleberry_finn_mark_twain.txt 8. ./doc/source/_util/cql.py 9. ./ide/nbproject/update-netbeans-classpaths.sh 10. ./pylib/cassandra-cqlsh-tests.sh 11. ./tools/stress/src/org/apache/cassandra/stress/report/TimingIntervals.java - To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org For additional commands, e-mail: dev-h...@cassandra.apache.org
Re: Welcome Berenguer Blasi as Cassandra committer
Just adding more congratulations, Berenguer! Well-deserved! Lorina Poland e. lor...@datastax.com w. www.datastax.com On Fri, Mar 26, 2021 at 12:17 PM Yifan Cai wrote: > > Congratulations Berenguer! > > - Yifan > > > On Mar 26, 2021, at 11:49 AM, Sumanth Pasupuleti < > sumanth.pasupuleti...@gmail.com> wrote: > > > > Congratulations Berenguer! > > - > To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org > For additional commands, e-mail: dev-h...@cassandra.apache.org > >
Download source release / binary files in source release
Hi, I noticed the download page [1] contains links to convenience binaries but not to the actual release. I can see that the source is in the place on the mirrors but there's not an obvious link to it. When I did download the the 3.11.10 release [2], I can see that it contained compiled binary files (jars), which I don't think is in line with ASF release policy. Thanks, Justin 1. https://cassandra.apache.org/download/ 2. https://www.apache.org/dyn/closer.lua/cassandra/3.11.10/apache-cassandra-3.11.10-src.tar.gz - To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org For additional commands, e-mail: dev-h...@cassandra.apache.org
Re: [DISCUSSION] When should we branch 4.0 and unfreeze trunk?
(mostly reiterating) +1 to branching and unfreezing trunk, and to codifying the release cadence. Excited about the 4.0 rc! and looking forward to the roadmap discussion!! On Thu, Mar 25, 2021 at 8:18 AM Paulo Motta wrote: > > My thinking was talking about when to lift the freeze was moot if we > hadn't branched, and the agreed upon release lifecycle is pretty clear that > we don't branch until GA. Am I misunderstanding the relationship there? > > The proposal of this thread is to branch and lift the freeze before GA. > > I agree to this proposal but I'm suggesting we close and codify the release > cadence discussion from [1] before we lift the freeze, and maybe kick off > the roadmap discussion but we probably shouldn't block the unfreeze on > this. > > Looking back at the thread from [1] I saw that while we reached an > agreement on the release cadence, we haven't discussed how we plan to > ensure the quality of the releases moving forward, so we should also kick > off this discussion but also don't need to block branching on this. > > [1] - > > http://mail-archives.apache.org/mod_mbox/cassandra-dev/202101.mbox/%3ccabxe4tqrft9yn9tscd0jcs4qxe4vfeezqqtkbcw16d+3rgg...@mail.gmail.com%3e > > > Em qui., 25 de mar. de 2021 às 12:00, Joshua McKenzie < > jmcken...@apache.org> > escreveu: > > > > > > > be very practical and codify our existing agreements > > > discussed on the mentioned threads before lifting the freeze > > > > Ah. My thinking was talking about when to lift the freeze was moot if we > > hadn't branched, and the agreed upon release lifecycle is pretty clear > that > > we don't branch until GA. Am I misunderstanding the relationship there? > > > > On Thu, Mar 25, 2021 at 10:56 AM Paulo Motta > > wrote: > > > > > > That said, I think freezing feature contribution and not branching > > until > > > GA like we've newly done with 4.0 is bad for the health of the project > > > > > > +1. I think the freeze and branching until GA was atypical and unique > to > > > 4.0 and won't be repeated in the upcoming releases. I agree with > > Sumanth's > > > proposal on the release doc that branching should not be tied to a > > specific > > > release phase but decided independently by the community during the > > release > > > process (as it's being done now). > > > > > > > I think we should probably discuss the release process separately and > > > revise our agreements and process based on learnings from this release. > > > > > > Just to clarify: I'm not proposing we make a lengthy revision of the > > > release process, but be very practical and codify our existing > agreements > > > discussed on the mentioned threads before lifting the freeze and > discuss > > > any remaining concerns (just to ensure we will not leave this for later > > and > > > have clear expectations for the next release cycles). > > > > > > Em qui., 25 de mar. de 2021 às 11:10, Joshua McKenzie < > > > jmcken...@apache.org> > > > escreveu: > > > > > > > The current "Release Lifecycle" wiki doc speaks to when we branch: > > > > > > https://cwiki.apache.org/confluence/display/CASSANDRA/Release+Lifecycle > > > > > > > > Specifically under "General Availability (GA)": > > > > > > > >- A new branch is created for the release with the new major > > version, > > > >limiting any new feature addition to the new release branch, with > > new > > > >feature development will continue to happen only on trunk. > > > > > > > > > > > > That said, I think freezing feature contribution and not branching > > until > > > GA > > > > like we've newly done with 4.0 is bad for the health of the project. > > > Also, > > > > I don't think the project can survive another release cycle as long > and > > > as > > > > exclusionary as the 4.0 release has been (judging by declining > > > contribution > > > > volume, declining external ticket creation and interactions, and > > > db-engine > > > > indicators of popularity declining), so I think we should probably > > > discuss > > > > the release process separately and revise our agreements and process > > > based > > > > on learnings from this release. > > > > > > > > Just my .02 though as I'm no longer actively involved. > > > > > > > > On Thu, Mar 25, 2021 at 9:15 AM Paulo Motta < > pauloricard...@gmail.com> > > > > wrote: > > > > > > > > > I agree we should start considering branching 4.0 and unfreezing > > soon, > > > > but > > > > > before I think we should: > > > > > - Close the loop on the agreed points of the "releases after 4.0" > [1] > > > and > > > > > "project roadmap" [2] threads and document the new release > guidelines > > > > > post-4.0 so we have a good starting point. > > > > > - Revisit the previous discussions on unfreezing 4.0 and address > any > > > > > remaining concerns that may still be open. > > > > > > > > > > Looking forward to this exciting milestone! > > > > > > > > > > [1] - > > > > > > > > > > > > > > > > > > > > http://mail-archives.apache.org/mod_mbox/cassandra-dev/202101.mbox/%3cc
Re: Download source release / binary files in source release
> When I did download the the 3.11.10 release [2], I can see that it contained > compiled binary files (jars), which I don't think is in line with ASF release > policy. Could you clarify why you think this is incompatible with ASF policy? AFAICT the policy only stipulates that binary releases _will_ contain dependencies in binary form, and that releases _will not_ contain (Category B) dependencies in source code form. I cannot find any stipulation that source releases must not contain binary forms of dependencies, but I may be missing it. On 26/03/2021, 23:48, "Justin Mclean" wrote: Hi, I noticed the download page [1] contains links to convenience binaries but not to the actual release. I can see that the source is in the place on the mirrors but there's not an obvious link to it. When I did download the the 3.11.10 release [2], I can see that it contained compiled binary files (jars), which I don't think is in line with ASF release policy. Thanks, Justin 1. https://cassandra.apache.org/download/ 2. https://www.apache.org/dyn/closer.lua/cassandra/3.11.10/apache-cassandra-3.11.10-src.tar.gz - 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: Download source release / binary files in source release
Hi, > Could you clarify why you think this is incompatible with ASF policy? Because a source release could not contain compiled code (category A or otherwise), if it does then it not open source. See for instance [1]. This is why tools like Apache Rat look for certain types of binary files in release artefacts. This has also come up before a number of times e.g. including the gradle jar in a source release e.g [2] Thanks, Justin 1. http://www.apache.org/legal/release-policy.html#artifacts 2. https://issues.apache.org/jira/browse/LEGAL-288 - 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
To quote Niclas in the legal thread: The notion that these jars are "not open source" and must therefor not be used in the way they are intended is a preposterous stance This seems to genuinely be against policy in a way that is profoundly frustrating: the source of the project is available, the dependencies are included compiled, forcing those to be stripped is just ridiculous. > On Mar 26, 2021, at 6:59 PM, Justin Mclean wrote: > > Hi, > >> Could you clarify why you think this is incompatible with ASF policy? > > Because a source release could not contain compiled code (category A or > otherwise), if it does then it not open source. See for instance [1]. This is > why tools like Apache Rat look for certain types of binary files in release > artefacts. > > This has also come up before a number of times e.g. including the gradle jar > in a source release e.g [2] > > Thanks, > Justin > > 1. http://www.apache.org/legal/release-policy.html#artifacts > 2. https://issues.apache.org/jira/browse/LEGAL-288 > > - > 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
HI, > The notion that these jars are "not open source" and must therefor not be > used in the way they are intended is a preposterous stance I suggest you read the whole thread. The outcome was that it's OK to put jars in version control but not in a source release. This has been discussed several times on the incubator list and elsewhere. What most projects do is provide a script that a user can run to download the needed bits. I recall Roy having something to say it a while ago: https://lists.apache.org/thread.html/0d6952401efbd72efbeafc86ebabbf7267f6c9d2d59f32dd93b7d4db%401332868587%40%3Cgeneral.incubator.apache.org%3E Thanks, Justin - To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org For additional commands, e-mail: dev-h...@cassandra.apache.org