Re: Clarifying CI release criteria

2022-01-04 Thread Joshua McKenzie
Here's a link to a draft article for the confluence wiki covering what we discussed on this thread: https://cwiki.apache.org/confluence/pages/resumedraft.action?draftId=199530280=7c72c252-918c-456b-9859-7d12e8fa9309; Assuming this article accurately captures what we discussed here as well as

Re: [DISCUSS] Releasable trunk and quality

2022-01-04 Thread Joshua McKenzie
I put together a draft confluence wiki page (login required) for the Build Lead role covering what we discussed in the thread here. Link: https://cwiki.apache.org/confluence/pages/resumedraft.action?draftId=199527692=96dfa1ef-d927-427a-bff8-0cf711c790c9; The only potentially controversial thing

Re: [DISCUSS] Releasable trunk and quality

2022-01-04 Thread bened...@apache.org
That all sounds terribly complicated to me. My view is that we should switch to the branch strategy outlined by Henrik (I happen to prefer it anyway) and move to GitHub integrations to control merge for each branch independently. Simples. From: David Capwell Date: Tuesday, 4 January 2022 at

Re: Clarifying CI release criteria

2022-01-04 Thread Ekaterina Dimitrova
Hey Josh, Thank you for leading these discussions and organizing the wiki pages (also from the other mail). I just wanted to mention about point 4 of Pending work - I have a draft version for CircleCI usage, also Andres has updated the rst documents around running tests in a loop, etc. BUT those

Re: [DISCUSS] Releasable trunk and quality

2022-01-04 Thread David Capwell
> The more I think on it, the more I am anyway strongly -1 on having some > bifurcated commit process. We should decide on a uniform commit process for > the whole project, for all patches, whatever that may be. Making the process stable and handle all the random things we need to handle takes

Re: [DISCUSS] Releasable trunk and quality

2022-01-04 Thread bened...@apache.org
To answer your point, I don’t have anything ideologically against a temporary divergence in treatment, but we should have a clear unified endpoint we are aiming for. I would hate for this discussion to end without a clear answer about what that endpoint should be, though - even if we don’t get

Re: Cassandra project biweekly status update 2022-01-03

2022-01-04 Thread Joshua McKenzie
I'll follow up with Chris on slack about this. He and I are looking into a couple other updates to the site as well so this should complement that workflow nicely. On Tue, Jan 4, 2022 at 10:27 AM Melissa Logan wrote: > Josh, shall we add these details to the monthly Changelog blog that Chris >

Re: Cassandra project biweekly status update 2022-01-03

2022-01-04 Thread Joshua McKenzie
> > Could we post these on the blog as well I always wanted to be a blogger. Sounds like now's my chance. ;) In all seriousness I think this is a great idea. I'll find out what I need to know to make this happen and make it so. On Mon, Jan 3, 2022 at 7:38 PM Patrick McFadin wrote: > What

Re: Cassandra project biweekly status update 2022-01-03

2022-01-04 Thread Melissa Logan
Josh, shall we add these details to the monthly Changelog blog that Chris T drafts? He uses your recaps as a basis. Shared on the #cassandra-website channel. Example: https://cassandra.apache.org/_/blog/Apache-Cassandra-Changelog-10-October-2021.html On Tue, Jan 4, 2022 at 7:21 AM Joshua