It came to my attention on IRC a week or so ago, and following up on the
ticket that someone asked if they should commit to 2.1, that developers
have been actively ignoring the 2.1 branch. If we're not committing
critical fixes there, even when we know they exist, I think it's time to
just call it
No problem, thanks for asking :)
Michael
On 1/7/19 6:20 PM, Jonathan Haddad wrote:
> It's been 5 months and 30+ bug fixes to each branch.
>
> Here's the two changelogs:
>
> https://github.com/apache/cassandra/blob/cassandra-3.0/CHANGES.txt
>
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,
It's been 5 months and 30+ bug fixes to each branch.
Here's the two changelogs:
https://github.com/apache/cassandra/blob/cassandra-3.0/CHANGES.txt
https://github.com/apache/cassandra/blob/cassandra-3.11/CHANGES.txt
How's everyone feel about getting a release out this week / early next
week?
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
This is fantastic!! Thanks a bunch for the effort on this, folks.
On Mon, Jan 7, 2019 at 4:31 PM Mick Semb Wever wrote:
>
>
> > Next step it to regenerate the docs for Cassandra-4.0 (latest). I'll do
> > this next week if no one objects.
>
>
> This has been done by Joey Lynch, Anthony Grasso and
And when should it get updated?
Currently our KEYS file: that contains the public keys of those that can signed
released binary artifacts; only contains a few of the PMC. My understanding is
that we've avoid updating it because it causes headache for operators in having
to validate the
15 matches
Mail list logo
