Sorry, I forgot to include the most important feature for potentially using bintray deb/rpm repos, signed by the bintray key:
- New gpg keys could be added to KEYS for interested new release managers, and releases could be done by those interested new Cassandra release managers, requiring only one key change for deb/rpm repository users. Michael On 1/9/19 11:13 AM, Michael Shuler wrote: > For Debian, Fedora, etc. to package Cassandra at the OS level, first all > dependencies (and deps of deps) must be packaged and uploaded, so they > can be depended on by Cassandra. This means Hadoop. It has been > attempted and abandoned by multiple people, myself included. > > A little digging on one example Apache project hosting deb/rpm repos at > bintray, Apache Ignite, there are multiple repo problems that can be > solved by the tickets I listed below. > > Details: > https://issues.apache.org/jira/browse/CASSANDRA-14968?focusedCommentId=16738342&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-16738342 > > tl;dr: > - I think we can use the bintray key to sign the repos, there's precedent > - using bintray to build the deb/rpm repos, all version in each suite > (22x, 30x, ..) will be installable, instead of just the latest version > > Michael > > On 1/9/19 8:06 AM, Stefan Podkowinski wrote: >> If creating native deb/rpm package signatures and repo metadata >> signatures is the only issue that stops us from releasing more often and >> sharing the burden in doing so, then I'd be happy to discuss dropping >> this altogether. We can always distribute binary packages along with >> checksums and a detached gpg signature by any KEYS person, just as we do >> with the tarballs. >> >> Having an Apache hosted Cassandra yum/deb repo may be convenient, but I >> wonder how many users will still download the packages and host them in >> their own internal repo. Even if it's just to have the option to pin the >> package to a specific version, which we currently don't offer, as only >> the latest package is included in the repo metadata. It might also >> encourage distros to keep downstream repos updated as well, since that >> would be the ideal way of creating and distributing package, i.e. having >> a Debian/Fedora/Ubuntu maintainer taking care of that and only have >> users come back to us for the vanilla rpm in case their downstream >> version is outdated. >> >> >> On 08.01.19 02:48, Michael Shuler wrote: >>> Yeah, I asked if someone made a request thinking I totally missed it! >>> Since the last couple tick-tock releases, which were time based, every >>> release has been initiated by someone commenting in IRC or dev@ that >>> "there are a lot of things in CHANGES.txt" or "important fix foo has >>> been committed, let's release". It looks like the interval on releases >>> has been about 4-6 months, so we're due :) >>> >>> More packaging / GPG key tickets, if someone wants to take them on: >>> https://issues.apache.org/jira/browse/CASSANDRA-14966 >>> https://issues.apache.org/jira/browse/CASSANDRA-14967 >>> https://issues.apache.org/jira/browse/CASSANDRA-14968 >>> >>> I see other Debian and RPM type repositories configured in the Apache >>> bintray project, so perhaps signing of the package repositories can be >>> done using their signing feature(?). >>> >>> I just really wish to cause users installation/upgrade difficulty as >>> little as possible. If we're going to change up to something that allows >>> more people to do maven and tarball releases, great, I don't care, since >>> there's no tar-install-client that cares. I absolutely don't want >>> deb/rpm package repository users to constantly need to update GPG keys >>> every release, that's not nice to our users. If there is a way to get >>> the repos set up correctly in bintray, and it's OK with INFRA to use the >>> bintray key signing feature, great. We should set up a new package >>> signing key and configure bintray to sign the metadata. One change for a >>> long-term solution. >>> >>> Michael >>> >>> On 1/7/19 4:34 PM, Jeff Jirsa wrote: >>>> I dont think it's awkward, I think a lot of us know there are serious >>>> bugs >>>> and we need a release, but we keep finding other bugs and it's super >>>> tempting to say "one more fix" >>>> >>>> We should probably just cut next 3.0.x and 3.11.x though, because >>>> there are >>>> some nasty bugs hiding in there that the testing for 4.0 has uncovered. >>>> >>>> >>>> On Mon, Jan 7, 2019 at 2:14 PM Jonathan Haddad <j...@jonhaddad.com> >>>> wrote: >>>> >>>>>> I don't understand how adding keys changes release frequency. Did >>>>> someone request a release to be made or are we on some assumed date >>>>> interval? >>>>> >>>>> I don't know if it would (especially by itself), I just know that if >>>>> more >>>>> people are able to do releases that's more opportunity to do so. >>>>> >>>>> I think getting more folks involved in the release process is a good >>>>> idea >>>>> for other reasons. People take vacations, there's job conflicts, >>>>> there's >>>>> life stuff (kids usually take priority), etc. >>>>> >>>>> The last release of 3.11 was almost half a year ago, and there's 30+ >>>>> bug >>>>> fixes in the 3.11 branch. >>>>> >>>>>> Did someone request a release to be made or are we on some assumed >>>>>> date >>>>> interval? >>>>> >>>>> I can't recall (and a search didn't find) anyone asking for a 3.11.4 >>>>> release, but I think part of the point is that requesting a release >>>>> from a >>>>> static release manager is a sign of a flaw in the release process. >>>>> >>>>> On a human, note, it feels a little awkward asking for a release. I >>>>> might >>>>> be alone on this though. >>>>> >>>>> Jon >>>>> >>>>> >>>>> On Mon, Jan 7, 2019 at 1:16 PM Michael Shuler <mich...@pbandjelly.org> >>>>> wrote: >>>>> >>>>>> Mick and I have discussed this previously, but I don't recall if it >>>>>> was >>>>>> email or irc. Apologies if I was unable to describe the problem to a >>>>>> point of general understanding. >>>>>> >>>>>> To reiterate the problem, changing gpg signature keys screws our >>>>>> debian >>>>>> and redhat package repositories for all users. Tarballs are not >>>>>> installed with a client that checks signatures in a known trust >>>>>> database. When gpg key signer changes, users need to modify their >>>>>> trust >>>>>> on every node, importing new key(s), in order for packages to >>>>>> install/upgrade with apt or yum. >>>>>> >>>>>> I don't understand how adding keys changes release frequency. Did >>>>>> someone request a release to be made or are we on some assumed date >>>>>> interval? >>>>>> >>>>>> Michael >>>>>> >>>>>> On 1/7/19 2:30 PM, Jonathan Haddad wrote: >>>>>>> That's a good point. Looking at the ASF docs I had assumed the >>>>>>> release >>>>>>> manager was per-project, but on closer inspection it appears to be >>>>>>> per-release. You're right, it does say that it can be any committer. >>>>>>> >>>>>>> http://www.apache.org/dev/release-publishing.html#release_manager >>>>>>> >>>>>>> We definitely need more frequent releases, if this is the first step >>>>>>> towards that goal, I think it's worth it. >>>>>>> >>>>>>> Glad you brought this up! >>>>>>> Jon >>>>>>> >>>>>>> >>>>>>> On Mon, Jan 7, 2019 at 11:58 AM Mick Semb Wever <m...@apache.org> >>>>> wrote: >>>>>>>> >>>>>>>>> I don't see any reason to have any keys in there, except from >>>>>>>>> release >>>>>>>>> managers who are signing releases. >>>>>>>> >>>>>>>> Shouldn't any PMC (or committer) should be able to be a release >>>>> manager? >>>>>>>> The release process should be reliable and reproducible enough to be >>>>>> safe >>>>>>>> for rotating release managers every release. I would have thought >>>>>> security >>>>>>>> concerns were better addressed by a more tested process? And >>>>>>>> AFAIK no >>>>>> other >>>>>>>> asf projects are as restrictive on who can be the release manager >>>>>>>> role >>>>>> (but >>>>>>>> i've only checked a few projects). >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> --------------------------------------------------------------------- >>>>>>>> >>>>>>>> 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 >>>>>> >>>>>> >>>>> -- >>>>> Jon Haddad >>>>> http://www.rustyrazorblade.com >>>>> twitter: rustyrazorblade >>>>> >>> >>> --------------------------------------------------------------------- >>> 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 >> > --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org For additional commands, e-mail: dev-h...@cassandra.apache.org
