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
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
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
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,
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
> 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
Also, in case someone brings it up, there's an ongoing relevant
discussion on the builds@a.o list on automating releases, which includes
lots of good thoughts on the topic.
https://lists.apache.org/thread.html/af4b2a5d73fde5ab76a376549f645404da7865a8b002145435b2359c@%3Cbuilds.apache.org%3E
To-do items that might further the goal of getting more people involved
in releases, here are a couple tickets on this:
https://issues.apache.org/jira/browse/CASSANDRA-14962
https://issues.apache.org/jira/browse/CASSANDRA-14963
#14962 is really a "we're doing it wrong" ticket on release
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.
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
> 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
I agree with Stefan, if someone isn't a release manager there's no reason
to add them, and it just increases the surface area for potential attack or
issue.
On Mon, Jan 7, 2019 at 11:35 AM Stefan Podkowinski wrote:
> I don't see any reason to have any keys in there, except from release
>
I don't see any reason to have any keys in there, except from release
managers who are signing releases. Additional keys from other developers
may even harm security, by creating more opportunities for compromising
keys.
On 07.01.19 11:29, Mick Semb Wever wrote:
And when should it get
13 matches
Mail list logo
