Re: [PROPOSAL] Moving deb/rpm repositories from downloads.apache.org to apache.jfrog.io

> 3. ASF Infra is requesting we remove the rpm/deb files from downloads.a.o > asap. > To be accurate: ASF Infra is requiring that we fix by (extra superfluous) signing and re-voting on all past rpm/deb rpm/deb files, OR remove them from downloads.a.o, asap. Resigning and re-voting all rpm/deb pa

Re: [PROPOSAL] Moving deb/rpm repositories from downloads.apache.org to apache.jfrog.io

I see. In that case, stick to the original plan makes more sense. On 11/08/2022 22:46, Mick Semb Wever wrote: We should have the new domain/URL created before the final move is made, and redirecting to the existing download.apache.org for the time be

Re: [PROPOSAL] Moving deb/rpm repositories from downloads.apache.org to apache.jfrog.io

> > We should have the new domain/URL created before the final move is made, > and redirecting to the existing download.apache.org for the time being. > This will ensure users can have a transition time and avoid causing a > cliff edge moment. > Good idea, but in this situation it would only comp

Re: [PROPOSAL] Moving deb/rpm repositories from downloads.apache.org to apache.jfrog.io

I see. Now I fully understand the change. There's no objections from me, everything sounds fine. We should have the new domain/URL created before the final move is made, and redirecting to the existing download.apache.org for the time being. This will ensure users can have a transition time an

Re: [PROPOSAL] Moving deb/rpm repositories from downloads.apache.org to apache.jfrog.io

Nothing is changing in regard to signing. Both package management systems have their own system for that which will remain. The package locations are being moved because downloads.apache.org wants another level of (superfluous) signing on top of that, which we do not currently have. Kind Regards

Re: [PROPOSAL] Moving deb/rpm repositories from downloads.apache.org to apache.jfrog.io

The signing of the rpm/deb packages (and their repos) will not change. Only the URL to the rpm/deb repo changes. All files (checksums and signatures) otherwise remain identical. On Thu, 11 Aug 2022 at 23:20, Bowen Song via dev wrote: > In that case, the move from signed RPM/DEB to unsigned can

Re: [PROPOSAL] Moving deb/rpm repositories from downloads.apache.org to apache.jfrog.io

In that case, the move from signed RPM/DEB to unsigned can be quiet problematic to some enterprise users. On 11/08/2022 22:16, Jeremiah D Jordan wrote: For ASF project the binary release are always considered as “convenience binaries”, the official release is always just the source artifacts.

Re: [PROPOSAL] Moving deb/rpm repositories from downloads.apache.org to apache.jfrog.io

For ASF project the binary release are always considered as “convenience binaries”, the official release is always just the source artifacts. See the ASF release policy for more information. https://www.apache.org/legal/release-policy.html#compiled-packages

Re: [PROPOSAL] Moving deb/rpm repositories from downloads.apache.org to apache.jfrog.io

I'm a bit unclear what's the scope of this change. Is it limited to the "*-bin.tar.gz" files only? I would assume the RPM/DEB packages are considered as parts of the "official releases", and aren't affected by this change. Am I right? On 11/08/2022 21:59, Mick Semb Wever wrote: > /Thes

Re: [PROPOSAL] Moving deb/rpm repositories from downloads.apache.org to apache.jfrog.io

> > *These repositories and their binaries are "convenience binaries" and > not the official Cassandra source binaries* > > Then where are the official binaries? > Wrong wording there., thanks for catching me. The official *releases* are the source artefacts, e.g. the *-src.tar.gz in https://down

Re: [PROPOSAL] Moving deb/rpm repositories from downloads.apache.org to apache.jfrog.io

> /These repositories and their binaries are "convenience binaries" and not the official Cassandra source binaries/ Then where are the official binaries? On 11/08/2022 21:40, Mick Semb Wever wrote: The proposal is to move our official debian and redhat repositories from downloads.apache.org

[PROPOSAL] Moving deb/rpm repositories from downloads.apache.org to apache.jfrog.io

The proposal is to move our official debian and redhat repositories from downloads.apache.org to Apache's JFrog Artifactory server at apache.jfrog.io , fronting it with the url aliases debian.cassandra.apache.org and redhat.cassandra.apache.org That is to replace the following URLs from https://do

Re: CEP-15 multi key transaction syntax

...and one more option... 5.) Introduce tuple assignments, removing all ambiguity around row vs. column operations. BEGIN TRANSACTION LET row1 = * FROM ks.tbl WHERE k=0 AND c=0; <-- * selects all columns LET row2 = (v) FROM ks.tbl WHERE k=1 AND c=0; SELECT row1.v, row2.v IF row1 IS NULL A

Re: CEP-15 multi key transaction syntax

via Benedict, here is a 4th option: 4.) Similar to #2, but don't rely on the key element being NULL. If the read returns no result, x effectively becomes NULL. Otherwise, it remains true/NOT NULL. BEGIN TRANSACTION LET x = true FROM ks.tbl WHERE k=0 AND c=0; LET row2_v = v FROM ks.tbl WHERE

Re: CEP-15 multi key transaction syntax

Hello again everyone! I've been working on a prototype in CASSANDRA-17719 for a grammar that roughly corresponds to what we've agreed on in this thread. One thing that isn't immediately obvious to me is how the LET syntax handles cases where

Re: Cassandra project status update 2022-08-03

> > > I think if we want to do this, it should be extremely easy - by which I > mean automatic, really. This shouldn’t be too tricky I think? We just need > to produce a diff of new test classes and methods within existing classes. Having a CircleCI job that automatically runs all new/modified te

Re: [DISCUSS] Remove Dead Pull Requests

 Perhaps we just restrict “trivial” patches to trunk? If it requires several PRs/branches then a Jira is perhaps warranted, and perhaps if it is trivial and unimportant it’s better not to waste the project’s time managing the overhead. This would also be simplified with a modified merge strateg

Re: [DISCUSS] Remove Dead Pull Requests

I agree the amount of work is somewhat overwhelming for the proposed change, but I was referring to the lack of a Jira ticket blocking the pull request. At least that is how it looks to the new observer. Perhaps we should add a "trivial change" label for requests that do not have a ticket and are

Re: [DISCUSS] Remove Dead Pull Requests

> > Is there an objection to accepting "typo" corrections without a ticket? > One problem to be aware of is that those pull requests need to be converted in patches and merged manually up to trunk if they were done on older branches. So it might not look like it at first but it can be quite time c

Re: [DISCUSS] Remove Dead Pull Requests

Those all seem like good suggestions to me > On 11 Aug 2022, at 08:44, Claude Warren, Jr via dev > wrote: > >  > My original goal was to reduce the number of pull requests in the backlog as > it appears, from the outside, that the project does not really care for > outside contributions when

Re: [DISCUSS] Remove Dead Pull Requests

My original goal was to reduce the number of pull requests in the backlog as it appears, from the outside, that the project does not really care for outside contributions when there are over 200 pull requests pending and many of them multiple years old. I guess that is an optics issue. Upon looki