Re: Calling for release managers (Committers and PMC)
Me too. > On 11 May 2020, at 20:23, Jake Luciani wrote: > > Happy to lend a hand > > On Mon, May 11, 2020 at 3:12 PM Eric Evans > wrote: > >> I can take a turn. >> >> On Fri, May 8, 2020 at 11:10 AM Vinay Chella >> wrote: >>> >>> I would like to help as well. >>> >>> >>> On Fri, May 8, 2020 at 8:54 AM Chris Lohfink >> wrote: >>> I'd like to get involved in this as well. On Thu, May 7, 2020 at 2:06 PM Jon Meredith >> wrote: > Sign me up. > > On Thu, May 7, 2020 at 12:36 PM Robert Stupp wrote: >> >> I can help >> >> -- >> Robert Stupp >> @snazy >> >>> Am 07.05.2020 um 20:29 schrieb Mick Semb Wever : >>> >>> The Cassandra release process has had some improvements to >> better in >>> line with the ASF guidelines: sha256 & sha512 checksums, staged >>> artefacts in svnpubsub, dep and rpm repositories complete and >> signed >>> in staging, and separate scripts and manual steps merged >> together. >>> >>> The updated documentation for cutting, voting, and publishing a >>> release is found here: >>> > >> https://cassandra.apache.org/doc/latest/development/release_process.html >>> >>> I am hoping to get as many Committers* and PMC members >> interested as >>> possible for cutting a future release. >>> >>> Who is interested? How many names can I get :-) >>> >>> The more that are interested then the easier it is to take turns >> and >>> be flexible depending on our own availability each time. I will >> help >>> out everyone on their first run. Indeed most of my motivation in >>> getting involved with the release process was to make it all as simple >>> and as forgettable as possible, so the role of the role manager >> can >>> change easily from release to release. >>> >>> *When a Committer cuts a release, a PMC member has to perform the very >>> last post-vote publish step. >>> >>> regards, >>> Mick >>> >>> >> - >>> 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 > > >>> -- >>> >>> Thanks, >>> Vinay Chella >> >> >> >> -- >> Eric Evans >> john.eric.ev...@gmail.com >> >> - >> 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: [discussion]Completing CEP-2
Thanks for raising this Patrick. The CEP concept is still new and it was intentional that it would evolve more as CEPs came in. I've got some feedback and questions inline. > Last week in our Cassandra Kubernetes SIG it was clear that we are coming > up on the completion of the specifications for CEP-2. The path we on look > something like this: > > - Agree to the overall specifications for a Cassandra Kubernetes Operator > with as much details as possible on the required features. > - One or more groups donating code as an initial commit. > - Jira and commit activity on common Cassandra Kubernetes operator. > > The two main questions that have come up as a result: > > 1. What constitutes a completed CEP? Is this something the PMC votes on or > how does this get approved as a part of the project My understanding so far is that a CEP shall have a lifecycle something like: draft -> raised -> discussion -> proposed -> accepted - > implementing -> done And it sounds like you are closing in the draft phase and raising it for further discussion? (Though there's some overlap between "draft -> raised" and "discussion -> proposed", hopefully that ambiguity is less of a concern when the lifecycle is seen as flexible and re-iterative, i.e. not waterfall.) Part of the CEP's proposal should be (imho)… - what groups are going to donate what code, - what is the initial scope and goal, - how those donated code bases are going to go through the IP Clearance process, - list of people that are: authors, have been involved, and/or identified as stakeholders. Again this is but my opinion, but the current proposal of "A new repository as a sub-project for Apache Cassandra specifically for a Kubernetes Operator" is too thin/ambiguous (despite all the great work that's been done behind it). If making the proposal something more concrete is difficult, maybe it would be better to include a prototype (or initial codebase) as part of CEP-2, giving folk something more concrete, and some proven code collaboration, to vote on and accept. So… Is the plan that separate codebases will be cleared and donated, and then within a Cassandra sub-project merged together? Or shall these multiple projects be worked on outside of the project, and form part of the CEP's proposal and then be cleared and donated? Can/Should the "Cassandra Kubernetes Operator SIG" confluence doc be a subpage to the CEP-2 page? And can we also get a brief agenda and summary of the meetings? (Recorded meetings lack searchability or easy referencing.) > 1. What constitutes a completed CEP? Is this something the PMC votes on or > how does this get approved as a part of the project Good question. To date the CEP requires a [DISCUSS] ML thread (on the finish defined proposal) and then a [VOTE] ML thread. Consensus is required on the vote. > 2. What are the procedures for code donation at this scale? It's likely > that more than one group will be participating with a large amount of code. Code donations need to go through the Incubator's IP Clearance process. https://incubator.apache.org/ip-clearance/ cheers, Mick - To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org For additional commands, e-mail: dev-h...@cassandra.apache.org
Re: Calling for release managers (Committers and PMC)
Please add me as well. > On 12 May 2020, at 09:51, Sam Tunnicliffe wrote: > > Me too. > >> On 11 May 2020, at 20:23, Jake Luciani wrote: >> >> Happy to lend a hand >> >> On Mon, May 11, 2020 at 3:12 PM Eric Evans >> wrote: >> >>> I can take a turn. >>> >>> On Fri, May 8, 2020 at 11:10 AM Vinay Chella >>> wrote: I would like to help as well. On Fri, May 8, 2020 at 8:54 AM Chris Lohfink >>> wrote: > I'd like to get involved in this as well. > > On Thu, May 7, 2020 at 2:06 PM Jon Meredith >>> wrote: > >> Sign me up. >> >> On Thu, May 7, 2020 at 12:36 PM Robert Stupp wrote: >>> >>> I can help >>> >>> -- >>> Robert Stupp >>> @snazy >>> Am 07.05.2020 um 20:29 schrieb Mick Semb Wever : The Cassandra release process has had some improvements to >>> better in line with the ASF guidelines: sha256 & sha512 checksums, staged artefacts in svnpubsub, dep and rpm repositories complete and >>> signed in staging, and separate scripts and manual steps merged >>> together. The updated documentation for cutting, voting, and publishing a release is found here: >> >>> https://cassandra.apache.org/doc/latest/development/release_process.html I am hoping to get as many Committers* and PMC members >>> interested as possible for cutting a future release. Who is interested? How many names can I get :-) The more that are interested then the easier it is to take turns >>> and be flexible depending on our own availability each time. I will >>> help out everyone on their first run. Indeed most of my motivation in getting involved with the release process was to make it all as > simple and as forgettable as possible, so the role of the role manager >>> can change easily from release to release. *When a Committer cuts a release, a PMC member has to perform the > very last post-vote publish step. regards, Mick >>> - 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 >> >> > -- Thanks, Vinay Chella >>> >>> >>> >>> -- >>> Eric Evans >>> john.eric.ev...@gmail.com >>> >>> - >>> 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
Re: Calling for release managers (Committers and PMC)
Thanks everyone! I've created a confluence page for the onboarding process. https://cwiki.apache.org/confluence/display/CASSANDRA/Release+Managers+Onboarding There's some prerequisites there for people to read and follow up on in their own time. Provide feedback and ask questions as needed. On Tue, 12 May 2020 at 14:10, Aleksey Yeshchenko wrote: > > Please add me as well. > > > On 12 May 2020, at 09:51, Sam Tunnicliffe wrote: > > > > Me too. > > > >> On 11 May 2020, at 20:23, Jake Luciani wrote: > >> > >> Happy to lend a hand > >> > >> On Mon, May 11, 2020 at 3:12 PM Eric Evans > >> wrote: > >> > >>> I can take a turn. > >>> > >>> On Fri, May 8, 2020 at 11:10 AM Vinay Chella > >>> wrote: > > I would like to help as well. > > > On Fri, May 8, 2020 at 8:54 AM Chris Lohfink > >>> wrote: > > > I'd like to get involved in this as well. > > > > On Thu, May 7, 2020 at 2:06 PM Jon Meredith > >>> wrote: > > > >> Sign me up. > >> > >> On Thu, May 7, 2020 at 12:36 PM Robert Stupp wrote: > >>> > >>> I can help > >>> > >>> -- > >>> Robert Stupp > >>> @snazy > >>> > Am 07.05.2020 um 20:29 schrieb Mick Semb Wever : > > The Cassandra release process has had some improvements to > >>> better in > line with the ASF guidelines: sha256 & sha512 checksums, staged > artefacts in svnpubsub, dep and rpm repositories complete and > >>> signed > in staging, and separate scripts and manual steps merged > >>> together. > > The updated documentation for cutting, voting, and publishing a > release is found here: > > >> > >>> https://cassandra.apache.org/doc/latest/development/release_process.html > > I am hoping to get as many Committers* and PMC members > >>> interested as > possible for cutting a future release. > > Who is interested? How many names can I get :-) > > The more that are interested then the easier it is to take turns > >>> and > be flexible depending on our own availability each time. I will > >>> help > out everyone on their first run. Indeed most of my motivation in > getting involved with the release process was to make it all as > > simple > and as forgettable as possible, so the role of the role manager > >>> can > change easily from release to release. > > *When a Committer cuts a release, a PMC member has to perform the > > very > last post-vote publish step. > - To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org For additional commands, e-mail: dev-h...@cassandra.apache.org
4.0 Ticket Review and 20200512 Status Update
Hi Everyone, This week's status update is below but we (Josh, Jon M, and myself) thought it was important for us all to take a closer look at which parts of the release cycle we've assigned different tickets to so we can get a better idea of how close we truly are to releasing beta1 and what work is left between then and rc/ga. With the release lifecycle document ( https://cwiki.apache.org/confluence/display/CASSANDRA/Release+Lifecycle) the community agreed upon previously in mind, we looked at all outstanding tickets. In many cases, tickets were already assigned to where we would have expected them to be based on that document and the ticket's perceived severity. In a few cases, tickets' assigned stage in the cycle was different from what the document outlined. In cases where we felt it was obvious we have reached out to those involved and updated it accordingly. Those tickets fell primarily into these categories: * Client API / Configuration / Other user interfaces - As a user interfaces, these should be stabilized before the end of the alpha stage * Testing Epic - should be completed by the end of the beta stage * Changes in RC - We shouldn't be making substantial changes in a Release Candidate but documentation, etc is ok in this stage in the cycle. Of the remaining tickets, some we felt were important for the community to discuss on a case by case basis as we have with other larger changes in the past. In particular, as we look at these, we think it is important for the community to think about whether or not we should block the 4.0 release on them or if they would be well suited to a subsequent release. One that we feel confident will have a shorter cycle than 4.0. Please look through them, especially if you are involved in one. We encourage all discussion to happen outside this thread: either in JIRA or in a separate [DISCUSS] thread on the mailing list. Questions I found helpful while reviewing myself: 1) Would you block the release over this ticket? 2) Would you prioritize this ticket over testing? 3) Does fixing this ticket make 4.0 a more stable release? Transient Replication: - https://issues.apache.org/jira/browse/CASSANDRA-15670: Transient Replication: unable to insert data when the keyspace is configured with the SimpleStrategy - https://issues.apache.org/jira/browse/CASSANDRA-14697: Transient Replication 4.0 pre-release followup work - https://issues.apache.org/jira/browse/CASSANDRA-14404: Transient Replication & Cheap Quorums: Decouple storage requirements from consensus group size using incremental repair Repair & Streaming: - https://issues.apache.org/jira/browse/CASSANDRA-15665: StreamManager should clearly differentiate between "initiator" and "receiver" sessions - https://issues.apache.org/jira/browse/CASSANDRA-14939: fix some operational holes in incremental repair - https://issues.apache.org/jira/browse/CASSANDRA-15406: Add command to show the progress of data streaming and index build Indexing: - https://issues.apache.org/jira/browse/CASSANDRA-15533: Don't allocate unneeded MergeIterator in OnDiskToken#iterator - https://issues.apache.org/jira/browse/CASSANDRA-13606: Improve handling of 2i initialization failures Test Tooling: - https://issues.apache.org/jira/browse/CASSANDRA-15624: Avoid lazy initializing shut down instances when trying to send them messages Other Features / Improvements: - https://issues.apache.org/jira/browse/CASSANDRA-15241: Virtual table to expose current running queries - https://issues.apache.org/jira/browse/CASSANDRA-15211: Remove BaseIterator.stopChild - https://issues.apache.org/jira/browse/CASSANDRA-14793: Improve system table handling when losing a disk when using JBOD - https://issues.apache.org/jira/browse/CASSANDRA-14694: add latency sample for speculative read repair writes - https://issues.apache.org/jira/browse/CASSANDRA-14361: Allow SimpleSeedProvider to resolve multiple IPs per DNS name - https://issues.apache.org/jira/browse/CASSANDRA-13994: Remove COMPACT STORAGE internals before 4.0 release - https://issues.apache.org/jira/browse/CASSANDRA-2848: Make the Client API support passing down timeouts (This one has been discussed before but given its current status and being interface related it could block a beta1 release) Ok, on with the regular status update: [Board] https://issues.apache.org/jira/secure/RapidBoard.jspa?rapidView=355 [Tickets that Need Attention] https://issues.apache.org/jira/secure/RapidBoard.jspa?rapidView=355&projectKey=CASSANDRA&quickFilter=1723&quickFilter=1719 There are 6 tickets in alpha that need attention and 18 in beta. The alpha tickets are either flaky tests or configuration changes. The beta tickets are primarily grouped into test plans and known bugs. [Needs Reviewer] https://issues.apache.org/jira/secure/RapidBoard.jspa?rapidView=355&projectKey=CASSANDRA&quickFilter=1661&quickFilter=1659 3 tickets are looking for reviewers, although only one is not related to Transient Replication. [Alpha Status]
